Service Oriented Architecture: Concepts, Technology and Design

Chapter 14 – Service Oriented Design: Composition Guidelines

Steps for composing a SOA

The fundamental components of a SOA:− XML data representation architecture− Web services built upon industry

standards− A platform capable of hosting and

processing XML data and Web Services Vendor Platform

Web Services

XML Data Representation

Steps for composing a SOA (cont)

Concerns at this stage− What types of services should be built and orchestrated?− How should the first-generation standards be implemented?− Which available extensions are required?

Steps for composing a SOA (cont)

Suggested preliminary steps for composing a SOA− Choose Service Layers− Position Core Standards− Choose SOA Extensions

Choosing Service Layers

This process may be very organization-specific and both immediate and long-term goals should be considered.

There are a few high-level guidelines

Choosing Service Layers:Guidelines

Existing configurations - If service layers already have been standardized new service designs should conform to these layers.

Required Standards - If new types of services or service layers are being developed ensure that they are delivered along with accompanying design standards.

Service composition performance - Service compositions can impose severe processing overhead, especially when intermediary services are required to process SOAP messages (each service having to perform a validation, deserialization and serialization steps).

Service Deployment - Deployment becomes a concern when solution-agnostic services are being developed. Re-usable services accessed remotely impose message latency on solutions that need to connect to them.

Choosing Service Layers:Guidelines (cont)

Business Services and XSD schema design - If an established XML data representation architecture exists, it should be analyzed for compatibility issues.

Business Service Maintenance - If proceeding with the agile-delivery strategy (Chapter 10), on-going maintenance should be considered.

Positioning Core SOA Standards

The second step in composing a SOA may seem easy since most vendor support is provided by a common set of XML and first-generation Web Services specifications

We have to decide how to position these standards to support the key characteristics we need in a SOA

Industry Standards and SOA

The use of specific Web Service markup languages (which exist in different published versions) can create problems

Our SOA should be fully standardized when it comes to the foundation of our architecture

XML and SOA

XML is fundamental to everything that makes up a contemporary SOA

Therefore some key factors need to be considered− RPC-style versus document-style SOAP messages –

RPC communication requires an XML architecture to be built around a parameter data exchange model which can cause conflicts with document-style WS-* specifications

XML and SOA (cont)

− Auto-generated XML – Though auto-generated XML output is good for immediate conversion or data sharing requirements but used often can cause a spread of non-standardized data representation.

− Fitting SOA on top of an established XML data representation architecture – To accomplish this, special care must be taken to fully standardize the existing architecture so that it is predictable and consistent.

The WS-I Basic Profile

This profile is the result of efforts to assemble mature, core specifications for Web Service Platforms

Compliance ensures good industry-wide conformance For example the Basic Profile v.1.0 and v.1.1 suggest the

following specifications:− WSDL 1.1− SOAP 1.1− UDDI 2.0− XML 1.0− XML Schema 1.0

The WS-I Basic Profile (cont)

The Profile also imposes its own design standards examples:

− The use of the SOAP encodingStyle attribute within SOAP envelopes is highly dicouraged.

− The WSDL binding element can only use the WSDL SOAP binding.

WSDL and SOA

WSDL definitions are the focal point of the design phase and are the principle deliverables of the process.

Some key design concerns:− Standardized use of namespaces – since WSDL

documents contain elements from different specifications (SOAP, XML Schema, and WSDL), namespaces must be carefully standardized.

WSDL and SOA (cont)

− Modular service definitions – WSDL documents can be modularized to facilitate reuse and centralization.

− Compatibility of granularity – interface granularity ideally corresponds to XML document granularity, but “WSDL first” often conflicts with XML document structure.

XML Schema and SOA

XML Schema definitions provide data integrity and are intrinsically part of many of the WS-* specifications. There are some considerations surrounding this standard:

− Modular XSD schemas – schemas can be modularized by the use of the include statement and follows the composability concerns within a SOA.

− Document-style messages and XSD schema – since document-style messages are intelligence-heavy, there is an emphasis on validation. Therefore schemas should be extensible to deal with multiple data contexts.

SOAP and SOA

SOAP messages are the action behind a SOA and are therefore a fundamental concern:

− SOAP message style and data types – SOA imposes a preferred payload structure and data type system on SOAP messaging frameworks which can potentially inhibit WS-* specifications since existing frameworks are highly RPC-style environments.

− SOAP headers – Metadata contained within SOAP headers prevents services from having to have knowledge of logic outside of itself. This is also the main arena for implementing WS-* specifications.

Namespaces and SOA

Namespaces in a SOA cannot be arbitrary, they must be thought of as domains or qualifiers for corresponding WSDL elements.

The WS-I Basic Profile provides a set of standards for the use of namespaces.

UDDI and SOA

UDDI provides a standard means of housing service description pointers.

Typically, UDDI is implemented on and enterprise-wide basis to facilitate the discovery of services across a SOA

Choosing SOA Extensions

The primary concepts that shape SOA are:− The principles of service-orientation− First-generation Web Services concepts− WS-* concepts

Many of the specifications above are in-fact optional

It is important to identify the primary characteristics that are actually required and what best supports a particular SOA

Choosing WS-* Specifications

Choosing WS-* specifications is not easy− The specifications are evolving and some are not fully

realized or accepted− The maturity of a specification under consideration

must be take into account

WS-BPEL and SOA

There is strong vendor platform support for the WS-BPEL specification.

The chief advantage to using WS-BPEL is that a business process description can be expressed without particular implementation technology