- SOAP
- Doing Business with SkatesTown
- Inventory Check Web Service
- A Closer Look at SOAP
- The SOAP Messaging Framework
- SOAP Intermediaries
- The SOAP Body
- The SOAP Processing Model
- Versioning in SOAP
- Processing Headers and Bodies
- Faults: Error Handling in SOAP
- Objects in XML: The SOAP Data Model
- The SOAP RPC Conventions
- XML, Straight Up: Document-Style SOAP
- When to Use Which Style
- The Transport Binding Framework
- Using SOAP to Send Binary Data
- Small-Scale SOAP, Big-Time SOAP
- Summary
- Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
When to Use Which Style
As a Java programmer, it might not always be clear which style of SOAP to use. Here are a few rules of thumb you can use when thinking about it:
If you're starting from code in Java, C#, or another procedural/OO language, and you're trying to expose methods as Web services, the RPC style is a natural fit.
If you have preexisting XML formats (schemas and so on) that you want to support, using the SOAP encoding would just get in the way. So, document style is preferable.
If you need to transmit object graphs that must maintain referential integrity (circular lists, for instance, or complex graphs), RPC provides an interoperable way to do it.
Validating document-style messages is straightforward, because they typically have XML schemas. You can't easily write an XML schema that will correctly validate an encoded SOAP data model, since the model allows for a nondeterministic set of valid serializations—for instance, multiref objects can be serialized in a variety of places (either in-place at any of the references, or as an independent element at the top level), and arrays are still valid regardless of the XML element name of the items. So, if schema validation using standard tools is important, document style is the way to go.
As you'll see in Chapter 13, "Web Services Interoperability," the Web Service Interoperability organization (WS-I) has come down hard against SOAP encoding, and has in fact banned its use in their Basic Profile of SOAP 1.1 (we can only assume they will continue to dislike it for SOAP 1.2).
The jury is definitely still out with respect to the value of the SOAP encoding. A lot of companies seem to be moving away from it; but, on the other hand, it's a developer-friendly technology for people trying to expose preexisting classes and methods as Web services. Despite WS-I's claims, there has been a lot of interoperability work to make sure RPC style works between most implementations of SOAP 1.1 and SOAP 1.2.
We'll talk a lot more about these styles in the next couple of chapters, when we describe them in relationship to WSDL and Axis.