JBI Component development (Part 2)

JBI Introduction

1. JSR 208: Java Business Integration (JBI)

Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group.

JBI employs concepts similar to J2EE to extend application packaging and deployment functionality to include JBI Components. JBI Components are an open-ended class of components that are based on JBI abstract business process metadata. The JBI JSR itself does not define how developers code Components. Both standard and proprietary ways of coding Components may exist. A specific class of Component may provide rich business process functionality while another class of Component may provide a specialized integration function like a data transformation table or support a domain specific business rule encoding.
A JBI Application is composed of one or more JBI Components and service assemblies.

More details at: http://jcp.org/en/jsr/detail?id=208


Component Framework

Java CAPS hosts a set of pluggable JBI-compliant components, which integrate various types of IT assets. These pluggable JBI components are interconnected with a fast, reliable, in-memory messaging bus called the Normalized Message Router (NMR) also referred to as the JBI Bus. Service containers adapt IT assets to a standard services model, based on XML message exchange using standardized message exchange patterns (MEP) based on abstract WSDL. This improves interoperability and allows a mix-and-match of technologies from various vendors. When sending and receiving messages outside the JBI environment, the engine component containers communicate using the in-memory NMR messaging infrastructure and pass messages out to the client through an appropriate binding component container. When communication is entirely within the JBI environment, no protocol conversion, message serialization, or message normalization is necessary because all messages are already normalized and are in standard XML format.




2. Normalized Message Router

Normalized messages are the messages of a JBI message exchange.

Message normalization is the process of storing protocol and business context in a generic, transportable fashion. All messages handled by the Normalized Message Router are in normalized form. Normalization is a two-way street:

• Normalizing a message consists of mapping context-specific data to a context-neutral abstraction. Essentially, a normalizer must 'translate' context information that needs to be interpreted by the NMR into a 'generic' form that the NMR understands. Any other information (e.g. payloads, additional relevant context) can be added to a message, and carried by the NMR, but these data are completely opaque to the NMR. Note that normalization does not imply canonicalization of the payload data.

• Denormalizing a message refers to the process of receiving a message from the NMR and translating it back into a context-specific representation. Denormalization represents the inverse of a normalization operation. For example a SOAP binding would denormalize a message by placing appropriate parts of the message and its metadata into a SOAP envelope, applying the required encoding style as it does so.


3. JBI components

The JBI component list is available at https://open-esb.dev.java.net/Components.html

- Service Engines:

Service Engines provide business logic and transformation services to other components, as well as consume such services. SEs can integrate Java-based applications (and other resources), or applications with available Java APIs.


- Binding Components:

Binding Component provide connectivity to services external to a JBI environment. This can involve communications protocols, or services provided by Enterprise Information Systems (EIS resources). BCs can integrate applications (and other resources) that use remote access technology that is not available directly in Java.


4. JavaCAPS 6 - Tools for JBI component development

The Sun JavaCAPS set of tool is based on:

  • NetBeans 6.1
  • Sun Component Development Kit


4.1. NetBeans 6.1
The NetBeans IDE is a modular, standards-based, integrated development environment (IDE) written in the Java programming language. The NetBeans project consists of an open source IDE and an application platform, which can be used as a generic framework to build any kind of application.

4.2. JBI Component Development Tools Requirements
Developing a JBI Component ( Service Engine or Binding Component ) involves using standard JBI api and implementing standard JBI spi apart from handling the component specific code. Lot of the development process such as build scripts, most of the JBI spi implementation, administration and testing is common for any JBI component development.

4.3. The Component Development Kit (CDK)

The CDK provides a development tools that helps user to develop, debug, unit test and install JBI components ( Service Engines and Binding Components ) using NetBeans IDE and also provides tools to develop the NetBeans plugin for the component.
The NetBeans plugin help the component end user to develop, test and deploy composite applications ( SA ) for the component using the IDE.


The CDK specification is available at:
http://wiki.open-esb.java.net/attach/JbiComponentDevTools/JBI_CDK_UI_Specification.html
http://wiki.open-esb.java.net/Wiki.jsp?page=JbiComponentDevTools

The illustration below shows the CDK (nbm) installed on NetBeans6.1 for Java CAPS:






The illustration below shows a new custom Service Engine developed by the CDK and used into the NetBeans CASA editor (SA):


See part 3 ...


Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Christophe Vaille

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today