- 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
Small-Scale SOAP, Big-Time SOAP
To finish our coverage of the SOAP protocol in this chapter, we'll briefly examine how the simple rules of SOAP's design allow a lot of flexibility for implementations. Let's consider three different styles of SOAP processors and look at how this one baseline protocol can scale from the very small to the very large.
Imagine that a maker of scientific equipment has just released a new digital thermometer for the home. Being a forward-looking company, it decides to add a SOAP-over-HTTP interface so that other devices plugged into the home network can query the temperature. This thermometer has exactly one method, getTemperature(), which returns the current temperature in degrees Celsius. Since it's so simple, the vendor has built a single-purpose SOAP engine into the hardware. This engine doesn't include a full XML processor but instead uses simple pattern-matching with regular expressions to do three simple things:
Check that the envelope looks right, and return a VersionMismatch fault if necessary.
If any header blocks are targeted for the ultimate destination that are marked mustUnderstand=true, return a mustUnderstand fault.
Confirm the soap:Body contains exactly one element with the getTemperature QName.
Despite its simplicity and extremely limited processing capability, our thermometer is perfectly SOAP 1.2 compliant. That means any other software that speaks SOAP can talk to it.
Our second example is a single-purpose application built to talk to a particular kind of Web service. SkatesTown might have built something like this in order to automate finding the lowest price on parts from its various suppliers (all of whom implement a standard RPC-style price checking service) each day. This sort of system typically has real XML parsing and uses shared libraries to manage the SOAP processing model, so that the developer doesn't have to rewrite the same mustUnderstand-checking logic again and again. It might also support one or two built-in extensions, such as a commonly supported security module. However, the capabilities of this system are determined when it's constructed, and it can't be dynamically extended.
Finally, let's consider a general-purpose middleware SOAP solution as you might implement it with a toolkit like Axis. Axis was designed to be a flexible framework that provides as much generic processing capability as possible while letting you build applications and extensions that easily plug in to the framework. It uses full-scale XML parsing, supports schema validation, and has a mechanism for building handlers—pieces of extension code that process SOAP messages in order to implement either local functionality (logging, management) or extension semantics (security, correlation).
The system in this example might be for a Grid computing system (see Chapter 8 for more) that needs to be able to talk to an unbounded variety of other services. Our SOAP engine has a variety of extensions for popular security, transactionality, reliability, and management protocols on top of SOAP. When conversations begin, an initial negotiation phase uses SOAP headers to determine which encryption protocols to use, whether the parties are legally allowed to transact business across the network, and what kind of notarization service will be used. Essentially, we use mustUnderstand headers to ask for the maximum level of functionality; then, if we receive errors, we back off to lower levels if appropriate. Once the business-level messages start to flow, they will be safely encrypted and contain SOAP headers to manage transactional context, handle routing through intermediaries, and ensure nonrepudiation. The system is also extensible by dropping in new JAR files and tweaking a few deployment descriptors.
So we've gone from a completely static, dumb system like a thermometer all the way to a richly functional B2B fabric—and SOAP's model of simple, well-layered abstractions has been the foundation throughout. Although it's true that the secure Grid client won't be able to make the thermometer talk at its level, the inherent capabilities of the SOAP processing model make it possible for the more functional client to find that out and to scale back (if appropriate) in order to talk to the simpler service.
Of course, wouldn't it be nice if there were standard ways for communicating parties to automatically find out about each other's capabilities before any messages even flow over the wire? There is such a way: It's called WSDL, and it's the subject of the next chapter.