Erl SOA Chapter 14 (Kelly)


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Erl SOA Chapter 14 (Kelly)

  1. 1. Service Oriented Architecture: Concepts, Technology and Design <ul><ul><li>Chapter 14 – Service Oriented Design: Composition Guidelines </li></ul></ul>
  2. 2. Steps for composing a SOA <ul><li>The fundamental components of a SOA: </li></ul><ul><ul><li>XML data representation architecture </li></ul></ul><ul><ul><li>Web services built upon industry standards </li></ul></ul><ul><ul><li>A platform capable of hosting and processing XML data and Web Services </li></ul></ul>Vendor Platform Web Services XML Data Representation
  3. 3. Steps for composing a SOA (cont)‏ <ul><li>Concerns at this stage </li></ul><ul><ul><li>What types of services should be built and orchestrated? </li></ul></ul><ul><ul><li>How should the first-generation standards be implemented? </li></ul></ul><ul><ul><li>Which available extensions are required? </li></ul></ul>
  4. 4. Steps for composing a SOA (cont)‏ <ul><li>Suggested preliminary steps for composing a SOA </li></ul><ul><ul><li>Choose Service Layers </li></ul></ul><ul><ul><li>Position Core Standards </li></ul></ul><ul><ul><li>Choose SOA Extensions </li></ul></ul>
  5. 5. Choosing Service Layers <ul><li>This process may be very organization-specific and both immediate and long-term goals should be considered. </li></ul><ul><li>There are a few high-level guidelines </li></ul>
  6. 6. Choosing Service Layers: Guidelines <ul><li>Existing configurations - If service layers already have been standardized new service designs should conform to these layers. </li></ul><ul><li>Required Standards - If new types of services or service layers are being developed ensure that they are delivered along with accompanying design standards. </li></ul><ul><li>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). </li></ul><ul><li>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. </li></ul>
  7. 7. Choosing Service Layers: Guidelines (cont)‏ <ul><li>Business Services and XSD schema design - If an established XML data representation architecture exists, it should be analyzed for compatibility issues. </li></ul><ul><li>Business Service Maintenance - If proceeding with the agile-delivery strategy (Chapter 10), on-going maintenance should be considered. </li></ul>
  8. 8. Positioning Core SOA Standards <ul><li>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 </li></ul><ul><li>We have to decide how to position these standards to support the key characteristics we need in a SOA </li></ul>
  9. 9. Industry Standards and SOA <ul><li>The use of specific Web Service markup languages (which exist in different published versions) can create problems </li></ul><ul><li>Our SOA should be fully standardized when it comes to the foundation of our architecture </li></ul>
  10. 10. XML and SOA <ul><li>XML is fundamental to everything that makes up a contemporary SOA </li></ul><ul><li>Therefore some key factors need to be considered </li></ul><ul><ul><li>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 </li></ul></ul>
  11. 11. XML and SOA (cont)‏ <ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  12. 12. The WS-I Basic Profile <ul><li>This profile is the result of efforts to assemble mature, core specifications for Web Service Platforms </li></ul><ul><li>Compliance ensures good industry-wide conformance </li></ul><ul><li>For example the Basic Profile v.1.0 and v.1.1 suggest the following specifications: </li></ul><ul><ul><li>WSDL 1.1 </li></ul></ul><ul><ul><li>SOAP 1.1 </li></ul></ul><ul><ul><li>UDDI 2.0 </li></ul></ul><ul><ul><li>XML 1.0 </li></ul></ul><ul><ul><li>XML Schema 1.0 </li></ul></ul>
  13. 13. The WS-I Basic Profile (cont)‏ <ul><li>The Profile also imposes its own design standards examples: </li></ul><ul><ul><li>The use of the SOAP encodingStyle attribute within SOAP envelopes is highly dicouraged. </li></ul></ul><ul><ul><li>The WSDL binding element can only use the WSDL SOAP binding. </li></ul></ul>
  14. 14. WSDL and SOA <ul><li>WSDL definitions are the focal point of the design phase and are the principle deliverables of the process. </li></ul><ul><li>Some key design concerns: </li></ul><ul><ul><li>Standardized use of namespaces – since WSDL documents contain elements from different specifications (SOAP, XML Schema, and WSDL), namespaces must be carefully standardized. </li></ul></ul>
  15. 15. WSDL and SOA (cont)‏ <ul><ul><li>Modular service definitions – WSDL documents can be modularized to facilitate reuse and centralization. </li></ul></ul><ul><ul><li>Compatibility of granularity – interface granularity ideally corresponds to XML document granularity, but “WSDL first” often conflicts with XML document structure. </li></ul></ul>
  16. 16. XML Schema and SOA <ul><li>XML Schema definitions provide data integrity and are intrinsically part of many of the WS-* specifications. There are some considerations surrounding this standard: </li></ul><ul><ul><li>Modular XSD schemas – schemas can be modularized by the use of the include statement and follows the composability concerns within a SOA. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  17. 17. SOAP and SOA <ul><li>SOAP messages are the action behind a SOA and are therefore a fundamental concern: </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  18. 18. Namespaces and SOA <ul><li>Namespaces in a SOA cannot be arbitrary, they must be thought of as domains or qualifiers for corresponding WSDL elements. </li></ul><ul><li>The WS-I Basic Profile provides a set of standards for the use of namespaces. </li></ul>
  19. 19. UDDI and SOA <ul><li>UDDI provides a standard means of housing service description pointers. </li></ul><ul><li>Typically, UDDI is implemented on and enterprise-wide basis to facilitate the discovery of services across a SOA </li></ul>
  20. 20. Choosing SOA Extensions <ul><li>The primary concepts that shape SOA are: </li></ul><ul><ul><li>The principles of service-orientation </li></ul></ul><ul><ul><li>First-generation Web Services concepts </li></ul></ul><ul><ul><li>WS-* concepts </li></ul></ul><ul><li>Many of the specifications above are in-fact optional </li></ul><ul><li>It is important to identify the primary characteristics that are actually required and what best supports a particular SOA </li></ul>
  21. 21. Choosing WS-* Specifications <ul><li>Choosing WS-* specifications is not easy </li></ul><ul><ul><li>The specifications are evolving and some are not fully realized or accepted </li></ul></ul><ul><ul><li>The maturity of a specification under consideration must be take into account </li></ul></ul>
  22. 22. WS-BPEL and SOA <ul><li>There is strong vendor platform support for the WS-BPEL specification. </li></ul><ul><li>The chief advantage to using WS-BPEL is that a business process description can be expressed without particular implementation technology </li></ul>