Download - Erl SOA Chapter 14 (Kelly)
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