Skip to main content

skip to main content

developerWorks  >  SOA and Web services  >

Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 3

Solutions for ESB scenarios

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Rick Robinson (rick_robinson@uk.ibm.com), IT Architect, IBM

28 Jun 2004

In Part 3 of this series on scenarios and solutions for implementing an Enterprise Service Bus, the author examines possible solutions for the various scenarios outlined in Part 2. The ideas on the role of the Bus as explained in Part 1 provide the foundation for the scenarios.

Continuing our series on architecting an Enterprise Service Bus (ESB) for a Service-Oriented Architecture (SOA), I now take a look at the various apparent solution patterns to the scenarios described in Part 2 (see Resources).

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 implementation options using current technologies, along with pros, cons, and migration considerations.

Note that the diagrams in each solution pattern depict service clients as being separate from the systems that provide services; of course, in many situations the same systems or applications might be both clients and providers of services. The diagrams are not intended to rule out this possibility by separating clients and providers, but do recognize that there are two different roles that might be played by the same system in different interactions. This distinction is often important in determining the way a system selects, identifies, and invokes services in its role as a client, 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
  • Enterprise Application Integration Infrastructure for Service-Oriented Architecture (EAI Infrastructure for SOA)
  • Service Choreographer
  • Full Service-Oriented Architecture Infrastructure (Full SOA Infrastructure)

The Basic Adaptor solution pattern

This solution option represents simple point-to-point service integration using wrapper or adaptor technology, rather than a true ESB. Such technology might enable integration through WSDL-defined SOAP access, or other interoperable technologies such as IBM WebSphere® MQ (MQ). In the case of technologies that do not provide a native model for service interface definition, such as WSDL, a custom model will be needed to fulfill the principles of SOA.

While simple in design, the benefits that can be obtained through this pattern should not be underestimated. For example, direct integration through MQ or SOAP/HTTP can still be loosely coupled, particularly if aspects of the interaction are declared using interfaces. At some point in the future, the integration could be interrupted by an ESB infrastructure that supports the integration technologies initially used. It is also possible to exert some level of control over 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. Support can be provided for Web services standards and Enterprise Application Integration (EAI) middleware. It can also be provided 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 software packages (such as SAP or Siebel).

Figure 1 illustrates 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 also apply 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 as supporting some aspects of Service Bus capability
The Basic Adaptor solution pattern

Implementation technology options for Basic Adaptors

Some 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 CICS now provides direct SOAP support, and many systems and application packages can support MQ or SOAP interfaces.
  • If the applications you wish to provide access to are custom-developed applications running in an application server environment, either the runtime or application development tooling for the application server can be used to add wrappers to the application. For example, WebSphere Studio Application Developer can be used 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 appropriate use of processing resources on the existing platform), an additional architecture layer might be required, as shown in Figure 2. This might be an application server layer hosting adaptors integrated with application or legacy systems. For example, Application Developer Integration Edition provides Java 2 Connector Architecture (JCA) connector tooling to access legacy systems, such as CICS, and provides both J2EE and Web services interfaces to them through a WebSphere runtime environment.
    Figure 2. Additional architecture layer to perform XML transformation processing
    The Additional architecture layer to perform XML transformation processing for the Basic Adaptor solution pattern
  • Where development tooling is used to create wrappers, it is possible to augment the function provided by the 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 framework becoming a de facto custom-developed Service Gateway or Web services-compliant Broker. Care is required when defining the capabilities of a proposed framework to verify that the benefits justify the development and maintenance cost, and that it would not be more appropriate to switch to a more sophisticated pattern.

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

Implications of the Basic Adaptor

On the positive side, this solution pattern requires minimal or no new infrastructure, and employs basic, widely supported standards and technologies. On the negative side, capabilities such as security, management, and so forth, 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 the use of interoperable technologies and open standards.

Alternative patterns

Where integration requirements cannot be met by any of the options above, or where some additional capability or quality of service requirement exists, a wrapper approach might be insufficient. In this case, a Service Gateway is the logical next step. If more sophisticated ESB capabilities are required, then either the Web services-compliant Broker or EAI Infrastructure for SOA patterns could be suitable.



