Enterprise Service Bus (ESB), is a flexible connectivity infrastructure that allows applications and services to be integrated.
Enterprise Service Bus (ESB) is a tool that can assist you in achieving the SOA goal. It provides flexible connectivity infrastructure to integrate applications and services. It is the core of an SOA, reducing the complexity, size, and number of interfaces.
An ESB is a tool that powers your SOA, reducing the number of interfaces and their complexity.
The following tasks are performed by an ESB between the requestor and the service
1) ROUTING messages between services
2) TRANSFERRING the transport protocols between service requestors and service
3) TRANSFORMING message formats between service requestors and service providers
4) HANDLING business events from different sources
The Enterprise Service Bus lets us concentrate on our core business.
These are the Advantages
1) Add new services faster
2) Modify services without causing any disruption to existing services
These are the two requirements to create an Enterprise Service BUS
a) All your applications must conform to Web Service standards. If not, an ESB focusing on standards-based service integration may be all that you need.
b) You may need a more advanced ESB to integrate services with non-service assets if not all of your applications meet the web services standards.
These are the four points I would like to emphasize about the products
1) WebSphere Enterprise Service Bus provides connectivity to Web services, JMS messaging, and service-oriented integration. It enables smart integration that connects your assets via a service-oriented interface.
2) Ease-of-use. These tools require little programming knowledge and are simple to use. This tool is interactive, integrated and offers a visual development experience. You don’t need to know Java to use it. Mediation simply refers to the in-flight processing and storage of information. It is easy to create, build, test and deploy services components. You will also find easy-to-understand samples.
3) Increased time to value. This cost-effective solution supports hundreds of ISV solutions such as SAP, Siebel and peoplesoft. Prebuilt mediations like XML transformation and content based routing can help you save time and money.
4) Easy integration with Websphere platform – unlike some competitors, we are able to move up the stack and solve more complicated business problems using process server, which was built on WebSphere ESB. WebSphere Process Server can be easily extended to meet your needs. WebSphere Enterprise Service Bus is built upon the WebSphere Application Server, a world-class J2EE foundation that provides industry-leading levels in availability, scaleability and performance.
Provides Web Services connectivity, messaging, and service-oriented integration
– Increases flexibility by adapting service-oriented interfaces
– Get support for JMS 1.1, a range of messaging protocols to exploit transports and interoperate within the WebSphere family
Use a wide range of interaction models to suit your needs
– Use advanced Web services support to integrate cutting edge capabilities
To extend your environment, take advantage of the comprehensive client package
Use UDDI 3.0 to secure the description, discovery and description of web services using open standards.
Reduce sharing by using WebSphere ESB for integration logic
– Customized routing
– Protocol conversation between various protocols: HTTP, IIOP and JMS
– Format Transformation between Standards: XML and SOAP. JMS messages. When used with adapters, many other formats are possible
– Supplied mediation function for database interaction
– Facilitate the flow of business events, and add intelligence to this flow
– Leverage WebSphere Adapters to capture and disseminate business events
Easy to use Enterprise Service Bus
Websphere Integration Developer is an integrated, interactive, and visual development environment that allows rapid development of integration logic. It’s easy to create, build, test and deploy services components and it can be managed. You can quickly get up and running with detailed documentation and easy-to-understand samples. This visual tool allows you to quickly develop standards-based artifacts such as WSDL, XML schema, XSLT, and WSDL. Visual composition model supports the declaration of services or connectivity. Facilitates the orchestration of mediation functions, with first-class support to intelligent message routing and enrichment. Integrates service-oriented and messaging-oriented services into one seamless tooling system. A true role-based support system simplifies administration.
WebSphere ESB was designed to be simple to use, both from a tool and runtime perspective. Websphere Integration Developer is the tool that is used with WebSphere ESB. It is designed for integration developers who are familiar with IT systems and architectures, but not Java developers.
WID and WESB are both designed to assist customers in getting up and running quickly. They provide comprehensive documentation and a visual development environment. The visual composition model makes it easy to orchestrate mediation functions. Administration is made easier by the fact that this tool is role-based.
WebSphere ESB – Improving value and time.
Get a cost-effective solution for services integration. You can leverage your SOA IT investments and quickly build a flexible integration infrastructure that will increase the value of all your investments, regardless which vendor. The modular approach allows you to grow your business quickly and start small. The extensive use of business and IT standards allows for greater interoperability and portability. You can get first-class support for hundreds ISV solutions. Wide range of WebSphere Adapter support, even new JCA-based adapters. Numerous ISVs are supported within the WebSphere Platform partner network.
Pre-built mediation functions can save time and reduce development costs. Mediations work in messages/events and are sent between service providers and requesters. You can use it for both One-Way or Request-Response interactions. Pre-built mediation functions enable mediations to visually be composed. They include XML Transformation, message logging and database lookup. Customers can add functionality by programming their own custom primitives’. You can dynamically re-configure your business to meet evolving needs. The WebSphere ESB runtime gives administrators the ability to reconfigure service interactions. You can avoid system downtime by dynamically adding or replacing integration logic.
Integration seamless between WebSphere ESB and the WebSphere platform
Make use of the WebSphere quality services. WebSphere runstime is used to provide world-class scalability, clustering and fail-over. Uses the WebSphere Administrative Console to manage WebSphere Application Server. WebSphere ESB and WebSphere Process Server. This document addresses end-to-end security requirements for authentication, resource access control and data integrity, confidentiality and privacy.
You can easily extend WebSphere Platform to suit your needs. Customers who have the right skills will be able to fully take advantage of WebSphere Application Server Network Delivery’s underlying capabilities. Expand your WebSphere MQ messaging base to allow for the integration of new environments using open standards. It is easy to move from WebSphere ESB into WebSphere Process Server using the same administration and tooling.
Integrates with IBM Tivoli security directory and systems management offerings. Tivoli Access manager is available for optional use to provide a secure, unified, and personalized experience that will assist in managing complexity and growth. Integration with IBM Tivoli composite application manager for SOA monitoring and management capabilities
Triangle of Truth: Service-Oriented Architecture
The triangle of truth is an easy way to see the key architectural elements that make up service-oriented architecture. The triangle of truth is quickly revealed when you start to think about the elements that are required for a service-oriented architecture. There must be a way for data to be represented between services. Additionally, services must be invoked. Finally, services should be combined into an integrated business application.
There are many programming models available today to support each component of the triangle. Developers are faced with two challenges: solving a specific business problem and choosing the right implementation technology. The WebSphere Process Server 6 SOA solution aims to reduce these complexities by combining the different programming models for service-oriented business applications into one simplified model.
This presentation will focus on the Service Component Architecture, (SCA), which was introduced in WebSphere Process Server version 6. It is a service-oriented component model that allows for the definition and activation of business services. This presentation will highlight the role that SCA plays in creating business services into business applications.
It is helpful to examine the components of a technology before you start to learn it. The slide below lists the most important aspects of SCA you need to know as you learn about SCA.
The Service Component Definition Language (SCDL) is the first thing that provides the foundation for SCA. SCDL is an XML-based definition language that is used to describe all SCA artifacts within a project. WebSphere Integration Developer V6.0 supports SCA by generating appropriate SCDL definitions for building SCA-based apps. However, a basic understanding of SCDL is helpful in understanding the overall architecture and debugging the applications.
Next, you need to be able to identify the types of artifacts using SCDL. SCA’s various artifact types were created to meet some of the requirements of service-oriented architecture. The service component definition is the foundation of SCA. Once you have defined a service component, you need a way to make that service available to clients both inside and outside the current.
Service Component Overview:
It is a common concept that will be familiar to WPS veterans. SCA was introduced as architecture and implementation in WPS V6 to support process integration. SCA is fundamental to WESB and the programming model in WPS. Everything is a Service and a Component. Each component has an interface that describes it.
SCA is a way to separate the component interface and their implementation. SCA components can be implemented in different ways without affecting their interface. For example, it is possible to replace an SCA component’s implementation with a Web Service invoke rather than an adapter-invocation. Invoking components is possible, so SCA can be considered as an invocation model.
This is how the situation looks on the next foil. We can see that a service component provides an invocable Service instance. It must possess an Implementation, Interface and Configuration properties in order to do that. The Implementation can include any of the WPS programming constructs. This is a critical point. It could also be a BSM, BPEL Process, Map, Adapter, POJO.
Interface can come in two forms: Interfaces that this module exposes to others for consumption, and Interfaces that are exposed by other modules we wish to consume. This second type of interface consumption is known as a reference. It is possible to describe the interface using Java interfaces, or WSDL. If there are multiple interfaces, you can’t mix WSDL and Java. This restriction does not apply to reference types.
Service Module: Overview
We have our Service Module. This is the SCA unit for packaging and deployment. This particular Module has 2 Service Components. Each component contains an implementation, interface and references. The second Service Component doesn’t contain a reference, as it does not invoke an external Service.
We can now see in the Service Module that there are additional items, which relate to the incoming and outgoing interfaces at the Module Level. An Interface and a reference are used to describe the incoming and outgoing interfaces at the Service Component Level. We have a similar notation at Service Module level. These are referred to imports, exports and standalone references.
An Export describes how the Service Module’s interface is exposed to the outside world in order for it to be consumed by another Service Component of a different Service Module. A standalone reference is the way that the Service Module exposes its interfaces to the outside world for consumption by another Service Component within a different Service Module. This invocation mode is used by clients who are either other SCA components of the same SCA module or non-SCA clients like a JSP. An import is when a Service Component invokes another Service. Wires are used to represent the potential invocation path or relationship between these artifacts.
SCA terminology and basics
SCA is a runtime that allows for the abstraction of component implementations
SCA separates infrastructure from Business Logic
Invocation programming model
Support for a variety invocation models
Provide the infrastructure needed to support application consumption
Universal model for Business Services. Publish and operate on business data. Service Data Objects, (SDO), is the universal model for “business information”. The components run on an SCA-enabled run-time with Java interfaces (jtyped) and WSDL port types9w typed. SDO’s, Java Classes, or simple Java types are used to describe arguments and returns. SCA’s focus is on the business purpose.
Service data objects and Business Objects
As the data abstraction, business objects are an important part of the WebSphere Process Server 6 SOA solution. While this is a key goal of the business objects framework, there are other important functions as well. The business object framework was designed to offer functional capabilities that are similar to those found in WebSphere Interchange Server (ICS). These capabilities have been developed to allow developers to reduce the complexity of developing applications that use federated or disparate business data, as often the case when creating integrated enterprise applications.
SCA allows services to be called either synchronously, or asynchronously.
The following semantics are also available for an asynchronous invocation model
One Way – Fire and Forget
Deferred Response-In this case, the client makes a request but does not block, and then later, he or she asks for the answer. This form of invocation requires a second parameter that specifies how the invocation will behave if the response is not available immediately. (invoke Async() will return a ticket identifying the invocation. invokeResponse() returns a ticket that can be used to retrieve the response to the invocation specified by the ticket.
As summarized below, the semantics of synchronous and asynchronous invocations are different. Asynchronous invocations can be passed-by-reference while synchronous invocations can be passed-by-value. You must use Java interfaces definitions if you want to achieve type-safety. There is software that allows you to create Java interfaces using WSDL definitions. Pass-by-value invocations are used for synchronous calls that occur outside of the JVM. This chart could have an additional column.
Enterprises service bus reference architecture
All these elements will be introduced later in the presentation. Let’s take a look at the scope and contents of WSEB, as well as all that the customer receives in the box. The product’s name is Enterprise Service Bus, not Enterprise Service Bus. This reflects the industry’s mindset. This allows for the creation of an ESB that brokers can use to respond to requests and provide service responses. It is a Web Services-oriented platform that supports service interactions within SOAs. ESB is built upon AS (ND), and is therefore fundamentally a J2EE platform. It shares the technology from WAS V6/WPS. The additional capabilities and products shown (e.g., TAM) can be used at your discretion.
Introduces the term “mediations” to describe message broker (or message) processing. Service invocations can be described as Service messages within the ESB. WID 4.0 is now available. This version supports the development and maintenance of mediation flows. The ESB supports mediation flow and primitives that can be used to build mediation processing. Basic ESB processing support is available. WESB uses the messaging support provided in WAS V6. (SIB). It uses the JMS1.1 provider and MQLink to communicate with an MQ QM. The WS support leverages the base AS support SOAP/HTTP, SOAP/JMS and various WS* capabilities. SCA (define), the programming model that was first developed, is shared with WPS. It is the basis for the composition and operation of process logic and mediation. SDO (define), allows for the logical representation business data. SMO (define), an extension of the SDO message, is the service message that flows through the ESB. XMS clients (C++,.Net). JAX/RPC client calls supported by WS C/C++ client. The WBI Adapters allow for connectivity to other endpoints (either the original adapters, or variants that support JCA 1.5).
Service requestors and service providers can connect through an Enterprise Service Bus in a loosely coupled SOA structure. Service that are loosely coupled allows for greater flexibility in the introduction of mediations and QOS. These can then be applied uniformly across all services connected through the bus. Mediation services intercept and modife messages between services (providers) or clients (requesters), that they are intended to be used. Mediation modules contain mediation flows and are used to implement mediation services. The Mediation Module is deployed on the server by WebSphere ESB or Process Server to provide ESB capabilities. The Mediation Module utilizes 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/Process Server introduces a new module called Mediation Module. This module intercepts and modifies messages between the service provider and service requester. The ESB functions for converting protocols, routing and transformation, as well as custom processing of the messages, are provided by Mediation Module. The Mediation Module is the unit that runs within the WebSphere ESB and Process Server. Interactions with providers and external service requesters defined by imports or exports. Interfaces are defined using WSDL.
WebSphere ESB and Process Server now have a new module called Mediation Module. This module allows the processing of messages between service requestors or providers. This allows for loosely coupled connectivity between service requestors, and facilitates mediation services. It also provides connections through the bus. The Mediation module can be used to convert protocols, transform, and perform other custom processing of messages in an ESB environment. WebSphere ESB supports the mediation modules. The WebSphere Process Server supports business module for business processing. The module exports allow service requestors to interact with the mediation module. Module imports allow the module to interact with the service providers. These interfaces can be exported and imported using the WSDL.
Mediation Module: Import bindings and export bindings
Different types of provider and requester interactions can be made available through different bindings to the imports or exports. WebSphere ESB supports JMS bindings – JMS 1.1 can be used by WebSphere platform Messaging to exploit a variety transports TCP/IP and SSL. Interacts with WebSphere MQ and WebSphere Message Broker. Web Services binding SOAP/HTTP, SOAP/JMS and WSDL 1.1. Service Registry –UDDI 3.0. WS-Security. WS-Automatic Transactions. WebSphere Adapter bindings JCA Adapters –SAP, PeopleSoft and Sibel. Files JDBC, WBI Adapters are available for all other requirements. Built-in SCA (Default) binding Used for module to module communication-supports both synschronous and asynchronous communication. WebSphere ESB allows you to update the binding through your admin console, enabling module to module connectivity.
Imports and exports are used to define interactions with external service providers and requesters. The Web Services Description Language (WSDL) is used to define import/export interfaces. This language may include multiple service operations. Different types of provider and requester can be made available through different bindings to the imports or exports. WebSphere ESB, Process Server v6.0.1, supports WebServices bindings, WebSphere Adapter bounds, and the default built in SCA binding. This flexibility allows providers and requestors to choose the protocol they prefer. Different bindings allow for easy transformation between service providers and requestors. The Import and Export bindings work the same way as for Business modules in WebSphere Process Server.
Component of the Mediation flow and Request-Response interaction
The Mediation module includes a new type SCA component called the Mediation Flow Component. The Mediation Flow components act as “service intermediaries” to pass a (9potentially modified request) from a requester to a provider and pass a (potentially modifed) response from the provider to a requester. The processing of requests and the response are separate. A request processing component within a mediation flow can send a reply back to the requester, without necessarily needing contact with a service provider.
The Mediation Module contains a new SCA component, the Mediation flow component. This component acts as a service intermediary in the processing of the message. The Mediation flow component allows for a standard method of processing the message regardless of what binding protocol is used by service providers or requestors. It can support either a one-way model in which no response is expected, or a two-way request and response model. Similar to other SCA components, it supports both synchronous and asynchronous invocation models. The Mediation flow component separates the request message from the response message. This allows for different processing of the request message. This allows for different processing on the request side and on the response side.
A mediator application developer can choose to handle the response in the mediation flow component, rather than calling the service provider. Based on the module export interface, the Mediation Module developer must create the response message.
Mediation Module: Contents
The Mediation Module can include the following: External service requesters can access mediation module exports that are defined using WSDL. WSDL defines imports that identify service providers and their interfaces. The Mediation flow component is a new type of SCA components. This provides the mediation function between the service requestors (providers) and the messages. A module may not need a mediation flow component if the only purpose is to convert the message from one protocol to the other. Optional SCA Java components – This is used when there is a requirement to use the Java interface or in conjunction with the custom mediator primitive.
The Mediation module contains exports, imports and a new type SCA component, the Mediation flow. Mediation Imports look just like regular SCA imports but with all supported bindings (Default SCA, JMS and Web Services). The entry points to the Bus are through imports. Mediation Exports work in the same way as normal SCA exports but with all supported bindings (Default SCA, JMS and Web Services). The bus exit point is the exports. The Mediation Flow component is a new type of SCA. It contains logic that controls how the message will be processed between the inputs and the outputs of the flow. The Mediation Flow component performs functions such as message routing, transformation, augmentation and logging. Optionally, the module may contain SCA Java components. These components can be used to implement custom mediation primitives. This topic will be covered in more detail later in this presentation.
The Mediation Flow editor is used to implement the mediation components. This process flows from the service requestor through the Enterprise Service Bus to the provider. There are three sections to the editor. The Operation Mediation section is the top. It defines the mapping between the source input operation and one or more target out operation. Visually wiring the input operation to the target operation creates the map. The Mediation Flow middle section, which is the part that creates the message processing flow, is created once the target and source operation have been connected. Here, mediator primitives are wired and added to create the message flow from input and output operations. To view or modify the properties and primitives of the connection, the mediator properties section is located at the bottom of the editor. It is highlighted in the mediation flow section.
Mediation flow component design methodologies.
There are two types of design methodologies
Design from the top
Developer creates a Mediation Flow component. This will include the necessary interfaces and references. Developer creates an implement (empty), for the Flow part. This will open Mediation Flow editor. Developers can create mappings using the Mediation Flow Editor.
The actual implementation of the flow element is done by the user. To assemble the module, you will use the mediation flow component. This method can be used to modify existing designs and merge the flow component.
WebSphere ESB offers several built-in mediator primitives. You can also add your custom mediation to cases not covered by the default mediation primitives. These built-in mediation primitives can be used.
1. The Message Logger is used to store/log message information in a database.
2. Message filter to filter messages and forward them to output terminals. It is based on a simple condition expression.
3. To insert information from a database into the message, use database lookup. The key id and location of the key are provided to the mediation primitive. The message will contain the value of the column that matches the key.
4.XSL Transformation mediation primitive can be used to transform messages with XSL transformation. This is used when the target provider uses a different interface to the incoming messages interface. The mapping feature within XSLT allows one to map input values to appropriate output fields.