Enterprise Service Bus Features and Advantages

An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services.

The Enterprise Service Bus(ESB) can help you achieve the goal of SOA. It is flexible connectivity infrastructure for integrating applications and services. It is at the heart of an SOA powering it by reducing the number, size, and complexity of interfaces.

An ESB powers your SOA by reducing the size, number and complexity of interface.

An ESB will performs the following things between requestor and service

1) ROUTING the messages between services
2) CONVERTING the transport protocols between requestor and service
3) TRANSFORMING the message formats between requestor and service
4) HANDLING the business events from disparate sources

The Enterprise Service Bus allows us focus on our core business.

The following Advantages

1) Add new services faster
2) Change services with minimal impact to existing services

The following two requirements for an Enterprise Service BUS

a) If all your applications confirm to Web Service standards then all you may require is an ESB focused on standards based service integration.
b) If not all your applications conform to the web services standards then you may require a more advanced ESB focused on the integration of services with existing non-services assets.

The four points i would like to highlight the products

1) Provides Web services connectivity, JMS Messaging and service oriented integration, WebSphere Enterprise Service Bus delivers smart integration to connect your assets through service oriented interface.
2) Ease of use. The tools are easy to use and require minimal programming skills. You don't have to know Java in order to use this tool it is integrated, interactive and provides a visual development experience. Mediation is simply the term used to describe the in-flight processing of information. It is simple to develop, build, test, deploy and manage services components. Easy to understand samples are also included.
3) Improved time to value. This cost effective solution has support for over hundreds of ISV solution such as SAP, Siebel, peoplesoft, JD Edwards, and Oracle. Save time and development costs by utilizing prebuilt mediations such as XML transformation, content based routing and message logging.
4) Seamless integration with the Websphere platform-unlike some of our competition, we have the ability to easily move up the stack to solve more complex business problems with process server, which is built on WebSphere ESB. So you can easily extend to leverage WebSphere Process Server as needs dictate. WebSphere Enterprise Service Bus is built on the WebSphere Application Server; A world -class J2EE foundation providing industry -leading levels of availability, scalability and performance.

Provides Web Services connectivity, messaging and service oriented integration

- Improves flexibility through the adaption of service oriented interfaces
- Gain support for a variety of messaging protocols including JMS 1.1 to exploit a variety of transports and interoperate with the WebSphere family
- Utilize a broad range of interaction models to meet your requirements
- Leverage advanced Web service support to incorporate leading edge capabilities
- Take advantage of a comprehensive clients package to extend your environment
- Leverage UDDI 3.0 for a secure description and description and discovery of web services in an open standards based way.
- reduce sharing by using WebSphere ESB to handle integration logic
- Customized routing -Transport/protocol specific routing and content based routing
- Protocol conversation between a variety of protocols: HTTP, IIOP, JMS
- Format transformation between standards: XML, SOAP, JMS messages and when used with adapters, many more
- Supplied mediation function for database interaction
- Allow the flow of business events and add needed intelligence to that flow
- Leverage WebSphere Adapters for capture and dissemination of business events

Delivering an Enterprise Service Bus that's easy to use
Websphere Integration Developer provides an integrated, interactive and visual development environment for rapid development of integration logic, simple to develop, build, test, deploy and manage services components. Get up and running quickly with comprehensive documentation, easy to understand samples. Provides a simplified and visual development experience for standards based artifacts like XML schema, WSDL, XSLT, etc. Supports the declaration of services and connectivity through a visual composition model. Allows easy orchestration of mediation functions with first-class support for intelligent message routing, enrichment and transformation. Offers a seamless integrated tooling approach to connect between service-oriented and messaging-oriented services. True role-based support provides a simplified administration experience.

WebSphere ESB is designed to be easy to use from both a tools and runtime perspective. Websphere Integration Developer, the tools that works with WebSphere ESB, is built for an integration developer-someone who understands IT systems and architectures but who is not a Java developer.

Both WESB and WID are designed to help customers get up and running quickly and easily, with comprehensive out of the box documentation and a simplified and visual development environment. A visual composition model allows easy orchestration of mediation functions. The fact that tool is role based makes administration much easier.

WebSphere ESB Improving time to value.

