| |
 |
Tuesday, June 25, 2002 |
|
XMethods uses SonicMQ for asynch version of XSpace
Tony Hong from XMethods is here, showing a nifty evolution of XSpace. It's currently a service that implements a simple shared address book. The concept is that of a tuplespace updated and queried by SOAP messages. The new twist, slated to become available July 15, is the use of SonicMQ, a JMS (Java Messaging Service) provider, to add reliability, security, and pub-sub notification services to the message flow.
The new service is done doc/literal style. A writer of the address book sends a XML document, which is the update, to the SonicMQ broker, and receives an acknowledgement. Separately, readers of the address book register with the broker for update notifications.
You'll be able to download Sonic's client software in order to interact with the service. As Tony points out, this is a great first step towards a broader appreciation of SOAP's one-way messaging. Alternatively, you'll be able to interact with the service over straight HTTP. In this scenario the services supplied by JMS will be either missing, or done differently. But the point is: the payload's the same either way, and can tap into evolving standards like WS-Security. Very cool stuff!
5:41:14 PM 
|
|
|
Monday, June 17, 2002 |
|
Is web services orchestration a new class of problem?
I agree with the RESTian argument that SOAP-accessible web services should support HTTP GET where appropriate. The notion is that this will help ensure low coordination costs both for person-to-machine as well as machine-to-machine communication.
In TAG Finding: URIs, Addressability, and the use of HTTP GET, Dan Connolly sums up the recommendation that resources be made URI-addressable where possible, and dispels two myths that have clouded the issue:
- Myth: Search services will not index anything with a "?" in the URI.
- This was a heuristic to avoid infinite loops in some search service crawlers, but it was not an architectural constraint, and modern search services use more sophisticated heuristics to avoid loops.
- Myth: URIs cannot be longer than 256 characters
- This was a limitation in some server implementations, and while servers continue to have limitations to prevent denial-of-service attacks, they are generally at least 4000 characters, and they evolve as the legitimate uses of application developers evolve.
-
How this relates to the orchestration of web services is still very unclear though. Consider this remark on the TAG mailing list, from Edwin Khodabakchian, CEO of Collaxa:
- we need to acknowledge the fact that we are solving a new class of problem that is more about machine-to-machine communication
Perhaps this really is a new class of problem, but if so I would like to see spelled out more clearly exactly how and why that is so, and what it implies.
11:47:56 AM
|
|
|
Thursday, May 16, 2002 |
|
Web services and the web ecosystem
Adam Bosworth gave a whirlwind tour of BEA's WebLogic Workshop. After the obligatory Hello World, he dived into the good stuff. Cajun (I'll still call it that, for brevity) takes the web services mantra of loose coupling very seriously. It separates interfaces from implementations by generating XML grammars, called maps. In a nutshell, your map abstracts away from member variables in implementation code. An element in the map, say <PERSON>, is not sensitive to changes in the names of underlying member variable names. This contrasts with most SOAP toolkits which generate interfaces based on those names -- interfaces that break when the names change.
A second key abstraction is conversational context. The framework persists member variables when a service is marked as conversational, and automatically sets up one-way messaging with callbacks. Under the covers, JMS (Java Messaging Service) is used rather than HTTP as the SOAP transport.
Bosworth argued that Microsoft's toolkit makes it too easy to create tightly-coupled RPC-style services. In the follow-on panel discussion, Microsoft's Dave Stutz admitted as much. "Guilty as charged," he said, while pointing that as with VB, early concept demos have been biased toward the simple, easy-to-use end of the spectrum.
I asked Stutz, Bosworth, and IBM's Sam Ruby if the doc/literal style of SOAP usage, which Visual Studio.NET in fact prefers, represents the generic approach to BEA's mapping technology. They agreed violently. Bosworth: "I'd even say RPC was a bad idea to begin with."
Bubbling under the surface here are the somewhat ominous implications of an architectural style that solely addresses application-to-application communication. "Where's the web in web services?" asked KnowNow's Rohit Khare. The term is a complete misnomer, the panel agreed. It should have been called Net Services, not Web Services, but the name stuck and it's too late to change it.
Tim O'Reilly jumped up to say that we ignore the social dimension of the web at our peril. There is "innovative froth" that comes from the bottom up, driven by open source energy and by the interactions among people and applications. I agree. Web services are reinventing the client/server space, and aiming to solve coordination and scaling problems that were never solved before. This necessarily goes beyond the original charter of the web, which was to be a distributed hypermedia application. But the two worlds are not wholly incompatible either. Not every message requires conversational context and asynchronous callbacks. There's a vast and useful intersection between the web as an interactive hypermedia application (used promiscuously by humans and applications), and web services as a mainly application-to-application affair.
It's great to see BEA, Microsoft, and IBM violently agreeing on architectural principles and protocols. But like Tim O'Reilly, I wish that consensus didn't sound so much like a vendor-driven secession from the web ecosystem.
3:02:41 PM
|
|
|
Thursday, May 02, 2002 |
|
Linking to SOAP-exposed resources
Since the REST/RPC/SOAP discussion flared up again, I've been looking for a single clear statement about what kind of problem may exist, and what to do about it. I found it in Paul Prescod's Google's Gaffe:
The point that has not yet filtered through to the mainstream of web services implementors is that linking is just as important for machine-to-machine applications as it is for human-facing applications. If it is impossible to link to SOAP-exposed resources, then they are less powerful and useful than HTTP-exposed ones. Until SOAP has an addressing mechanism as rich as HTTP URIs, SOAP is less, rather than more powerful than HTTP. A hugely important class of web services is addressable by URI, and accessible to GET. We call these things web pages. The fact that such pages can be consumed by human-operated browsers and machine-operated scripts in the same way was, and remains, a great thing. As some pages evolve into services intended mainly for programmatic use, XML becomes a natural representation format. This need not undermine the value of the URL-line which, as I've pointed out, remains an incredibly vital style of access.
In practice, though, I don't find that SOAP undermines the URL-line. Toolkits seem perfectly happy to let me turn service names, method names, and parameters into URLs. I have here, for example, both Visual Studio.NET and GLUE. If I write a SOAP service called StockQuote in either of these, with a method called getQuote, then in addition to the SOAP/RPC interface I can automatically use:
http://host/StockQuote/getQuote?sym=VRSN
or:
http://host/StockQuote.asmx/getQuote?sym=VRSN
Should Google have done something like this? Absolutely. I miss being able to type http://google.com/xml?q=roy+fielding. As I pointed out in a essay on monetizing web services, this was possible a few months ago. Arguably it still should be. But that's just a business decision Google has made. In practice, given the restrictions placed on the Google API, the regular web-friendly HTTP GET remains the preferred way to link to the infinite space of Google queries, as people do every day.
So, SOAP toolkits already support a RESTful mode for GET-style (though not for POST-style) operations. Since GET-style reads are what both people and machines mainly use the Web to do, I'd say we're in pretty good shape.
PS: The top Google result for "restful soap" -- ahead of a bunch of W3C mailing list postings -- is an ad for a restful soap full of aromatic fragrance. The name of this restful soap? Desert Storm. Go figure.
2:04:18 PM
|
|
|
Tuesday, April 30, 2002 |
|
Visualizing Googlespace
I've received a number of interesting responses to my current BYTE.com column on the Google API. Nelson Minar, former Popular Power CTO who's now with Google, wrote to point out that since HTML doctitles are of uncertain quality, the snippets (relevant text chunks) returned by the Google API might form an interesting search space. When I tried that, though, the results didn't seem to diverge enough. The name of the game, in this kind of surfing, is to chart a course through googlespace that diverges enough to turn up interesting new connections, but not so much as to end up off in the weeds.
So far, titles seem like the happy medium between URLs and snippets. But I'm not done yet. I have a hunch that things will get really juicy when the evaluation function is augmented by something outside of Google. This kind of cross-wiring is what most excited me when I did my original mindshare experiment. When the activation threshold for these experiments is low, because lots of services have standardized APIs, we'll see (I am sure) some compelling emergent behaviors.
Another reader, Martin Spernau, pointed me to a graphical Google browser based on the TouchGraph framework. At the TouchGraph site, one of the demos of the framework browses a taxonomy of graph-based interfaces. Such visualizations never fail to fascinate me. But I confess that they don't hold my interest for very long, either. I suspect that the reason is the same: the evaluation functions are too simple, and too isolated. Consider this interactive map of the Net industry. According to its creator, Valdis Krebs:
The data is gathered from various public sources and includes only data on business partnerships such as strategic alliances and joint ventures.
It's easy to imagine an evaluation function that's sensitive to the sizes of the business entities, the durations of the partnerships, the job-posting patterns in various cities, and a million other things. Visualizing these dimensions would be a worthy challenge for a graph-based interface. Semantic web visionaries suppose that all this metadata will be encoded in standard ways, and will then unlock these powerful evaluation functions. I think it's going to happen the other way around. Web APIs will surface whatever meager bits of metadata already exist. Applications will combine these APIs to create novel effects. Then metadata will be incrementally improved in order to enhance the effects.
11:10:06 AM
|
|
|
Monday, April 29, 2002 |
|
The Google API is a two-way street
Google's new SOAP API seemed to follow a boom-and-bust trajectory. Everyone was excited about it until it arrived. Then doubts arose. "Bah," scoffed Edd Dumbill in an O'Reilly Network column (http://www.oreillynet.com/cs/weblog/view/wlg/1303), "what a waste of space for something that can be done in one line of shell script." Edd's point -- that an HTML-screenscraping alternative to the Google SOAP API is easy to hack together -- is quite correct. But the conclusion -- that Google's SOAP API is silly -- is, I think, very wrong. Full story at BYTE.com.
1:27:09 PM
|
|
|
Wednesday, March 27, 2002 |
|
Pipelining the Web
I had another look at the W3C's XSLT service. Turns out you can send it parameters after all. The syntax seems a bit outdated, but it works fine. Now the original solution to the Nasa newsfeed seems silly. All that was really needed was a parameterized stylesheet and three URLS, one for each channel.
This way of composing Web services by blogging URL-lines feels like the spiritual descendent of the Unix pipeline. This is part of what motivates the REST discussion, I think. We're going to be hearing more and more about orchestration of services in the coming months and years. There will be many ways to do that. I hope that basic URL-line-plus-XLST will be a viable strategy. Maybe I'm just being nostalgic, but I don't think so. I have a hunch that pipelined XML processing will be important for all the reasons that pipelined text processing has been.
10:22:56 PM
|
|
© Copyright 2002 Jon Udell.
|
|
