[The Prentice Hall Service Technology Series from Thomas Erl 01] • Service-Oriented Architecture · Concepts, Technology, and Design by Erl, Thomas -- Read -- Imperial Library of Trantor

Index

1.1. Why this book is important

1.1.1. The false SOA 1.1.2. The ideal SOA 1.1.3. The real SOA

1.2. Objectives of this book

1.2.1. Understanding SOA, service-orientation, and Web services 1.2.2. Learning how to build SOA with Web services

1.3. Who this book is for 1.4. What this book does not cover 1.5. How this book is organized

1.5.1. Part I: SOA and Web Services Fundamentals

Introducing SOA (Chapter 3) The Evolution of SOA (Chapter 4) Web Services and Primitive SOA (Chapter 5)

1.5.2. Part II: SOA and WS-* Extensions

Web Services and Contemporary SOAPart I: Activity Management and Composition (Chapter 6) Web Services and Contemporary SOAPart II: Advanced Messaging, Metadata, and Security (Chapter 7)

1.5.3. Part III: SOA and Service-Orientation

Principles of Service-Orientation (Chapter 8) Service Layers (Chapter 9)

1.5.4. Part IV: Building SOA (Planning and Analysis)

SOA Delivery Strategies (Chapter 10) Service-Oriented AnalysisPart I: Introduction (Chapter 11) Service-Oriented AnalysisPart II: Service Modeling (Chapter 12)

1.5.5. Part V: Building SOA (Technology and Design)

Service-Oriented DesignPart I: Introduction (Chapter 13) Service-Oriented DesignPart II: SOA Composition Guidelines (Chapter 14) Service-Oriented DesignPart III: Service Design (Chapter 15) Service-Oriented DesignPart IV: Business Process Design (Chapter 16) Fundamental WS-* Extensions (Chapter 17) SOA Platforms (Chapter 18) Case Studies: Conclusion (Appendix A) Service Models Reference (Appendix B)

1.5.6. Conventions

1.6. Additional information

1.6.1. The XML & Web Services Integration Framework (XWIF) 1.6.2. www.serviceoriented.ws 1.6.3. Contact the Author

Chapter 2. Case Studies

2.1. How case studies are used

2.1.1. Style characteristics 2.1.2. Relationship to abstract content 2.1.3. Code samples

2.2. Case #1 background: RailCo Ltd.

2.2.1. History 2.2.2. Technical infrastructure 2.2.3. Automation solutions 2.2.4. Business goals and obstacles

Figure 2.1. RailCo's initial set of Web services, designed only to allow RailCo to connect to TLS's B2B solution.

2.3. Case #2 background: Transit Line Systems Inc.

2.3.1. History 2.3.2. Technical infrastructure 2.3.3. Automation solutions 2.3.4. Business goals and obstacles

Figure 2.2. The Web services that comprise the TLS B2B solution.

Part I: SOA and Web Services Fundamentals

Chapter 3. Introducing SOA

3.1. Fundamental SOA

3.1.1. A service-oriented analogy 3.1.2. How services encapsulate logic

Figure 3.1. Services can encapsulate varying amounts of logic.

3.1.3. How services relate

Figure 3.2. Because it has access to service B's service description, service A has all of the information it needs to communicate with service B.

3.1.4. How services communicate

Figure 3.3. A message existing as an independent unit of communication.

3.1.5. How services are designed

Figure 3.4. Service-orientation principles address design issues.

3.1.6. How services are built 3.1.7. Primitive SOA

3.2. Common characteristics of contemporary SOA

3.2.1. Contemporary SOA is at the core of the service-oriented computing platform 3.2.2. Contemporary SOA increases quality of service 3.2.3. Contemporary SOA is fundamentally autonomous 3.2.4. Contemporary SOA is based on open standards

Figure 3.5. Standard open technologies are used within and outside of solution boundaries.

3.2.5. Contemporary SOA supports vendor diversity

Figure 3.6. Disparate technology platforms do not prevent service-oriented solutions from interoperating.

3.2.6. Contemporary SOA promotes discovery

Figure 3.7. Registries enable a mechanism for the discovery of services.

3.2.7. Contemporary SOA fosters intrinsic interoperability

Figure 3.8. Intrinsically interoperable services enable unforeseen integration opportunities.

3.2.8. Contemporary SOA promotes federation

Figure 3.9. Services enable standardized federation of disparate legacy systems.

3.2.9. Contemporary SOA promotes architectural composability

Figure 3.10. Different solutions can be composed of different extensions and can continue to interoperate as long as they support the common extensions required.

3.2.10. Contemporary SOA fosters inherent reusability

Figure 3.11. Inherent reuse accommodates unforeseen reuse opportunities.

3.2.11. Contemporary SOA emphasizes extensibility

Figure 3.12. Extensible services can expand functionality with minimal impact.

3.2.12. Contemporary SOA supports a service-oriented business modeling paradigm

Figure 3.13. A collection (layer) of services encapsulating business process logic.

3.2.13. Contemporary SOA implements layers of abstraction

Figure 3.14. Application logic created with proprietary technology can be abstracted through a dedicated service layer.

3.2.14. Contemporary SOA promotes loose coupling throughout the enterprise

Figure 3.15. Through the implementation of service layers that abstract business and application logic, the loose coupling paradigm can be applied to the enterprise as a whole.

3.2.15. Contemporary SOA promotes organizational agility

Figure 3.16. A loosely coupled relationship between business and application technology allows each end to more efficiently respond to changes in the other.

3.2.16. Contemporary SOA is a building block 3.2.17. Contemporary SOA is an evolution 3.2.18. Contemporary SOA is still maturing 3.2.19. Contemporary SOA is an achievable ideal 3.2.20. Defining SOA 3.2.21. Separating concrete characteristics

3.3. Common misperceptions about SOA

3.3.1. "An application that uses Web services is service-oriented." 3.3.2. "SOA is just a marketing term used to re-brand Web services." 3.3.3. "SOA is just a marketing term used to re-brand distributed computing with Web services." 3.3.4. "SOA simplifies distributed computing." 3.3.5. "An application with Web services that uses WS-* extensions is service-oriented." 3.3.6. "If you understand Web services you won't have a problem building SOA." 3.3.7. "Once you go SOA, everything becomes interoperable."

3.4. Common tangible benefits of SOA

3.4.1. Improved integration (and intrinsic interoperability) 3.4.2. Inherent reuse 3.4.3. Streamlined architectures and solutions 3.4.4. Leveraging the legacy investment 3.4.5. Establishing standardized XML data representation 3.4.6. Focused investment on communications infrastructure 3.4.7. "Best-of-breed" alternatives 3.4.8. Organizational agility

3.5. Common pitfalls of adopting SOA

3.5.1. Building service-oriented architectures like traditional distributed architectures 3.5.2. Not standardizing SOA 3.5.3. Not creating a transition plan 3.5.4. Not starting with an XML foundation architecture 3.5.5. Not understanding SOA performance requirements 3.5.6. Not understanding Web services security 3.5.7. Not keeping in touch with product platforms and standards development