Gain a cost effective solution for services integration Leverage your SOA IT investments by quickly building a flexible integration infrastructure to extend the value of your existing investments, regardless of vendor. Modular approach supports ability to start small and grow as fast as the business requires. Extensive business and IT standards support facilities greater interoperability & portability. Utilize first class support for hundreds of ISV solutions. Extensive WebSphere Adapter support, including new JCA-based adapters. Support for numerous ISVs within the WebSphere Platform partner ecosystem.

Save time and development costs by utilizing pre-built mediation functions. Mediations operate in messages/events as they are passed between service requesters and service providers. Operate on both One-Way and Request-Response interactions. Pre-built mediation functions allow mediations to be visually composed and include XML transformation, message logging, message routing, and database lookup, Customers can augment the function provided by the supplied primitives by programming their own 'custom primitives'. Dynamically re-configure to meet changing business needs. WebSphere ESB runtime provides the administrator with the ability to reconfigure service interactions. Avoid system downtime by adding or replacing integration logic dynamically.

WebSphere ESB Seamless integration with the WebSphere platform

Leverages WebSphere qualities of service. Inherits the WebSphere runtime for world class scalability, clustering, and fail-over. Utilizes the common WebSphere Administrative Console to enable system management across WebSphere Application Server. WebSphere ESB, and WebSphere Process Server. Addresses end-to-end security requirements on authentication, resource access control, data integrity, confidentiality, privacy, and secure interoperability.

Easily extends to leverage WebSphere Platform as needs dictate. Customers with the right skills can take full advantage of the underlying capabilities of WebSphere Application Server Network Deployment. Extend your existing WebSphere MQ messaging foundation to integrate new environments in an open, standards-based way. Common tooling and administration means the move from WebSphere ESB to WebSphere Process Server is painless.

Integrates with IBM Tivoli security, directory, and systems management offerings. Includes Tivoli Access Manager, for optional use, to deliver a secure, unified and personalized experience that will help manage growth and complexity. Integrates with IBM Tivoli Composite Application Manager for SOA for added monitoring and management capabilities

Service Oriented Architecture: Triangle of Truth

The triangle of truth is a simple way to look at the important architectural constructs that make up a service oriented architecture. As you begin thinking about what is needed to build a service oriented architecture, the triad that makes up the triangle of truth quickly emerges. Specifically, there needs to be a way to represent the data that is exchanged between services, there must be a mechanism for invoking services, and there should be a way to compose services into a larger integrated business application.

Today there are many different programming models for supporting each construct in the triangle of truth. This situation presents developers with the challenge of not only needing to solve a particular business problem, but they are also faced with choosing and understanding the appropriate implementation technology. One of the important goals of the WebSphere Process Server v6 SOA solution is to mitigate these complexities by converging the various programming models used for implementing service oriented business applications into a simplified programming model.

This presentation focuses specifically on the Service Component Architecture (SCA) introduced in WebSphere Process Server v6 as the service oriented component model for defining and invoking business services. In addition to the important role SCA plays in providing an invocation model for the SOA solution in WebSphere Process Server v6, you will also learn in this presentation that it also plays a role in composing business services into composite business applications.

SCA Basics:

Whenever you are beginning to learn a new technology or programming model, it is often useful to look at the pieces that compose the overall architecture of that technology. This slide lists some of the important features of SCA that you should be aware of as you begin learning about SCA.

First, the Service Component Definition Language(SCDL) provides the basis of SCA. SCDL is an XML based definition language, and is used to define all SCA artifacts in a project. The WebSphere Integration Developer V6.0 tools support of SCA takes care of generating the appropriate SCDL definitions when building an SCA-based applications, however a basic familiarity with SCDL can certainly help understanding the overall architecture and debugging applications.

The next important part of SCA to understand is different is the different types of artifacts that can be defined using SCDL. The various artifact types that exists in SCA were designed to support some of the basic requirements of this service oriented architecture. To start, the most basic building block in SCA is the service component definition. Once a service component is defined, it is important to have a mechanism for making that service available to clients inside and outside of the current.

Service Component Overview:

This is a common concept which will be familiar to those from a WPS background. SCA was first introduced in the concept of WPS V6 as an architecture and implementation to support the enablement of a Service Oriented Architecture approach to process Integration. SCA underpins the programming model in WPS and is also fundamental to WESB. Everything is a Service And a Component And has an interface which describes it.

