ChainBuilder ESBLevel 1 Training

Introduction to ChainBuilder ESB

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

Day 1 Schedule

Bostech Overview Concepts and Terminology

JBI ESB

Overview of Product and Features Demonstration

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.

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.

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?

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

Types of routing to consider Static or Deterministic Routing Content-based Routing Policy-based Routing Complex Rules-based Routing

Routing

ESB Capabilities

RoutingThe ability to send a request to a particular service provider based on deterministic or variable routing criteria

Some Examples Include: XML XML XML COBOL Copybook Object XML

Message Transformation

ESB Capabilities

Message TransformationThe ability to convert the structure and format of the incoming business service request to the structure and format expected by the service provider

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 EnhancementThe ability to add or modify the information contained in the message as required by the service provider

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 TransformationThe 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)

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

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)

JBI Specification Architecture

Normalized Message Router

BC

SESESE

BC BC BC

Installation

Deployment

Control

Monitoring

JMX Admin Tools

WSDL

WSDL

WSDL

WSDL

Java Business Integration (JBI)

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)

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

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]

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

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.

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

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.

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.

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.

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

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.

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)

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.

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.

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

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.

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.

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.

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.

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

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

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

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

Roadmap

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

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

Day 1 Review

Bostech Overview Concepts and Terminology

JBI ESB

Overview of Product and Features Demonstration