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.

by Vance McCarthy

Tags: SOAP, SOAP Messages, Developers, RPC, Web Services, HTTP, XML,



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
  1. A processing model which specifies the rules for processing a SOAP message;
  2. An extensibility framework that enables developers to use extensions inside and outside the SOAP envelope;
  3. The message construct that comprises the rules for constructing SOAP messages; and
  4. The protocol binding framework, or the rules for specifying the exchange of SOAP messages over underlying protocols such as HTTP.
and Adjunct (Part 2), which defines a data model for SOAP. This data model section includes rules for
  1. Representing remote procedure calls (RPCs);
  2. Encoding SOAP messages and
  3. 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.
Invoking SOAP RPC with SOAP 1.2
SOAP 1.2 specifies that to invoke a SOAP RPC, the following information is needed:
  1. The address of the target SOAP node.
  2. The procedure or method name.
  3. The identities and values of any arguments to be passed to the procedure or method together with any output parameters and return value.
  4. 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.
  5. 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.
  6. Optionally, data that may be carried as a part of SOAP header blocks.
The W3C's Proposed Recommendation document presents several code samples to illustrate several operations, including
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
  • The Best of SOAP Tools and Info -- 2003 -- Here is IDN's Quick List reference to some of the best known, and most used, SOAP support tools available. Take a quick survey of the web's best resources for downloads and info on SOAP 1.2 ranging from Apache to SoapBuilders, to Soapware to Microsoft (for free stuff).

  • Developer's Guide to SOAP Clients -- Here's one of most developer-friendly SOAP building sites we've come across -- for just about any developer (Java, VB/.NET, C++ or Perl).

  • O'Reilly's 'Java and SOAP' Offers Troubleshooting Tips -- O'Reilly's Java and SOAP gives developers insights into how SOAP envelops are formed using a variety of techniques. Author Robert Englander is clear in his view that Java developers who ignore SOAP and XML-RPC do so at some risk.

  • Bank Finds SOAP Key to Leveraging Legacy Assets -- One of Canada's leading banks has found SOAP is not just a protocol, but provides an important tool for leveraging legacy assets in an Internet world. See how ScotiaBank used SOAP to enable their small staff to quickly "integrate" more than 1500 customer Win32/Win2000 clients with a new high-speed Internet system for customers -- without needing to rewrite any custom client software.

  • SOAP 1.2 Marks Start of Web Services Testing Era -- ZapThink, a Waltham, Mass.-based research firm, predicts the release of SOAP 1.2 will fuel the search for -- and development of -- tools and technologies that help developers (and sysadmins) make sure that the web services they build today will work optimally. If you're preparing for SOAP 1.2, take a tour of the web services management options that await you.

  • 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.

  • In the "Part 0" SOAP 1.2 Primer, W3C presents a kind of tutorial with a lot of detail and code samples illustrating how SOAP messages are exchanged (both document-style and RPC) and how its HTTP Bindings work. Most of the SOAP 1.2 changes center on how the protocol envelops core data and works with data transport (such as XML, email, etc.).

  • The SOAP 1.2 Core Specification defines the three major areas of the SOAP Messaging Framework required to implement in a SOAP-conformant message. They are: (1) the Processing Model, (2) the Message Construct, and (3) SOAP Protocol Binding Framework. The section also provides an illustration for a version transition from SOAP 1.1 to SOAP 1.2. In the SOAP 1.2 Adjuncts SOAP Part 2, developers will find all the add-ins that they mayuse with various SOAP messaging framework -- aspects such as a message data model, an RPC convention, techniques for encoding graphs in XML and creating an HTTP binding.

    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.]


    back

    • Share
    Go