Do Java programmers really need SOAP?

SOAP, or the Simple Object Access Protocol, defines XML syntax used to standardize a language-neutral remote method invocation, its input parameters, and return value. A good portion of the SOAP specification describes how application data types can be serialized as XML. SOAP messages can be sent over HTTP or SMTP.

Microsoft included SOAP in its Hailstorm Web services initiative. The ebXML standards group recently adopted it. And it's the target of two new Java Specification Requests (JSR)--XML RPC JSR 101 and Services Description Language JSR 110.

But is the XML Tail Wagging the Java Dog?
The problem for Java architects is that, this early in the development cycle, SOAP is essentially an early prototype, yet the hype behind it is putting pressure on developers to become early adopters. In this case, the root of the problem lies in the significant amount of XML standard and concept thrashing, as early implementations compete to shape the direction of standards in this new information infrastructure. Specifically, there is thrashing in the areas of schemas, XML Query, Meta data registries, XML protocols and the Semantic Web.

SOAP Invocation

Here is an example invocation from the W3C SOAP document <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/ soap/envelope/" <SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">    <SOAP-ENV:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">          <symbol>DIS</symbol>       </m:GetLastTradePrice>    </SOAP-ENV:Body> </SOAP-ENV:Envelopegt; The example illustrates the two mandatory features of a SOAP message: an envelope (which is the root element) and a message body. You can also have an optional header to provide processing instructions to the recepient of the envelope. There is also a fault element for returning error information in the response, if a fault has occurred.