1. ChainBuilder ESB Level 1 Training Introduction to ChainBuilder ESB

2. Schedule Day 1: Understanding the Product and its Features  Concepts and Terminology  Overview of Product and Features  Demonstration Day 2: The Basics of Configuration  Installation  Message Formats  Translation Mappings  Component Flow Editor Day 3: Putting it all Together  Lab Examples  Running the Service Assembly

3. Day 1 Schedule Bostech Overview Concepts and Terminology  JBI  ESB Overview of Product and Features Demonstration

4. Bostech: Who We Are Bostech consists of a team of pioneers in the business integration software market place. The team has been responsible for the following integration products:  HubLink Integrator Healthcare Interface Engine, 1994- 2000  OM3 Message Broker, 1998-2000  Cloverleaf EAI, 1999-2006  ChainBuilder EAI, 2004-present  Linc for Amazon.com, 2004-present  ChainBuilder ESB, 2006-present Based in Columbus, Ohio with additional R&D resources in Beijing, China. The Columbus technical team averages over 9 years of integration product experience.

5. ChainBuilder ESB ChainBuilder ESB is an Enterprise Service Bus (ESB) that allows developers to implement a Service Oriented Architecture (SOA). SOA is the hottest philosophy in information technology today.  It’s a concept of “loosely coupling” services and applications between producers and consumers.  Independent services can be accessed without knowledge of their underlying platform implementation. ESBs are generally considered to be the least complex-lowest cost approach to implementing a Service-Oriented Architecture (SOA).  A “Bus” approach where: Base functions are broken up into their constituent parts (modular programming), Distributed deployment where needed (distributed computing), Constituent parts work together as necessary (Modular programming).  Web Services model with XML messaging.  Event-driven, standards-based.

6. In the move towards “Service Oriented Architecture” (SOA), client applications are decoupled from services. The “Enterprise Service Bus” (ESB) provides the communication bridge… Client Application Service Provider (Java/EJB) Service Provider (CICS/Mainframe) Client Application Service Provider (Java/EJB) Service Provider (CICS/Mainframe) Enterprise Service Bus Why Use an Enterprise Service Bus?

7.  Could be implemented through XML, a database, or embedded within the Mediator ESB component  Usually contains the following core information Implementation Service Name Service Protocol and binding information Protocol-specific info (i.e. timeouts, failover location) Service-specific routing information Service Mapping ESB Capabilities Service Mapping The ability to translate a business service into the corresponding service implementation and provide binding and location information

8.  Types of routing to consider Static or Deterministic Routing Content-based Routing Policy-based Routing Complex Rules-based Routing Routing ESB Capabilities Routing The ability to send a request to a particular service provider based on deterministic or variable routing criteria

9.  Some Examples Include: XML  XML XML  COBOL Copybook Object  XML Message Transformation ESB Capabilities Message Transformation The ability to convert the structure and format of the incoming business service request to the structure and format expected by the service provider

10.  Types of Message Enhancement Date format conversion Supplement data not included in original message Data conversion (i.e. spaces to zero) Rules-based Enhancement Message Enhancement ESB Capabilities Message Enhancement The ability to add or modify the information contained in the message as required by the service provider

11.  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  Examples SOAP/JMS  IIOP XML/HTTP  CICS/MQ XML/HTTP  RMI/IIOP SOAP/MQ  ATMI XML/HTTP  OTMA Protocol Transformation ESB Capabilities Protocol Transformation 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)

12. Java Business Integration (JBI) Specification  The goal of JBI is to create a standards-based architecture for integrating middleware components to perform ESB capabilities  The JBI specification is not concerned about how external consumers or service providers interact, but rather how internal consumers and providers interact  JBI defines two types of components Service Engines (SEs) Binding Components (BCs) Java Business Integration (JBI) JSR-208 JBI Specification and the Impact on an ESB

13. JBI Advantages and the effect on Commercial ESBs  Third-party or Custom Service Engines (SE) and Binding Components (BC) can be swapped in and out without impacting applications or services  Avoids “Vendor Lock-in”  Allows for “Best of Breed” technologies and solutions  We can mix Open Source and Commercial solutions  We can swap in and out integration services (i.e. capabilities) we don’t need, creating a lighter-weight solution that meets our specific needs JBI 2.0 under development with Java Community Process Expert Group Java Business Integration (JBI)

