Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Erl SOA Chapter 14 (Kelly)

635 Aufrufe

Veröffentlicht am

  • Login to see the comments

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>