SCA separates component interface from their implementation. The implementation of an SCA component may change without affecting the interface. It is possible for example, to replace the implementation of component, say with a Web Service invocation rather than invocation through an adapter. We invoke components, so one can regard SCA as perhaps as invocation model as much as anything.

This situation is kind of represented on this next foil - we can see that a Service Component provides an invocable Service Instance. In order to provide that, it must have an Implementation, an Interface, and Configuration properties. A critical point here is that the Implementation can be any of the programming constructs that we provide in WPS. So it could be a BSM, BPEL Process, Map, Adapter, POJO.

Interface can be of two types-Interfaces that this module exposes for consumption by others, and Interfaces exposed by other modules that we want to consume. This latter type of interface consumption is called a reference. We should also note that the interface can be described using either Java interfaces or WSDL. But if there are multiple interfaces specified then you cannot mix WSDL with Java. For reference type you do not have that restriction.

Service Module: Overview

Here we have got our Service Module, which we know is the SCA unit of packaging and deployment. We can see that this particular Module contains 2 Service Components- each containing an implementation, Interface and references where appropriate. This second Service Component does not contain a reference because it does not invoke any external Service.

Now in the Service Module we can see that we have a number of additional things, which are related to incoming and outgoing Interfaces at the Module Level. Remember that an Interface and reference describe incoming and outgoing interface at the Service Component level. Well we have a similar notation at the Service Module level, referred to as imports, Exports and Standalone references.

An Export is how the Service Module exposes its interface to the outside world for consumption by another Service Component within a different Service Module. A Standalone Reference is how the Service Module exposes its interfaces for consumption using a non-SCA client invocation mechanism. Clients using this invocation mode are either Other SCA components within the same SCA module, or non SCA clients such as a JSP. An Import is how a Service Component invokes an external Service. The relationship or potential invocation path between these artefacts is represented by wires.

SCA Basics and terminology

SCA is a runtime that facilitates the abstraction of a component's implementation
SCA separates infrastructure from Business Logic
Provide a programming model for invocation
Support a variety of the invocation models
Provide the runtime infrastructure suited for application consumption

Universal model for Business Services, Publish or operate on business data. Service Data Objects (SDO) provides the universal model for "business data". Components run on a SCA enabled run-time, Java interfaces (j-typed), WSDL port types9w-typed). Arguments and return are described using SDO's, Java classes, or simple Java types. SCA focus on business purpose.

Service data Objects and Business Objects
As introduced already in the triangle of truth, business objects play an important role in the WebSphere Process Server v6 SOA solution as the data abstraction. This is indeed an important goal of the business object framework, but in addition to this, the business object framework also provides some other important functions. Specifically, the business object framework was developed to provide functional capabilities similar to the business object construct found in WebSphere Interchange Server(ICS). The set of capabilities that have been adopted to support ICS style business object functions, are needed to provide a way to help developers mitigate the complexities related to developing applications that work with federated and disparate business data as is commonly the case with integrated enterprise applications.

SCA provides the ability for services to be called synchronously or asynchronously.
An asynchronous invocation model is also provided with the following semantics
One Way -Fire and Forget
Deferred Response-In this model the client makes a request, but does not bloc, but at some later point in time goes back and asks for the response. In this form of invocation takes a second parameter which specifies whether the invocation behaves when the response is not immediately available. (invoke Async() returns a ticket that identifies the invocation. invokeResponse() passes a ticket back in that is used to get the response that corresponds to the invocation identified by the ticket)

The semantics of the synchronous vs asynchronous invocations differ as summarized here. So synchronous invocations are pass-by-reference, whereas asynchronous invocations are pass-by-value. Note also that if you want type-safety you've got to be using Java interfaces definitions. However there is tooling to allow you to generate Java interfaces from WSDL definitions. Synchronous calls outside the JVM are pass-by-value invocations. We could use an extra column in this chart.

Enterprises service bus reference architecture
We are going to introduce all these elements later in the presentation. Lets look at the scope of WSEB and all the things the customer gets in the box. The product is named ESB not Enterprise Service Bus. The naming reflects the industry mindset. It allows an ESB to be built which brokers service requests and responses. It is primarily a Web Services focused platform specifically to support the service interactions that take place within a SOA. ESB is built on AS (ND) and therefore fundamentally a J2EE platform. It leverages and shares technology introduced with WAS V6 and WPS. Use of the additional products and capabilities shown ( for example, TAM) are optional.

