three roads to the soa implementation framework

8/2/2019 Three Roads to the SOA Implementation Framework

1/25

Three Roads to the SOA Implementation Framework

BYRONALD SCHMELZER APRIL 1, 2004 EMAIL THIS POST PRINT THIS POSTPOST A COMMENT

FILED UNDER IMPLEMENTING SOA,SERVICE-ORIENTED ARCHITECTURE (SOA),WEB SERVICES

No company wants integration. The only reason anybody spends money on integration at all is because software as

a rule doesnt integrate by itself. But no executive thinks that spending money on integration addresses a strategic

need of the business. Instead, money spent on integration goes for fixing something that really shouldnt have been

broken in the first place.

The sad fact of the matter is that in the forty-plus year history of distributed computing, integration has constantly

been a money-suck for every company with two or more computers that need to talk with each other. Its been a

long, dark tunnel, but now finally! we can see the light at the end of the tunnel.

The Light at the End of the Tunnel

Fundamentally, software must integrate without significant human intervention. In other words, the distributed

computing architecture itself must provide the necessary infrastructure to resolve integration issues while putting

application development into the hands of the IT user. In an enterprise SOA, business users create application

functionality by building and managing business processes. Also, the architecture should abstract the underlying

technology, so that developer who formerly were concerned with connecting systems and applications can now

concern themselves with building Services. As a result, the entire IT mindset must then shift from connecting A to B

(the integration mindset) to building business Services that abstract IT functionality (the Service orientation mindset)

OK, fair enough, but theres still plenty of dark tunnel ahead before we can get to th is vision of the SOA

Implementation Framework (SOAIF), which ZapThink introduced in ourService Orientation Market Trendsreport.

The SOAIF envisions a comprehensive framework that provides all the technology that enterprises need to build

and run an SOA process, management, security, modeling, and more. In fact, as enterprises look to implement

SOAs, and vendors work to produce solutions that enable such architectures, three separate approaches to

integrating disparate, heterogeneous information and systems in the enterprise are in the process of converging to

provide an optimal implementation of an SOA one that meets the requirements for loosely coupled, coarse

grained, asynchronous Services. The following three approaches, therefore, are essentially transitional approaches

leading to the SOAIF that underlies ZapThinks vision of Service Orientation.

Approach #1: The Enterprise Service Bus

One approach that contributes to an optimal SOA implementation is the use of an Enterprise Service Bus (ESB) to

provide an infrastructural element to distributed Services on the network. The ESB approach to integration considers

systems as discrete, distributed Services that connect to each other via an asynchronous, message-oriented

communications infrastructure. The message-oriented infrastructure allows loosely coupled, document-oriented

exchanges between independent systems.
http://www.zapthink.com/author/rschmelzerzapthink-com/http://www.zapthink.com/author/rschmelzerzapthink-com/http://www.zapthink.com/author/rschmelzerzapthink-com/http://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/email/http://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/email/http://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/print/http://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/print/http://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/#commentshttp://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/#commentshttp://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/#commentshttp://www.zapthink.com/tag/implementing-soa/http://www.zapthink.com/tag/implementing-soa/http://www.zapthink.com/tag/service-oriented-architecture-soa/http://www.zapthink.com/tag/service-oriented-architecture-soa/http://www.zapthink.com/tag/service-oriented-architecture-soa/http://www.zapthink.com/tag/web-services/http://www.zapthink.com/tag/web-services/http://www.zapthink.com/tag/web-services/http://www.zapthink.com/report.html?id=ZTR-WS110http://www.zapthink.com/report.html?id=ZTR-WS110http://www.zapthink.com/report.html?id=ZTR-WS110http://www.zapthink.com/report.html?id=ZTR-WS110http://www.zapthink.com/tag/web-services/http://www.zapthink.com/tag/service-oriented-architecture-soa/http://www.zapthink.com/tag/implementing-soa/http://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/#commentshttp://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/print/http://www.zapthink.com/2004/04/01/three-roads-to-the-soa-implementation-framework/email/http://www.zapthink.com/author/rschmelzerzapthink-com/


2/25

While ESBs can provide the critical infrastructure components that simplify and scale integration approaches, ESBs

by themselves dont provide the required integration to meet high-level business requirements, and neither do they

necessarily provide guarantees of loose coupling and coarse granularity to meet evolving Service-oriented needs.

Basically, implementing ESBs to meet SOA requirements require the addition of extra functionality to compose fine-

grained atomic Services into coarse-grained business Services and provide policy-driven, managed, and secure

Service interactions.

Approach #2: Business Process Management

Companies have long sought to solve business process issues by implementing Business Process

Management (BPM) approaches that consider systems and IT assets as activities or tasks that participate in well-

coordinated and centrally orchestrated business processes. Traditionally, the challenge of BPM is that while it is

possible to construct processes that achieve integration goals, enterprises typically use BPM tools only at design

time, modeling processes as they used to be or processes as they should be, but rarely processes as they actually

are in the IT environment.

So, while BPM solutions can craft orchestrated processes that are composed of fine-grained Services, they dont

contain the runtime environment necessary for loosely coupled, asynchronous Service interactions. At the very

least, a BPM solution must be used in conjunction with a loosely-coupled integration approach to make the business

processes runtime activities that coordinate integration. Thus, by itself, BPM solutions arent sufficient to meet SOA

requirements.

Approach #3: Service-Oriented Integration

The Service-Oriented Integration approach uses the architectural guiding principles of Service orientation to

construct an ecosystem of Services that business users can dynamically combine and compose into higher-level

processes that meet continuously evolving and changing business requirements. SOI approaches transcend brittle,

tightly-coupled EAI and B2Bi integration approaches by mandating a separation of the consumer of each Service

from the producer of that Service, thus enforcing the critical aspect of loose coupling that is required to allow an

integration scenario to evolve automatically to meet business requirements.

Yet, even SOI by itself provides no guidance on how to build the right Services to meet current business

requirements, nor does it provide a means to execute Services in the most effective, scalable manner to guarantee

long-running interactions. Furthermore, there exist a wide variety of ways to implement an SOI at runtime, but its as

yet unclear what approaches are the best for realizing the goals of loosely coupled, coarse-grained, asynchronous

SOAs.

The ZapThink Take

ZapThink believes the answer lies in a convergence of the above approaches. The message-oriented, loosely

coupled approach of ESBs provide an optimal base on top of which to run the loosely-coupled, coarse grained

Services implemented in an SOI. BPM solutions provide the process-driven guidance necessary to ensure that they


3/25

compose fine-grained Services into real, run-time business processes. Through the combination of these

approaches, companies can move toward the vision of software that integrates automatically.

Nevertheless, it is important to understand that the hands-free integration vision of Service orientation is still many

years off and systems and applications must talk to each other today. Fortunately, there are roads enterprises

can take that will lead them from the brittle, expensive integration of the recent past toward this grand vision. ESBs,

BPM solutions, and SOI approaches are all roads, that when taken together, lead to true Service orientation.