14. JBI Specification Architecture Normalized Message Router BC SE BC Installation Deployment Control Monitoring JMX Admin Tools WSDL Java Business Integration (JBI)

15. JBI Runtime Environment Two types of plug-in components: 1. Service Engine (SE) business logic or transformation service, e.g, Transform or XSLT 2. Binding Component (BC) communication logic for external connectivity, e.g, Web Services, File, JMS Components only interact with Normalized Message Router (NMR)

16. ChainBuilder ESB An open standards-based Java Business Integration (JBI)-compliant Enterprise Service Bus  Modular components approach more easily embedded into a software vendor product suite.  Architecture allows vendors to rapidly upgrade and augment their product offering to their customers. Focused on ease of use  Graphical configuration through “wizard” editors  Abstracts the complexities of the open standard specifications Emphasis on rapid deployment  Pre-built service and binding components  Architecture allows users to leverage components from other vendors or that are home grown Leverage mature enterprise applications  Proprietary message model support (fixed, delimited, etc.)  Non-web services communications adapters Vertical market standards support orientation Web interface console allows remote monitoring, administration and run- time control

17. Concepts and Terminology - SOA Service Oriented Architecture (SOA) - SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between one or more services.[1][1] Pros:  Promotes reuse of functionality at a global level. Since a service is exposed in a platform independent way, it can be reused by many more applications than a language specific class, method, etc.  Simplifies interconnection to and usage of existing IT assets. Cons:  SOA solutions generally add overhead to a solution, which make an application slower than a solution written from the ground up in a single language. [1] Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0- 13-185858-0 [1]

18. Concepts and Terminology - ESB Enterprise Service Bus (ESB) - There is no standard definition of ESB. It can be used to describe an architectural style (basically a synonym for SOA), but the term usually refers to a software infrastructure that enables the architectural style. An ESB can be thought of as the framework used to build an SOA solution.

19. Concepts and Terminology - JBI Java Business Integration (JBI) - A standard developed under the Java Community Process (JSR 208) for implementing a Service Oriented Architecture.  Borrows many concepts from Web Services model.  Defines a container that hosts pluggable components that consume and/or provide services

20. Concepts and Terminology – JBI Terms JBI Container - A JBI implementation that is the host for the components and services that will be installed and deployed. Example JBI containers are Apache Servicemix, OpenESB and ObjectWeb Petals. Binding Component (BC) - A component that provides connectivity to services external to the JBI environment. These usually provide a communication protocol and marshalling logic to convert between an external interface and the Normalized Message Router.

21. Concepts and Terminology – Service Engine Service Engine (SE) - A component that provides and possibly consumes services from other JBI components. These are usually the components that provide business logic or transformation services. These are not accessible to external systems.

22. Concepts and Terminology – Message Exchange Message Exchange (ME) and Message Exchange Pattern (MEP) - A Message Exchange serves as a container for the Normalized Messages that are part of a service invocation. In addition to the messages, the ME contains metadata and state information. The ME is what is actually transferred on the NMR, between components. Like a web service operation, a message exchange may contain an input message, an output message and possibly fault messages. There are four different Message Exchange Patterns used in JBI. The type of MEP determines which messages may exist in the Message Exchange as well as how the Message Exchange is sent on the NMR.

23. Message Exchange Patterns (MEPs) Message Exchange Patterns are based on the WSDL 2.0 model MEPs are between the Consumer and Provider. The Message Exchange Patterns defined in the WSDL can be:  In-Only – One way  Robust In-Only – Reliable one way  In-Out – request response  In Optional-Out – request optional response Consumer  In Only -> Provider

24. Concepts and Terminology – Message Exchange  In-Only - A one-way service invocation. Message Exchange will only contain an "in" message. The consumer will not receive notification if an error occurs.  Robust In-Only - A reliable one-way service invocation. Message Exchange will only contain an "in" message, but may return a "fault" message if an error occurs.  In-Out - A request - response service invocation. Message Exchange will contain an "in" message and an "out" message. If an error occurs, the ME may contain a "fault" message instead of an "out" message.  In Optional-Out - A request - optional response service invocation. Message Exchange will contain an "in" message and optionally an "out" message. If an error occurs, the ME may contain a "fault" message.