Introduces the concept of "mediations" as a term for message (broker) processing. Service invocations are Service messages within the ESB. A new version of WID is released which supports the development of mediation flows. The ESB supports mediation flows and primitives with which to build mediation processing. Support for basic ESB processing is supplied. WESB leverages the messaging support delivered in WAS V6 (SIB) using the JMS 1.1 provider and the MQLink to interoperate with an MQ QM. The WS support again leverages base AS support SOAP/HTTP and SOAP/JMS as protocols and the various WS-* capability. SCA (define) is the programming model which is the technology first surfaced, and shared with WPS. It is the foundation for the composition of mediation and process logic. SDO (define) allows for the logical representation of business data. The SMO (define) is an extension of an SDO message which is the service message which flows through the ESB. XMS clients (C++ and .Net). JAX/RPC client invocations supported via WS C/C++ client. Connectivity to other endpoints is achieved using the WBI Adapters (either the original adapters or the variants which support JCA 1.5).

In a loosely coupled SOA architecture, Service requestors and providers connect with each other through an Enterprise Service Bus. Loosely coupled Services provide more flexibility and ability to introduce mediations and QOS that can then be applied uniformly to the services connecting through the bus. Mediation services intercept and modify messages that are passed between existing services(providers) and clients (requesters) that want to use those services. Mediation services are implemented using mediation modules that contain mediations flows. WebSphere ESB and Process Server provide the ESB capability through the use of Mediation Module deployed in the server. Mediation Module uses the same Service component architecture (SCA) introduced in WebSphere Integration Developer V6.0.0 and WebSphere Process Server V6.0.0

ESB concepts: Medition Module

WebSphere ESB and Process Server introduces a new type of module, called Mediation Module, that intercept and modify messages between service requester and the service provider. Mediation module provides the ESB functions of converting protocols, routing, transformation and other custom processing on the messages. Mediation Module is the unit of deployment and runs within the WebSphere ESB or Process Server. Interactions with external service requesters and providers defined by imports and exports, whose interfaces is defined using WSDL.

A new type of module is introduced in WebSphere ESB and Process Server, called Mediation Module, provides the ESB functionality by allowing the processing the messages between service requestors and providers. This enables loosely coupled connectivity and mediation services between different service requestors and provides connecting through the bus. The Mediation module allows converting protocols, routing, transformation and other custom processing on the messages, tpically needed in an ESB environment. The WebSphere Process Server supports business modules used for business processing and the new mediation modules, whereas WebSphere ESB supports mediation modules. Service requestors interact with the mediation module in the bus via the module exports, and the module interacts with the service providers via the module imports. These export and import interfaces are defined using the WSDL.

Mediation Module: Import and Export bindings

Different kinds of requester and provider types of interactions are made available via different bindings for the imports and exports. WebSphere ESB provides support for JMS bindings- JMS 1.1 provided by WebSphere platform Messaging can exploit a variety of transports TCP/IP, SSL, HTTP(S). Allows interaction with the WebSphere family WAS, WebSphere MQ, WebSphere Message Broker. Web Services binding SOAP/ HTTP, SOAP/JMS, WSDL 1.1, Service Registry -UDDI 3.0, WS-Security, WS-Automatic Transactions. WebSphere Adapter bindings JCA Adapters -SAP, PeopleSoft, Sibel, Files, JDBC, WBI Adapters for all the rest. Built-in SCA (Default) binding Used for module to module communication-supports both synschronous and asynchronous communication. WebSphere ESB supports update this binding via the admin console allowing module to module connectivity to be changed.

Interactions with external service requesters and providers are defined by imports and exports. Import/export interfaces are defined using the Web Services Description Language (WSDL), which may contain several service operations. Different kinds of requester and provider are made available via different bindings for the imports and exports. WebSphere ESB and Process Server v6.0.1 supports JMS binding, WebServices bindings, WebSphere Adapter bindings and the default built-in SCA binding. These different bindings allows maximum flexibility for the requestors and providers to use the protocol of their choice. Use of different bindings permits easy transformation of protocols between the service requestors and providers. The import and Export bindings are same as used for Business modules in WebSphere Process Server.

Mediation flow component and Request-Response interaction