Understand Enterprise Service Bus scenarios and

solutions in service-oriented architecture

IntroductionState-of-the-art IT integration is the implementation of Service-Oriented Architectures (SOAs) using web services

technologies, and many excellent descriptions of their benefits and practice are available (seeResources). Morerecently, the concept of anEnterprise Service Bus(ESB) has been expressed as a key component of the SOAinfrastructure (seeResources). However, it is important to clarify whether the ESB is a product, technology,standard, or something else. In particular, is the ESB something that can be built today, and if so, how?This article describes the ESB as a set of infrastructure capabilities implemented by middleware technology thatenable an SOA. The ESB supports service, message, and event-based interactions in a heterogeneousenvironment, with appropriate service levels and manageability. A variety of capabilities required to achieve this aresummarized and categorized. However, not all are required in every situation in which an ESB can deliver value.This article identifies a set of minimum capabilities that fulfill the most basic needs for an ESB consistent with theprinciples of SOA. Identifying these minimum capabilities allows you to identify which existing technologies to use toimplement an ESB supporting an SOA. By considering how the requirements of a specific situation define the needfor additional capabilities, you can then choose the most appropriate implementation technology for that situation.I will define a set of ESB scenarios in SOA capturing common starting points for ESB or SOA implementation in

following articles. The solution patterns, in turn, provide guidance for choosing appropriate implementationtechnologies.As the uses to which an ESB solution is put evolve and mature, the capabilities required of it will also evolve.Similarly, the availability and capability of explicit ESB products will also mature. In the final article of this series, Iwill therefore consider a roadmap for SOA and ESB adoption to guide the initial use of ESB capabilities andtechnologies, and illustrate options for a gradual approach.

Back to top

The role of the ESB within an SOAWhile I will not discuss the definition of SOA in depth (seeResources), it is useful to summarize here the principlesthat most descriptions of SOA agree with:

The use of explicit implementation-independent interfaces to define services. The use of communication protocols that stress location transparency and interoperability. The definition of services that encapsulate reusable business function.

Figure 1illustrates these principles. Note that while web services technology is an excellent match to theseprinciples, it is not the only technology consistent with them.
https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pconhttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure1https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure1https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure1https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pconhttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resources


4/25

Figure 1: The principles of SOA

In order to implement an SOA, both applications and infrastructure must support SOA principles. Enabling anapplication for SOA involves the creation of service interfaces to existing or new functions, either directly or throughthe use of adaptors. Enabling the infrastructure, at the most basic level, involves provision of the capabilitiesto routeand deliver service requests to the correct service provider. However, it is also vital that the infrastructuresupports the substitutionof one service implementation by another with no effect to the clients of that service. Thisrequires not only that the service interfaces be specified according to SOA principles, but also that the infrastructure

allows client code to invoke services in a manner independent of the service location and the communicationprotocol involved. Such service routing and substitution are amongst the many capabilities of the ESB.The ESB supports these service interaction capabilities, and provides the integrated communication, messaging,and event infrastructure to enable them. Thus, it combines the major enterprise integration patterns in use today intoa single entity. The ESB provides an infrastructure for an SOA consistent with the needs of the enterprise, to providesuitable service levels and manageability, and to operate in a heterogeneous environment.The remainder of this article will discuss this role of the ESB in SOA, including the capabilities it provides beyondbasic routing and transport, as described in a capability model for the ESB below. The remainder of this article willdiscuss this role of the ESB in SOA, including the capabilities it provides beyond basic routing and transport, asdescribed in the section capability model for the ESBbelow.

The structure of the ESBThe ESB is sometimes described as a distributedinfrastructure, and contrasted against other solutions, such asmessage brokering technologies, commonly described as hub-and-spoke. However, this is a false distinction. Two

different issues are being addressed: the centralization of control, and the distribution of infrastructure. Both ESBand hub-and-spoke solutions centralize control of configuration, such as the routing of service interactions, thenaming of services, and so forth. Similarly, both solutions might deploy in a simple centralized infrastructure, or in amore sophisticated, distributed manner.Figure 2illustrates this point.Of course, different technologies will have different constraints on the physical deployment patterns they support --some might be suited to very widespread distribution to support integration over large geographical areas, whileothers might be more suited to deployment in localized clusters to support high-availability and scalability. Matchingthe requirements for physical distribution to the capabilities of candidate technologies is an important aspect of ESBdesign. Also important is the ability to incrementally extend the initial deployment to reflect evolving requirements, tointegrate additional systems, or to extend the geographical reach of the infrastructure.
https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure2https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure2https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure2https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure2


5/25

Figure 2: Centralized control over distributed ESB infrastructure

I should also position the ESB in relation to other components in the SOA infrastructure, in particular, the ServiceDirectory, Business Service Choreography, and Business-to-Business (B2B) Gateway components. Since the SOAprinciples above do not strictly require these components, let's treat them as optional components.Figure 3showsan SOA indicating the relationship of these components to the ESB.

Figure 3: The role of the ESB in an SOA

The ESB requires some form of service routing directoryin order to route service requests. However, an SOA mightalso have a separate business service directory, which, in its most basic form, might be a design-time servicecatalog used to achieve reuse of services across the development activities of an organization. The vision of webservices places a UDDI directory in the role of both the business service directory and service routing directoryroles, thus enabling the dynamic discovery and invocation of services. Such a directory might be viewed as part ofthe ESB; however, until such solutions become common, the business service directory is likely to be separate fromthe ESB.
https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure3https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure3https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure3https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#figure3


6/25

The role of the Business Service Choreographer is to compose business processesfrom several business services;it will, therefore, invoke services through the ESB, and then expose the business process as other services availableto clients, again through the ESB. However, its role in choreographing business processes and services identifiesthe Business Service Choreographer, a business workflow technology, as separate from the ESB, an infrastructuretechnology.Finally, the role of a B2B Gateway component is to make the services of two or more organizations available toeach other in a controlled and secure manner. It is useful to view such components as connected to the ESB, butnot part of it. While gatewaytechnologiesexist that provide capabilities suitable for implementing both B2B Gatewaycomponents and the ESB, the purposeof the B2B Gateway component separates it from the ESB. Indeed, this

purpose might require additional capabilities, such as partner relationship management, that would not be part of anESB and not necessarily supported by ESB technologies.

A capability model for the ESBTable 1summarizes and categorizes some of the ESB capabilities identified in existing literature (seeResources).While some are quite basic, others, such as autonomic or intelligent capabilities, represent significant steps towardsan On Demand operating environment. It is important to recognize that most current ESB scenarios require only asubset of these capabilities within a subset of these categories. The minimumcapabilities required for an ESBimplementation are considered in the section The minimum capability ESB Implementation for SOA below.

Table 1: Capabilities of the ESB defined in existing literatureCommunications Service interaction

Routing

Addressing Communication technologies, protocols, and