Chapter 4. The Evolution of SOA

4.1. An SOA timeline (from XML to Web services to SOA)

4.1.1. XML: a brief history 4.1.2. Web services: a brief history 4.1.3. SOA: a brief history

Figure 4.1. An early incarnation of SOA.

4.1.4. How SOA is re-shaping XML and Web services

4.2. The continuing evolution of SOA (standards organizations and contributing vendors)

4.2.1. "Standards" vs. "Specifications" vs. "Extensions" 4.2.2. Standards organizations that contribute to SOA

The World Wide Web Consortium (W3C) Organization for the Advancement of Structured Information Standards (OASIS) The Web Services Interoperability Organization (WS-I) How they compare Table 4.1. A Comparison of Standards Organizations

4.2.3. Major vendors that contribute to SOA

Why standards are being developed in support of SOA The vendor influence Vendor alliances Choosing a standards organization Why you should care

4.3. The roots of SOA (comparing SOA to past architectures)

4.3.1. What is architecture?

Application architecture Enterprise architecture Service-oriented architecture

4.3.2. SOA vs. client-server architecture

Client-server architecture: a brief history Figure 4.2. A typical single-tier client-server architecture. Figure 4.3. A typical two-tier client-server architecture. Application logic Application processing Technology Security Administration

4.3.3. SOA vs. distributed Internet architecture

Distributed Internet architecture: a brief history Figure 4.4. A typical multi-tier client-server architecture. Figure 4.5. A typical distributed Internet architecture. Application logic Figure 4.6. Components rely on proxy stubs for remote communication. Application processing Technology Security Administration

4.3.4. SOA vs. hybrid Web service architecture

Web services as component wrappers Figure 4.7. Wrapper services encapsulating components. Web services within SOA

4.3.5. Service-orientation and object-orientation (Part I)

Chapter 5. Web Services and Primitive SOA

5.1. The Web services framework

Figure 5.1. The structural relationship between sections in Chapters 3 and 5.

5.2. Services (as Web services)

5.2.1. Service roles

Service provider Figure 5.2. As the recipient of a request message, the Web service is classified as a service provider. Service requestor Figure 5.3. The sender of the request message is classified as a service requestor. Figure 5.4. TLS and RailCo services swapping roles in different but related message exchanges. Intermediaries Figure 5.5. The intermediary service transitions through service provider and service requestor roles while processing a message. Figure 5.6. A passive intermediary service processing a message without altering its contents. Figure 5.7. An active intermediary service. Initial sender and ultimate receiver Figure 5.8. Web services acting as initial sender and ultimate receiver. Figure 5.9. The TLS Load Balancing Service acting as an intermediary between the RailCo initial sender and the TLS ultimate receiver. Service compositions Figure 5.10. A service composition consisting of four members. Figure 5.11. The Accounts Payable Service enlisting other TLS services in a service composition.

5.2.2. Service models

Business service model Utility service model Controller service model Figure 5.12. A service composition consisting of a master controller, a sub-controller, four business services, and one utility service. Figure 5.13. The Accounts Payable Service acting as a business and controller service, composing two other business services.

5.3. Service descriptions (with WSDL)

Figure 5.14. WSDL definitions enable loose coupling between services. Figure 5.15. Each service requestor is using the WSDL of a service provider to ensure that messages sent will be understood and accepted. 5.3.1. Service endpoints and service descriptions

Figure 5.16. WSDL document consisting of abstract and concrete parts that collectively describe a service endpoint.

5.3.2. Abstract description

portType, operation, and message

5.3.3. Concrete description

binding, port, and service

5.3.4. Metadata and service contracts

Figure 5.17. A service contract comprised of a collection of service descriptions and possibly additional documents.

5.3.5. Semantic descriptions 5.3.6. Service description advertisement and discovery

Private and public registries Figure 5.18. Service description locations centralized in a registry. Business entities and business services Binding templates and tModels Figure 5.19. The basic structure of a UDDI business entity record. Figure 5.20. The TLS service registry containing pointers to current TLS WSDL definitions.

5.4. Messaging (with SOAP)

5.4.1. Messages

Envelope, header, and body Figure 5.21. The basic structure of a SOAP message. Header blocks Message styles Figure 5.22. The RailCo Invoice Submission Service packaging the contents of three documents into one SOAP message. Attachments Faults

5.4.2. Nodes

Figure 5.23. A SOAP node transmitting a SOAP message received by the service logic. Node types Figure 5.24. The positioning of SOAP nodes within a message transmission between RailCo and TLS. SOAP intermediaries Figure 5.25. Different types of SOAP nodes involved with processing a message.

5.4.3. Message paths

Figure 5.26. A message path consisting of three Web services. Figure 5.27. A message path determined at runtime.

Part II: SOA and WS-* Extensions

Chapter 6. Web Services and Contemporary SOA (Part I: Activity Management and Composition)

Figure 6.1. Specifications and concepts covered in this chapter. 6.1. Message exchange patterns

Figure 6.2. Not all message exchanges require both requests and responses. 6.1.1. Primitive MEPs

Request-response Figure 6.3. The request-response MEP. Figure 6.4. A sample request-response exchange between the TLS Accounts Payable and Vendor Profile Services. Fire-and-forget Figure 6.5. The fire-and-forget MEP. Figure 6.6. The TLS Accounts Payable Service sending off a one-way notification message. Complex MEPs Figure 6.7. The publish-and-subscribe messaging model is a composite of two primitive MEPs. Figure 6.8. The TLS Notification Service notifying subscribers about a problem condition via a notification broadcast.

6.1.2. MEPs and SOAP 6.1.3. MEPs and WSDL

Figure 6.9. The four basic patterns supported by WSDL 1.1.

6.1.4. MEPs and SOA

6.2. Service activity

Figure 6.10. In an activity, multiple Web services collaborate to do a specific piece of work. 6.2.1. Primitive and complex service activities

Figure 6.11. A primitive service activity consisting of a simple MEP. Figure 6.12. A complex activity involving four services.

6.2.2. Service activities and SOA

Figure 6.13. A sample complex activity spanning RailCo and TLS boundaries.

6.3. Coordination

Figure 6.14. Coordination provides services that introduce controlled structure into activities. 6.3.1. Coordinator composition

Figure 6.15. The coordinator service composition.

6.3.2. Coordination types and coordination protocols 6.3.3. Coordination contexts and coordination participants 6.3.5. The activation and registration process

Figure 6.16. The WS-Coordination registration process.

6.3.5. The completion process

Figure 6.17. The WS-Coordination completion process.

6.3.6. Coordination and SOA

Figure 6.18. Coordination as it relates to other parts of SOA. Figure 6.19. The TLS Accounts Payable, Vendor Profile, and Ledger Services being managed by a coordination.

6.4. Atomic transactions

