JSR-208 JBI (Java Business Integration) Specification and the Impact on an ESB
Open Source ESB Projects</li></li></ul><li>Who am I?<br /><ul><li>My name is Shan Kandaswamy Technical Architect / Manager</li></ul>Little background on my work<br /><ul><li>Worked mostly for Automotive IT clients - projects managing, architecting and developing
Let me move on to actual presentation</li></li></ul><li>Thanks to…<br /><ul><li>I am not going to lie I did not invent or patternise ESB or SOA
I did not create the entire presentation content all by myself.
Like java re-usability, I gathered information around the www
Presentation is an extract from my fav architect Mark Richard, an IBM Consultant /Architect.</li></ul> So thanks to all the resources available on the internet <br />… and thanks to Google my favorite search engine.<br />
What is an ESB?<br /><ul><li>There is no industry agreed upon definition of what an ESB is
From Wiki </li></ul>“An enterprise service bus (ESB) consists of a software architecture construct which provides fundamental services for complex architectures via an event-driven and standards-based messaging-engine (the bus)”<br />
How does Gartner define an ESB?<br />“An Enterprise Service Bus (ESB) is a new architecture that exploits Web Services, messaging, middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow”<br />Bottom line<br /><ul><li>There is no single consise deinition of an ESB
We will try to understand what an ESB is by understanding its role and capabilities.</li></li></ul><li>ESB Architecture Context<br /><ul><li>In the move towards SOA, client applications are decoupled from services. The ESB provides the communication bridge</li></li></ul><li>The ESB helps facilitate the following:<br /><ul><li>Service location transperancy
Ability to separate Business Services from the service implementation.
Business Service vs. Implementation Service</li></ul>Business Service Def<br />Make Payment<br />WSDL<br />Make Payment<br />Business Services are <br />exposed to client as a service name<br />and specified input and output structures.<br />(example: through WSDL)<br />Implementation Services are coded within the Service Providers (example: through Webservices)<br />Process Payment<br />Post BAR Payment<br />Post Housing Payment<br />Java<br />
Routing<br />The ability to channel a request to a particular service provider based on deterministic or variable criteria.<br /> <br />Types of routing to consider<br /><ul><li>Static or deterministic Routing
Complex Rules-based Routing</li></li></ul><li>Message Transformation<br />The ability to convert the structure and format of the incoming business service request to the structure and format expected by the service provider<br /><ul><li>Some examples includes:
Object XML</li></li></ul><li>Message Enhancement<br />The ability to add or modify the information contained in the message as required by the service provider.<br /> <br />Types of Message Enhancement<br /><ul><li>Date format conversion
Supplement data not included in original message
Rules-based enhancement</li></li></ul><li>Protocol Transformation<br />The ability to accept one type of protocol from the consumer as input (i.e. SOAP/JMS) and communicate to the service provider through a different protocol (i.e. IIOP)<br /> <br /><ul><li>A form of message transformation concerned with the message structure, not the message payload.
Has both physical connection attributes as well as logical connectivity attributes
XML/HTTP OTMA (Open Transaction Manager Access)</li></li></ul><li>Service Mapping<br />The ability to translate a business service into the corresponding service implementation and provide binding and location information<br /> <br /><ul><li>Could be implemented through XML, a database, or embedded within the Mediator ESB component
Usually contains the following core information
Protocol specific info (i.e. timeouts, failover location)
Service-specific routing information</li></li></ul><li>Message Processing<br />The ability to manage state and perform request management by accepting an input request and ensuring delivery back to the client via message synchronization<br />For updates this might require the use of XA or messaging sync points to ensure guaranteed message processing and delivery<br />
Process Choreography<br />The ability to manage complex business process that requires the coordination of multiple business service to fulfill a single business service request<br /> <br /><ul><li>Usually BPEL based
Process Choreography can be though of as a manifestation of a use case or business process</li></ul>Each of the business process nodes can be an<br />Independent business service.<br />
Service Orchestration<br />The ability to manage the coordination of multiple implementation services<br /> <br /><ul><li>Can be BPEL based but is usually implemented through inter-service communication or aggregate services
Difference between Service Orchestration and Process Choreography is based on the type of service being coordinated
Service Orchestration Implementation Services</li></li></ul><li>Transaction Management<br />The ability to provide a single unit of work for a business service request by providing a framework for the co-ordination of multiple resources across multiple disparate services<br /> <br /><ul><li>Specifically, the ESB should provide a compensatory transactional framework for a service request.
JSR-95 Activity Service for Extended Transactions</li></li></ul><li>Security<br />The ability to protect enterprise services from unauthorized access<br /><ul><li>In SOA there are no more silos; services become visible to the entire enterprise through ESB
ESB should provide authentication, authorization, and auditing
ESB should access a security manager or authentication and authorization rather than have the direct responsibility</li></li></ul><li>ESB Components<br /><ul><li>There is no one single product that can effectively do all of the capabilities required of an ESB
An ESB can be broken down into the following components
Reduced Complexity: Only those services requiring Choreography go through Choreographer</li></li></ul><li>Process Choreographer and the ESB<br />Considerations<br /><ul><li>Should process choreography sit above or below the Mediator?
Reduced Complexity: Only those services requiring Choreography go through the Choreographer</li></li></ul><li>Additional Considerations<br /><ul><li>Choreography contains business logic – does it really belong in an ESB?
Should business rules reside outside the ESB in the client? No I don’t think so…</li></li></ul><li>JBI (Java Business Integration) Advantages and the effect on Commercial ESBs<br /><ul><li> Third-party or Custom Service Engines (SE) and the Binding Components (BC) can be swapped in and out without impacting applications or services