Esb Interoperability Standards Freund
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Esb Interoperability Standards Freund as PDF for free.
More details
- Words: 3,440
- Pages: 17
ESB Interoperability Standards
ESB Interoperability Standards Date: 02 June 2008 Authors: Thomas Freund STSM, IBM SWG Strategy Peter Niblett STSM, IBM SWG WebSphere Messaging Architecture
© Copyright IBM Corporation 2008 All rights reserved.
06/02/2008
ESB Interoperability Standards
06/02/2008
Abstract and Executive Summary Thousands of Enterprises worldwide have adopted the principles of Service Oriented Architecture (SOA). SOA provides an architectural approach that brings the flexibility and agility required by today’s global business environment. An Enterprise Service Bus (ESB) is a vital ingredient of SOA that facilitates the interaction of business services by mediating the message exchanges between them. ESB infrastructure products are available from a number of software vendors, but there is a lack of consistency between them when it comes to standards support. This has led a number of ESB customers to ask for an industry-wide agreed list of standards supported by an ESB. This Whitepaper documents the essential standards requirements for an ESB, using a scenario-based approach. This Whitepaper is directed toward analysts, customers and partners, and is intended to facilitate: 1. Market Growth: Grow the market for ESB infrastructure by removing marketplace confusion. Provide a clear & universal understanding of the ESB standardization requirements. 2. Industry Adoption: Ensure functional requirements and interoperability guarantees are met across a heterogeneous system-wide environment. 3. Customer Benefit: Provide the assurances of flexibility and interoperability derived from solutions built on standards. 4. Standards Development: Solidify the ESB definition by ensuring precision through standards and profiles.
ESB Interoperability Standards
06/02/2008
Table of Contents Abstract and Executive Summary....................................................................................... 2 Table of Contents................................................................................................................ 3 1 Introduction................................................................................................................. 4 1.1 1.2
2 3
ESB and Web service Standards................................................................................. 7 ESB Scenarios............................................................................................................. 9 3.1 3.2
4
Routing ................................................................................................................................. 9 Conversion.......................................................................................................................... 11
Profile Relationship .................................................................................................. 13 4.1 4.2
5 6
SOA & ESB Positioning....................................................................................................... 4 ESB Definition...................................................................................................................... 4
WS-I Profiles ...................................................................................................................... 13 Requirements for additional Profiles .................................................................................. 13
Summary ................................................................................................................... 15 References................................................................................................................. 16
ESB Interoperability Standards
06/02/2008
1 Introduction This section very briefly articulates the overall rationale for Enterprise Service Bus (ESB) standards. The value of an ESB is derived from how it augments a Service Oriented Architecture and as such, it needs to support standards.
1.1 SOA & ESB Positioning A Service Oriented Architecture (SOA) is a software model in which the concept of a ‘service’ is an abstraction of a function used by an application. SOA logically decouples the service requester from the service provider by isolating the service definition from a service implementation. SOA addresses the business demand for applications to be responsive to business needs and to adapt to dynamic business environments. In SOA, services may be defined as Web services to provide a standards-based approach to interoperability. The Service Component Architecture (SCA) builds on open-standards such as Web services and augments SOA by: a.) providing a cross-language programming model that promotes reuse and b.) defining a flexible and agile mechanism with which to assemble applications. The ESB provides a vital ingredient of the SOA environment. An ESB decouples the service requester from the service provider by mediating (if necessary) the service interaction between communicating participants. We call this decoupling service virtualization. Interposed between requester and provider, an ESB simplifies service connectivity by dealing with the service selection process and handling any mismatches that might occur. For example the requesters and providers might have different security or reliability requirements, or the interface provided by the service might not exactly match the interface expected by the requester. In a SOA environment one often needs to facilitate the communications between service requesters and service providers that possess differing service characteristics (in such cases, service metadata may be available that describes a service’s requirements, capabilities or other general information regarding service usage). An ESB can also be used to introduce additional functionality into the communications path between interacting services. We call this aspect-oriented connectivity. We discuss service virtualization and aspect-oriented connectivity in more detail in the next section.
1.2 ESB Definition
ESB Interoperability Standards
06/02/2008
An ESB enables services to be connected into solutions - even if they were not originally designed to work with each other. An ESB is a recommended element for any SOAbased solution that requires mediation to facilitate a requester-provider interchange. An ESB includes a distributed, configurable infrastructure, whose tasks are to provide: • Routing: The ESB acts as a match-maker between service requester and service provider. • Conversion: The ESB handles protocol or interaction differences. • Transformation: The ESB can be programmed to handle interface mismatches that might occur and compensate accordingly, if possible. • Aspect-oriented connectivity: Additional “added-value” functionality. The services that connect to the ESB may declare their service characteristics or their expectations relating to service interactions (including any requirements on other participants). An ESB provides service virtualization for the following essential mediation functional elements: • Identity or location – participants need not know the identity or location of other participants, e.g., requesters need not be aware that a request could be serviced by any of several providers; service requesters and providers can be added or removed without disruption. Hides service identity or location Determines appropriate service from candidate providers Routes messages between requester & provider • Interaction pattern or protocol – requesters need not share the same communication protocol or interaction pattern. Interaction partners may chose to use one-way, request/response, asynchronous, synchronous, and publish/subscribe type interactions Handles service interaction differences Converts transport protocols Adapts differing interaction patterns • Interface – requesters and providers need not agree on common interface. The ESB reconciles syntactic differences by transforming request messages into a form expected by the provider. Handles service interface differences Translates message formats An ESB also provides aspect oriented connectivity supplying operational characteristics that apply across the participants such as security, management, logging, auditing, etc. that may be required in an enriched business environment. In order to provide this additional functionality an ESB may make use of general-purpose SOA utilities that supply such capabilities. These utilities could include a security service, registry/repository service, logging service, etc.
ESB Interoperability Standards
06/02/2008
An ESB performs the following between requestor and service
` MATCHES & ROUTES communications between services
` CONVERTS between different transport protocols
` TRANSFORMS between different data formats
` IDENTIFIES & DISTRIBUTES business events Shape = Transport protocol Color = Data format
The ESB is given responsibility for delivering messages between requesters and providers, ensuring the required functionality as defined for the interaction. Service requesters send requests which are then mediated (if required) by the ESB. The ESB routes and transforms each request message into a format acceptable to the service provider. Service providers receive these requests and can react to them without having to know about a request's origin. Similar mediation takes place for any response message sent back by the service provider. The ESB is transparent to the service requesters and providers: it matches a service requester’s requirements with a service provider’s capability, adding value to service interactions without changing the service providers or requesters themselves. Web services standards (WS-*) have a critical role to play where interoperability between disparate ESB implementations is needed. By providing an ESB that offers WS-* support a customer has the assurance of flexibility and interoperability that such a standardsbased approach provides. In addition, an ESB that provides WS* support can provide a convenient way to add Web service connectivity to existing applications that lack Web service interfaces. This whitepaper proposes a set of WS-* standards relevant to the various ESB facilities. Note that this definition of an ESB does not include Service Choreography or Process Management. These form key parts of SOA, but we view them as complementary to an ESB, rather than functions provided in the ESB itself. For additional information on the details of the ESB definition see “Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution” [flurry2007].
ESB Interoperability Standards
06/02/2008
2 ESB and Web service Standards This section of the whitepaper lists a set of Web services standards that are relevant to an ESB. These standards relate to connectivity of service requesters and service providers, and communications between ESBs. The aim of this proposal is to help establish an industry-wide consensus on the set of applicable standards for Web services-based ESB implementations. Section 3.0, ESB Scenarios provides use cases to illustrate the applicability of the Web service standards. Many of these Web services standards are contained in Web service Interoperability (WS-I) Profiles. Section 4.0, Profile Relationship discusses ESB-related WS-I profile requirements. In this section, we identify how standard protocols may be used to enable interoperability between ESBs or between an ESB and the services that use it. Requesters and providers that utilize an ESB that conforms to a standards-based solution will gain the benefits that such an approach provides for the interactions between them. It is to be expected that ESBs will also support connectivity using specifications other than those listed in this section, for example an ESB might support communications via the Java™ Message Service (JMS). We subdivide this area into the following interoperability aspects: • Transfer: Communication protocols that transfer messages between service endpoints. An ESB must support the use of HTTP or HTTPS as a transfer protocol to carry messages between the service requester and the service provider. An ESB may support other transport mechanisms, for example JMS. • Message Format and Protocols: Messaging protocols define both the message structure and rules governing the processing along the message path between message participants. An ESB must support the use of XML [XML] messages that use SOAP 1.1 [SOAP 1.1] or SOAP 1.2 [SOAP 1.2] as the message format and protocol for message exchange. It must include support for SOAP XML messages which have binary content that has been serialized as a MIME multipart message using the mechanisms defined by MTOM [MTOM] and XOP [XOP]. It may support SOAP with Attachments [SwA]. An ESB must also support asynchronous SOAP messaging through the use of WS-Addressing [WSADDR] Message Addressing Properties. An ESB may also support non-SOAP interaction, specifically REST-style messages encoded in XML. See also: Service Definition (WSDL and XSD). • Identity or Location: A definition of the addressing and the message header information required in a message exchange. An ESB must support the use of WS-Addressing [WSADDR] ‘endpoint references’ to convey addressing information of the service requesters and service providers. It should also support
ESB Interoperability Standards
•
•
06/02/2008
use of the WS-Addressing Message Addressing Properties. These enrich a message by adding header elements used for routing. Quality of Service: Enriches a standard message exchange with extended aspects of requester-supplier interaction. Such Qualities of Service are frequently required in enterprise business applications. ESBs must support WS-Security [WSSec], [WSSec 1.1] and WS-ReliableMessaging [WS-ReliableMessaging] [WSReliableMessaging][WS-ReliableMessaging][WS-ReliableMessaging][WSReliableMessaging]and may support WS-SecureConversation [WSSecConv], WS-Trust [WSTrust][WSTrust][WSTrust][WSTrust][WSTrust], and WSFederation [WS-Federation]. Service Definition: An ESB must support the use of WSDL 1.1 to describe Service interfaces, with XML Schema being used as the way of representing the format of data used in XML-based message exchanges. XML provides a platform neutral mechanism for transferring data between services. An ESB may use additional (proprietary) bindings in conjunction with XML Schema, to describe the structure of binary and character encoded (ASCII/Unicode) messages. Service Component Description Language (SCDL) may be used to describe the requester and the provider’s capabilities of a service component, and any requirements it has on its interactions with other services.
Topic
Standard Required
Transfer
Feature
HTTP 1.1, HTTPS
Message Format and Protocols SOAP 1.1 / 1.2 MTOM/XOP XML1.0
SOAP with Attachments
Identity or Location
WS-Addressing 1.0
Quality of Service
WS-Security 1.1, WS-ReliableMessaging 1.1
WS-SecureConversation 1.3, WS-Trust. WS-Federation
Service Definition
WSDL 1.1, XML Schema
SCDL
ESB Interoperability Standards
06/02/2008
3 ESB Scenarios The previous section listed the proposed standards that underpin an interoperable, programmable and manageable ESB. In this section we illustrate the use of such standards by means of a set of scenarios. The scenarios are based on a fictional company that is using an ESB to physically decouple its SOA service requesters and providers, so as to give it the flexibility to implement applications more quickly. The company has decided that open standards should be used for specific aspects of its ESB. These scenarios are intended to illustrate the use of standards and are not meant to be an exhaustive list of ESB scenarios. The scenarios listed here could be varied, for example by using different transport protocols.
3.1 Routing Use case requirement: The fictional company wants to virtualize the identity or location of its services. This means that its service requesters need not be aware of the identity or location of the service providers, but requests from these requesters are routed to a provider based on a series of criteria such as specific requestor or provider characteristics, request type or other environmental information. In this simple routing scenario, all interacting participants, both service requesters and providers are illustrated using SOAP/HTTP bindings 1 for their interactions, and a request may be serviced by any of several service providers. Additional service requesters and providers can be added to the system, and messages can be routed to them, without disrupting the requesters. The Service Requesters are not aware of these service providers, and do not connect directly to them. Instead they connect via an intermediary 2 (mediation) provided by the ESB. That intermediary implements the same interface as the “real” service providers. The ESB may be configured to deal with response messages in one of two ways. As the service provider responses flow back through the ESB, either they can be sent directly to the service requester, or the ESB can perform mediation function such as routing. The ESB can control this by the way that it sets the request message’s WS-Addressing [reply endpoint] MAP. The ESB mediation, constructed at development time, is associated at deployment time with the service providers which it will select between at run-time. In this simple scenario the mediation logic selects the service provider at random from this static list of possible providers.
1
Although not shown, this services selection scenario might involve REST services. The scenario illustrates a generally common ESB pattern of an explicit intermediary however this is not meant to preclude other configurations i.e. it does not dictate either the placement of the mediation function or restrict the form of access to ESB.
2
ESB Interoperability Standards
06/02/2008
ESB Service Requester
Transform
Route
XML Message
Service Provider
SOAP/HTTP WS-Addressing
Legend Relevant Element ESB Function Exercised
Requirement
Specification
Transfer
HTTP 1.1
Message Format and Protocols
SOAP 1.1 or 1.2
Identity or Location
WS-Addressing 1.0
Service Definition
XML Schema WSDL 1.1
ESB Interoperability Standards
06/02/2008
3.2 Conversion Scenario: A company has some internal services that expose SOAP/JMS interfaces, and wishes to make them available to requesters via SOAP/HTTP interfaces. Use case requirement: The ESB handles the conversion between transport protocols and adapts between differing interaction patterns. The Service providers continue to support their SOAP/JMS interfaces, unchanged. The ESB publishes new SOAP/HTTP endpoints, with the same WSDL portTypes as the original services, and maps HTTP messages to JMS messages and vice versa. Since the new endpoint and its corresponding original Service Provider both have the same service interface (WSDL portType) the actual message bodies can be converted in a mechanical fashion, without the need for the transformation discussed in the previous scenario. In the version of the scenario described here the SOAP/HTTP service definition includes assertions that indicate that the service Requesters have to use asynchronous WSAddressing (non-anonymous replyTo references). This means that the ESB can simply map HTTP requests to JMS requests and JMS responses to HTTP responses as they arrive. The ESB could also choose to publish endpoints that support synchronous SOAP/HTTP invocation. In such a case the ESB would have to keep the requester’s HTTP connection active until it received the JMS response from the original service provider.
Service Interface Definition WSDL
WSDL
ESB Service Requester
Transform
“protocol 1” SOAP/HTTP WS-Addressing
Legend Unused
Relevant Element ESB Function Exercised
Route
“protocol 2” SOAP/JMS
Service Provider
ESB Interoperability Standards
06/02/2008
Requirement
Specification
Transfer
HTTP 1.1, JMS
Message Format and Protocols
SOAP 1.1 or 1.2.
Identity or Location
WS-Addressing 1.0
Service Definition
XML Schema WSDL 1.1
ESB Interoperability Standards
06/02/2008
4 Profile Relationship 4.1 WS-I Profiles The Web service Interoperability (WS-I) Profiles provide implementation guidelines for how related Web services specifications should be used together for best interoperability. WS-I have defined or are working on the following profiles: • WS-I Basic Profile, • WS-I Attachments Profile • WS-I Simple SOAP Binding Profile • WS-I Basic Security Profile • WS-I Reliable Secure Profile
Additional WS-I Profiles
WS -I Reliable Secure Profile WS-SecureConversation WS-ReliableMessaging Token Profiles
WS -I Basic Security Profile
WS-Security WS -I Basic Profile
WS -I Attachments Profile
WS-I Simple SOAP Profile
Figure: WS-I Profiles
4.2 Requirements for additional Profiles The definition of additional profiles related to ESB environments is a logical follow-on work effort based on the material contained in this document. It is expected that one or more profiles may be required to cover the range of customer use case requirements (as outlined in section 3).
ESB Interoperability Standards
06/02/2008
A profile is defined to contain the following sections: 1. A scope statement which describes the problem domain addressed by the Profile (which may be a reproduction of segments of the business summary). The ESB use cases contained in this document provide a general understanding of the standards requirements associated with an overall ESB customer scenario. Any profile definition is driven by general customer usage scenarios. 2. A list of referenced specifications including specification levels. This also includes other Profiles since Profiles, like the specifications they reference, are composable. 3. A set of “requirements” that constitute constraints on the underlying specification and/or guidance concerning how to use the referenced specifications to best achieve interoperability. Such definitions are beyond the scope of this document. The set of current WS-I profiles that would be referenced in an additional ESB-related Profile includes: • • •
WS-I Basic Security Profile WS-I Basic Profile (1.1 or higher) WS-I Reliable Secure Profile
ESB Interoperability Standards
06/02/2008
5 Summary ESBs extend the capabilities of SOA and advance the realization of SOA. Mediations can be employed to facilitate interactions between mismatched service requesters and providers. The ESB also provides a common model for accessing, managing and administering system-wide services. Today's fast-paced business world demands the ability to change and adapt rapidly. With an Enterprise Service Bus, you can connect your business applications and processes quickly and easily as you respond to business challenges and opportunities when they arise. By adopting a standards-based approach leveraging Web services a customer has the assurance of the flexibility and the interoperability that such a strategy provides.
ESB Interoperability Standards
06/02/2008
6 References ESB •
[esb2004] “Understand Enterprise Service Bus scenarios and solutions in ServiceOriented Architecture, Part 1” • [ibmSJ2005] “The Enterprise Service Bus: Making service-oriented architecture real”, http://www.research.ibm.com/journal/sj/444/schmidt.html • [schmidt2005] “SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus” • [snell2005] “Simplify integration architectures with an Enterprise Service Bus” • [flurry2007] “Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution”, http://www128.ibm.com/developerworks/library/ar-esbpat1/ Whitepapers • [SOAfoundation] “IBM SOA Foundation: An architectural introduction and overview” Specifications • [MTOM] W3C Recommendation, "SOAP Message Transformation Optimization Mechanism" http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/, 25 January 2005. • [SOAP 1.1] W3C Note, "SOAP: Simple Object Access Protocol 1.1," http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, 08 May 2000. • [SwA] W3C Note, "SOAP Messages with Attachments" http://www.w3.org/TR/SOAP-attachments, 11 December 2000. • [SOAP 1.2] W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework", http://www.w3.org/TR/soap12-part1/, June 2003. • [WSADDR] Web services Addressing (WS-Addressing), Web services Addressing (WS-Addressing) 1.0, W3C Recommendation, http://www.w3.org/2005/08/addressing • [WSDL] Web services Description Language (WSDL) 1.1 "http://www.w3.org/TR/2001/NOTE-wsdl-20010315" • [WS-Federation] Web Services Federation (WS-Federation) 1.1, http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WSFederation-V1-1B.pdf?S_TACT=105AGX04&S_CMP=LP • [WS-ReliableMessaging] [WS-ReliableMessaging] Web Services Reliable Messaging (WS-ReliableMessaging) 1.1, http://docs.oasis-open.org/wsrx/wsrm/200702/wsrm-1.1-spec-os-01-e1.pdf • [WSSec] OASIS Standard 200401, March 2004, "Web services Security: SOAP Message Security 1.0 (WS-Security 2004), "http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf • [WSSec 1.1] OASIS Standard, February 2006, "Web services Security: SOAP Message Security 1.1 (WS-Security 2004), http://docs.oasisopen.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
ESB Interoperability Standards • • • • • • •
06/02/2008
[WSSecConv] Web services Secure Conversation (WS-SecureConversation) 1.3, http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/wssecureconversation-1.3-os.doc. [WSTrust] Web services Trust (WS-Trust) 1.3, http://docs.oasis-open.org/wssx/ws-trust/200512/ws-trust-1.3-os.doc. [XML] W3C Recommendation, "Extensible Markup Language (XML) 1.0 (Fourth Edition),"http://www.w3.org/TR/2006/REC-xml-20060816, 16 August 2006. [XML-ns] W3C Recommendation, "Namespaces in XML 1.0 (Second Edition)," http://www.w3.org/TR/2006/REC-xml-names-20060816, 16 August 2006. [XML-Schema1] W3C Recommendation, "XML Schema Part 1: Structures Second Edition," http://www.w3.org/TR/2004/REC-xmlschema-1-20041028, 28 October 2004. [XML-Schema2] W3C Recommendation, "XML Schema Part 2: Datatypes Second Edition," http://www.w3.org/TR/2004/REC-xmlschema-2-20041028, 28 October 2004. [XOP] W3C Recommendation, "XML-binary Optimized Packaging" http://www.w3.org/TR/2005/REC-xop10-20050125/-xop10-20050125/, 25 January 2005.
ESB Interoperability Standards Date: 02 June 2008 Authors: Thomas Freund STSM, IBM SWG Strategy Peter Niblett STSM, IBM SWG WebSphere Messaging Architecture
© Copyright IBM Corporation 2008 All rights reserved.
06/02/2008
ESB Interoperability Standards
06/02/2008
Abstract and Executive Summary Thousands of Enterprises worldwide have adopted the principles of Service Oriented Architecture (SOA). SOA provides an architectural approach that brings the flexibility and agility required by today’s global business environment. An Enterprise Service Bus (ESB) is a vital ingredient of SOA that facilitates the interaction of business services by mediating the message exchanges between them. ESB infrastructure products are available from a number of software vendors, but there is a lack of consistency between them when it comes to standards support. This has led a number of ESB customers to ask for an industry-wide agreed list of standards supported by an ESB. This Whitepaper documents the essential standards requirements for an ESB, using a scenario-based approach. This Whitepaper is directed toward analysts, customers and partners, and is intended to facilitate: 1. Market Growth: Grow the market for ESB infrastructure by removing marketplace confusion. Provide a clear & universal understanding of the ESB standardization requirements. 2. Industry Adoption: Ensure functional requirements and interoperability guarantees are met across a heterogeneous system-wide environment. 3. Customer Benefit: Provide the assurances of flexibility and interoperability derived from solutions built on standards. 4. Standards Development: Solidify the ESB definition by ensuring precision through standards and profiles.
ESB Interoperability Standards
06/02/2008
Table of Contents Abstract and Executive Summary....................................................................................... 2 Table of Contents................................................................................................................ 3 1 Introduction................................................................................................................. 4 1.1 1.2
2 3
ESB and Web service Standards................................................................................. 7 ESB Scenarios............................................................................................................. 9 3.1 3.2
4
Routing ................................................................................................................................. 9 Conversion.......................................................................................................................... 11
Profile Relationship .................................................................................................. 13 4.1 4.2
5 6
SOA & ESB Positioning....................................................................................................... 4 ESB Definition...................................................................................................................... 4
WS-I Profiles ...................................................................................................................... 13 Requirements for additional Profiles .................................................................................. 13
Summary ................................................................................................................... 15 References................................................................................................................. 16
ESB Interoperability Standards
06/02/2008
1 Introduction This section very briefly articulates the overall rationale for Enterprise Service Bus (ESB) standards. The value of an ESB is derived from how it augments a Service Oriented Architecture and as such, it needs to support standards.
1.1 SOA & ESB Positioning A Service Oriented Architecture (SOA) is a software model in which the concept of a ‘service’ is an abstraction of a function used by an application. SOA logically decouples the service requester from the service provider by isolating the service definition from a service implementation. SOA addresses the business demand for applications to be responsive to business needs and to adapt to dynamic business environments. In SOA, services may be defined as Web services to provide a standards-based approach to interoperability. The Service Component Architecture (SCA) builds on open-standards such as Web services and augments SOA by: a.) providing a cross-language programming model that promotes reuse and b.) defining a flexible and agile mechanism with which to assemble applications. The ESB provides a vital ingredient of the SOA environment. An ESB decouples the service requester from the service provider by mediating (if necessary) the service interaction between communicating participants. We call this decoupling service virtualization. Interposed between requester and provider, an ESB simplifies service connectivity by dealing with the service selection process and handling any mismatches that might occur. For example the requesters and providers might have different security or reliability requirements, or the interface provided by the service might not exactly match the interface expected by the requester. In a SOA environment one often needs to facilitate the communications between service requesters and service providers that possess differing service characteristics (in such cases, service metadata may be available that describes a service’s requirements, capabilities or other general information regarding service usage). An ESB can also be used to introduce additional functionality into the communications path between interacting services. We call this aspect-oriented connectivity. We discuss service virtualization and aspect-oriented connectivity in more detail in the next section.
1.2 ESB Definition
ESB Interoperability Standards
06/02/2008
An ESB enables services to be connected into solutions - even if they were not originally designed to work with each other. An ESB is a recommended element for any SOAbased solution that requires mediation to facilitate a requester-provider interchange. An ESB includes a distributed, configurable infrastructure, whose tasks are to provide: • Routing: The ESB acts as a match-maker between service requester and service provider. • Conversion: The ESB handles protocol or interaction differences. • Transformation: The ESB can be programmed to handle interface mismatches that might occur and compensate accordingly, if possible. • Aspect-oriented connectivity: Additional “added-value” functionality. The services that connect to the ESB may declare their service characteristics or their expectations relating to service interactions (including any requirements on other participants). An ESB provides service virtualization for the following essential mediation functional elements: • Identity or location – participants need not know the identity or location of other participants, e.g., requesters need not be aware that a request could be serviced by any of several providers; service requesters and providers can be added or removed without disruption. Hides service identity or location Determines appropriate service from candidate providers Routes messages between requester & provider • Interaction pattern or protocol – requesters need not share the same communication protocol or interaction pattern. Interaction partners may chose to use one-way, request/response, asynchronous, synchronous, and publish/subscribe type interactions Handles service interaction differences Converts transport protocols Adapts differing interaction patterns • Interface – requesters and providers need not agree on common interface. The ESB reconciles syntactic differences by transforming request messages into a form expected by the provider. Handles service interface differences Translates message formats An ESB also provides aspect oriented connectivity supplying operational characteristics that apply across the participants such as security, management, logging, auditing, etc. that may be required in an enriched business environment. In order to provide this additional functionality an ESB may make use of general-purpose SOA utilities that supply such capabilities. These utilities could include a security service, registry/repository service, logging service, etc.
ESB Interoperability Standards
06/02/2008
An ESB performs the following between requestor and service
` MATCHES & ROUTES communications between services
` CONVERTS between different transport protocols
` TRANSFORMS between different data formats
` IDENTIFIES & DISTRIBUTES business events Shape = Transport protocol Color = Data format
The ESB is given responsibility for delivering messages between requesters and providers, ensuring the required functionality as defined for the interaction. Service requesters send requests which are then mediated (if required) by the ESB. The ESB routes and transforms each request message into a format acceptable to the service provider. Service providers receive these requests and can react to them without having to know about a request's origin. Similar mediation takes place for any response message sent back by the service provider. The ESB is transparent to the service requesters and providers: it matches a service requester’s requirements with a service provider’s capability, adding value to service interactions without changing the service providers or requesters themselves. Web services standards (WS-*) have a critical role to play where interoperability between disparate ESB implementations is needed. By providing an ESB that offers WS-* support a customer has the assurance of flexibility and interoperability that such a standardsbased approach provides. In addition, an ESB that provides WS* support can provide a convenient way to add Web service connectivity to existing applications that lack Web service interfaces. This whitepaper proposes a set of WS-* standards relevant to the various ESB facilities. Note that this definition of an ESB does not include Service Choreography or Process Management. These form key parts of SOA, but we view them as complementary to an ESB, rather than functions provided in the ESB itself. For additional information on the details of the ESB definition see “Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution” [flurry2007].
ESB Interoperability Standards
06/02/2008
2 ESB and Web service Standards This section of the whitepaper lists a set of Web services standards that are relevant to an ESB. These standards relate to connectivity of service requesters and service providers, and communications between ESBs. The aim of this proposal is to help establish an industry-wide consensus on the set of applicable standards for Web services-based ESB implementations. Section 3.0, ESB Scenarios provides use cases to illustrate the applicability of the Web service standards. Many of these Web services standards are contained in Web service Interoperability (WS-I) Profiles. Section 4.0, Profile Relationship discusses ESB-related WS-I profile requirements. In this section, we identify how standard protocols may be used to enable interoperability between ESBs or between an ESB and the services that use it. Requesters and providers that utilize an ESB that conforms to a standards-based solution will gain the benefits that such an approach provides for the interactions between them. It is to be expected that ESBs will also support connectivity using specifications other than those listed in this section, for example an ESB might support communications via the Java™ Message Service (JMS). We subdivide this area into the following interoperability aspects: • Transfer: Communication protocols that transfer messages between service endpoints. An ESB must support the use of HTTP or HTTPS as a transfer protocol to carry messages between the service requester and the service provider. An ESB may support other transport mechanisms, for example JMS. • Message Format and Protocols: Messaging protocols define both the message structure and rules governing the processing along the message path between message participants. An ESB must support the use of XML [XML] messages that use SOAP 1.1 [SOAP 1.1] or SOAP 1.2 [SOAP 1.2] as the message format and protocol for message exchange. It must include support for SOAP XML messages which have binary content that has been serialized as a MIME multipart message using the mechanisms defined by MTOM [MTOM] and XOP [XOP]. It may support SOAP with Attachments [SwA]. An ESB must also support asynchronous SOAP messaging through the use of WS-Addressing [WSADDR] Message Addressing Properties. An ESB may also support non-SOAP interaction, specifically REST-style messages encoded in XML. See also: Service Definition (WSDL and XSD). • Identity or Location: A definition of the addressing and the message header information required in a message exchange. An ESB must support the use of WS-Addressing [WSADDR] ‘endpoint references’ to convey addressing information of the service requesters and service providers. It should also support
ESB Interoperability Standards
•
•
06/02/2008
use of the WS-Addressing Message Addressing Properties. These enrich a message by adding header elements used for routing. Quality of Service: Enriches a standard message exchange with extended aspects of requester-supplier interaction. Such Qualities of Service are frequently required in enterprise business applications. ESBs must support WS-Security [WSSec], [WSSec 1.1] and WS-ReliableMessaging [WS-ReliableMessaging] [WSReliableMessaging][WS-ReliableMessaging][WS-ReliableMessaging][WSReliableMessaging]and may support WS-SecureConversation [WSSecConv], WS-Trust [WSTrust][WSTrust][WSTrust][WSTrust][WSTrust], and WSFederation [WS-Federation]. Service Definition: An ESB must support the use of WSDL 1.1 to describe Service interfaces, with XML Schema being used as the way of representing the format of data used in XML-based message exchanges. XML provides a platform neutral mechanism for transferring data between services. An ESB may use additional (proprietary) bindings in conjunction with XML Schema, to describe the structure of binary and character encoded (ASCII/Unicode) messages. Service Component Description Language (SCDL) may be used to describe the requester and the provider’s capabilities of a service component, and any requirements it has on its interactions with other services.
Topic
Standard Required
Transfer
Feature
HTTP 1.1, HTTPS
Message Format and Protocols SOAP 1.1 / 1.2 MTOM/XOP XML1.0
SOAP with Attachments
Identity or Location
WS-Addressing 1.0
Quality of Service
WS-Security 1.1, WS-ReliableMessaging 1.1
WS-SecureConversation 1.3, WS-Trust. WS-Federation
Service Definition
WSDL 1.1, XML Schema
SCDL
ESB Interoperability Standards
06/02/2008
3 ESB Scenarios The previous section listed the proposed standards that underpin an interoperable, programmable and manageable ESB. In this section we illustrate the use of such standards by means of a set of scenarios. The scenarios are based on a fictional company that is using an ESB to physically decouple its SOA service requesters and providers, so as to give it the flexibility to implement applications more quickly. The company has decided that open standards should be used for specific aspects of its ESB. These scenarios are intended to illustrate the use of standards and are not meant to be an exhaustive list of ESB scenarios. The scenarios listed here could be varied, for example by using different transport protocols.
3.1 Routing Use case requirement: The fictional company wants to virtualize the identity or location of its services. This means that its service requesters need not be aware of the identity or location of the service providers, but requests from these requesters are routed to a provider based on a series of criteria such as specific requestor or provider characteristics, request type or other environmental information. In this simple routing scenario, all interacting participants, both service requesters and providers are illustrated using SOAP/HTTP bindings 1 for their interactions, and a request may be serviced by any of several service providers. Additional service requesters and providers can be added to the system, and messages can be routed to them, without disrupting the requesters. The Service Requesters are not aware of these service providers, and do not connect directly to them. Instead they connect via an intermediary 2 (mediation) provided by the ESB. That intermediary implements the same interface as the “real” service providers. The ESB may be configured to deal with response messages in one of two ways. As the service provider responses flow back through the ESB, either they can be sent directly to the service requester, or the ESB can perform mediation function such as routing. The ESB can control this by the way that it sets the request message’s WS-Addressing [reply endpoint] MAP. The ESB mediation, constructed at development time, is associated at deployment time with the service providers which it will select between at run-time. In this simple scenario the mediation logic selects the service provider at random from this static list of possible providers.
1
Although not shown, this services selection scenario might involve REST services. The scenario illustrates a generally common ESB pattern of an explicit intermediary however this is not meant to preclude other configurations i.e. it does not dictate either the placement of the mediation function or restrict the form of access to ESB.
2
ESB Interoperability Standards
06/02/2008
ESB Service Requester
Transform
Route
XML Message
Service Provider
SOAP/HTTP WS-Addressing
Legend Relevant Element ESB Function Exercised
Requirement
Specification
Transfer
HTTP 1.1
Message Format and Protocols
SOAP 1.1 or 1.2
Identity or Location
WS-Addressing 1.0
Service Definition
XML Schema WSDL 1.1
ESB Interoperability Standards
06/02/2008
3.2 Conversion Scenario: A company has some internal services that expose SOAP/JMS interfaces, and wishes to make them available to requesters via SOAP/HTTP interfaces. Use case requirement: The ESB handles the conversion between transport protocols and adapts between differing interaction patterns. The Service providers continue to support their SOAP/JMS interfaces, unchanged. The ESB publishes new SOAP/HTTP endpoints, with the same WSDL portTypes as the original services, and maps HTTP messages to JMS messages and vice versa. Since the new endpoint and its corresponding original Service Provider both have the same service interface (WSDL portType) the actual message bodies can be converted in a mechanical fashion, without the need for the transformation discussed in the previous scenario. In the version of the scenario described here the SOAP/HTTP service definition includes assertions that indicate that the service Requesters have to use asynchronous WSAddressing (non-anonymous replyTo references). This means that the ESB can simply map HTTP requests to JMS requests and JMS responses to HTTP responses as they arrive. The ESB could also choose to publish endpoints that support synchronous SOAP/HTTP invocation. In such a case the ESB would have to keep the requester’s HTTP connection active until it received the JMS response from the original service provider.
Service Interface Definition WSDL
WSDL
ESB Service Requester
Transform
“protocol 1” SOAP/HTTP WS-Addressing
Legend Unused
Relevant Element ESB Function Exercised
Route
“protocol 2” SOAP/JMS
Service Provider
ESB Interoperability Standards
06/02/2008
Requirement
Specification
Transfer
HTTP 1.1, JMS
Message Format and Protocols
SOAP 1.1 or 1.2.
Identity or Location
WS-Addressing 1.0
Service Definition
XML Schema WSDL 1.1
ESB Interoperability Standards
06/02/2008
4 Profile Relationship 4.1 WS-I Profiles The Web service Interoperability (WS-I) Profiles provide implementation guidelines for how related Web services specifications should be used together for best interoperability. WS-I have defined or are working on the following profiles: • WS-I Basic Profile, • WS-I Attachments Profile • WS-I Simple SOAP Binding Profile • WS-I Basic Security Profile • WS-I Reliable Secure Profile
Additional WS-I Profiles
WS -I Reliable Secure Profile WS-SecureConversation WS-ReliableMessaging Token Profiles
WS -I Basic Security Profile
WS-Security WS -I Basic Profile
WS -I Attachments Profile
WS-I Simple SOAP Profile
Figure: WS-I Profiles
4.2 Requirements for additional Profiles The definition of additional profiles related to ESB environments is a logical follow-on work effort based on the material contained in this document. It is expected that one or more profiles may be required to cover the range of customer use case requirements (as outlined in section 3).
ESB Interoperability Standards
06/02/2008
A profile is defined to contain the following sections: 1. A scope statement which describes the problem domain addressed by the Profile (which may be a reproduction of segments of the business summary). The ESB use cases contained in this document provide a general understanding of the standards requirements associated with an overall ESB customer scenario. Any profile definition is driven by general customer usage scenarios. 2. A list of referenced specifications including specification levels. This also includes other Profiles since Profiles, like the specifications they reference, are composable. 3. A set of “requirements” that constitute constraints on the underlying specification and/or guidance concerning how to use the referenced specifications to best achieve interoperability. Such definitions are beyond the scope of this document. The set of current WS-I profiles that would be referenced in an additional ESB-related Profile includes: • • •
WS-I Basic Security Profile WS-I Basic Profile (1.1 or higher) WS-I Reliable Secure Profile
ESB Interoperability Standards
06/02/2008
5 Summary ESBs extend the capabilities of SOA and advance the realization of SOA. Mediations can be employed to facilitate interactions between mismatched service requesters and providers. The ESB also provides a common model for accessing, managing and administering system-wide services. Today's fast-paced business world demands the ability to change and adapt rapidly. With an Enterprise Service Bus, you can connect your business applications and processes quickly and easily as you respond to business challenges and opportunities when they arise. By adopting a standards-based approach leveraging Web services a customer has the assurance of the flexibility and the interoperability that such a strategy provides.
ESB Interoperability Standards
06/02/2008
6 References ESB •
[esb2004] “Understand Enterprise Service Bus scenarios and solutions in ServiceOriented Architecture, Part 1” • [ibmSJ2005] “The Enterprise Service Bus: Making service-oriented architecture real”, http://www.research.ibm.com/journal/sj/444/schmidt.html • [schmidt2005] “SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus” • [snell2005] “Simplify integration architectures with an Enterprise Service Bus” • [flurry2007] “Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution”, http://www128.ibm.com/developerworks/library/ar-esbpat1/ Whitepapers • [SOAfoundation] “IBM SOA Foundation: An architectural introduction and overview” Specifications • [MTOM] W3C Recommendation, "SOAP Message Transformation Optimization Mechanism" http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/, 25 January 2005. • [SOAP 1.1] W3C Note, "SOAP: Simple Object Access Protocol 1.1," http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, 08 May 2000. • [SwA] W3C Note, "SOAP Messages with Attachments" http://www.w3.org/TR/SOAP-attachments, 11 December 2000. • [SOAP 1.2] W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework", http://www.w3.org/TR/soap12-part1/, June 2003. • [WSADDR] Web services Addressing (WS-Addressing), Web services Addressing (WS-Addressing) 1.0, W3C Recommendation, http://www.w3.org/2005/08/addressing • [WSDL] Web services Description Language (WSDL) 1.1 "http://www.w3.org/TR/2001/NOTE-wsdl-20010315" • [WS-Federation] Web Services Federation (WS-Federation) 1.1, http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WSFederation-V1-1B.pdf?S_TACT=105AGX04&S_CMP=LP • [WS-ReliableMessaging] [WS-ReliableMessaging] Web Services Reliable Messaging (WS-ReliableMessaging) 1.1, http://docs.oasis-open.org/wsrx/wsrm/200702/wsrm-1.1-spec-os-01-e1.pdf • [WSSec] OASIS Standard 200401, March 2004, "Web services Security: SOAP Message Security 1.0 (WS-Security 2004), "http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf • [WSSec 1.1] OASIS Standard, February 2006, "Web services Security: SOAP Message Security 1.1 (WS-Security 2004), http://docs.oasisopen.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
ESB Interoperability Standards • • • • • • •
06/02/2008
[WSSecConv] Web services Secure Conversation (WS-SecureConversation) 1.3, http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/wssecureconversation-1.3-os.doc. [WSTrust] Web services Trust (WS-Trust) 1.3, http://docs.oasis-open.org/wssx/ws-trust/200512/ws-trust-1.3-os.doc. [XML] W3C Recommendation, "Extensible Markup Language (XML) 1.0 (Fourth Edition),"http://www.w3.org/TR/2006/REC-xml-20060816, 16 August 2006. [XML-ns] W3C Recommendation, "Namespaces in XML 1.0 (Second Edition)," http://www.w3.org/TR/2006/REC-xml-names-20060816, 16 August 2006. [XML-Schema1] W3C Recommendation, "XML Schema Part 1: Structures Second Edition," http://www.w3.org/TR/2004/REC-xmlschema-1-20041028, 28 October 2004. [XML-Schema2] W3C Recommendation, "XML Schema Part 2: Datatypes Second Edition," http://www.w3.org/TR/2004/REC-xmlschema-2-20041028, 28 October 2004. [XOP] W3C Recommendation, "XML-binary Optimized Packaging" http://www.w3.org/TR/2005/REC-xop10-20050125/-xop10-20050125/, 25 January 2005.
Related Documents
Esb Interoperability Standards Freund
October 2019 11
Freund
November 2019 13
Towards An Interoperability Framework For Metadata Standards
October 2019 14
Esb Presentation
November 2019 14
Network Interoperability
November 2019 11