Figure 6.20. Atomic transactions apply an all-or-nothing requirement to work performed as part of an activity. 6.4.1. ACID transactions 6.4.2. Atomic transaction protocols 6.4.3. The atomic transaction coordinator

Figure 6.21. The atomic transaction coordinator service model.

6.4.4. The atomic transaction process

Figure 6.22. The coordinator requesting that transaction participants prepare to vote. Figure 6.23. The transaction participants voting on the outcome of the atomic transaction. Figure 6.24. The coordinator aborting the transaction and notifying participants to rollback all changes.

6.4.5. Atomic transactions and SOA

Figure 6.25. Atomic transaction relating to other parts of SOA. Figure 6.26. All changes made by the TLS Accounts Payable, Vendor Profile, and Ledger Services are under the control of an atomic transaction.

6.5. Business activities

Figure 6.27. A business activity controls the integrity of a service activity by providing participants with a "plan B" (a compensation). 6.5.1. Business activity protocols 6.5.2. The business activity coordinator

Figure 6.28. The business activity coordinator service model.

6.5.3. Business activity states 6.5.4. Business activities and atomic transactions

Figure 6.29. Two atomic transactions residing within the scope of a business activity.

6.5.5. Business activities and SOA

Figure 6.30. A business activity relating to other parts of SOA. Figure 6.31. The TLS Purchase Order Submission Process wrapped in a long-running business activity and spanning two organizations (two participants).

6.6. Orchestration

Figure 6.32. An orchestration controls almost every facet of a complex activity. 6.6.1. Business protocols and process definition 6.6.2. Process services and partner services

Figure 6.33. A process service coordinating and exposing functionality from three partner services. Figure 6.34. The process service, after first being invoked by a partner service, then invokes another partner service.

6.6.3. Basic activities and structured activities 6.6.4. Sequences, flows, and links 6.6.5. Orchestrations and activities 6.6.6. Orchestration and coordination 6.6.7. Orchestration and SOA

Figure 6.35. Orchestration relating to other parts of SOA. Figure 6.36. The extended TLS Purchase Order Submission Process managed by an orchestration and involving numerous potential partner organizations.

6.7. Choreography

Figure 6.37. A choreography enables collaboration between its participants. 6.7.1. Collaboration 6.7.2. Roles and participants 6.7.3. Relationships and channels 6.7.4. Interactions and work units 6.7.5. Reusability, composability, and modularity

Figure 6.38. A choreography composed of two smaller choreographies.

6.7.6. Orchestrations and choreographies

Figure 6.39. A choreography enabling collaboration between two different orchestrations.

6.7.7. Choreography and SOA

Figure 6.40. Choreography relating to other parts of SOA.

Chapter 7. Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)

7.1. Addressing

Figure 7.2. Addressing turns messages into autonomous units of communication. 7.1.1. Endpoint references

Figure 7.3. A SOAP message containing a reference to the instance of the service that sent it.

7.1.2. Message information headers

Figure 7.4. A SOAP message with message information headers specifying exactly how the recipient service should respond to its arrival.

7.1.3. Addressing and transport protocol independence 7.1.4. Addressing and SOA

Figure 7.5. Addressing relating to other parts of SOA. Figure 7.6. Separate service instances communicating using endpoint references and MI headers across two pools of Web services within TLS.

7.2. Reliable messaging

Figure 7.7. Reliable messaging provides a guaranteed notification of delivery success or failure. 7.2.1. RM Source, RM Destination, Application Source, and Application Destination

Figure 7.8. An application source, RM source, RM destination, and application destination.

7.2.2. Sequences 7.2.3. Acknowledgements

Figure 7.9. A sequence acknowledgement sent by the RM destination after the successful delivery of a sequence of messages. Figure 7.10. A request acknowledgement sent by the RM source to the RM destination, indicating that the RM source would like to receive an acknowledgement message before the sequence completes. Figure 7.11. A negative acknowledgement sent by the RM destination to the RM source, indicating a failed delivery prior to the completion of the sequence.

7.2.4. Delivery assurances

Figure 7.12. The AtMostOnce delivery assurance. Figure 7.13. The AtLeastOnce delivery assurance. Figure 7.14. The ExactlyOnce delivery assurance. Figure 7.15. The InOrder delivery assurance.

7.2.5. Reliable messaging and addressing 7.2.6. Reliable messaging and SOA

Figure 7.16. Reliable messaging relating to other parts of SOA. Figure 7.17. After transmitting a series of invoice messages, the last message within the sequence triggers the issuance of an acknowledgement message by TLS.

7.3. Correlation

Figure 7.18. Correlation places the association of message exchanges into the hands of the message itself. 7.3.1. Correlation in abstract 7.3.2. Correlation in MEPs and activities 7.3.3. Correlation in coordination 7.3.4. Correlation in orchestration 7.3.5. Correlation in addressing 7.3.6. Correlation in reliable messaging 7.3.7. Correlation and SOA

7.4. Policies

Figure 7.19. Policies can express a variety of service properties, including rules. 7.4.1. The WS-Policy framework

Figure 7.20. The basic structure of a policy description.

7.4.2. Policy assertions and policy alternatives 7.4.3. Policy assertion types and policy vocabularies 7.4.4. Policy subjects and policy scopes 7.4.5. Policy expressions and policy attachments 7.4.6. What you really need to know 7.4.7. Policies in coordination 7.4.8. Policies in orchestration and choreography 7.4.9. Policies in reliable messaging 7.4.10. Policies and SOA

Figure 7.21. Policies relating to other parts of SOA.

7.5. Metadata exchange

Figure 7.22. Metadata exchanges let service requestors ask what they want to know about service providers. 7.5.1. The WS-MetadataExchange specification 7.5.2. Get Metadata request and response messages

Figure 7.23. Contents of a sample Get Metadata response message.

7.5.3. Get request and response messages

Figure 7.24. Contents of a sample Get response message.

7.5.4. Selective retrieval of metadata 7.5.5. Metadata exchange and service description discovery 7.5.6. Metadata exchange and version control 7.5.7. Metadata exchange and SOA

Figure 7.25. Metadata exchange relating to other parts of SOA. Figure 7.26. The revised RailCo Invoice Submission Process now includes a periodic metadata exchange with TLS.

7.6. Security

7.6.1. Identification, authentication, and authorization

Figure 7.27. An identity is a claim made regarding the origin of a message. Figure 7.28. Authentication means proving an identity. Figure 7.29. Authorization means determining to what extent authentication applies.

7.6.2. Single sign-on

Figure 7.30. A basic message exchange demonstrating single sign-on (in this case, as implemented by SAML).

7.6.3. Confidentiality and integrity

Figure 7.31. Confidentiality means that the privacy of the message has been protected throughout its message path. Figure 7.32. Integrity means ensuring that a message's contents have not changed during transmission.

7.6.4. Transport-level security and message-level security

Figure 7.33. Transport-level security only protects the message during transit between service endpoints. Figure 7.34. Message-level security guarantees end-to-end message protection.

