Patterns: Implementing Self-Service in an SOA Environment

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.