25. The communication unit between component and NMR Components exchange messages over the NMR; one is the consumer, the other is the provider of the service  Consumer: responsible for creating a ME and routing it to NMR  Provider: responsible for receiving the ME  Component can have both consumer and provider roles The Message Exchange serves as a “ carrier ” for the normalized messages. It holds:  in  out  fault  state information  metadata Message Exchanges (MEs)

26. Concepts and Terminology – Normalized Message Normalized Message - The messages that are contained in a message exchange. The Normalized Message has the following properties:  Content - The main payload of the message. This MUST be XML data.  Properties - Metadata, can be used by components or the user to set key-value data along with the message.  Attachments - A normalized message may contain multiple attachments which may contain any type of data. This is best used for transferring non-XML data.

27. Normalized Messages (NMs) Normalized Message consists of  Message Content: an XML payload (java.lang.Source)  Message Context: meta-data in the form of message properties (Meta-data can be JBI and component defined, like a file name for a file component.)  Attachments: added to the normalized message using the Java Activation Framework to support non-xml content Message Exchange can contain one or more Normalized Messages.

28. Normalized Message Router (NMR) NMR provides mediated message exchange to allow components to interoperate Loosely-coupled message exchange between components Abstract WSDL-based service description is the only coupling between the consumer and provider

29. Concepts and Terminology - Endpoint  Endpoint - A distinct address where a service is provided. Generically, this can refer to any service endpoint, like a web service endpoint is usually addressed by a distinct URL. Another service endpoint could be a specific JMS queue, or a specific folder on the file system where requests will be read. Within the JBI container, endpoints refer to a specific a service within a component.

30. Concepts and Terminology – Service Unit Service Unit - An object that is deployed into a JBI component that contains all of the necessary artifacts (configuration files, translations, message definitions, etc) to create a service. Each type of component defines what its Service Unit Archive (zip file) must contain. For example, a transformation component Service Unit will contain a map file and additional service description information.

31. Concepts and Terminology – Service Assembly  Service Assembly - A collection of Service Units that are deployed into a JBI container. This is literally a zip file containing a collection of Service Unit zip files. It also contains a JBI descriptor that contains additional information about the relationships between the included Service Units.

32. ChainBuilder ESB Product Schematic Open standards-based Enterprise Service Bus 100% JAVA (improved platform portability) and compliant with the Java Business Integration (JBI) open standard JBI container agnostic Support available for Windows and Linux An optional ChainBuilder Common Service Layer extends error handling and user code entry points that are not defined in JBI standard.

33. ChainBuilder ESB Product Schematic Pre-built binding components for protocol support Emphasis on rapid deployment Mix new SOA and mature applications with WebServices and non-WebServices’ communications adaptors Technology is designed to be embeddable Architecture allows users to leverage components from other vendors or that are home grown

34. ChainBuilder ESB Product Schematic Pre-built Service Engines Emphasis on rapid deployment Content-based router and sequencer allows developers to intelligently connect components Service Engines for mapping, transformation, JDBC database support, and incorporating user scripts Technology is designed to be embeddable Architecture allows users to leverage components from other vendors or that are home grown

35. ChainBuilder ESB Product Schematic Pre-built Eclipse plug-ins Ease of use graphical configuration through wizards Abstracts the complexities of open standards specification Emphasis on rapid deployment Mix new SOA and mature applications with XML and proprietary message formats, like fixed, delimited, etc. Vertical market standard support, like X12 and HL7

36. ChainBuilder ESB Product Schematic Web interface console allows ESB management, administration and run- time control AJAX-based web interface Remote management Manage any ChainBuilder ESB or third-party JBI component in the ESB

37. Roadmap ETL Reliable Message Delivery through JMS Improved Administration Console Multiple Environment Macro Support WS-Security SAML

38. Example SA Read in an HL7 record from a file and sent it over tcp/ip  This simulates a hospital HIS system sending tcp/ip transactions Route all to file Route A01 transactions  Map to XML  Send via web services to patient billing system Receive xml over web services and write to file  Simulates the remote system which is receiving patient data

39. Day 1 Review Bostech Overview Concepts and Terminology  JBI  ESB Overview of Product and Features Demonstration