7.6.5. Encryption and digital signatures

Figure 7.35. A digitally signed SOAP message containing encrypted data.

7.6.6. Security and SOA

Figure 7.36. Security, as it relates to policies, SOAP messages, and Web services.

7.7. Notification and eventing

Figure 7.37. Once subscribed, service A is notified of anything service B publishes that is of interest to service A. 7.7.1. Publish-and-subscribe in abstract 7.7.2. One concept, two specifications 7.7.3. The WS-Notification Framework

Situations, notification messages, and topics Notification producers and publishers Notification consumers and subscribers Figure 7.38. A basic notification architecture. Notification broker, publisher registration manager, and subscription manager Figure 7.39. A notification architecture including a middle tier.

7.7.4. The WS-Eventing specification

Event sources Event sinks and subscribers Subscription managers Notification messages and subscription end messages Subscription messages and subscription filters Figure 7.40. A basic eventing architecture.

7.7.5. WS-Notification and WS-Eventing 7.7.6. Notification, eventing, and SOA

Figure 7.41. Notification and eventing establishing standardized publish-and-subscribe models within SOA. Figure 7.42. The new RailCo subscription service allows RailCo to receive notifications from the TLS System Notification Service.

Part III: SOA and Service-Orientation

Chapter 8. Principles of Service-Orientation

8.1. Service-orientation and the enterprise

Figure 8.1. The business and application logic domains. Figure 8.2. The service interface layer positioned between enterprise layers that promote application and business logic. Figure 8.3. The service interface layer abstracts connectivity from service deployment environments.

8.2. Anatomy of a service-oriented architecture

8.2.1. Logical components of the Web services framework

Figure 8.4. A Web service sporting two operations. Figure 8.5. An operation processing outgoing and incoming SOAP messages. Figure 8.6. A basic communications scenario between Web services.

8.2.2. Logical components of automation logic

Figure 8.7. A primitive view of how SOA modularizes automation logic into units. Figure 8.8. A primitive view of how units of communication enable interaction between units of logic.

8.2.3. Components of an SOA

Figure 8.9. The scope of an operation within a process. Figure 8.10. Operations belonging to different services representing various parts of process logic.

8.2.4. How components in an SOA inter-relate

Figure 8.11. How the components of a service-oriented architecture relate. Figure 8.12. How the components of a service-oriented architecture define each other.

8.3. Common principles of service-orientation

8.3.1. Services are reusable

Figure 8.13. A reusable service exposes reusable operations. Figure 8.14. The RailCo Invoice Submission Service and its operations.

8.3.2. Services share a formal contract

Figure 8.15. Service contracts formally define the service, operation, and message components of a service-oriented architecture.

8.3.3. Services are loosely coupled

Figure 8.16. Services limit dependencies to the service contract, allowing underlying provider and requestor logic to remain loosely coupled.

8.3.4. Services abstract underlying logic

Figure 8.17. Service operations abstract the underlying details of the functionality they expose. Figure 8.18. Neither of RailCo's or TLS's service requestors require any knowledge of what lies behind the other's service providers.

8.3.5. Services are composable

Figure 8.19. The UpdateEverything operation encapsulating a service composition. Figure 8.20. The RailCo Order Fulfillment Service with its one operation. Figure 8.21. The TLS Accounts Payable Service composition.

8.3.6. Services are autonomous

Figure 8.22. Autonomous services have control over underlying resources. Figure 8.23. RailCo's services luckily encapsulate explicit portions of legacy and newly added application logic.

8.3.7. Services are stateless

Figure 8.24. Stateless and stateful stages a service passes through while processing a message.

8.3.8. Services are discoverable

Figure 8.25. RailCo's services are not discoverable, but TLS's inventory of services are stored in an internal registry.

8.4. How service-orientation principles inter-relate

8.4.1. Service reusability

Figure 8.26. Service reusability and its relationship with other service-orientation principles.

8.4.2. Service contract

Figure 8.27. The service contract and its relationship with other service-orientation principles.

8.4.3. Service loose coupling

Figure 8.28. Service loose coupling and its relationship with other service-orientation principles.

8.4.4. Service abstraction

Figure 8.29. Service abstraction and its relationship with other service-orientation principles.

8.4.5. Service composability

Figure 8.30. Service composability and its relationship with other service-orientation principles.

8.4.6. Service autonomy

Figure 8.31. Service autonomy and its relationship with other service-orientation principles.

8.4.7. Service statelessness

Figure 8.32. Service statelessness and its relationship with other service-orientation principles.

8.4.8. Service discoverability

Figure 8.33. Service discoverability and its relationship with other service-orientation principles.

8.5. Service-orientation and object-orientation (Part II)

Table 8.1. An overview of how service-orientation principles relate to object-orientation principles.

8.6. Native Web service support for service-orientation principles

Table 8.2. A look at which service-orientation principles are automatically supported by Web services.

Chapter 9. Service Layers

9.1. Service-orientation and contemporary SOA

Figure 9.1. External influences that form and support contemporary SOA. 9.1.1. Mapping the origins and supporting sources of concrete SOA characteristics

Table 9.1. A review of how contemporary SOA characteristics are influenced by Web services specifications and service-orientation principles.

9.1.2. Unsupported SOA characteristics

9.2. Service layer abstraction

9.2.1. Problems solved by layering services

What logic should be represented by services? How should services relate to existing application logic? How can services best represent business logic? How can services be built and positioned to promote agility? Abstraction is the key Figure 9.2. The three primary service layers.

9.3. Application service layer

Figure 9.3. The application service layer.

9.4. Business service layer

Figure 9.4. The business service layer.

9.5. Orchestration service layer

Figure 9.5. The orchestration service layer.

9.6. Agnostic services

Figure 9.6. Services uniting previously isolated business processes and solution environments.

9.7. Service layer configuration scenarios

9.7.1. Scenario #1: Hybrid application services only

Figure 9.7. Hybrid services encapsulating both business and application logic.

9.7.2. Scenario #2: Hybrid and utility application services

Figure 9.8. Hybrid services composing available utility application services.

9.7.3. Scenario #3: Task-centric business services and utility application services

Figure 9.9. Task-centric business services and utility application services cleanly abstracting business and application logic.

9.7.4. Scenario #4: Task-centric business services, entity-centric business services, and utility application services

Figure 9.10. Two types of business services composing application services.

9.7.5. Scenario #5: Process services, hybrid application services, and utility application services

Figure 9.11. An orchestration layer providing a process service that composes different types of application services.

9.7.6. Scenario #6: Process services, task-centric business services, and utility application services

Figure 9.12. A process service composing task-centric and utility application services.

9.7.7. Scenario #7: Process services, task-centric business services, entity-centric business services, and utility application services

Figure 9.13. Process and business services composing utility application services.

9.7.8. Scenario #8: Process services, entity-centric business services, and utility application services

Figure 9.14. A process service composing entity-centric services, which compose utility application services.

Part IV: Building SOA (Planning and Analysis)

