- Chapter 3: Simple Object Access Protocol (SOAP)
- Simple Object Access Protocol (SOAP)
- Doing Business with SkatesTown
- Inventory Check Web Service
- SOAP Envelope Framework
- Taking Advantage of SOAP Extensibility
- SOAP Intermediaries
- Error Handling in SOAP
- SOAP Data Encoding
- Architecting Distributed Systems with Web Services
- Purchase Order Submission Web Service
- SOAP Protocol Bindings
- Summary
- The Road Ahead
- Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
This chapter addressed the fourth level of the Web services interoperability stack—XML messaging. It focused on explaining some of the core features of XML protocols and SOAP 1.1 as the de facto standard for Web service messaging and invocation. The goal was to give you a solid understanding of SOAP and a first-hand experience building and consuming Web services using the Apache Axis engine. To this end, we covered, in some detail:
The evolution of XML protocols from first-generation technologies based on pure XML 1.0 (WDDX and XML-RPC) to XML Schema and Namespace powered second-generation protocols, of which SOAP is a prime example. The chapter also discussed the motivation and history behind SOAP's creation.
The simple yet flexible design of the SOAP envelope framework, including versioning and vertical extensibility using SOAP headers. In SOAP, all context information orthogonal to what is in the SOAP body is carried via headers. SOAP's envelope framework allows you to design higher-level protocols on top of SOAP in a decentralized manner.
SOAP intermediaries as the key innovation enabling horizontal extensibility. Because of intermediaries, Web services can be organized into very flexible system and network architectures and value-added services can be provided on top of basic Web service messaging.
SOAP error handling using SOAP faults. Any robust messaging protocol needs a well-designed exception-handling model. With their ability to communicate error information targeted at both software and humans, as well as clearly identifying the source of the error condition, SOAP faults make it possible to integrate SOAP as part of robust, mission-critical systems.
Encoding data using SOAP. The chapter covered both SOAP's abstract data model encoding and a number of other heuristics for determining an appropriate data representation model for SOAP messages.
Using SOAP for both messaging and RPC applications. By design, SOAP is independent of all traditional aspects of messaging: participant organization, interaction pattern, synchronicity, and so on. As a result, SOAP can be used for just about any distributed system. This chapter provided some guidelines that help narrow the space of what is possible to the space of what makes sense in the real-world solutions.
Using SOAP over multiple protocols. The SOAP specification mentions an HTTP binding for SOAP, but Web services can be meaningfully bound to many other packaging and protocol schemes: MIME packages to support attachments, SMTP for scalable asynchronous messaging without the need for special middleware, and many others.
During the course of the chapter, we developed two meaningful e-commerce Web services for SkatesTown: an inventory check RPC service (with or without e-mail confirmations) and a purchase order submission messaging service. Our implementation on both the server and the client used design best practices for separating data and business logic from the details of SOAP and XML processing.