standards (for example, IBM WebSphere MQ,HTTP, and HTTPS)

Publish / subscribe

Response / request Fire-and-forget, events Synchronous and asynchronous messaging

Service interface definition (for example, Web ServicesDescription Language (WSDL))

Support for substitution of service implementation

Service messaging models required for communication andintegration (for example, SOAP or enterprise applicationintegration (EAI) middleware models)

Service directory and discovery

Integration Quality of services

Database Service aggregation

Legacy and application adaptors Connectivity to EAI middleware

Service mapping Protocol transformation Application server environments (for example, J2EE

and .NET)

Language interfaces for service invocation (forexample, Java and C/C++/C#)

Transactions (Atomic transactions, Compensation, WS-Transaction)

Various assured delivery paradigms (for example, WS-ReliableMessaging or support for EAI middleware)

Security Service level

Authentication Authorization Non-repudiation

Confidentiality Security standards (for example, Kerberos and WS-

Security)

Performance Throughput Availability

Other continuous measures that might form the basis of contractsor agreements

Message processing Management and autonomic
https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#table1https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#table1https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#resourceshttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#table1


7/25

Encoded logic Content-based logic

Message and data transformations Validation

Intermediaries Object identity mapping Data enrichment

Service provisioning and registration Logging, metering, and monitoring

Discovery Integration to systems management and administration tooling

Self-monitoring and self-management

Modeling Infrastructure intelligence

Object modeling Common business object models Data format libraries Public versus private models for B2B integration Development and deployment tooling

Business rules Policy driven behavior, particularly for service level, security and

quality of service capabilities (for example, WS-Policy)

Pattern recognition

Many of these capabilities can be implemented either using proprietary technologies, or through the use of openstandards. However, the various technology candidates for ESB implementation might vary considerably in theirperformance, scalability, and availability characteristics, as well as in the ESB capabilities and open standards theysupport. Because of this, and the fact that some of the relevant standards are recent or still emerging, many criticaldecisions in implementing the ESB today are concerned with the trade-off between more mature, proprietarytechnologies and less mature open-standard support.In this series of articles, I will not discuss each of these capability categories in detail. Rather, I will focus on thosethat drive decisions between different approaches to adopt or implement an ESB. In particular, in the next section, Iwill discuss what constitutes the minimum capabilities that an ESB requires in order to support an SOA.

The minimum capability ESB implementation for SOAIf only a subset of the capabilities identified earlier are relevant to most SOA scenarios, we can ask: what constitutestheminimumset of capabilities that are required in order to implement an ESB? In order to do this, consider the moscommonly agreed elements of the ESB definition:

The ESB is a logical architectural component that provides an integration infrastructure consistent with theprinciples of SOA.

SOA principles require the use of implementation-independent interfaces, communication protocols that

stress location-transparency and interoperability, and service definitions that are relatively coarse-grainedand encapsulate reusable function.

The ESB might be implemented as a distributed, heterogeneous infrastructure. The ESB provides the means to manage the service infrastructure and the capability to operate in the

distributed, heterogeneous environment of today.Table 2illustrates the minimum ESB capabilities defined from those principles.

Table 2: The minimum ESB capabilitiesCommunication Integration

Routing and addressing services providing location

transparency An administration capability to control service

addressing and naming

At least one form of messaging paradigm (forexample, request / response, publish / subscribe,and so forth)

Support for at least one transport protocol that is orcan be made widely available

Support for multiple means of integration to service providers, such

as Java 2 Connectors, web services, asynchronous messaging,adaptors, and so forth

Service interaction
https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#table2https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#table2https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#table2


8/25

An open and implementation-independent service messaging and interfacing model, that should isolate application code from the specifics ofrouting services and transport protocols, and allow service implementations to be substituted

Note that these minimum capabilities do not require the use of particular technologies, such as EAI middleware, webservices, J2EE, or XML. The use of those technologies is very likely, as they fit the requirements well, but it is notmandatory. Conversely, the minimum capabilities are nearly, but not wholly, fulfilled by the simple use ofSOAP/HTTP and WSDL:

URL addressing and the existing HTTP and DNS infrastructure provide a "bus" infrastructure with routingservices and location transparency.

SOAP/HTTP supports the Request-Responsemessaging paradigm. The HTTP transport protocol is widely available. SOAP and WSDL are an open, implementation-independent service messaging and interfacing model.

However, this basic use of SOAP/HTTP and WSDL is really just point-to-point integration, and does not fulfill somekey capabilities required of an ESB:

No administration capabilityto control service addressing and naming exists. Service names are controlledindividually by each adaptor, and service routing control is dispersed between the addresses invoked byservice clients, the HTTP infrastructure, and the service names assigned to adaptors.

While dependent on implementation details, this approach does not tend to facilitate the substitution ofservice implementations; service requester code (perhaps generated by development tools) will often binddirectly to specific service provider implementations through specific protocols at specific addresses.Substituting one service implementation for another will require changes to and redeployment of the

application code.Of course, further capabilities are required in many or even most scenarios, and will become increasingly common.In particular, the following types of requirements are likely to lead to the use of more sophisticated technologies,either now or over time:

Quality of Service and Service Level capabilities. Higher level SOA concepts, for example service choreography, directory, transformations, and so forth. On Demand operating environment requirements, such as Management and Autonomic capabilities as well

as Infrastructure Intelligence capabilities. Truly heterogeneous operation across multiple networks, multiple protocols, and multiple domains of

disparate ownership.Back to top

Security issues affecting the ESBI wont directly address security requirements here; however, they are likely to be important to the choice ofESB technology. For example, if no authentication or authorization of service requests is required, the choice oftechnology can be very broad. More likely, if some level of security is required, it is important to assess what style ofsecurity will be acceptable. For example:

1. Is security in the communications infrastructure acceptable, for example, in the use of Secure Socket Layermutual authentication between EAI middleware servers, or in the use of the HTTPS protocol?

2. Is individual, point-to-point security acceptable between participating systems, or is an end-to-end modelrequired? For example, is there a need to propagate client identity through intermediate systems such asbrokers to the end-providers of service implementations?

3. Is security in the application layer acceptable, for example, can the client code perform basic HTTPauthentication with a userid and password, or can it pass such information to the service as applicationdata?

4. Is compliance to a security standard security, such as Kerberos or WS-Security, required?

While all of these approaches are possible, the industry direction is towards standards-compliant security (forexample, WS-Security) features supported by infrastructure and middleware. However, these standards arerelatively recent, and product support for them is still emerging rather than established, particularly whereinteroperability is concerned. Thus, one priority of any ESB architecture should thus be to establish the securityrequirements as early as possible, so that they can be included in the choice of implementation technology.

Back to top

SummaryIn this article, I have discussed the most common principles of SOA, and how they relate to web servicestechnology. Based on these principles, I have described a need for an infrastructure component that provides arouting capability to allow services to interact with each other, as well as to support substitution of one serviceimplementation by another. These capabilities are among those implemented by an ESB.
https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pconhttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pconhttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pconhttps://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pcon


9/25

The ESB provides a distributed infrastructure while maintaining centralization of control, requiring some form ofservice routing directory and perhaps a business service directory as well. The Business Service Choreographerinvokes services from the ESB and then exposes processes as new services through the ESB.The many capabilities of the ESB include provisions for:

Communications Service interactions Integration Quality of services Security

Service level Message processing Management and autonomic services Modeling Infrastructure intelligence

From these diverse capabilities, I defined the minimum capabilities to establish an ESB as providing forcommunication, integration, and service interactions.In the next part of this series, I will discuss the common scenarios, the relevant solution patterns for these scenariosand will look at the most common issues affecting these scenarios.

Back to top

ESB scenarios and analysisThe ESB scenarios in SOA section describes the starting points for many SOA and ESB implementations. Each

scenario indicates specific issues driving the architecture and design decisions that affect the selection of solutionpatterns (covered in Part 3 of this series). You can read about these issues in more detail in theIssues driving ESBarchitecture and design decisionssection. These solution patterns represent an evolution from a basic use of servicetechnology, through simple ESB implementations, to a sophisticated SOA infrastructure.It is not the intention of the ESB scenarios to represent the entirety of an organization?s requirements for SOA orESB. For example, whereas one of the scenarios, such as Basic integration of two systems, might seem a goodmatch to a particular current requirement, that requirement might evolve over time into something moresophisticated, such as the Enable wider connectivity to one or more applicationsscenario. Alternatively, there mightbe many separate requirements for SOA or ESB infrastructure which individually match simple scenarios, but overalrepresent something more complex.A balance needs to be struck between implementing a solution that meets the immediately apparent needs,attempting to anticipate future needs, and defining a consistent solution across an Enterprise. It might beappropriate to recognize the organization?s needs as a whole as a relatively sophisticated scenario such

as Implement an SOA infrastructure with high quality of service and web services standards support. An alternativewould be to treat individual situations separately as simple scenarios, but define a roadmap for evolving the resultingsolutions over time into a common infrastructure.

ESB scenarios in SOAThe scenarios characterized in the sections below are:

Basic integration of two systems Enable wider connectivity to one or more applications Enable wider connectivity to legacy systems Enable wider connectivity to an enterprise application integration (EAI) infrastructure Implement controlled integration of services or systems between organizations Automate processes by choreographing services Implement an SOA infrastructure with high quality of service and web services standards support

Basic integration of two systemsScenario

A business need exists to provide basic integration between two systems implemented in different technologies, such as J2EE, .NET, CICS,and so forth. The web services SOAP standard or messaging middleware might be candidate integration technologies. The environments ofboth applications need to support, to some extent, the integration technology. An important question for this scenario is whether the need tointegrate additional systems will likely arise in the future. The use of an extensible solution in the first place might provide support for futurerequirements; however, the additional work of building such a solution needs to be balanced against the initial need to solve a simple problem.
https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table1http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table1http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table3http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table3http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table4http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table4http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table5http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table5http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table6http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table6http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table7http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table7http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table7http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table6http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table5http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table4http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table3http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#table1http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#2.2https://www.ibm.com/developerworks/webservices/library/ws-esbscen/#ibm-pcon


10/25

Most relevantissues

Relevant solution patterns (see next article)

1,3,4,6,10,13 Implement basic integration using wrappers or adaptors -- see Basic Adaptors.

Or, with future expansion in mind, either:o Add a controlling Service Gateway.o Or implement a sophisticated infrastructure -- such as a web services-compliant Brokeror Enterprise

Application Integration Infrastructure for Service-Oriented Architecture (EAI Infrastructure for SOA).

Enable wider connectivity to one or more applicationsScenario

Existing packaged or custom-developed applications, (for example, Customer Relationship Management (CRM), Enterprise Resource Planning(ERP), and so forth) perhaps implemented in the J2EE platform or other application server environments, provide functions that are usefulbeyond the applications themselves. Value exists in exposing these functions as services either to enable the applications to interoperate witheach other, or to provide access to new channels or clients. The use of interoperable or open standard communication and service protocolsseems the best way forward.

Most relevant issues Relevant solution patterns (see next article)

1,2,3,4,6,8,9,10,11,12,13,14 Implement basic integration using wrappers or adaptors -- see Basic Adaptors. Add a controlling Service Gateway. If more sophisticated capabilities are required, implement a Web services-compliant Brokeror

an EAI Infrastructure for SOA.

If Process Choreography is also required, implement a Service Choreographeror a FullService-Oriented Architecture Infrastructure (Full SOA Infrastructure).

Enable wider connectivity to legacy systemsScenario

An organization has a large investment in legacy technologies (such as CICS, IMS, and so forth) supporting applications that provide their corebusiness transactions and data access. Significant value exists in providing interoperable or open standard, service-based access to thosetransactions (for example, transactions that query account balance, create orders, schedule or track deliveries, query stock levels, and soforth).


1,2,3,4,7,8,9,10,11,13,14 Implement basic integration using wrappers or adaptors -- see Basic Adaptors. Or, with future expansion in mind, either:

o Add a controlling Service Gateway.o Or implement a sophisticated infrastructure with a Web services Compliant-Brokeror

an EAI Infrastructure for SOA.

Enable wider connectivity to an EAI infrastructureScenario

There is an existing EAI infrastructure, such as IBM WebSphere Business Integration, to which extended access based on interoperableprotocols or open standards is required. While the exposure of service interfaces defined in terms of XML business data through a highlyinteroperable protocol such as HTTP or WebSphere MQ might provide an appropriate level of interoperability in some scenarios, support for the


11/25

WSDL and SOAP web services standards might be required if neither a custom-developed, nor a proprietary extension to the existing scope ofintegration, are acceptable.


3,4,5,8,9,11,13,14 Extend the EAI infrastructure using open data formats with an EAI Infrastructure for SOA. Add a controlling Service Gateway.

Or add open standard support to the infrastructure with a web services-compliant Broker.

Implement controlled integration of services or systems between organizationsScenario

An organization wishes to enable its customers, suppliers, or other partners to integrate directly with functions provided by one or moreapplications, legacy or otherwise. A point of control is required to provide secure, manageable access from external parties to thoseapplications. The use of open standards is preferred as the organization has no direct control over the technologies used by its partners. Thisscenario might apply either between separate organizations, or between units of a larger distributed organization.


1,2,3,4,6,8,9,10,11,13,14 Add a Service Gateway.

Or if more sophisticated capabilities are required implement a web services-compliantBroker.

Implement controlled integration of services or systems between organizationsScenario

An organization wishes to enable its customers, suppliers, or other partners to integrate directly with functions provided by one or moreapplications, legacy or otherwise. A point of control is required to provide secure, manageable access from external parties to thoseapplications. The use of open standards is preferred as the organization has no direct control over the technologies used by its partners. Thisscenario might apply either between separate organizations, or between units of a larger distributed organization.


1,2,3,4,6,8,9,10,11,13,14 Add a Service Gateway. Or if more sophisticated capabilities are required implement a web services-compliant

Broker.

Automate processes by choreographing servicesScenario (Note: this scenario can be considered an evolution of the Enable wider connectivity to one or more applicationsscenario. It is notconsidered an ESB scenario, as service choreography is usually implemented separately to the ESB, as described in the first a rticle in thisseries. However, I include it here as it is a scenario that often drives requirements for an ESB as well as for a service choreographycomponent.)

Existing packaged (for example, CRM, ERP, and so forth) or custom-developed applications, perhaps implemented in the J2EE platform orother application server environments, provide functions that are useful beyond the applications themselves. These functions can be exposedas services using interoperable or open standard communication and service protocols so that the applications can interact. The interactionscombine at some level to form business processes. These processes should be explicitly modeled and executed using appropriate modelingand process execution technology, possibly in compliance with appropriate open standards.


12/25


1,2,3,4,6,10,11,12,13,14 If the direct connection of services is possible, implement a Service Choreographer. If more sophisticated integration or control is required, implement a Full SOA

Infrastructure.

Implement an SOA infrastructure with high quality of service and web services standards supportScenario

This scenario is a composite of the preceding scenarios. It represents the need to enable widespread internal or external access to servicesprovided by multiple applications, legacy or otherwise. Various security, aggregation, transformation, routing, and service choreographycapabilities are required. An IT organization often drives this scenario in response to increasing demands from across the business it supportsto allow more widespread and flexible integration between business systems.


All Implement a Full SOA Infrastructure.

Back to top

Issues driving ESB architecture and design decisionsIn order to identify a suitable solution pattern and implementation technology for an ESB, requirements for specificESB capabilities will need to be analyzed in detail. The intention of the following questions is to aid this process, andthe preceding section indicates the specific questions relevant to each scenario.

1. Are the existing functions and their data interfaces good matches to the services you want to provide, or canyou modify or aggregate the applications?

o o If not, transformation or aggregation capability will be required either in adaptors or the ESBinfrastructure, or will have to be performed by service clients.

2. Should the services be exposed in the form of some common business data model? If so, do the systemsimplementing those services already support that model, or can they be made to do so?

o If not, transformation or aggregation capability will be required either in adaptors or the ESBinfrastructure.

3. Are open standards required, or can appropriate interoperability be achieved through EAI middleware? Ifopen standards are required, which ones are appropriate?

o While the use of open standards is one way to achieve interoperability, proprietary EAI middlewareis also highly interoperable and often significantly more mature. Many organizations also haveextensive existing infrastructures that can, in some scenarios, minimize the benefits of openstandards.

o In scenarios where open standards are required, web services are perhaps the most obvious choicein this context. However, you can also apply Java Messaging Service (JMS), JDBC, basic XML, orseveral other technologies, such as EDI or industry XML formats.

o In practice, you cannot always assume interoperability between different implementations of thesame standards, particularly if the standards are recent or emerging. In the case of web services,the Web Services Interoperability Organization has published the Basic Profile for interoperabilityusing SOAP and WSDL, and other profiles for more advanced standards will follow (for example,WS-Security, WS-Transaction, and so forth). Until such profiles are comprehensive, established, andwidely supported by products, the use of open standards will not guarantee and might not alwaysfacilitate interoperability.

4. Is support for basic communication protocols and standards (for example, WebSphere MQ, SOAP, WSDL)required, or are more advanced capabilities (for instance, WS-Security, WS-Transaction, and so forth)needed?

o Requirements to support more sophisticated standards will impose more stringent constraints on theoptions for implementation technologies, and might imply the use of less mature technologies.

5. When considering changes to the message formats and protocols used by an existing infrastructure,including the possibility of adoption of open standards, are these changes required throughout the existing
http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#ibm-pcon


13/25

infrastructure, or can they be applied at the edges? If EAI technology is in use or under consideration, doesthat technology have its own internal format, or can it process open standards as an internal format?

o Any use of open standards is likely to be driven by the need to extend access. As such, it is moreimportant that they are available at the interfaces to existing infrastructure than to be used internally.

o If internal use of specific formats, technologies, or standards is required, this will place constraints onthe choice of implementation technology.

6. Do the systems implementing functions that will be exposed as services, support the required technologiesor open standards, such as SOAP, JMS, or XML?

o If not, either the ESB infrastructure or adaptors will need the capability to transform between the

required open standards and the formats supported by the service providers.7. Where access to legacy systems is required, and with the use of more recent XML-based technologies

(including SOAP, but also basic XML with EAI middleware), is direct support (for example, CICS SOAPsupport) available for that legacy system, or are separate adaptors required? Does the legacy platformsupport XML processing, and, if so, is this type of processing a sensible use of the platform capabilities?

o If, for any of these reasons, a required SOAP or XML capability will not be made available on alegacy platform, appropriate transformation capability will be required either in adaptors (such asJ2C Connector Architecture (JCA) or WebSphere Business Integration Adaptors), in an integrationtier, or in the ESB infrastructure.

8. If an EAI technology is already available, does it implement servicesas message flows with appropriatefunction and interface granularity? What connectivity protocols does it support (for example, JCA, SOAP,WebSphere MQ, and Java Remote Method Invocation)?

o If existing message flows do not provide the required services, then additional flows will be needed

to perform transformations. If the EAI technology does not directly support the required standards, aService Gateway component can be added.

9. What measure of protection should be afforded to the service provider systems from service client channelsin the form of workload buffering, security, logging, and so forth?

o Such buffering will often be a role of the ESB infrastructure, and define some of the capabilities itrequires. If specific service provider systems (for example, legacy transactional systems) haveadditional needs for protection, a dedicated integration tier could be used.

10. How many services will be enabled? What aspects of enablement should be consistent across the services,and how can consistency be enforced, perhaps across multiple platforms and applications?

o If very few services are involved, a simple point-to-point integration model might be appropriate.However, if more are involved or likely to become so over time, the addition of a control point, suchas that provided by an ESB, becomes increasingly beneficial.

11. Are the service interactions contained within the organization, or are some interactions external?o If external access is required, a Service Gateway component can be used to provide additional

control. This is often the case in addition to an ESB infrastructure implementation within a singleorganization, as the requirements for security and service routing might differ for services madeavailable externally.

12. Are there requirements for service choreography, and do they involve short-lived or long-lived (in otherwords, stateful) processes, or both? Do they include manual activities?

o Where these requirements constitute business function, the choreography should be implemented ina Service Choreographer component separate from the ESB. Requirements to support long-livedstateful processes or manual activities will place constraints on the choice of implementationtechnology.

13. What service level requirements should the infrastructure support (for example, service response time,throughput, availability, and so forth), and how is it required to scale over time?

o Some of the candidate technologies for ESB implementation are relatively new and might only havebeen tested against limited service levels. Similarly, because the relevant open standards are eitherrecent or emerging, support for them in more established products and technologies is also new.

o For the foreseeable future, critical architectural decisions will be concerned with balancing thebenefits of specific open standards, supported by emerging or mature product technologies againstservice level requirements. These point-in-time decisions will need to recognize that somestandards, and product support for them, are relatively mature (for example, XML, SOAP, and soforth), others (for example, WS-Security) are newer, while others (for example, WS-Transaction) arestill emerging.

o The trade-off between the benefits of standards and proven service level characteristics will oftendrive a mixed approach combining standards-compliant, and proprietary, or custom technologies inan ESB and SOA architecture.


14/25

14. Is a point-to-point or end-to-end security model required (for example, should the ESB simply authorizeservice requests, or should it pass the requestor identity or other credentials through to the serviceprovider)? Is there a need to integrate the service security model with application or legacy securitysystems?

o If point-to-point security is acceptable, a number of existing solutions (for example, SSL, J2EEsecurity for database access, adaptor security models, and so forth) can be applied. If end-to-endsecurity is required, the WS-Security standard is a possibility, providing all the systems involvedsupport it. Alternatively, you could use a custom model with custom message headers or passsecurity information as application data.

Back to topSummaryIn this article, I have established some of the most common scenarios for ESB implementation and the issuesimposing direct forces on corresponding solutions. While the issues covered here might not be all-inclusive, they areamongst those most commonly encountered.The common scenarios outlined range from the basic integration of two systems, to implementing an SOAinfrastructure with high quality-of-service, and web services standard support. The fourteen different issuesdescribed take into account:

Existing data interfaces Business data models The use of open standards Support for basic or advanced communications protocols

Changes to messaging formats from existing systems Exposing existing services through new technologies Access to legacy systems Existing EAI technologies The measures of protection needed How many services to enable and the level of consistency needed Interacting intra-company and with other companies The need for service choreography Infrastructure-level support for service level requirements The use of point-to-point or end-to-end security models

Understanding these basic scenarios and issues gives a strong basis for the potential solutions that you candevelop. In Part 3 of this series, I will discuss the actual solutions as mentioned in this article, namely:

Basic Adaptors Service Gateway Web services-compliant Broker Service Choreographer EAI Infrastructure for an SOA Full SOA Infrastructure

Finally, I will discuss some options available to organizations considering how to evolve their infrastructure in acontrolled and incremental fashion. I will also explain the issues that can guide you in developing your own ESBroadmap.

Continuing our series on architecting an Enterprise Service Bus (ESB) for a Service-Oriented Architecture (SOA), Inow take a look at the various apparent solution patterns to the scenarios described in Part 2 (seeResources).Each of the following sections describes a solution pattern for one style of ESB implementation -- except the Basic

Adaptors pattern, which represents a simpler, point-to-point solution. Each pattern suggests various implementationoptions using current technologies, along with pros, cons, and migration considerations.Note that the diagrams in each solution pattern depict service clientsas being separate from the systems thatprovide services; of course, in many situations the same systems or applications might be both clients and providersof services. The diagrams are not intended to rule out this possibility by separating clients and providers, but dorecognize that there are two different rolesthat might be played by the same system in different interactions. Thisdistinction is often important in determining the way a system selects, identifies, and invokes services in its role as aclient, and receives, handles, and responds to service requests in its role as a provider.The solution patterns characterized in this section are:

Basic Adaptors Service Gateway Web services-compliant Broker
http://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen2.html#ibm-pcon


15/25

Enterprise Application Integration Infrastructure for Service-Oriented Architecture (EAI Infrastructure forSOA)

Service Choreographer Full Service-Oriented Architecture Infrastructure (Full SOA Infrastructure)

The Basic Adaptor solution patternThis solution option represents simple point-to-point service integration using wrapper or adaptor technology, ratherthan a true ESB. Such technology might enable integration through WSDL-defined SOAP access, or otherinteroperable technologies such as IBM WebSphere MQ (MQ). In the case of technologies that do not provide anative model for service interface definition, such as WSDL, a custom model will be needed to fulfill the principles ofSOA.While simple in design, the benefits that can be obtained through this pattern should not be underestimated. Forexample, directintegration through MQ or SOAP/HTTP can still be loosely coupled, particularly if aspects of theinteraction are declared using interfaces. At some point in the future, the integration could be interruptedby an ESBinfrastructure that supports the integration technologies initially used. It is also possible to exert some level of controover service naming and addressing at a process level.A wide range of adapters are available, or can be created, via development tooling or runtime technology. Supportcan be provided for web services standards and Enterprise Application Integration (EAI) middleware. It can also beprovided for a variety of systems including, modern distributed application servers (Java 2 Enterprise Edition (J2EE)servers such as WebSphere or .NET), legacy applications (such as CICS), and Commercial Off-the-Shelf softwarepackages (such as SAP or Siebel).Figure 1illustrates the generic Basic Adaptor solution, including the use of existing HTTP and EAI middleware

infrastructure to support new integrations. While the figure depicts an internal integration scenario, it could alsoapply to external scenarios, providing HTTP is used as the communication protocol, or some form of Internet-compatible EAI technology is available, such as MQ internet pass-thru.

Figure 1. Basic Adaptor solution pattern depicting existing HTTP and unmodified EAI infrastructures assupporting some aspects of Service Bus capability

Implementation technology options for Basic AdaptorsSome of the available options for implementing a Basic Adaptors pattern are:

Use SOAP or EAI capability directly provided by legacy systems or applications. For example, IBM CICSnow provides direct SOAP support, and many systems and application packages can support MQ or SOAPinterfaces.

If the applications you wish to provide access to are custom-developed applications running in an applicationserver environment, either the runtime or application development tooling for the application server can be
http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure4


16/25

used to add wrappers to the application. For example, WebSphere Studio Application Developer can beused to add XML, SOAP, or MQ support to J2EE applications deployed in WebSphere Application Server(Application Server).

Where such support is not available or appropriate (for example, if XML transformation is not an appropriateuse of processing resources on the existing platform), an additional architecture layer might be required, asshown inFigure 2. This might be an application server layer hosting adaptors integrated with application orlegacy systems. For example, Application Developer Integration Edition provides Java 2 ConnectorArchitecture (JCA) connector tooling to access legacy systems, such as CICS, and provides both J2EE andweb services interfaces to them through a WebSphere runtime environment.

Figure 2. Additional architecture layer to perform XML transformation processing

Where development tooling is used to create wrappers, it is possible to augment the function provided bythe tooling: by creating a framework or set of utility classes to perform common tasks, such as security,logging, and so forth. However, this approach can lead to scope creep, and result in the frameworkbecoming a de facto custom-developedService Gatewayorweb services-compliant Broker. Care isrequired when defining the capabilities of a proposed framework to verify that the benefits justify thedevelopment and maintenance cost, and that it would not be more appropriate to switch to a moresophisticated pattern.

SeeResourcesfor more information on the details of implementation advice for this pattern.

Implications of the Basic AdaptorOn the positive side, this solution pattern requires minimal or no new infrastructure, and employs basic, widelysupported standards and technologies. On the negative side, capabilities such as security, management, and soforth, are left to the applications or the implementation of individual wrappers.

Migration to a more sophisticated architecture should be relatively straightforward as this pattern is based on theuse of interoperable technologies and open standards.

Alternative patternsWhere integration requirements cannot be met by any of the options above, or where some additional capability orquality of service requirement exists, a wrapper approach might be insufficient. In this case, aService Gatewayisthe logical next step. If more sophisticated ESB capabilities are required, then either theweb services-compliantBrokerorEAI Infrastructure for SOApatterns could be suitable.

Back to top

The Service Gateway solution patternThis pattern represents a basic ESB implementation, close to "The minimum capability ESB implementation"described inPart 1. Service Gateways often support client connectivity through SOAP/HTTP, MQ, Java Message
http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/##figure5http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/##figure5http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/##figure5http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen/#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen/#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen/#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen/#2.2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/##figure5


17/25

Service (JMS), and so forth, but might support broader integration to service providers through the JCA orWebSphere Business Integration Adaptors, for example. The gateway component acts as a central control point forservice routing, protocol transformation, and security.A gateway can be used to provide clients with a consistent service namespace (for example, in the form of URLs forSOAP/HTTP services) and authorization model to services that are in fact provided by disparate systems throughmultiple protocols. This is obviously a requirement where there is a need to expose services to external partnerssuch as clients or suppliers, but might also be useful within a single enterprise where there is a desire to simplifyaccess from applications to functions implemented in a variety of systems and technologies.A key gateway capability is the transformation from service protocols supported by clients to service protocols

supported by providers. Protocols might include SOAP/HTTP, MQ or SOAP/JMS, JCA, RMI/IIOP, and so forth. Thecapabilities of candidate implementation technologies will need to be assessed against the required client andprovider protocols.Figure 3depicts the Service Gateway solution pattern

Figure 3. Implementation of an ESB using a Service Gateway pattern

Implementation technology options for the Service GatewayThe Service Gateway solution pattern can be implemented in the following ways:

Use packaged gateway technology, such as the Web Services Gateway provided with Application ServerNetwork Deployment or WebSphere Business Integration Connection. Many gateway technologies supportsome form of intermediary filter or handler programming model to enable custom enhancements to function.The Web Services Gateway provides some configurable, intermediary function. It also supports the use ofweb services request and response handlers as defined in the Java APIs for XML-based Remote Procedure

Call (JAX-RPC) specification. Use the application development and runtime capabilities of a modern application server technology to

implement a custom gateway. This might involve the same type of adaptors as described in theBasicAdaptorssolution pattern above.

If more sophisticated function is required, consider more sophisticated EAI middleware such as WebSphereBusiness Integration Message Broker.

A number of implementations of this pattern exist in legacy technology usually without the use of WebService technologies. For example, many organizations have constructed router transactions that offer asimple interface using a text-like data model to multiple legacy transactions. Such systems are effectivelyimplementing the Gateway pattern, using a custom data format with some of the portability benefits of XML.

Implications of the Service Gateway
http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure6


18/25

On the positive side, this solution can involve minimal infrastructure, although some gateway technology must bedeployed in an appropriately resilient manner. The emphasis on interoperable protocols and open standards alsosimplifies infrastructure concerns. The ability of most gateway technology to interact with a number of other interfacetypes, such as RMI/IIOP and JCA, should minimize the deployment of additional connectivity technology.However, gateway technologies will often limit service processing to simple one-to-one mapping of request /response and publish / subscribe services. More sophisticated functions, such as message transformation, messagecorrelation, message aggregation, and so forth might lie outside the capabilities of appropriate technology, orrequire inappropriate development effort in a custom scenario.Most ESB technologies recognize the Gateway pattern and its associated capabilities. Given this, the use of

interoperable protocols and open standards, and the simplicity of gateway function, any migration issues to a moresophisticated ESB infrastructure should be kept reasonably low.

Alternative patterns to the Service GatewayThe most obvious alternative patterns areweb services-compliant BrokerorEAI Infrastructure for SOA. Thesepatterns are suitable when the requirements indicate more capability than would comfortably be associated witha gateway, or than is provided by packaged Gateway technologies. On the other hand, if very few services are infact involved, a simpleBasic Adaptorssolution might be appropriate.

Back to top

Web services-compliant Broker solution patternThis solution pattern represents a sophisticated ESB implementation, providing all the capabilities of a full-fledgedEAI solution, and using an open-standards model. The precise requirements of a specific situation will define whatlevel of EAI capability is required, and hence which EAI technologies are appropriate.Figure 4shows the

implementation of an ESB using a web services-compliant Broker.

Figure 4. Implementation of a rich-featured ESB using a web services-compliant Broker

Implementation technology options for the web services-compliant Broker The available implementation options for theweb services-compliant Brokerare:

The most likely implementation technology for this solution is EAI middleware, such as WebSphereBusiness Integration Server, providing appropriate web services support.

Optionally, where web services support is required primarily for external integration, the proprietary featuresof the EAI middleware can be used internally, combined with the use of aService Gatewaycomponent toadd web services support.

SeeResourcesfor more information on the details of implementation advice for this pattern.

Implications of the web services-compliant Broker
http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure7http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure7http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure7http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#resourceshttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure7http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#1http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3


19/25

The advantages of this implementation are the provision of rich functionality within an open-standards model.However, while EAI middleware is mature, its support for open standards, particularly the more advanced webservices standards, such as WS-Policy and WS-Transaction, might not yet be so mature. So, the primarydisadvantage of this scenario is that it simply might not be viable in all situations.

Alternative patterns to the web services-compliant BrokerIf appropriate web services support cannot be provided, the requirements for a Service Bus can be fulfilled in a moreproprietary or custom manner by theEAI Infrastructure for SOApattern, perhaps in combination with a ServiceGateway component to add web services interfaces. Alternatively, if open-standards support is the most criticalrequirement, and some of the EAI capabilities, such as transformation and aggregation, can be accomplished

elsewhere, perhaps in applications or adaptors, theService Gatewaypattern might be appropriate.Back to top

EAI Infrastructure for SOAFor reasons discussed throughout this article, it might not always be appropriate to adopt the web servicesstandards. However, the principles of SOA can still be applied to construct a solution based around eitherproprietary or custom technology, or alternative open standards.An obvious approach, proven in many successful implementations, is to use EAI technology often, but notexclusively, in combination with XML, to construct a custom SOA infrastructure. As long as service interfaces areexplicitly defined and of appropriate granularity, EAI middleware can ensure that the interoperability and locationindependence principles of SOA are met.The potential benefits of this approach are significant, as the full functional and performance power of mature EAItechnology is applied to the flexibility of SOA. These benefits apply both to the implementation of new, robust

infrastructures for SOA, or to the application of SOA principles to an existing infrastructure.An ESB implemented in this way will use and benefit from important open and de facto standards. Indeed, it might infact be the means by which widespread introduction of these standards to the existing IT infrastructure takes place,providing a basis for further evolution:

Many EAI technologies are so widespread, particularly within individual organizations, that they bring thesame interoperability benefits as open standards.

Where appropriate, XML data and message formats can be used to facilitate interoperability and platformindependence -- just as XML facilitates these benefits in the web services standards.

It is likely that the EAI technology will support some form of web services, so open-standard interfaces mightbe provided where appropriate, particularly using the document/literal SOAP model to expose any XMLformats in use. Alternatively, such access could be provided by addition of aService Gatewayto thesolution.

In some cases, the use of Java as a platform-independent programming language can be used to provide a

client API package, and this might be usable not only from J2EE environments but from standalone Javaenvironments, Database environments that support Java, and various others.

The EAI middleware might support other open standards, such as Java Messaging Service, which while notperhaps quite as broadly applicable as web services, are nevertheless supported by multiple technologies.

This approach can represent a significant step towards a fully open-standard SOA infrastructure. While migration toweb services standards is likely to be at least a consideration at some point, this approach can represent asignificant step towards a fully open-standard SOA infrastructure. The interim use of EAI and perhaps XMLtechnologies does at least provide a means to address questions such as interface granularity, common datamodels and formats, and so forth, all of which are important steps along the way.Finally, I should re-emphasize the benefits of this approach. Mature EAI technology offers an incredible wealth ofESB capability (process and data modeling, transformation, content-based routing, service aggregation andchoreography, and so forth) with proven performance, availability, and scalability characteristics. Where these

capabilities are the most significant requirements, the use of EAI technology to implement an ESB without webservices technologies at the core of the solution is entirely appropriate, particularly since there are a number ofoptions for adding web services support where required.Figure 5depicts the components involved in this solution pattern.
http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure8http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure8http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure8http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#4


20/25

Figure 5. Implementation of a rich-featured Service Bus using EAI middleware

Implementation technology options for the EAI middleware patternThe choice of EAI middleware will be determined by matching the ESB capabilities required by a specific situationwith the features of various EAI products such as the WebSphere Business Integration family.A key area of design activity is in the service interface definition model. In order to comply with the principles ofSOA, services should be defined using an explicit interface. While some EAI technologies might offer such a model,in other cases, a custom solution is required. In practice, this is often implemented using an XML schema combiningservice identification, addressing, and business data. However, non-XML solutions are possible, such as the textual

solutions used by some legacy implementations of theService Gatewaypattern.The function of those aspects of the interface model that are not related to the data model is to declaratively definehow the features of the EAI infrastructure should be used to mediate service requests and responses. Somemechanism is required by which applications can interpret the interface definition and make the appropriate calls tothe EAI infrastructure. Again, this might be provided by the EAI technology; alternatives include the enforcement ofdesign and development standards, or the use of framework APIs.The development and maintenance of a framework API is obviously not trivial, but it is more effective than enforcingstandards across multiple applications. Such an approach is most beneficial where at least a majority of theapplications connecting to the Service Bus support the same programming language, such as Java.Choices also exist in the adoption of a business data model, whether XML-based, proprietary, or custom. Since alarge number of both general and industry-specific XML data models exist, there might be some advantage inadopting one of these models. However, many are in the process of migrating to the web services standards; if thissolution pattern is under consideration because the available web services technologies are not suitable for some

reason, then those standards would not be an option. Finally, if some form of web services or other standards-basedaccess is required to services implemented using this custom solution, then options exist either to use web servicessupport provided by the EAI technology, or to add an explicitService Gatewaycomponent if that provides a bettermatch to the requirements.

Implications of the EAI middleware patternAs this solution pattern can represent significant development, implementation, and maintenance effort, it demandscareful consideration. The benefits are that the solution is entirely consistent with the principles of SOA, hasrepeatedly been proven to deliver business benefit, and can be implemented in mature technologies with enterprise-class function, resilience, and performance.The costs lie primarily in two areas. Firstly, in the initial implementation and ongoing maintenance of the solution,and secondly, in the migration effort that is eventually likely to be required to adopt an open-standards solution asweb services technologies mature, and their use becomes increasingly compelling.
http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#2


21/25

Adoption of this pattern is a point-in-time decision depending on whether near or medium-term advantages justifythe necessary investment. The investment required can depend on the existing level of use of EAI, and on theextent of any additional custom development. The definition of near or medium term depends on when an individualorganization believes that emerging web services standards will be sufficiently mature to meet its functional andnon-functional requirements.

Alternative patterns to EAI middlewareTheweb services-compliant Brokerpattern represents a similar implementation using open-standards technology.

Back to top

The Service Choreographer solution pattern

This pattern consists of the implementation of a dedicated Service Choreography component. Such a component isnot really an ESB, but will support connectivity to services through various protocols, such as SOAP/HTTP or MQ,that either require or imply the presence of an ESB. In some scenarios, such support might be sufficient to allowdirect connectivity to service providers and server requestors. Where that is not the case, an ESB could be providedthrough any of the other solution patterns described in this article. This would constitute theFull SOAInfrastructuresolution pattern.Figure 6depicts the implementation of a Service Choreographer.

Figure 6. Implementation of a Service Choreographer

Implementation technology options for the Service Choreographer The most important choice to make in this solution pattern is the degree to which open-standard support is required.Three scenarios exist:

The wholesale adoption of web services standards for service interfaces and process modeling. The adoption of web services standards for service interfaces combined with the use of proprietary process

modeling technology. The use of both proprietary interfaces and proprietary process modeling technology.

These questions are particularly relevant to this solution pattern as the web services standards relating to processmodeling (primarily Business Process Execution Language for Web Services) are amongst the most recent, andhence amongst those for which product support is least mature. Most vendors of Service Choreography technologywill offer a mixture of proprietary and standards-based technology. Examples of the technology include:

WebSphere Enterprise Process Choreographer technology, which provides support for web servicesinterfaces and process definitions.

MQ Workflow provides support for more mature but more proprietary Service Choreography technology witheither web services or proprietary interfaces.
http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure9http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure9http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#figure9http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#6http://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#ibm-pconhttp://www.ibm.com/developerworks/webservices/library/ws-esbscen3/#3


22/25

If a proprietary technology is adopted, perhaps in order to address scalability or resilience requirements, aServiceGatewaycomponent could be added to provide web services connectivity. If the Service Choreography technologychosen cannot provide sufficient integration with service providers (for example, legacy systems or applicationservers), then an ESB will be required following one of the other solution patterns.

Implications of the Service ChoreographerThe implications of this solution pattern depend largely on whether a standards-based or proprietary solution isimplemented. Standards-based solutions are currently less mature, but will eventually offer better interoperability.Proprietary solutions will likely offer scalability and resil

three roads to the soa implementation framework

Documents