Chapter 10. SOA Delivery Strategies

10.1. SOA delivery lifecycle phases

10.1.1. Basic phases of the SOA delivery lifecycle

Figure 10.1. Common phases of an SOA delivery lifecycle.

10.1.2. Service-oriented analysis 10.1.3. Service-oriented design 10.1.4. Service development 10.1.5. Service testing 10.1.6. Service deployment 10.1.7. Service administration 10.1.8. SOA delivery strategies

10.2. The top-down strategy

10.2.1. Process

Figure 10.2. Common top-down strategy process steps. Step 1: Define relevant enterprise-wide ontology Step 2: Align relevant business models (including entity models) with new or revised ontology Step 3: Perform service-oriented analysis Step 4: Perform service-oriented design Step 5: Develop the required services Step 6: Test the services and all service operations Step 7: Deploy the services

10.2.2. Pros and cons

10.3. The bottom-up strategy

10.3.1. Process

Figure 10.3. Common bottom-up strategy process steps. Step 1: Model required application services Step 2: Design the required application services Step 3: Develop the required application services Step 4: Test the services Step 5: Deploy the services

10.3.2. Pros and cons

10.4. The agile strategy

10.4.1. Process

Figure 10.4. A sample agile strategy process. Step 1: Begin the top-down analysis, focusing first on key parts of the ontology and related business entities Step 2: When the top-down analysis has sufficiently progressed, perform service-oriented analysis Step 3: Perform service-oriented design Steps 4, 5, and 6: Develop, test, and deploy the services Step 7: As the top-down analysis continues to progress, revisit business services

10.4.2. Pros and cons

Chapter 11. Service-Oriented Analysis (Part I: Introduction)

11.1. Introduction to service-oriented analysis

11.1.1. Objectives of service-oriented analysis 11.1.2. The service-oriented analysis process

Figure 11.1. A high-level service-oriented analysis process. Step 1: Define business automation requirements Step 2: Identify existing automation systems Step 3: Model candidate services

11.2. Benefits of a business-centric SOA

11.2.1. Business services build agility into business models

Figure 11.2. Changes originating in the business logic domain are accommodated by the application logic domain and vice versa.

11.2.2. Business services prepare a process for orchestration 11.2.3. Business services enable reuse 11.2.4. Only business services can realize the service-oriented enterprise

11.3. Deriving business services

11.3.1. Sources from which business services can be derived

Business Process Management (BPM) models Figure 11.3. Parts of a process that can be encapsulated by a business service. Entity models Figure 11.4. Relationships between RailCo entities (normally these entity symbols would contain attributes as well).

11.3.2. Types of derived business services

Task-centric business services Entity-centric business services Figure 11.5. Different organizations, different approaches to building services.

11.3.3. Business services and orchestration

Chapter 12. Service-Oriented Analysis (Part II: Service Modeling)

12.1. Service modeling (a step-by-step process)

12.1.1. "Services" versus "Service Candidates" 12.1.2. Process description

Figure 12.1. A sample service modeling process. Step 1: Decompose the business process Figure 12.2. The RailCo Invoice Submission Process. Figure 12.3. The RailCo Order Fulfillment Process. Step 2: Identify business service operation candidates Step 3: Abstract orchestration logic Step 4: Create business service candidates Figure 12.4. Our first round of service candidates. Step 5: Refine and apply principles of service-orientation Figure 12.5. The revised set of RailCo service candidates. Step 6: Identify candidate service compositions Figure 12.6. A sample composition representing the Invoice Submission Process. Figure 12.7. A sample composition representing the Order Fulfillment Process. Step 7: Revise business service operation grouping Step 8: Analyze application processing requirements Step 9: Identify application service operation candidates Step 10: Create application service candidates Step 11: Revise candidate service compositions Step 12: Revise application service operation grouping Optional Step: Keep an inventory of service candidates

12.2. Service modeling guidelines

12.2.1. Take into account potential cross-process reusability of logic being encapsulated (task-centric business service candidates)

Figure 12.8. Service logic being reused across processes.

12.2.2. Consider potential intra-process reusability of logic being encapsulated (task-centric business service candidates)

Figure 12.9. Service logic being reused within a process.

12.2.3. Factor in process-related dependencies (task-centric business service candidates) 12.2.4. Model for cross-application reuse (application service candidates) 12.2.5. Speculate on further decomposition requirements 12.2.6. Identify logical units of work with explicit boundaries 12.2.7. Prevent logic boundary creep 12.2.8. Emulate process services when not using orchestration (task-centric business service candidates)

Figure 12.10. A parent business service layer acting as an orchestration layer.

12.2.9. Target a balanced model 12.2.10. Classify service modeling logic 12.2.11. Allocate appropriate modeling resources

Figure 12.11. This intentionally simplistic diagram highlights the type of expertise recommended for modeling service layers.

12.2.12. Create and publish business service modeling standards

12.3. Classifying service model logic

12.3.1. The SOE model

Figure 12.12. The SOE model.

12.3.2. The enterprise business model 12.3.3. "Building Blocks" versus "Service Models" 12.3.4. Basic modeling building blocks

Figure 12.13. The three fundamental building blocks of the enterprise business model. Primitive business activities Process activities Business services Primitive business services Primitive business process

12.4. Contrasting service modeling approaches (an example)

Part V: Building SOA (Technology and Design)

Chapter 13. Service-Oriented Design (Part I: Introduction)

13.1. Introduction to service-oriented design

13.1.1. Objectives of service-oriented design 13.1.2. "Design standards" versus "Industry standards" 13.1.3. The service-oriented design process

Figure 13.1. A high-level service-oriented design process. Step 1: Compose SOA Steps 2 to 4: Design services Step 5: Design service-oriented business process

13.1.4. Prerequisites

Figure 13.2. Three core specifications associated with service design.

13.2. WSDL-related XML Schema language basics

Figure 13.3. An XSD schema document. "Elements" vs. "Constructs" 13.2.1. The schema element

Example 13.1. The most basic form of schema declaration.

13.2.2. The element element

Example 13.2. An element declaration in an XSD schema. Example 13.3. The usage of this element in an XML document instance.

13.2.3. The complexType and simpleType elements

Example 13.4. A complexType containing two element declarations.

13.2.4. The import and include elements

Example 13.5. The import and include elements.

13.2.5. Other important elements

13.3. WSDL language basics

Figure 13.4. The structure of a WSDL definition. 13.3.1. The definitions element

Example 13.6. A definitions element of the Employee Service, declaring a number of namespaces.

13.3.2. The types element

Figure 13.5. The WSDL types construct populated by XSD schema types used by the message construct to represent the SOAP message body. Example 13.7. A types construct containing an XSD schema construct in which a complexType is defined.

13.3.3. The message and part elements

Example 13.8. Two message constructs likely representing the input and output messages for an operation. Example 13.9. A simple parameter message requiring just a single integer value.

13.3.4. The portType, interface, and operation elements

Example 13.10. The portType construct hosting two operation constructs.