Back to top


The Service Gateway solution pattern

This pattern represents a basic ESB implementation, close to "The minimum capability ESB implementation" described in Part 1. Service Gateways often support client connectivity through SOAP/HTTP, MQ, Java Message Service (JMS), and so forth, but might support broader integration to service providers through the JCA or WebSphere Business Integration Adaptors, for example. The gateway component acts as a central control point for service 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 for SOAP/HTTP services) and authorization model to services that are in fact provided by disparate systems through multiple protocols. This is obviously a requirement where there is a need to expose services to external partners such as clients or suppliers, but might also be useful within a single enterprise where there is a desire to simplify access 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. The capabilities of candidate implementation technologies will need to be assessed against the required client and provider protocols.

Figure 3 depicts the Service Gateway solution pattern


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

Implementation technology options for the Service Gateway

The Service Gateway solution pattern can be implemented in the following ways:

  • Use packaged gateway technology, such as the Web Services Gateway provided with Application Server Network Deployment or WebSphere Business Integration Connection. Many gateway technologies support some 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 of Web 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 the Basic Adaptors solution pattern above.
  • If more sophisticated function is required, consider more sophisticated EAI middleware such as WebSphere Business Integration Message Broker.
  • A number of implementations of this pattern exist in legacy technology usually without the use of Web Service technologies. For example, many organizations have constructed router transactions that offer a simple interface using a text-like data model to multiple legacy transactions. Such systems are effectively implementing the Gateway pattern, using a custom data format with some of the portability benefits of XML.

Implications of the Service Gateway

On the positive side, this solution can involve minimal infrastructure, although some gateway technology must be deployed in an appropriately resilient manner. The emphasis on interoperable protocols and open standards also simplifies infrastructure concerns. The ability of most gateway technology to interact with a number of other interface types, 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, message correlation, message aggregation, and so forth might lie outside the capabilities of appropriate technology, or require 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 more sophisticated ESB infrastructure should be kept reasonably low.

Alternative patterns to the Service Gateway

The most obvious alternative patterns are Web services-compliant Broker or EAI Infrastructure for SOA. These patterns are suitable when the requirements indicate more capability than would comfortably be associated with a gateway, or than is provided by packaged Gateway technologies. On the other hand, if very few services are in fact involved, a simple Basic Adaptors solution might be appropriate.



Back to top


Web services-compliant Broker solution pattern

This solution pattern represents a sophisticated ESB implementation, providing all the capabilities of a full-fledged EAI solution, and using an open-standards model. The precise requirements of a specific situation will define what level of EAI capability is required, and hence which EAI technologies are appropriate. Figure 4 shows 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
The Web services-compliant Broker solution pattern

Implementation technology options for the Web services-compliant Broker

The available implementation options for the Web services-compliant Broker are:

  • The most likely implementation technology for this solution is EAI middleware, such as WebSphere Business Integration Server, providing appropriate Web services support.
  • Optionally, where Web services support is required primarily for external integration, the proprietary features of the EAI middleware can be used internally, combined with the use of a Service Gateway component to add Web services support.

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

Implications of the Web services-compliant Broker

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 Web services standards, such as WS-Policy and WS-Transaction, might not yet be so mature. So, the primary disadvantage of this scenario is that it simply might not be viable in all situations.

Alternative patterns to the Web services-compliant Broker

If appropriate Web services support cannot be provided, the requirements for a Service Bus can be fulfilled in a more proprietary or custom manner by the EAI Infrastructure for SOA pattern, perhaps in combination with a Service Gateway component to add Web services interfaces. Alternatively, if open-standards support is the most critical requirement, and some of the EAI capabilities, such as transformation and aggregation, can be accomplished elsewhere, perhaps in applications or adaptors, the Service Gateway pattern might be appropriate.



Back to top


EAI Infrastructure for SOA

For reasons discussed throughout this article, it might not always be appropriate to adopt the Web services standards. However, the principles of SOA can still be applied to construct a solution based around either proprietary or custom technology, or alternative open standards.

