O'Reilly logo

Patterns: Implementing Self-Service in an SOA Environment by Fernando Teixeira, Shashi Shrimali, Peter Hood, Sandy Grewal, Diego Cotignola, Anup Aggarwal, Carla Sadtler

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 7. Application and system design guidelines 173
򐂰 Type-dynamic
The service requester obtains both the service interface specification and the
service implementation information from a public, private, or shared UDDI
registry at runtime. No proxy code is generated; the service requester directly
uses the more generic SOAP APIs to bind to the service provider and invoke
the Web service.
Message structure
The Web services specification does not mandate any particular message
structure. The message structure is defined by the service provider. Message
structures can be anything from simple strings to complex XML documents.
SOAP encoding versus literal encoding
SOAP encoding, the infamous set of rules often referred to as Section 5 encoding
after its location in the specification, was introduced to provide standard rules for
encoding data within SOAP envelopes. Simple services and clients could simply
agree to follow a set of rules for encoding data to XML in order to make writing
services and clients easier. But SOAP encoding is only a suggestion in the
specification. Thus, when a product claims SOAP compatibility, it is not explicitly
claiming SOAP encoding compatibility. This is why the available higher-level
APIs cannot be correct in general when they do automatic marshalling of
datatypes. Just as the extensibility of SOAP with regard to transports often
causes implicit assumptions that create compatibility problems, so does this
extensibility with regard to payload data encoding. To know whether the client
API will generate SOAP envelopes that a specific Web service will understand,
we must be explicitly aware of the data encoding that the Web service expects
and whether that encoding is supported by the client API.
An alternative is to use literal encoding where the payload of a SOAP message is
defined completely by a specific schema, often an XML Schema. Instead of
having the Web service and the client agree to follow a set of rules for serializing
the data, they agree on the exact format of the data. If the format is described by
using an XML Schema, a development tool can read it and provide automatic
marshalling of the data from the native language structures into XML. In this
case, all the toolkit has to understand is the entire XML Schema specification
instead of the combination of the particular encoding rules as well as the chosen
type system. The only issue left with using literal encoding is how the tool finds
the particular service's XML Schema. This issue is solved by WSDL.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required