13.3.5. The input and output elements (when used with operation)

Example 13.11. operation elements with child input and output elements. Example 13.12. An operation element with a single child input element.

13.3.6. The binding element

Example 13.13. The binding construct hosting concrete operation definitions.

13.3.7. The input and output elements (when used with binding)

Example 13.14. input and output elements providing message processing information.

13.3.8. The service, port, and endpoint elements

Example 13.15. The service and port elements establishing the physical service address.

13.3.9. The import element

Example 13.16. The import element referencing a schema document.

13.3.10. The documentation element

Example 13.17. The documentation element providing a description of the overall service interface.

13.4. SOAP language basics

Figure 13.6. The structure of a SOAP message document. 13.4.1. The Envelope element

Example 13.18. The root Envelope construct hosting Header and Body constructs.

13.4.2. The Header element

Example 13.19. The Header construct hosting a header block.

13.4.3. The Body element

Figure 13.7. A SOAP message body defined within the WSDL message construct. The actual processing of the SOAP message via a wire protocol is governed by the constructs within the concrete definition. Example 13.20. The contents of a sample Body construct.

13.4.4. The Fault element

Example 13.21. The Fault construct residing within the Body construct.

13.5. Service interface design tools

13.5.1. Auto-generation 13.5.2. Design tools 13.5.3. Hand coding

Chapter 14. Service-Oriented Design (Part II: SOA Composition Guidelines)

14.1. Steps to composing SOA

Figure 14.1. The most fundamental components of an SOA. Figure 14.2. Suggested steps for composing a preliminary SOA. 14.1.1. Step 1: Choose service layers 14.1.2. Step 2: Position core standards 14.1.3. Step 3: Choose SOA extensions

14.2. Considerations for choosing service layers

Figure 14.3. Designated service layers organize and standardize Web services within SOA.

14.3. Considerations for positioning core SOA standards

Figure 14.4. SOA can structure the manner in which common XML and Web services standards are applied. 14.3.1. Industry standards and SOA

Figure 14.5. The operational relationship between core SOA specifications.

14.3.2. XML and SOA

RPC-style versus document-style SOAP messages Auto-generated XML Fitting SOA on top of an established XML data representation architecture

14.3.3. The WS-I Basic Profile 14.3.4. WSDL and SOA

Standardized use of namespaces Modular service definitions Compatibility of granularity

14.3.5. XML Schema and SOA

Modular XSD schemas Document-style messages and XSD schemas

14.3.6. SOAP and SOA

SOAP message style and data types SOAP headers

14.3.7. Namespaces and SOA 14.3.8. UDDI and SOA

Figure 14.6. A composed view of the core standards that comprise part of RailCo's planned SOA.

14.4. Considerations for choosing SOA extensions

Figure 14.7. WS-* extensions allow for individual SOAs to be uniquely composed. 14.4.1. Choosing SOA characteristics 14.4.2. Choosing WS-* specifications 14.4.3. WS-BPEL and SOA

Figure 14.8. WS-BPEL realizing the orchestration service sub-layer within our service layer. Figure 14.9. A composed view of the SOA TLS is planning for the Timesheet Submission solution.

Chapter 15. Service-Oriented Design (Part III: Service Design)

15.1. Service design overview

15.1.1. Design standards 15.1.2. About the process descriptions 15.1.3. Prerequisites

15.2. Entity-centric business service design (a step-by-step process)

Figure 15.1. Entity-centric services establish the business service layer. 15.2.1. Process description

Figure 15.2. The entity-centric business service design process. Figure 15.3. The Employee Service candidate. Step 1: Review existing services Figure 15.4. The existing inventory of TLS services. Step 2: Define the message schema types Example 15.1. The Employee schema providing complexType constructs used to establish the data representation anticipated for the "Get weekly hours limit" operation candidate. Example 15.2. The EmployeeHistory schema, with a different targetNamespace to identify its distinct origin. Figure 15.5. Two schemas originating from two different data sources. Example 15.3. The WSDL types construct being populated by imported schemas. Step 3: Derive an abstract service interface Figure 15.6. The Employee Service operations. Example 15.4. The message and portType parts of the Employee Service definition that implement the abstract definition details of the two service operations. Step 4: Apply principles of service-orientation Example 15.5. The service interface, supplemented with additional metadata documentation. Step 5: Standardize and refine the service interface Figure 15.7. The revised Employee Service operation names. Example 15.6. The two operation constructs with new, standardized names. Step 6: Extend the service design Figure 15.8. An Employee Service offering a full range of operations. Example 15.7. An expanded portType construct. Step 7: Identify required processing Figure 15.9. The revised composition hierarchy identifying new potential application services. Example 15.8. The final abstract service definition.

15.3. Application service design (a step-by-step process)

Figure 15.10. Application services establish the bottom sub-layer of the service layer. 15.3.1. Process description

Figure 15.11. The application service design process. Figure 15.12. The Transform Accounting Documents Service candidate. Step 1: Review existing services Step 2: Confirm the context Step 3: Derive an initial service interface Figure 15.13. The first cut of the Transform Accounting Documents Service. Example 15.9. The XSD schema types required by the TransformToNative operation. Example 15.10. The additional tpes for use by the TransformToXML operation. Example 15.11. The message and portType constructs of the abstract Transform Accounting Documents Service definition. Step 4: Apply principles of service-orientation Example 15.12. The Transform Accounting Documents portType construct with supplemental metadata documentation. Step 5: Standardize and refine the service interface Figure 15.14. The final design of the Transform Service. Example 15.13. The revised types construct. Step 6: Outfit the service candidate with speculative features Step 7: Identify technical constraints Example 15.14. The final abstract service definition.

15.4. Task-centric business service design (a step-by-step process)

Figure 15.15. Task-centric business services can comprise the business service layer, along with entity-centric neighbors. 15.4.1. Process description

Figure 15.16. The task-centric business service design process. Figure 15.17. The Invoice Processing Service candidate. Figure 15.18. The Invoice Processing Service composition. Step 1: Define the workflow logic Figure 15.19. A successful completion of the Invoice Submission Process. Figure 15.20. A failure condition caused by an error during the transformation step. Step 2: Derive the service interface Figure 15.21. Identified requests and responses for the Invoice Processing Service. Figure 15.22. The Invoice Processing Service with a new operation. Example 15.15. A complexType construct designed to receive two parameters from the Polling Notification Service. Example 15.16. The remaining parts of the abstract Invoice Processing Service definition establishing an operation with just one input message. Step 3: Apply principles of service-orientation Example 15.17. The portType construct with an additional documentation element. Step 4: Standardize and refine the service interface Example 15.18. The revised types construct of the Invoice Processing Service definition. Example 15.19. The documentation element contents also have been changed. Figure 15.23. The Invoice Processing Service with a revised operation name. Example 15.20. The revised message and portType constructs. Step 5: Identify required processing Example 15.21. The final abstract service definition.

15.5. Service design guidelines