An obvious approach, proven in many successful implementations, is to use EAI technology often, but not exclusively, in combination with XML, to construct a custom SOA infrastructure. As long as service interfaces are explicitly defined and of appropriate granularity, EAI middleware can ensure that the interoperability and location independence principles of SOA are met.

The potential benefits of this approach are significant, as the full functional and performance power of mature EAI technology 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 in fact 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 the same interoperability benefits as open standards.
  • Where appropriate, XML data and message formats can be used to facilitate interoperability and platform independence -- 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 might be provided where appropriate, particularly using the document/literal SOAP model to expose any XML formats in use. Alternatively, such access could be provided by addition of a Service Gateway to the solution.
  • 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 Java environments, Database environments that support Java, and various others.
  • The EAI middleware might support other open standards, such as Java Messaging Service, which while not perhaps 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 to Web services standards is likely to be at least a consideration at some point, this approach can represent a significant step towards a fully open-standard SOA infrastructure. The interim use of EAI and perhaps XML technologies does at least provide a means to address questions such as interface granularity, common data models 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 of ESB capability (process and data modeling, transformation, content-based routing, service aggregation and choreography, 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 Web services technologies at the core of the solution is entirely appropriate, particularly since there are a number of options for adding Web services support where required.

Figure 5 depicts the components involved in this solution pattern.


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

Implementation technology options for the EAI middleware pattern

The choice of EAI middleware will be determined by matching the ESB capabilities required by a specific situation with 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 of SOA, 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 combining service identification, addressing, and business data. However, non-XML solutions are possible, such as the textual solutions used by some legacy implementations of the Service Gateway pattern.

The function of those aspects of the interface model that are not related to the data model is to declaratively define how the features of the EAI infrastructure should be used to mediate service requests and responses. Some mechanism is required by which applications can interpret the interface definition and make the appropriate calls to the EAI infrastructure. Again, this might be provided by the EAI technology; alternatives include the enforcement of design 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 enforcing standards across multiple applications. Such an approach is most beneficial where at least a majority of the applications 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 a large number of both general and industry-specific XML data models exist, there might be some advantage in adopting one of these models. However, many are in the process of migrating to the Web services standards; if this solution 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-based access is required to services implemented using this custom solution, then options exist either to use Web services support provided by the EAI technology, or to add an explicit Service Gateway component if that provides a better match to the requirements.

Implications of the EAI middleware pattern

As this solution pattern can represent significant development, implementation, and maintenance effort, it demands careful consideration. The benefits are that the solution is entirely consistent with the principles of SOA, has repeatedly 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 as Web services technologies mature, and their use becomes increasingly compelling.

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

Alternative patterns to EAI middleware

The Web services-compliant Broker pattern 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 is not 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 allow direct connectivity to service providers and server requestors. Where that is not the case, an ESB could be provided through any of the other solution patterns described in this article. This would constitute the Full SOA Infrastructure solution pattern.

Figure 6 depicts the implementation of a Service Choreographer.


Figure 6. Implementation of a Service Choreographer
The Service Choreographer solution pattern

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 process modeling (primarily Business Process Execution Language for Web Services) are amongst the most recent, and hence amongst those for which product support is least mature. Most vendors of Service Choreography technology will offer a mixture of proprietary and standards-based technology. Examples of the technology include:

  • WebSphere Enterprise Process Choreographer technology, which provides support for Web services interfaces and process definitions.
  • MQ Workflow provides support for more mature but more proprietary Service Choreography technology with either Web services or proprietary interfaces.

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

Implications of the Service Choreographer

The implications of this solution pattern depend largely on whether a standards-based or proprietary solution is implemented. Standards-based solutions are currently less mature, but will eventually offer better interoperability. Proprietary solutions will likely offer scalability and resilience in better-known models, and might well utilize highly interoperable communication technologies such as MQ. However, as open-standard technologies mature and become pervasive, some migration effort might eventually be required.



Back to top


The Full SOA Infrastructure solution pattern

This pattern represents the combination of a Service Choreographer component with a Service Bus implementation. As both these aspects are described in detail elsewhere in this article, they will not be described further here, except to say that an entire spectrum of implementation is obviously possible. At one end are entirely proprietary solutions using the EAI Infrastructure for SOA pattern for the ESB and a proprietary Service Choreographer technology. At the other are entirely open-standard solutions using the Web services-compliant Broker pattern for the ESB, and an open-standards compliant Service Choreographer technology.



Back to top


A roadmap for SOA and ESB adoption

The patterns described in this article are concerned with constructing an ESB for immediate needs, and are likely to be simply the first step towards a more comprehensive SOA implementation. This section discusses some of the options available to an organization considering how to evolve in a controlled and incremental fashion. I do not propose that there is a single roadmap for all organizations; rather, I intend to discuss some of the issues that should be considered in the construction of an SOA or ESB roadmap.

Identifying the immediate scope of concern

In a simplistic view, two major aspects to implementing a comprehensive SOA exist: the implementation of a fully functional, resilient infrastructure, and the exposure of all relevant function across the business as services. While not entirely independent, a degree of decoupling exists between these two aspects, allowing organizations some flexibility in how they choose to approach them.

In some ways, the first decision is whether to prove an ESB technology, or to prove the SOA principles of functional architecture? This question leads to two extremes of approach:

  • Rich Infrastructure, Pilot Function -- Here, the primary concern is proving technology capability. The infrastructure is likely to include sophisticated ESB capabilities (whether open-standard or proprietary), and perhaps constitute the Full SOA Infrastructure solution pattern. However, such a technical solution incorporates a high degree of risk and might incorporate relatively immature technologies. Thus, its implementation will not be linked to business critical projects or functions. The functions exposed as services might either be of low criticality, or remain delivered primarily through alternative channels. As the infrastructure capability is proven and matures, services will be migrated to it over time.
  • Basic Infrastructure, Rich Function -- Here, the primary concern is the exposure of business function as services so that they can be accessed or combined in new ways to deliver business value. In this case, the forecasted business benefit or other factors driving change are usually significant enough that a lower level of technical risk is mandated. Consequently, the infrastructure is implemented either using only the most basic and mature Web services standards, or using more established EAI technologies. Once the infrastructure is in place and supporting service interactions, its capabilities can be upgraded or migrated over time as ESB technologies mature.

Of course, there are two other extreme cases of approach -- to do nothing, or to do everything at once, but these are perhaps less interesting from the point of view of a roadmap!

Another approach is adoption by stealth. That is, the incremental adoption of SOA and ESB principles, technologies, and infrastructure by individual departments, projects, or applications. Many organizations might in this way have progressed further with ESB or SOA adoption than might be immediately apparent. This local adoption of specific technologies or practices might often provide a more successful proof of them than a big-bang approach. This is similar to the Rich Infrastructure, Pilot Function approach, but consists of many basic infrastructures rather than a single rich one.

There are two other aspects of an approach to SOA that should be established early on: the provision of internal or external access to services, and an approach to service granularity.

The decision to support internal or external access will drive several factors, including what level of service security is required (see Security issues affecting the ESB above), and whether an explicit Service Gateway component is required to control external access. External access might also drive the use of Web services standards, whereas for internal access more flexibility is possible, such as MQ, RMI/IIOP, or proprietary XML, as discussed in the EAI Infrastructure for SOA solution pattern.

The issue of service granularity has been discussed widely in the industry (see Resources). A comprehensive SOA is likely to contain various granularities of service, from technical operational functions, such as logging, billing, and so forth, through business functions, such as query account balance, to business processes, such as process stock order.

Services at each level of granularity will be composed from services, or other functions of lower levels of granularity. Hence, there are several levels of service aggregation or choreography to consider, which might well be suited to more than one implementation technology. A practical way to deal with this issue in any specific situation is to identify, characterize, and name the levels of service granularity which are applicable. Specific aggregation or choreography requirements between different granularity levels can then be defined, and appropriate implementation technologies selected.

Finally in this context, it is worth noting the relationship between the top-down and bottom-up models of service enablement. The bottom-up approach is focused on enabling the functions of applications and legacy systems as services. In the general case, this involves the use of adaptors and development tooling to provide appropriate interfaces, and results in the enablement of relatively fine-grained business functions.

The top-down approach is more concerned with the architectural process of analyzing business systems and components to identify processes and services. This tends to identify coarse-grained services which are likely to be composed of more fine-grained services.

It is likely that many organizations will employ both these approaches to service identification and enablement; some sort of meeting in the middle is then required to combine them. That meeting is likely to be more straightforward to engineer if it is undertaken while explicitly recognizing and categorizing the various granularity levels as suggested here.

SOA milestones

Whichever broad approach is taken to full SOA implementation, there are a number of milestones that will need to be passed along the way. This section identifies and discusses some of these milestones. The milestones are not presented in order, as they are largely independent, and the order in which they are achieved depends on many factors affecting individual organizations:

  • Standards-based Security model -- While simplified or proprietary models might be sufficient in the short term, a full-featured and open-standard security model will be essential to a comprehensive SOA. Understanding the point at which product support for the Web services security standards meets an organization’s requirements should be a key component of the overall implementation plan.
  • Enable service legacy systems and applications -- In the same way that the evolution of modern application servers (for example, J2EE servers such as Application Server) led organizations to enable SQL and JDBC or ODBC interfaces to their databases, the evolution of SOA will drive organizations to enable service-based access to their legacy transactions and application functions. Organizations should therefore, plan to define and implement the most appropriate form of service enablement for each system. Options include leveraging native XML or Web services support, the use of adaptors such as JCA adaptors, or the use of EAI or Gateway technology providing legacy connectivity.
  • Implement a high quality of service infrastructure -- By far the most mature Web services support available is for an unreliable communication protocol, SOAP/HTTP; standards offering higher qualities of services, such as WS-ReliableMessaging or WS-Transaction, are not yet widely supported. Providing higher qualities of service for SOA currently requires the use of EAI technology. Long-term, organizations should keep abreast of support for emerging standards, and the convergence of EAI technologies with Web services standards.
  • Identified service granularity levels -- as noted in Identifying the immediate scope of concern above, it is critical to identify the levels of granularity relevant to an SOA, and the requirements for aggregation and choreography between them. Implementation of each level of granularity (for example, technical function, business function, business process, and so forth) and the associated choreography should also form a key milestone.

Steps to SOA implementation

Following the discussions in the preceding two sections, you are now in a position to compose a general roadmap for SOA and Service Bus implementation:

  1. Decide which elements of SOA technology or SOA function are your priorities to implement (see Identifying the immediate scope of concern).
  2. Identify or define a suitable project to implement a first solution, either a technical pilot, a business pilot, or perhaps a real business project with an acceptable risk profile.
  3. Identify which one of the ESB Scenarios in SOA is applicable to the project. Further analyze the requirements relative to the Issues driving ESB architecture and design decisions and A capability model for the ESB. Select one of the solution patterns based on this analysis. Based on further analysis and security and non-functional requirements (see Security issues affecting the ESB), select an appropriate implementation technology.
  4. In parallel to this work, begin planning the roadmap to evolve this first implementation towards a fully comprehensive SOA. Depending on the focus of the initial pilot, this might involve various aspects of evolving the technical capability of the infrastructure, or enabling additional functional services to take advantage of it. In either case, the roadmap should include the SOA milestones identified above.

Beyond these initial projects, plan to evolve in several directions:

  • Evolve and improve data models and processes across the organization.
  • Implement phased-service enablement of applications, and bring them into the infrastructure.
  • Evolve the technical capability of the SOA infrastructure.

This ends my series explaining how to make best use of an ESB from an architectural point of view. As the technology behind SOA progresses, you might see more uses and solutions for the ESB that we hopefully will explore even further, in the future.



Resources



About the author

Rick Robinson works as an IT Architect for IBM, having joined the company in March 1997 as a developer. He is a member of the Architecture Services group in EMEA WebSphere Lab Services, having focused on the WebSphere software platform since its origins in 1999. Rick has a technology, rather than industry, focus, but has spent much of the last three years working with companies in the Financial sector. Rick is an accredited member of the IT Architect Profession within IBM. Prior to joining IBM, Rick studied for a Ph.D. in Physics.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful		Extremely
useful
 


Back to top