Title: Java Business Integration JSR 208
1Java Business IntegrationJSR 208
- Chin-Yi Tsai
- cyt_at_pmlab.iecs.fcu.edu.tw
- http//140.134.26.25/cyt
2Integration Difficulties
3Integration Solution
Services (WS-I)
(interoperability)
Components (pluggable) (interoperability)
4Specification(?Java EE 5????)Java Business
IntegrationJSR 208
JBI-Compliant Component1
JBI-Compliant Component2
5ESB, SOA, JBI
- ESB
- Architecture technique to integrate incompatible
business applications over a common messaging
bus. - Unlock and extend your existing systems and
technology investments on a modern Service
Oriented and Event Driven Architecture - SOA
- An architectural principle for structuring
systems that SOA emphasizes the de-coupling of
system components - ESB SOA
- ESB is one architecture style that abides by the
rules of a Service Orientated Architecture. - JBI
- Defines common interfaces (SPI) for components
and message exchanges and service deployment.
6What Does a Service Do
- Transform data
- Route messages
- Query databases
- Orchestrate conversations
- Apply business logic
- Apply business policy
- Handle business exceptions
- Solicit approvals
How Is a Service Implemented?
- XSLT
- Enterprise JavaBeans. (EJB.) technology
- BPEL
- SQL
- XQuery
- Routing Table
- Business Rules
- EDI Transform
7Outline
- Overview of JBI
- integration
- JBI Architecture
- SE
- BC
- NMR
- JMX (Management)
- Conclusion (Keywords)
- Reference
- Appendix
8Overview of JBI
- Standard meta-container for services
- Standard SPI for plug-in
- Service Engines provide and aggregate services
- Binding Components provide protocols and
transports - Loose coupling via WSDL message exchanges
- JBI defines an environment for plug-in components
that interact using a services model based
directly on WSDL 2.0
??????? (plug-in) ????????
9Component as Container
- JBI directly supports the deployment of artifacts
to plug-in components, using an archive (ZIP
file) package called a service unit.
10Component as Container (Contd)
- Groups of service units are often developed or
collected together, to form parts of a larger
application or new service that are tested and
deployed together. - A group of JBI service units, along with a
description of their relationships and target
components, is called a service assembly.
11Overview of JBI
- Java Business Integration (JBI) is a
specification developed under the Java Community
Process (JCP) for an approach to implementing a
service-oriented architecture (SOA). - Creating a standards-based architecture for
integration solutions - A suitable standard technology instead of
proprietary vendor solution - JBI defines an architecture that allows the
construction of integration systems from plug-in
components, that interoperate through the method
of mediated message exchange.
12Overview of JBI (Contd)
- JBI plug-in components are responsible for
providing and consuming services.
13JBI Architecture
- JBI provides an environment in which plug-in
components reside. - The environment provides a set of services to
facilitate execution of provided services,
interaction between components, as well as
management of the overall system created by a JBI
installation and all installed components. - JBI provides for interoperation between plug-in
components by means of message-based service
invocation, described using a standard service
description language. - JBI provides a set of services to facilitate
management of the JBI environment, including the
installed components. This includes component
installation and life cycle management services.
Plug-in component Message exchange Management
14High-level View of JBI Architecture
Single JVM
Other JVM
SE BC NMR JMX (Management)
15Component Framework
- JBI components (service engines and binding
components) provide interfaces for the use of
JBI, and use interfaces provided by JBI. - The JBI framework provides the following for the
use of components - Component installation context
- Component context
- Class loading
- Error indication
16Standardized Integration
- SPI (Service Provider Interface) not API
- Allow for proprietary black boxes as
integration services
17Service Engine
- Hosts business logic implementing services
- Exposes service endpoints
- Is a target for deployment a container
18Binding Component
- Handles protocol-specific message re-formatting
- Should contain no business logic
- ????????
19Normalized Message Router
- The normalized message router, or NMR, receives
message exchanges from JBI components (engines or
bindings), and routes them to the appropriate
component for processing. - decoupling
- The JBI environment's primary function is to
route normalized message exchanges from one
component to another. - Messages are delivered in a normalized form.
NMR
normalize
normalize
component
component
De-normalize
De-normalize
20Normalized Message Router (Contd)
21Message Exchange
- A Message Exchange (ME) serves as a container
for the normalized messages that are part of a
service invocation. - JBI supports a fixed set of message exchange
patterns - a well-defined sequence of message exchanges
between the consumer and the provider. - A message exchange pattern (or MEP) no matter
what contents (or type) of the messages
themselves. By supporting a limited set of MEPs,
the JBI standard ensures that components have a
simple, well known interaction model to
implement, ensuring interoperability.
22JBI Messaging Architecture
23Normalized Message Exchange (1)
- External Service Consumer Message Processing
24Normalized Message Exchange (2)
- External Service Provider Message Processing
25Example
- One-way Message Adapter
- A message is sent to the JBI environment,
transformed, then sent to a destination outside
of the environment.
26Service Invocation to MEP Mapping
27Message Exchange Patterns (MEPs)
- An MEP defines the sequence, direction, and
cardinality of all messages that occur in the
course of invoking and performing the operation. - All message exchanges between consumer and
provider are mediated by the NMR. - The components interact with the NMR, using their
individual DeliveryChannels - Sending MessageExchange instance
- Accepting MessageExchange instance
- MEPs
- In-only Message Exchange Pattern
- Robust In-Only Message Exchange Pattern
- In-Out Message Exchange Pattern
- In-Optional-Out Message Exchange Pattern
28In-only Message Exchange Pattern
- Describing a one-way messaging pattern
29Robust In-Only Message Exchange Pattern (fault
scenario)
- Allowing the provider to easily return error
responses to in-only message exchange
30In-Out Message Exchange Pattern
31In-Out Message Exchange Pattern (Contd)
32In-Optional-Out Message Exchange Pattern
33In-Optional-Out Message Exchange Pattern (Contd)
34In-Optional-Out Message Exchange Pattern (Contd)
35In-Optional-Out Message Exchange Pattern (Contd)
36One-way Service Invocation Between two Service
Engines
37SE Invokes Service Provided by Remote JBI
Instance Robust In with Fault
38SE Invokes Remote Service
39Management (JMX)
- The JBI environment, including bindings and
engines, is administered through JMX. (MBean) - Installation of engines and bindings (components)
- Life cycle management of components (start/stop
controls) - Deployment of component artifacts to engines and
bindings that support dynamic additions to their
internal execution environments. - Monitoring and control.
40Conclusion (Keywords)
- JSR 208 (SOA infrastructure/enabler)
- Meta-container (JBI Environment / JBI Container)
- Plug-in
- WSDL 2.0
- JMX (Management)
- Messaging (NMR)
- SE BC
- ESB enabler
- Assembling JBI-compliant component
- Installation (AP server, EJB Container, BPEL
engine) - Installing it into the JBI environment thanks to
JMX based administrative tools - Deployment (BPEL process definition)
- JBI component can be seen as a container (ex
BPEL engine) - Services (ex BPEL) must be deployed into the
component thanks to JBI administrative tools - Activation
- After deployment, services are accessible through
the JBI environment as Endpoints
41Reference
42Reference
- Sun SOA Home
- http//www.sun.com/products/soa/index.jsp
- The Java EE 5 Tutorial
- http//java.sun.com/javaee/5/docs/tutorial/doc/
- Java EE At a Glance
- http//java.sun.com/javaee/
- Project Open ESB
- https//open-esb.dev.java.net/
- LogicBlaze FUSE Open source SOA platform
- http//www.logicblaze.com/index.jsp
- ServiceMix Home
- http//servicemix.org/site/home.html
- ActiveMQ Home
- http//www.activemq.org/site/home.html
- PETALS Services Platform
- http//petals.objectweb.org/
- Mule Home
- http//mule.codehaus.org/
- Celtix
- http//celtix.objectweb.org/
- JBoss JEMS - The Open Source Platform for SOA
- http//www.jboss.com/products/soa
- Oracle Service-Oriented Architecture Technology
Center - http//www.oracle.com/technology/tech/webservices/
index.html
43Reference (Contd)
- Sun SOA Home
- http//www.sun.com/products/soa/index.jsp
- JCP (Java Community Process)
- http//jcp.org/en/home/index
- JSR 208 (JBI)
- http//jcp.org/en/jsr/detail?id208
44Appendix
45ESB
ServiceMix Apache Synapsele Mule Celtix Suns
Java Open Enterprise Service Bus
46ServiceMiX
- Open Source JBI Container based on JBI
Specification (JSR208) - Supports Transaction Management through Jencks
andJava Transaction API (JTA) - Supports Java Message Service (JMS) through
ActiveMQ - Can extend any J2EE compliant Server with JBI by
simply deploying Servicemix (e.g. Geronimo)
47ServiceMix
48(ServiceMix) Standard Component-Binding Component
- HTTP
- FTP
- File
- RSS
- Email
- SOAP
- WSIF (Web Service Invocation Framework)
- SAAJ (Soap With Attachments and Apache Axis)
- JAX WS (Java API for XML Web Services)
- XSQL (XML Query Language)
- JMS (Java Message Service)
49(ServiceMix) Standard Component-Service Engine
- BPE (Container for BPEL)
- EIP (Enterprise Integration Patterns)
- Groovy (Container for Scripting)
- JCA (Java Connector Architecture)
- JSR181 (Container for annotated POJOs)
- Quartz (Timer)
- XPath (Message Transformation with XPath)
- XSLT (Message Transformation with XSLT)
50ServiceMix
51(ServiceMix) Straight-throw flow
52(ServiceMix) Seda Flow
53(ServiceMix) JMS Flow
54Basic Example Message Flow Diagram
55Basic Example Message Flow Diagram
- Messages flow through the components as follows
- The timer component sends a message to
inputSender through the Normalized Message Router
(NMR). - inputSender converts the message (marshals it)
into a JMS message, then uses the jmsTemplate
bean to publish the message. - jmsTemplate uses the jmsFactorybean to get a
connection to the port associated with the JMS
topic called "demo.org.servicemix.source." The
message is published on the "demo.org.servicemix.s
ource" topic. - jencks (the JCA resource adapter) listens on port
61616 for messages. - inputReceiver subscribes to the
"demo.org.servicemix.source" topic via jencks and
receives the JMS message. - inputReceiver normalizes the JMS message and
sends it to outputSender via the NMR. - outputSender marshals the normalized message to a
JMS message and uses jmsTemplate to publish the
message on the "demo.org.servicemix.result"
topic. - jmsTemplate publishes it on the
"demo.org.servicemix.result" topic using
jmsFactory to get a connection to the result
topic. - jencks listens on port 61616 for messages.
- jmsTrace subscribes to the "demo.org.servicemix.re
sult" topic and receives the JMS message via
jencks. - jmsTrace converts the JMS message into a
normalized message and sends it to trace via the
NMR. - trace transforms the normalized message into a
string and logs it to the console.
56Basic Example Message Flow Diagram
- Using the distributoraposs web interface, a
department store customer submits an order for
multiple products. An HTTP request is sent to the
OrderReceiver, an HTTP binding component (BC). 3 - The OrderReceiver sends the message to an
OrderRouter service engine (SE) 4 component. This
SE is responsible for parsing the order and
deciding, based on the message content, which
OrderTransformer should receive which part of the
message (i.e., an order for a product). - The OrderRouter publishes the orders to the
appropriate message topics based on the message
content. Specifically, the OrderRouter publishes
the messages based on which wholesaler sells the
item. - The OrderTransformer is a service engine
component, which modifies the message and puts it
in a format which is readable by the wholesaler
interface that will fulfill the order. - Each OrderTransformer sends the modified message
to the OrderProcessor. - The OrderProcessor is a binding component that
has two functionsa. It places an order to the
appropriate wholesaler through the
wholesaleraposs Webservice or proprietary
interface. b. It also publishes a message about
the order on a topic. - The message on the topic is subsequently picked
up by the BusinessMonitor component via the
jmsTrace component. - The BusinessMonitor component monitors the orders
for quality assurance and business analytics,
such as data mining.
57Basic Example Message Flow Diagram
58BPEL Logical Flow Diagram
59File Binding Logical Flow Diagram
60HTTP Binding Example Message Flow Diagram
61JMS Binding Example Message Flow Diagram
62Quartz Example Message Flow Diagram
63RSS Binding Example Message Flow Diagram
64Department Store Distributor Order Processing
System
65(No Transcript)
66Online Ticket Reservation System
67Online Application for Tax ID No. System
68Department of Public Works Project Monitoring
System
69Network Status Indicator
70News Feed Monitoring System
71(No Transcript)
72Mule
73Reliable One-way MEP with Fault Message Sequence
Chart
74Reliable Two-way Exchange Message Sequence Chart
75One-way Transactional Message Exchange
76A simple integration problem using JBI
77JBI Components for Adapter Application
78- SU
- SE-Tx Transformation Service
- BC-Y Provider Service Proxy
- SE-Seq Adapter Logic
- BC-X Client Service Proxy
79Graphic View of Adapter Service Assembly
80Adapter Pattern Message Sequence Diagram
81JBI Component Installation Time
82(No Transcript)
83JBI Component Execution Time
84Component Interaction -- Service Consumer
- Find a service endpoint
- Create a message exchange
- Send the message
85Component Interaction -- Service Provider
- Activate an endpoint
- Receive a message
- Send the response
- Close the exchange
86(No Transcript)
87SOA Architecture Principles
- Well-defined service interfaces
- Loose coupling
- Document-based, mostly asynchronous,
conversational interactions - Service registration and discovery
88To Form Ideal SOA Infrastructure
- Combine the best of previous technologies
89JBI Architecture
90Bring it Together
91Assembling Services into Processes
92Events-Driven Application Models
- Asynchronous One-way Communication
- Simple Events
- Brokered Events
- Enterprise Service Busses
- Event Stream Processing Engines
93Simple Events
- Simple Events
- Simulating Request/Reply
94Brokered Event
- Brokered Event
- Point to point (Send to One Interested Party )
95- Enterprise Service Bus - Orchestration Service
- Event Stream Processing (ESP)
96SOA and Events
Event Sink
Event Source
Service Consumer
Service Provider
Notification
Event Sink
Event Source
Service Consumer
One-way
97ESB enables SOA and EDA
- SOA Service Oriented Architecture
- Distributed, Web Services
- WSDL, SOAP, XML, XSD
- Registry Lookup, UDDI
- Request / Reply
- EDA Event Driven Enterprise
- Message Oriented
- Qualities of Service
- Asynchronous Publish / Subscribe
98JBI Messaging
- JBI defines a model and the APIs for messaging
between JBI components - All types of interaction
- One-Way
- Reliable One-Way
- Request Response
- Request Optional-Response
- Messaging API
- Components send messages to the JBI container
- Components read messages from the JBI container
- JBI vs JMS
99JBI Addressing
- An interface is a group of operations
- A service implements an interface represented by
qualified name and its WSDL definition - A service has one or more endpoints accessible by
different bindings - Endpoints can be
- external for services accessible via a binding
component - internal for services provided by a service engine
100JBI Component Packaging (installation)
- Write an XML descriptor for the component
- the deployment descriptor
- Package the descriptor with component logic in a
JAR archive - Install the component in JBI environment
- Component deployment descriptor
101Deployment
- Provide services to JBI environment through the
JBI component - Service (component artifact) is described by XML
descriptor and packaged as Service Unit (SU) - Services that have to be deployed into different
components to produce a new application can be
grouped into a Service Assembly (SA). - The SA contains an XML descriptor to describe how
each SU is deployed on its target component - Service assembly deployment descriptor
102Components and Artifacts Lifecycle
- Components and artifacts are managed with the
same unified lifecycle - Lifecycle management is accessible by admin tools
via standard JMX MBean defined by the
specification
103Applying JBI With ESB
- Open ESB
- Sun's Open Source Enterprise Service Bus
- A standard, distributed integration
infrastructure - Highly distributed scalable JBI services
- Uses JBI Reference Implementation code
- Based on MOMasync XML message exchanges
- Centralized management
- Standard deployment of composite services
- QOS characteristics
- Open ESB Architecture
104Integration Solution Proxy Service
105Integration Solution Proxy Service
- Composite App Service Assembly
- A collection of service unit
- Proxy service deployment
106Composite Application Using JBI
107(No Transcript)
108BPEL
109JBI
- Service based
- Plug-in components serve roles
- Service provider, consumer, both
- Providers supply self-description
- Messages
- Operations and message exchange patterns
- Services
- Endpoints
- All using WSDL
- Service Engines
- Provide local services
- Business Processes (orchestration BPEL4WS)
- Transformation (XSLT, EDI)
- Business Logic (EJBs)
- Integrated Java technology-based apps
- Consume services
- Binding Components
- Proxy for remote service providers
- Protocol SOAP, AS2, ebXML MSH, XML-over-HTTP,
EDI, etc. - Access for remote service consumers
- Protocol access to
- SE-provided services
- BC-proxied services
- Contain no business logic
- Convention break at your peril
- No Restrictions
110Normalized Message Router
- Key to interoperation between components
- Mediated Message Exchange
- Normalized Message
- Abstract Message (payload) Message Properties
(metadata) - WSDL Abstract Message
- WSDL interface operation message definition
- Properties (metadata)
- Protocol-supplied context information
- Security tokens
- Transaction information
- Data other components may recognize
- Message Exchange Pattern
- Support for simple communications primitives
- Message exchange patterns are defined from the
providers perspective
111Inside Message Exchange Handling
112JBI
- JBI is a messaging-based plug-in architecture
- JBI does not define the pluggable component
themselves, but - Defines the framework, container interface,
behavior, and common services - JBI allows anyone to create JBI compliant
integration plug-in component and integrate them
dynamically into the JBI infrastructure - Key pieces of the JBI environment
- SE
- BC
- NMR
- JBI runtime environment (JBI meta container)
113JBI
- JBI is an architecture for integration systems
specifying plug-in components that interoperate
by exchanging messages, rather than by
interacting directly. This decoupling increases
flexibility because each component needs to know
how to interact with the JBI bus only and not
with n number of other components. JBI components
provide services, consume services, or sometimes
both. There are two types of components Service
Engines (SE) and Binding Components (BC). The SEs
provide business logic and transformation
services. The BCs provide connectivity for
applications that are external to the JBI. The
separation of business and processing logic from
communication logic makes the implementation of
components much less complex. - The mediated message exchange between components
is provided by the Normalized Message Router
(NMR). The NMR routes normalized messages between
service providers and consumers. A normalized
message consists of two parts the message
content (payload) and the message metadata. The
message metadata contains information such as
security information, that can affect the
processing of the message as it routes through
the JBI. Messages flowing into the JBI, via
binding components, are translated into a
normalized (neutral) format, then routed to their
destination. Prior to final delivery the
normalized message is translated into the
appropriate format for the recipient. A message
can be routed through several JBI components
depending on what processing is needed. - The JBI environment also supplies a set of
services for self management, including services
for component installation and life cycle
management of components. - In summary, the JBI specification creates a
standards-based technology for enterprise
application integration.
114JBI
- LogicBlaze has implemented the ServiceMix ESB
based on the JBI (JSR 208) specification in order
to create a standards based ESB and the
ServiceMix ESB combines the functionality of both
a Service Oriented Architecture (S0A) and Event
Driven Architecture (EDA) to achieve an agile,
enterprise ESB. - ServiceMix supports event driven architecture for
events occurring both internal and external to
the bus. In other words, JMS binding components
can listen for the arrival of messages, i.e., the
"event" on topics or queues which are external to
the bus, while other components can listen for
messages on the normalized message bus. - JSR 208 describes a set of Java APIs to interact
with an implementation of a Java-based Enterprise
Service Bus (ESB). This ESB must provide for the
integration of disparate service components,
enabling them to communicate with their consumers
or clients through a myriad of communications
modules. - It is specified as a set of Java based APIs and
component packaging conventions that all JBI
compliant ESB implementations must follow. The
JBI 1.0 APIs attempt to ensure that Java
components developed can be deployed and executed
across different vendors ESB implementations. - All plug-in components on the ESB, regardless of
type (SE or BC), and regardless of role (consumer
or provider), all communicate in the same way. - All components on the ESB communicate with one
another by passing messages.
115- The ESB will only work with normalized messages,
i.e. ones with protocol specificity removed. This
means that you cannot tell, from examining the
message, the connection or protocol over which it
was sent. - A component must normalize any message before
sending it to the ESB. Similarly, if a BC needs
to send a message to an external system (outside
of the ESB), the message must be denormalized
before further routing or use. Denormalization
puts back communications protocol-dependent
frames, headers, and other information. This is
the reason why an ESB is often also called a NMR
or Normalized Message Router.
116- Services that need to be accessed by the ESB are
accessed as endpoints. - Endpoint is how a service is addressed by the
ESB. - Service is the actual business entity the
performs the desired function - Service units provide information about the
services and their endpoints to the component - Service assembly is how several service units are
packaged and deployed on to target components - Integrating old and new components and services
using a service-oriented architecture requires an
infrastructure that can connect any component or
service, regardless of location, messaging
protocol, and message format. To orchestrate
existing services and components to meet the
needs of today's dynamic business climate, this
infrastructure must be highly customizable. The
enterprise service bus (ESB) infrastructure
fulfills these requirements.
117- Enterprise service bus (ESB) is a centralized,
logical, architectural component that operates in
a distributed, heterogeneous environment to
facilitate the requirements of a highly scalable,
fault-tolerant, service-messaging framework. - JBI embodies a messaging model based on Web
Services Description Language (WSDL) for easy
mapping to Web services, HTTP, email, and JMS.
JBI integrates with legacy systems, binary
transports, document-oriented transports, and RPC
(remote procedure call) systems. - Message normalization is the process of mapping
context-specific data to a context-neutral
abstraction to transport data in a standard
format. All messages handled by the NMR are
normalized. - An NMR is not embodied by any concrete object. It
is abstracted as a set of APIs, SPIs (service
provider interfaces), and components. The NMR
APIs include - JBI Message API
- JBI Service API
- JBI Message Exchange Factory API
- Service Description SPI
- Message Exchange Patterns API
- Endpoint Reference API
118- JBI supports two kinds of components, service
engines and binding components. Components
interact with JBI in two ways - SPIs Interfaces implemented by a binding or
engine - APIs Interfaces exposed to bindings or engines
by the framework - An external service consumer sends a service
request across a specific protocol and transport
to a binding component. The binding component
converts the request to a normalized message. The
binding component then creates a message packet
called a message exchange (ME) and sends it
across the binding component's delivery channel
to the NMR for delivery to a service provider.