W3C Adopts SOAP 1.2; IDN Offers Dev JumpStart Kit
The W3C last week officially published SOAP 1.2 as a formal standard, setting the Internet-based remote procedure call as a core foundation for multi-platform web services. To mark the event, IDN presents a Developer JumpStart Kit for SOAP, amassing major SOAP assets for the developer. Get info on SOAP specs, Case Studies and tips from experts from all over, including Apache, SoapBuilders, Microsoft, Java experts, Soapware and many others.
To mark the event, IDN presents a Developer JumpStart Kit for SOAP, amassing a major developer resource of SOAP-related assets. What follows are links to our stories, Case Studies and tips over the past year, as well as some of the best SOAP resources you'll find across the web, including Apache, SoapBuilders, Soapware and even Microsoft (for free stuff)..
First, a run-through of the SOAP 1.2 spec, with documentation.
A SOAP 1.2 Review -- with Documentation
Interoperability is a key concern for SOAP 1.2, as one of its goals is to encapsulate remote procedure call (RPC) functionality using the extensibility and flexibility of XML.
[In specific, SOAP Part 2 section 4 has defined a uniform representation for RPC invocations and responses carried in SOAP messages. SOAP 1.2 integrates core XML technologies. SOAP 1.2 is designed to work seamlessly with W3C XML schemas, maximizing SOAP's utility with a broad range of XML tools, and paving the way for future work on WSDL. It also makes use of XML Namespaces as a flexible and lightweight mechanism for handling XML language mixing.]
SOAP 1.2's standing as a W3C standard has been under a cloud since late last year, when WebMethods and Epicentric suggested that they might maintain rights to some of their technology that led to the development of SOAP. (Seeearlier IDN coverage of SOAP.) Both have since dropped such claims.
The SOAP 1.2 documents are broken into three (3) distinct sections:
Primer (Part 0); which describes how SOAP may be used, by describing representative SOAP message structures and message exchange patterns.
Messaging Framework (Part 1); which defines the SOAP envelope. Specifically, the framework provides
- A processing model which specifies the rules for processing a SOAP message;
- An extensibility framework that enables developers to use extensions inside and outside the SOAP envelope;
- The message construct that comprises the rules for constructing SOAP messages; and
- The protocol binding framework, or the rules for specifying the exchange of SOAP messages over underlying protocols such as HTTP.
- Representing remote procedure calls (RPCs);
- Encoding SOAP messages and
- Describing SOAP features and SOAP bindings. It also provides a standard binding of SOAP to HTTP 1.1, allowing SOAP messages to be exchanged using the mechanisms of the World Wide Web.
SOAP 1.2 specifies that to invoke a SOAP RPC, the following information is needed:
- The address of the target SOAP node.
- The procedure or method name.
- The identities and values of any arguments to be passed to the procedure or method together with any output parameters and return value.
- A clear separation of the arguments used to identify the Web resource that is the actual target for the RPC, as contrasted with those that convey data or control information used for processing the call by the target resource.
- The message exchange pattern that will be employed to convey the RPC, together with an identification of the so-called "Web Method" to be used.
- Optionally, data that may be carried as a part of SOAP header blocks.
a SOAP message expressing data for a travel reservation;
a SOAP response to refine some information in the request, and
a SOAP RPC request with a mandatory header and input parameters.
More SOAP 1.2 Developer Resources
xmlhack explains changes in HTTP POST and GET in SOAP 1.2 noting in part, "The biggest change in these drafts is the addition of a binding to GET method of the HTTP protocol, which enables a URL to be associated directly with a SOAP resource." Xmlhack also has a number of interesting links relating to this issue.
For more on HTTP GET versus POST see this good developers' guide on HTTP GET versus POST from Tampere University of Technology, Finland.]