Databases Reference
In-Depth Information
Separate common objects into their own namespaces
Common objects, which are used across multiple namespaces, should be created in
their own namespace. For example, the address element is used across all domains.
If we were to create it in the order namespace, we would be forcing all our other
schemas to import the order schema, which would unnecessarily complicate our
XML instances. The issue would become more acute if common object definitions
were sprinkled across multiple namespaces.
Using WSDL to define business services
A service, as defined by a WSDL document, is made up of two parts. Firstly, there is
the abstract part, which defines the individual operations that make up a service, the
messages that define the parameters for the operations, and the types which define
our XML data types used by our messages.
The second part of the WSDL document defines the binding, that is, how to
physically encode the messages on the wire (for example, SOAP), the transport
protocol on the wire (for example, HTTP), and also the physical location or
endpoint of the service (for example, its URL).
Ideally, we should only be concerned with designing the abstract part of the WSDL
document, as the runtime binding should be more of a deployment detail. However,
the reality is that the style of binding has implications for how we design the
abstract components if we want to ensure interoperability between service
providers and consumers.
By far, the most common binding for a web service is SOAP over HTTP. However,
this comes in a number of different varieties, as we can specify whether the
invocation method adopts a Remote Procedure Call (RPC) style or a document
style binding (that is, a more message-oriented approach). We also have a choice
as to whether the SOAP message is encoded or literal. This gives us four basic
combinations, that is, RPC/encoded, RPC/literal, Document/encoded, and
Document/literal.
It is generally accepted that for the purposes of interoperability, Document/literal is
the best practice. However, the Document/literal style has some drawbacks.
Firstly, not all Document/literal services are WS-I compliant, as WS-I recommends
that the SOAP body contains only a single child element within the SOAP body.
However, Document/literal allows you to define WSDL messages containing
multiple parts, where each part is manifested as a child element within the
SOAP body.
