JMS Work Brings Asynchronous Features to Apache SOAP
Vendor support for a variety of SOAP-to-Java (and Java-to-SOAP) communications techniques is gaining steam. In the latest example, the Apache Axis Project later this month will release the industry's first native SOAP support asynchronous web services. The support for asynchronous communications follows the inclusion of a JMS (Java Message Service) transport mechanism offered to Apache by Sonic Software.
Vendor support for a variety of SOAP-to-Java (and Java-to-SOAP) communications techniques is gaining steam. As a result, later this month, the Apache Axis Project will release Axis 1.0, which will include the industry's first native support asynchronous web services. This asynchronous support follows the inclusion of a JMS (Java Message Service) transport mechanism being offered to the Apache project by Sonic Software.
Inside Apache Axis' Asynchron-icity
At its base, the Axis asynchronous work revolves around a simple concept, David Chappell told Integration Developer News . "In Axis, we're defining the underlying core engine and the SOAP processor that is capable of sending and/or receiving autonomous asynchronous communications." Chappell is VP and Chief Technology Evangelist at Sonic, as well as the man who oversaw the design and development of the first commercial JMS implementation.
"We saw the need to drive asynchronous web services processing to Apache Axis and contacted the other committers," Chappell told IDN. "We chose it because Apache SOAP has become the de facto standard for SOAP processing in Java. The move is all about providing standards based products," he said.
[Earlier this summer, the Apache Software Foundation (ASF) confirmed their intent to include native support for asynchronous I/O on the list of features for the next major release (Apache 3.0) of the Open Source web server.]
The Apache Axis Project, which is run within the auspices of the Apache Software Foundation (ASF), has an ongoing focus on defining the next generation of Apache SOAP, a standard SOAP processing engine used across a variety of commercial, Open Source and vendor implementations.
Inside the Axis Work
The Axis work took on the following form. "We have submitted a JMS transport mechanism for Apache Axis, and it will be part of Axis 1.0 when it gets released within the next several weeks," Chappell told IDN. The capability would let developers build applications that support one-way invocations and request/response messaging using JMS as the underlying protocol as an alternative to HTTP. The Axis API would let a developer perform an RPC-style operation, document-style request/ response, or a one-way invocation across the wire, where the SOAP envelope can be sent over HTTP or JMS, without the developer needing to know the details, he said.
"The simple JMS transport will enable developers to use Apache Axis SOAP APIs, and then have a JMS transport layer seamlessly embedded," Chappell explained. Axis was designed to support different transports in a "plug-in" way, Chappell said, helping developers avoid the heavy lifting of digging into the Axis code itself and figuring out how to do it. It also provides developers with a wider selection of transports beyond HTTP, which is seen by many developers as a bit too unreliable for mission-critical, bi-directional web services.
The "binding mechanisms" that provide this seamless support for JMS is one of the key technology features slated for the Axis 1.0 release, Chappell added, noting that it sets the stage for the support of multiple message techniques. The primary focus of the Apache Axis team to date has been to support the JAX-RPC programming model, he said.
But of all the venues for participating in work on asynchronous work, why did Sonic choose Apache Axis?
Chappell's reasons are quite simple: "The notion of asynchronous communications for web services is being talked about everywhere, and there is an advantage in bringing up these features for an Open Source platform like Apache It gives us a public forum where we can just agree to an approach and build it."
So timing and seeding the developer community with capabilities is key. "While overlapping standards' bodies may be bogged down [in implementation], competing on how to define what the next thing is," Chappell said "Apache Axis can just go and do it. That's how Open Source movements tend to evolve. First we agree upon the approach, and then we implement."
But, developers shouldn't get the idea that these technologies will make building an asynchronous web service a simple drag-and-drop operation. "There is nothing inherent in what we're adding [to Axis] that will help alleviate the need for SOAP knowledge, but the Axis APIs will provide high-level access to the functions and data details that go in and out of the SOAP envelope without the developer needing to worry about the envelope, or how it goes across the wire," Chappell added.
Is Everyone On Board?
Chappell doesn't expect any political hiccups in the rollout of the asynchronous capabilities. "We've got agreement from the other vendors on the Axis development team," which includes IBM, Macromedia and others.
Axis is also part of the SOAPBuilders interoperability effort, making sure that different versions of the SOAP stacks used by Java and Microsoft developers will interact. Individual members of the Axis team, including Sonic, are also heavily involved all the major standards organizations such as W3C and OASIS. Sonic is chairing one of the technical subcommittees at the WS-I on use scenarios for SOAP and Web services.
"From our point of view, we are representing how a programmer or developer would approach the problem, and we think that will lead to more rapid adoption of more complex web services that need two-way communications," he said. "That's what all vendors are looking for."
Beyond Axis 1.0
Despite this big step forward, Chappell and others in Axis have grander goals in mind.
"The real exciting stuff is going forward -- where we'll add asynchronous processing to the core Axis engine. The end game is to add asynchronous bi-directional indications into the Axis engine which will be protocol-independent. The capability will be mostly invisible to developers, although the API will be updated to reflect different protocols," Chappell told IDN. "The asynchronous capabilities will be hidden in the Axis engine layer so the details won't bubble up to the developer."
"While we are big proponents of JMS, we also understand that JMS is simply a choice of transport and we intend for the Axis engine to support other transports," Chappell said. This means the choice of protocol can be separate from the overall programming model a developer may choose. "So, the goal is that the APIs a developer can use are written to support asynchronous communications, and the underlying Axis engine is redesigned and the choice of transport. That will mean, out of the box, an Apache developer can pick whatever transport he or she wants," he said.
As an example, Chappell suggests that with this goal developers will be able to support other asynchronous connectivity technologies that aren't JMS based. As other asynchronous protocols evolve, there is no reason that the other end of your communications couldn't be with C++, .NET or whatever. "This brings much, much closer to abstractingâ€¦ SOAP," he said. The evolution and widespread adoption of platform-independent, asynchronous, reliable protocols is a long way off. JMS is here and now, and that's why we chose to implement that first.
Support for Web Services Workflow to Follow
Chappell further said the ongoing Axis work is enabling the Axis engine to support asynchronous processing. "That means allowing Axis to support any number of future evolving standards," including certain now-in-conflict proposed business process orchestration and choreography management standards as BPEL4WS and WSCI, he said. "Regardless of the conflicting proposals, a common set of capabilities for asynchronous processing and correlation will be needed. So, we may be providing the core asynchronous process and Axis engine can be adopted to a number of different approaches at the higher level of a web services application."
For Sonic, that flexibility also means opportunity. The Sonic XQ enterprise service bus (for web services among other integration projects) provides some features better suited than other messaging vendors, for example, for supporting deployment across the Internet and firewalls. Masking the complexity developers might encounter when supporting different messaging services would help Sonic's market penetration, Chappell said. "We certainly believe we provide a very strong JMS-driven approach for asynchronous web services, but we need to make it easier for developers to think about building those kinds of projects. Including these features in Axis is one way we think we can help the industry, and hopefully Sonic."
Putting this trade-off in context, Chappell added, "We bring a great deal to the table in this effort with our years of experience with real customers in asynchronous environments and web services deployments. Also, rather than building proprietary interfaces ourselves, we are embracing an existing de-facto standard, helping to shape its future direction, and giving that back to the Open Source community."
Sonic Software provides a "developers exchange" portal from their website where you can get updates on this and other web services-related topics. http://developer.sonicsoftware.com. Also, you can see the work being made available to ASF at http://xml.apache.org/axis/mail.html
David Chappell is the co-author of Java Web Services, published by O'Reilly and Associates. http://www.oreilly.com/catalog/javawebserv/, and Java Message Service, also published by O'Reilly and Associates.