15.5.1. Apply naming standards 15.5.2. Apply a suitable level of interface granularity 15.5.3. Design service operations to be inherently extensible 15.5.4. Identify known and potential service requestors 15.5.5. Consider using modular WSDL documents

Example 15.22. An import element used to pull in the bindings construct residing in a separate file.

15.5.6. Use namespaces carefully

Example 15.23. The namespace declarations within the definitions element of the TLS Employee.wsdl file.

15.5.7. Use the SOAP document and literal attribute values

Example 15.24. The binding construct of the TLS Employee.wsdl document.

15.5.8. Use WS-I Profiles even if WS-I compliance isn't required 15.5.9. Document services with metadata

Chapter 16. Service-Oriented Design (Part IV: Business Process Design)

16.1. WS-BPEL language basics

Figure 16.1. A common WS-BPEL process definition structure. 16.1.1. A brief history of BPEL4WS and WS-BPEL 16.1.2. Prerequisites 16.1.3. The process element

Example 16.1. A skeleton process definition.

16.1.4. The partnerLinks and partnerLink elements

Example 16.2. The partnerLinks construct containing one partnerLink element in which the process service is invoked by an external client partner and four partnerLink elements that identify partner services invoked by the process service.

16.1.5. The partnerLinkType element

Example 16.3. A WSDL definitions construct containing a partnerLinkType construct.

16.1.6. The variables element

Example 16.4. The variables construct hosting only some of the child variable elements used later by the Timesheet Submission Process.

16.1.7. The getVariableProperty and getVariableData functions

getVariableProperty(variable name, property name) getVariableData(variable name, part name, location path) Example 16.5. Two getVariableData functions being used to retrieve specific pieces of data from different variables.

16.1.8. The sequence element

Example 16.6. A skeleton sequence construct containing only some of the many activity elements provided by WS-BPEL.

16.1.9. The invoke element

Table 16.1. invoke element attributes Example 16.7. The invoke element identifying the target partner service details.

16.1.10. The receive element

Table 16.2. receive element attributes Example 16.8. The receive element used in the Timesheet Submission Process definition to indicate the client partner service responsible for launching the process with the submission of a timesheet document.

16.1.11. The reply element

Table 16.3. reply element attributes Example 16.9. A potential companion reply element to the previously displayed receive element.

16.1.12. The switch, case, and otherwise elements

Example 16.10. A skeleton case element wherein the condition attribute uses the getVariableData function to compare the content of the EmployeeResponseMessage variable to a zero value.

16.1.13. The assign, copy, from, and to elements

Example 16.11. Within this assign construct, the contents of the TimesheetSubmissionFailedMessage variable are copied to two different message variables.

16.1.14. faultHandlers, catch, and catchAll elements

Example 16.12. The faultHandlers construct hosting catch and catchAll child constructs.

16.1.15. Other WS-BPEL elements

Table 16.4. Quick reference table providing short descriptions for additional WS-BPEL elements (listed in alphabetical order).

16.2. WS-Coordination overview

16.2.1. The CoordinationContext element

Example 16.13. A skeleton CoordinationContext construct.

16.2.2. The Identifier and Expires elements

Example 16.14. Identifier and Expires elements containing values relating to the header.

16.2.3. The CoordinationType element 16.2.4. The RegistrationService element

Example 16.15. The RegistrationService element containing a URL pointing to the location of the registration service.

16.2.5. Designating the WS-BusinessActivity coordination type

Example 16.16. The CoordinationType element representing the WS-BusinessActivity protocol.

16.2.6. Designating the WS-AtomicTransaction coordination type

Example 16.17. The CoordinationType element representing the WS-AtomicTransaction protocol.

16.3. Service-oriented business process design (a step-by-step process)

Figure 16.2. A concrete definition of a process service designed using a process modeling tool. 16.3.1. Process description

Figure 16.3. A high-level process for designing business processes. Figure 16.4. The original TLS Timesheet Submission Process. Figure 16.5. Service designs created so far. Figure 16.6. The original service composition defined during the service modeling stage. Figure 16.7. The Timesheet Submission Process Service candidate. Step 1: Map out interaction scenarios Figure 16.8. A successful completion of the Timesheet Submission Process. Figure 16.9. A failure condition caused by an authorization rejection. Figure 16.10. The incoming and outgoing request messages expected to be processed by the Timesheet Submission Process Service. Step 2: Design the process service interface Figure 16.11. Timesheet Submission Process Service design. Example 16.18. The abstract service definition for the Timesheet Submission Process Service. Step 3: Formalize partner service conversations Example 16.19. The revised Employee service definitions construct. Example 16.20. The partnerLinks construct containing partnerLink elements for each of the process partner services. Example 16.21. The variables construct containing individual variable elements representing input and output messages from all partner services and for the process service itself. Step 4: Define process logic Figure 16.12. A descriptive, diagrammatic view of the process definition logic. Example 16.22. The receive element providing an entry point by which the process can be initiated. Example 16.23. The assign and copy constructs hosting a from element that retrieves customer billing information from the message stored in the ClientSubmission variable and a to element that is used to assign these values to the InvoiceHoursRequest variable. Example 16.24. The invoke element containing a series of attributes that provide all of the information necessary for the orchestration engine to locate and instantiate the Invoice Service. Example 16.25. The switch construct hosting a case element that uses the getVariableData function within its condition attribute to compare hours billed against hours recorded. Example 16.26. The faultHandlers construct used in this process. Figure 16.13. A visual representation of the process logic within the faultHandlers construct. Example 16.27. Two copy elements used to populate the EmployeeHistoryRequest message. Example 16.28. The last activities in the process. Step 5: Align interaction scenarios and refine process (optional) Figure 16.14. Sequential, synchronous execution of process activities. Figure 16.15. Concurrent execution of process activities using the flow construct.

Chapter 17. Fundamental WS-* Extensions

You must Understand this 17.1. WS-Addressing language basics

Figure 17.1. How WS-Addressing relates to the other WS-* specifications discussed in this chapter. 17.1.1. The EndpointReference element

Table 17.1. WS-Addressing endpoint reference elements. Example 17.1. A SOAP header containing the EndpointReference construct.

17.1.2. Message information header elements

Table 17.2. WS-Addressing message information header elements Example 17.2. A SOAP header with WS-Addressing message information header elements, three of which contain Endpoint Reference elements.

17.1.3. WS-Addressing reusability

Example 17.3. A sample WS-Notification SOAP header for a notification message. Example 17.4. A sample WS-Eventing SOAP header for a notification message.

17.2. WS-ReliableMessaging language basics

Figure 17.2. How WS-ReliableMessaging relates to the other WS-* specifications discussed in this chapter. 17.2.1. The Sequence, MessageNumber, and LastMessage elements

Example 17.5. A Sequence construct with a LastMessage element, indicating that this is the final message in the sequence.

17.2.2. The SequenceAcknowledgement and AcknowledgementRange elements

