Transcript Slide 1

ChainBuilder ESB
Level 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, 19942000
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.
Why Use an Enterprise Service Bus?
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
Client Application
Enterprise Service Bus
Service Provider
(Java/EJB)
Service Provider
(CICS/Mainframe)
Service Provider
(Java/EJB)
Service Provider
(CICS/Mainframe)
ESB Capabilities
Service Mapping
The ability to translate a business service into the corresponding
service implementation and provide binding and location
information


Service
Mapping
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
ESB Capabilities
Routing
The ability to send a request to a particular service provider
based on deterministic or variable routing criteria

Types of routing to consider




Static or Deterministic Routing
Content-based Routing
Policy-based Routing
Complex Rules-based Routing
Routing
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

Some Examples Include:



XML  XML
XML  COBOL Copybook
Object  XML
Message
Transformation
ESB Capabilities
Message Enhancement
The ability to add or modify the information contained in the
message as required 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
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)



Protocol
Transformation
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
Java Business Integration (JBI)
JSR-208 JBI Specification and the
Impact on an ESB

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)

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
BC
BC
BC
BC
WSDL
WSDL
JMX Admin
Tools
Installation
Normalized Message Router
Deployment
WSDL
Control
WSDL
Monitoring
SE
SE
SE
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 runtime 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 013-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.
Message Exchanges (MEs)


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
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 runtime 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