Mediation module contains a new type of SCA component, called Mediation Flow Component. Mediation Flow Components act as 'service intermediaries' to pass a 9potentially modified) request from a service requester to a service provider, pass a (potentially modified) response from a service provider to a service requester. Processing of requests is separated from processing of responses in the mediation flow component. Request processing within a mediation flow component can send a response back to the requester without necessarily needing to contact a service provider.

Mediation Module contain a new SCA component called Mediation flow component which acts as a service intermediary for the processing of the message. The Mediation flow component provides a standard way of processing the message independent of the binding protocol used by the service requestors or providers. It supports one way model where no response is expected or 2 way request and response model. It supports synchronous or asynchronous invocation model, similar to other SCA components. Within the Mediation flow component, the processing of the request message is performed separately from the response message. This allows different processing of the request message is performed separately from the response message. This allows different processing to occur on the request and the response side by having different mediation primitives on the request and response flows.

The mediation application developer may choose to create and handle the response within the mediation flow component without actually calling the service provider. The Mediation Module developer will need to construct the response message based on the interface definition of the module export.

Mediation Module: Contents
Mediation Module can have the following: Exports, defined using WSDL that expose the mediation module to external service requesters. Imports, defined using WSDL, that identify external service providers and their interfaces. A new type of SCA component called, Mediation flow component- this provides the mediation function on the messages between these services requestors and the providers. In cases where the only need is to transform the message from one interaction protocol to another, there may not be any need for a mediation flow component in the module. Optional SCA Java components-this is used in conjunction with the custom mediation primitive or when there is a need to use Java interface.

Mediation module contain exports, imports, a new type of SCA component called the Mediation flow component and optionally other SCA components of type. Mediation Imports are like normal SCA imports with all the supported bindings, namely, Default SCA, JMS, Web Services. Imports are the entry points into the Bus. Similarly, Mediation Exports are like normal SCA exports with all the supported bindings, namely Default SCA, JMS, Web Services. Exports are the exit point from the Bus. A new type of SCA component, called the Mediation Flow component, contains logic of how the message is processed between the input and output of the flow. Functions like message routing, transformation, augmentation, logging or any other custom processing are performed on the message within the Mediation Flow component. Lastly, the module can optionally contain SCA Java components, used to implement custom mediation primitive. More on this later in the presentation.

Mediation Flow editior is used provide the implementation of the mediation components that are used to process the message flow as it flows from the service requestor to the provider through the Enterprise Service bus. The editor contains 3 sections. The top one is the Operation Mediation section used to define the mapping of the source input operation to one or more target output operation. The map is created by visually wiring the input operation to the appropriate target out operation. Once the connection is made between a source and target operation, the middle section called the Mediation Flow section is used to create the message processing flow. Mediation Primitives are added here and wired to create the message flow between input and output operation. The bottom most section of the editor is the mediation properties section to view or modify the properties of the connection, primitives that are highlighted in the mediation flow section.

Mediation flow component design methodologies.
Two types of design methodology

Top- down design
Developer creates with Mediation Flow component with the required interfaces and references. Developers generates an implement (empty) for the Flow component This will open the Mediation Flow component editor. Using the Mediation Flow Editor, the developer create mappings from a source operation to one or more target operations.

Bottom-up design
User starts with actual implementation of the flow component does not yet have the Mediation Flow component. The mediation flow component is then used to assemble the module. This approach can be used to modify any existing design and then merging the implementation of the flow component.

WebSphere ESB provides several built-in mediation primitives and allows the capability of adding your own custom mediation for cases that are note covered by the built-in mediation primitives. Following built-in mediation primitives are provided.

1. Message Logger used to log/store message information to a database.

2. Message Filter to filter messages selectively forwarding them on to output terminals, based on simple condition expression.

3. Database lookup to access information in a database and insert it in the message. The mediation primitive is supplied with key id to look for and where in the message is the value of the key. Using the two information, the value of the specified column for the matching key is inserted in the specified location within the message.

4.XSL Transformation mediation primitive is used to transform messages using XSL transformation. This is mainly used when the target provider has a different interface than the incoming message interface. Using the mapping within the XSLT, one can map the input values to the appropriate output fields.

5. Stop mediation primitive used to stop the flow execution.

6. Fail mediation primitive used for error conditions, where the flow execution is stopped and an exception is generated.

Custom mediation primitive is used to do message processing that is not covered by other ediation primitives by executing custom logic. Custom Mediation Primitive calls a SCA Java component that you create or provide. The SCA Java component must be within the same Mediation module.