| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 | ||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||
 NEWSReliable Web services By Jon Udell October 4, 2002 NOW THAT WE ALL AGREE Web services must converse in a loosely coupled and asynchronous manner, it's clear that message-oriented middleware has a vital role to play. SOAP traffic usually cruises the HTTP highway, but it doesn't have to. We've talked to developers who are hitching rides on WebSphere MQ (formerly MQSeries), Microsoft Message Queue and JMS (Java Message Service). Even as the traditional messaging vendors reach out to the Web, upstarts such as Kenamea and KnowNow are building prototypes of what could become a Web-native messaging layer. These new products bring the classic benefits -- queueing, guaranteed exactly once delivery, and transactions -- across the Web and all the way down to the desktop.
In September, Kenamea launched a new version of its messaging platform, renamed from Kenamea Application Network (see our review, "Reliable messaging" ) to Kenamea Web Messaging Platform. The company says its new version offers connectors to RIM and Palm devices, simplifies integration with Web application servers, and sports a native HTTP API that extends the reach of Kenamea-style messaging to systems not supported by its JMS or EJB connectors. Also in September, Bedford, Mass-based Sonic Software joined the Apache Axis project. The short-term plan is to add a simple JMS transport to the open-source Web services engine that powers (among others) IBM's WebSphere and Macromedia's ColdFusion MX, so that Axis 1.0 (which is nearing final form) will be able to convey SOAP traffic over JMS. In the long run, Sonic's vice president and chief technical evangelist Dave Chappell tells InfoWorld, Sonic hopes to work with the Axis team to "build asynchronous invocation support into the Axis core engine." JMS is the de facto standard, he believes. But in a posting to the axis-dev mailing list, he suggests "generalizing the asynchronous support beyond JMS, such that it works with any protocol such as HTTP and SMTP/POP/IMAP." Connecting enterprise messaging systems to legacy systems is not a new problem, of course. The strategy was always to control what you could and accept what you couldn't. What is new is the notion of a heterogenous business Web that spans JMS-and non-JMS-flavored reliable transports, and degrades gracefully over other transports such as HTTP. Depending on whom you talk to, we either will or won't see the emergence of a generic protocol along the lines proposed by IBM in its HTTPR (Reliable HTTP) specification. Building reliability into the Web services stack at the transport layer sounds like a good idea. But veterans point out that even if it can be achieved, it won't solve all our problems. Alden Hart, now CTO of the Adrenaline Group in Arlington, Va., was vice president of engineering for CyberCash during its heyday. Because flaky networks and unpredictable latencies were a given, the CyberCash architecture was loosely coupled and message driven. Smart pipes are a bad idea, Hart believes, but smart connectors that inject reliability services into the network -- for example, queue control -- are useful. Even so, reliability is in the eye of the beholder. Suppose an e-commerce user clicks a buy link twice. Usually, you'll want to discard the second message. But sometimes it means the user wants two items. "Only the app knows for sure," Hart said, "and you'll find these kinds of judgment calls popping up everywhere." For Edwin Khodabakchian, CEO of Web services orchestration vendor Collaxa, in Redwood Shores, Calif., reliable messaging is great to have if you can get it, and asynchrony is a must-have. But since the business Web will be a hodgepodge of transports into the indefinite future, you can't count on asynchronous messaging with guaranteed delivery. Even if you could, it wouldn't make sense to push all the plumbing down into the network. "One of the lessons we learned from Collaxa WSOS [Web Service Orchestration Server] 1.0," Khodabakchian says, "is that developers have to be aware of the network and of asynchrony." In WSOS 2.0, service producers and consumers are joined by "two-way proxies" that require developers to explicitly model and account for failures and exceptions. That's admittedly more work, but for complex real-world business scenarios, the bad news may be that there are no shortcuts. The good news: As reliable messaging platforms proliferate and converge, developers can worry less about messages being sent and received, and think more about how they are understood.
 RELATED ARTICLES  Reliable messagingWSOS tunes up services RELATED SUBJECTS MiddlewareSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