Example 17.6. A SequenceAcknowledgement construct indicating that 11 out of a sequence of 15 messages were received.

17.2.3. The Nack element

Example 17.7. A SequenceAcknowledgement construct containing a Nack element that indicates that the fifth message was not received.

17.2.4. The AckRequested element

Example 17.8. The AckRequested header construct indicating that the RM source would like to receive a sequence acknowledgement message.

17.2.5. Other WS-ReliableMessaging elements

Table 17.3. Additional WS-ReliableMessaging elements.

17.3. WS-Policy language basics

Figure 17.3. How WS-Policy relates to the other WS-* specifications discussed in this chapter. 17.3.1. The Policy element and common policy assertions 17.3.2. The ExactlyOne element

Example 17.9. The ExactlyOne construct housing two alternative policy assertions, one of which must be used.

17.3.3. The All element

Example 17.10. The All and ExactlyOne constructs used together to provide two alternative policy groups.

17.3.4. The Usage attribute

Table 17.4. Possible settings for the Usage attribute.

17.3.5. The Preference attribute 17.3.6. The PolicyReference element

Example 17.11. Separate PolicyReference elements referencing two policy documents.

17.3.7. The PolicyURIs attribute

Example 17.12. The PolicyURIs attribute referencing two policy documents.

17.3.8. The PolicyAttachment element

Example 17.13. The PolicyAttachment construct using the child AppliesTo construct to associate a policy with a WS-Addressing EndpointReference construct.

17.3.9. Additional types of policy assertions

17.4. WS-MetadataExchange language basics

Figure 17.4. How WS-MetadataExchange relates to the other WS-* specifications discussed in this chapter. 17.4.1. The GetMetadata element

Example 17.14. A SOAP request message containing the GetMetadata element in the Body construct. Note the use of the WS-Addressing message information header elements in the SOAP header.

17.4.2. The Dialect element

Example 17.15. The Dialect element being used to indicate that the XSD schema requested should comply to version 1.0 of the XML Schema Definition Language.

17.4.3. The Identifier element

Example 17.16. The Identifier element added to specify the XSD schema's target namespace.

17.4.4. The Metadata, MetadataSection, and MetadataReference elements

Example 17.17. A GetMetadata response message returning the contents of an entire WSDL definition, along with a pointer to the associated XSD schema.

17.4.5. The Get message

Example 17.18. A Get message SOAP header identified by the Action element value. The resource being requested is targeted in the To element.

17.5. WS-Security language basics

Figure 17.5. How WS-Security relates to the other WS-* specifications discussed in this chapter. 17.5.1. The Security element (WS-Security) 17.5.2. The UsernameToken, Username, and Password elements (WS-Security) 17.5.3. The BinarySecurityToken element (WS-Security) 17.5.4. The SecurityTokenReference element (WS-Security)

Example 17.19. The Security SOAP header used by RailCo to provide user name and password values.

17.5.5. Composing Security element contents (WS-Security)

Example 17.20. The WS-Security SOAP header hosting a SAML authorization assertion.

17.5.6. The EncryptedData element (XML-Encryption) 17.5.7. The CipherData, CipherValue, and CipherReference elements (XML-Encryption)

Example 17.21. An XML document within a SOAP message containing an encrypted element.

17.5.8. XML-Signature elements

Table 17.5. XML-Signature elements Example 17.22. A SOAP message header containing a digital signature.

Chapter 18. SOA Platforms

18.1. SOA platform basics

18.1.1. Basic platform building blocks

Figure 18.1. Fundamental software technology architecture layers.

18.1.2. Common SOA platform layers

Figure 18.2. The common layers required by a development and runtime platform for building SOA.

18.1.3. Relationship between SOA layers and technologies

Figure 18.3. A logical view of the basic relationships between the core parts of a service-oriented architecture.

18.1.4. Fundamental service technology architecture

Service processing tasks Service processing logic Figure 18.4. A service provider consisting of message processing and business logic. Table 18.1. Service provider logic categorization. Figure 18.5. A revised service provider model now including an endpoint within the message processing logic. Figure 18.6. A service requestor consisting of message processing and business logic. Table 18.2. Service requestor logic categorization. Message processing logic Figure 18.7. An example of the types of processing functions that can comprise the message processing logic of a service. Figure 18.8. The message processing logic part of a service requestor includes a proxy component. Business logic Figure 18.9. The same unit of business logic participating within a service provider and a service requestor. Figure 18.10. One unit of business logic being encapsulated by two different service providers. Figure 18.11. The same unit of business logic facilitating a service provider and acting on its own by communicating independently with a separate component. Service agents Figure 18.12. Service agents processing incoming and outgoing SOAP message headers.

18.1.5. Vendor platforms

18.2. SOA support in J2EE

18.2.1. Platform overview

Figure 18.13. Relevant layers of the J2EE platform as they relate to SOA. Figure 18.14. How parts of the J2EE platform inter-relate. Architecture components Runtime environments Programming languages APIs Service providers Figure 18.15. A typical J2EE service provider. Service requestors Figure 18.16. A typical J2EE service requestor. Service agents Figure 18.17. J2EE handlers as service agents. Platform extensions

18.2.2. Primitive SOA support

Service encapsulation Loose coupling Messaging

18.2.3. Support for service-orientation principles

Autonomy Reusability Statelessness Discoverability

18.2.4. Contemporary SOA support

Based on open standards Supports vendor diversity Intrinsically interoperable Promotes federation Architecturally composable Extensibility Supports service-oriented business modeling Logic-level abstraction Organizational agility and enterprise-wide loose coupling

18.3. SOA support in .NET

18.3.1. Platform overview

Figure 18.18. Relevant layers of the .NET framework, as they relate to SOA. Figure 18.19. How parts of the .NET framework inter-relate. Architecture components Runtime environments Programming languages APIs Service providers Figure 18.20. A typical .NET service provider. Service requestors Figure 18.21. A typical .NET service requestor. Service agents Figure 18.22. Types of .NET service agents. Platform extensions

18.3.2. Primitive SOA support

Service encapsulation Loose coupling Messaging

18.3.3. Support for service-orientation principles

Autonomy Reusability Statelessness Discoverability

18.3.4. Contemporary SOA support

18.4. Integration considerations

Figure 18.23. Disparate solutions communicating freely across an open communications platform. A testament to the inherent interoperability established by SOA.

Appendix A. Case Studies: Conclusion

A.1. RailCo Ltd.

Figure A.1. RailCo's service composition that automates its Invoice Submission Process. Figure A.2. The Order Fulfillment Process is automated by a PO Processing Service that composes two reusable application services.

A.2. Transit Line Systems Inc.

Figure A.3. The service layers established by TLS's new SOA.

A.3. The Oasis Car Wash

Appendix B. Service Models Reference

Table B-1. An overview of service models.

About the Author About SOA Systems About the Photographs Index

Symbol A B C D E F G H I J K L M N O P Q R S T U V W X

← Prev
Back
Next →

← Prev
Back
Next →