Dale Dougherty's Weblog

HOME   Who Am I?   Discuss   Stories MEMBERS Join Now Login

From: IBM To: Apache -- Here's SOAP4J Posted by Dale Dougherty, 6/2/00 at 5:59:14 PM. IBM announced this week that it had contributed its open-source reference implementation of SOAP 1.1, named SOAP4J, to the Apache Software Foundation's XML Project at xml.apache.org. SOAP (Simple Object Access Protocol) is a lightweight XML-based protocol that could help create a new generation of distributed services across the Web. SOAP 1.1 and SOAP4J The SOAP 1.0 specification was developed by Developmentor, Userland and Microsoft. (Dave Winer's XML-RPC might be considered an early snapshot of SOAP.) IBM joined the development team to help produce version 1.1 of the spec, which has been submitted to the W3C for consideration. The SOAP 1.1 specification, http://www.w3.org/TR/SOAP/. The SOAP4J code itself is a little hard to find on xml.apache.org. Check out: http://xml.apache.org/dist/soap/. SOAP seems to be a leading candidate to define a new layer of messaging services for the Internet, largely based on XML and HTTP. However, it is not the only candidate; the W3C has yet to weigh in on whether it even considers SOAP's problem domain to be within its scope of activity. At WWW9 in Amsterdam, the W3C's Dan Connolly organized a panel on XML protocols on which a dissenting view was expressed that protocols such as SOAP were not really necessary -- these applications could be accomplished within the existing framework. Yet it is likely that the W3C (pushed by its members) will take action on SOAP and open some kind of XML protocols working group. Then the question will come up as to whether they should standardize on SOAP, or simply use it as one of many possible sources for yet another specification. Certainly, with IBM and Microsoft as strong supporters of SOAP, one has good reason to dismiss some worry about the vagaries of the standards process and just jump in. Following IBM's announcement, I spoke with Robert Sutor of IBM, who is the Program Director for XML technology. I asked him what IBM wanted to see got into the SOAP 1.1 specification? There were three main areas. SOAP 1.0 was really limited to HTTP. It's really seen as a web-rpc thing. While we expect that to be useful, and used quite a lot, we know that you're transporting messages, and though you may use the Internet to get between enterprises, you do want to be able to jump inside the enterprise. You want to go inside a given company in lots of different ways. Limiting SOAP to one transfer protocol didn't make sense. You had to be able to use it with something like SMTP. It was basically simplifying SOAP so that you still get to use it with HTTP but you are not limited to HTTP. Secondly, we've been working with many companies including Microsoft in the W3C on its Schema proposal and part of that is the datatype specification. Any of these new proposals had to be based on the technology that the W3C was working on such as datatypes, and specifically not on what Microsoft's XDR proposal included. So we had to get these things together. The final thing is that we really see SOAP being used as a way of accessing services on the Web and services throughout the enterprise. So the ways these services are exposed may be particularly simple. In a credit card verification application, I may ask in a simple web-rpc form to validate a credit card purchase and pass a few parameters such as the credit card number. Pretty much what I want to get back is a yes or no answer. I do not very much want to know what you are running on your side, whether it's CORBA or DCOM. And you shouldn't expect to have to know much about what's running on my side. It shouldn't make any difference in how I couch this request. We felt that the first version of SOAP that came out had a little bit too much of a COM flavor to it. It didn't require COM but in terms of some of the terminology, etc, it referenced COM. We wanted to make sure SOAP was completely neutral to the programming environment that was used, as well as the distributed object technology that you are connecting to SOAP. The role of SOAP is not to replace "CORBA, or Java, or DCOM, or MQ Series and all the messaging you can do there," said Sutor. "The legacy world is very rich out there and sometimes you need all the complexity of these systems within enterprises." He explained that SOAP is used to fill gaps, which is why it's very lightweight to connect enterprises and services across the Internet. Sutor said IBM expects SOAP to be used to connect a lot of handheld devices such as PDAs into servers. I asked him to talk about the code base that was contributed to the Apache Group? In April we released SOAP4J and this is what we contributed to the Apache Group, just as IBM had contributed its XML4J parser. It's a collection of code and samples. It includes some sample client code for building SOAP messages and sending them off. It also has server side code, which is really in two pieces. One is the actual SOAP listener. This is something typically you'd invoke from a Java Server page. It would listen for a message, unwrap it and invoke a java method at some point, and it would construct the answer and send it back. Another aspect is the management of how do you actually connect a server with the services that it offers. So this is what the codebase does. There's also some examples, pretty simple-minded, stock-quote and addressbook applications, all written in Java. These will work with any servlet-based web server. Sutor suggest that a starting point for developers was to work with the listener side. "Set up the listener, register the services, then experiment with the client side and actually invoke these services." Sutor also spoke about why it made to sense to release this SOAP 1.1 implementation as open source. He noted that it was extremely important to connect open standards with open-source reference implementations. No one's going to make money over a SOAP listener. It's the services that are important. This basic technology that corresponds to SOAP needs to be done in an Open Source community because it needs to work perfectly for everybody. We need to have people examining the code; we need to have the code as high quality as possible. We hope it will help spur the growth of SOAP. I asked him if developers should be wary of SOAP and its dependency on schemas, which are not finalized at the W3C. Schemas are very close, in particular the datatypes. There's likely to be a period when we're adapting to changes. But in terms of waiting versus moving ahead, we need to be pragmatic. This notion of driving the Web of being a huge collection of distributed services will be very important. The technology has to get out there fast and evolve very quickly. It's going to be a fact of life that implementations are being done with the specifications as they are developed. We worked very hard with Microsoft to make sure that what we have is good. Sure, more work needs to be done, but it's not half-baked. As anyone who has dealt with HTML knows, versioning is a fact of life. Code will need to evolve. You simply can't wait.

Elsewhere