Friday Nov 07, 2008

JavaCAPS - Introduction of JBI Component development (Part 1)

The same question came to me every night, how to develop a JBI Service Engine ?
To have better nights, I decide to build a JBI Service Engine component through a use case as:


How to build a JBI - Java Library Wrapper Service Engine ?

Introduction

These 11 bloglets describe how to develop a JBI Service Engine that handles Java library.

It is divided in different parts:
• introduces JBI components framework
• introduces tools for JavaCAPS
• enlightens JBI Service Engine
• describes a use cases: How to build a Library Wrapper Service Engine using JNI.

For business applications using a JBI Service, developing Service Engine on Java CAPS infrastructure could
be a solution to integrate legacy systems or proprietary systems.

We will see how to develop our own JBI Service Engine by using the following tools:

  • NetBeans 6.1
  • Component Development Kit
For the JBI - Library Wrapper Service Engine, I propose the following approach:
The Architecture of the Library Wrapper Service Engine is divided into four parts:
  • Java JNI Library: MyLib
  • Mapper: JNIMapper
  • JBI Generic Library Wrapper Service Engine.
  • Service Unit

The illustration below shows the Library Wrapper Service Engine architecture:



To create and build the Library Wrapper Service Engine, we will create the following projects under NetBeans 6.1:



See part 2...

Thursday Nov 06, 2008

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 ...


Wednesday Nov 05, 2008

JBI Component development (Part 3)

Developing JBI components 

1. Developing JBI componets - Theory


Implementing a JBI plug-in component involves fulfilling several JBI-defined contracts.
These contracts cover:

• Installation packaging and description
• Component life cycle management
• Messaging based on defined message exchange patterns
• Publication of offered services
• Service unit management


More details are available on the document: the JBI Components: Part 1 (Theory) from Ron Ten-Hove
https://open-esb.dev.java.net/public/pdf/JBI-Components-Theory.pdf

Technical document on developing JBI components from Srinivasan Chikkala
https://open-esb.dev.java.net/public/jbi-comp-examples/Developing_JBI_Components.html


2. Library Wrapper Service Engine ?

2.1. Architecture point of view

2.1.1. Specialized JBI Service Engine

A specialized Java Library Service Engine is easier to build, but it could be not relevant.
Needs for the Specialized Library Service Engine:

JBI Specific Library Wrapper Service Engine to glue the Java Library.
WSDL that describe the Library interface.
The Java Library calls are hard coded in the Library Wrapper Service Engine.

2.1.2. Generic JBI Service Engine

A Generic Java Library Service Engine is more complex to build, but it allows at design time to
use a Java library by using a WSDL that describe this Java Library.

Needs for the Generic Library Wrapper Service Engine:

JBI Generic Library Wrapper Service Engine.
WSDL that describe the Library interface.
Wrapper component to glue the Generic Service Engine to the Java Library
Dynamic loading of the Java Library Wrapper from the Generic Service Engine.

2.2. Use case: How to build a Library Wrapper Service Engine ?

For this use case, the Generic approach has been chosen.

The use case will demonstrate how to build a Generic Library Wrapper Service Engine
that uses a Java JNI wrapper Library.


2.2.1. Architecture of the Library Wrapper Service Engine



The Architecture of the Library Wrapper Service Engine is divided into four parts:


Java JNI Library: MyLib
Mapper: JNIMapper
JBI Generic Library Wrapper Service Engine.
Service Unit





Components of the JNI library: MyLib:

MyLib C. (MyLib.so or .dll)
Java JNI Wrapper using naitive call to MyLib C. (JNIWrapper.jar)
WSDL that describe the Java JNI Library interface. (MyLib.wsdl).

Components of the Mapper: LibMapper:

WSDLParser using JAXB APIs to parse any WSDL as MyLib.wsdl (WSDLParser.jar).
WSDLParser parses the MyLib.wsdl to find the operation name from the NMR message input.

LibMapper component glues the Generic Service Engine with any Java Lib. (LibMapper.jar).
Mapper implements IMapper interface for dynamic loading from the SE. (JNIMapper.jar).

IMapper defines two methods:

- init(params);
- callLib(params);

- init(params): provides the wsdl name to the mapper.

- callLib(params): provides the:
DOM Node that content datas extracted from the NMR message.
messageInput name from the NMR message.

- JNIMapper: to glue the Generic Service Engine with the specific Java JNIWrapper (JNIMapper.jar).
JNIMapper extends Mapper for the specific JNIWrapper library.
Components of the Generic Library Wrapper Service Engine: LibWrapperServiceEngine


JBI Generic Library Wrapper Service Engine that implement the IMaper interface.

Components of the Service Unit:

JBI descriptor (jbi.xml).
WSDL that describe the Java JNI Library interface (MyLib.wsdl).
Properties file (Map.properties) used by the Generic Service Engine to define the name of the:

- WSDL (MyLib.wsdl)
- specific JNIMapper class that extends Mapper interface (mapper.JNIMapper) for dynamic loading by the SE.


3. The Library Wrapper Service Engine component

To create and build our Library Wrapper Service Engine, we will use NetBeans 6.1 as IDE tool.
List of the projects in NetBeans 6.1 needed to create and build the Library Wrapper Service Engine:


See part 4 ...

Tuesday Nov 04, 2008

JBI Component development (Part 4)

Java JNI Wrapper Library - JNIWrapper

1. The Java JNI Wrapper Library (JNIWrapper)

Java Native Interface (JNI) is a standard programming interface for writing Java native methods and embedding the Java virtual machine into native applications. The primary goal is binary compatibility of native method libraries across all Java virtual machine implementations on a given platform.

JNI Spec available at:
http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/jniTOC.html

Components of the JNI library: MyLib:

- MyLib C. (MyLib.so or .dll)
- Java JNI Wrapper using native call to MyLib C. (JNIWrapper.jar)
- WSDL that describe the Java JNI Library interface. (MyLib.wsdl).


To create the JNIWrapper, use NetBeans and create a new Java project: JNIWrapper.
At the end of this topic the project will produce a JNIWrapper.jar file.

1.1.Build the JNIWrapper:

For this use case the native library is called MyLib and is written in C and provides 2 methods:






The parameter to define a rule in the getPolicyRule method is a C structure:





To wrap the C structure we use a Java class:





To map the two C methods with Java, we need to declare two java native methods:





Use the javah tool from the SDK to generate the .h that define the natice call:




Now you need to implement the source.c that include the .h generated by javah.
At the Java level we created the two methods that wrap the native call:





Our JNIWrapper is now ready, we need to create the WSDL file that define our JNIWrapper library.

1.2. Create the WSDL


The WSDL (MyLib.wsdl) will define two operations and a complex type as:

- getPolicyRule operation for the java method: getPolicyRule(String ruleName);
- setPolicyRule operation for the java method: setPolicyRule(PMRULE rule);
- Rule type for the java class PMRule.





See part 5 ...

Monday Nov 03, 2008

JBI Component development (Part 5)

Mapper component - LibMapper 

1. The Mapper component (LibMapper)

Components of the Mapper: LibMapper:

- WSDLParser using JAXB APIs to parse any WSDL as MyLib.wsdl (WSDLParser.jar).
WSDLParser parses the MyLib.wsdl to find the operation name from the NMR message input.

- Mapper component glues the Generic Service Engine with any Java Lib. (LibMapper.jar).
Mapper implements IMapper interface for dynamic loading from the SE. (JNIMapper.jar).
IMapper defines two methods:

- init(params): provides the wsdl name to the mapper.

- callLib(params): provides the:
DOM Node that content datas extracted from the NMR message.
messageInput name from the NMR message.


- JNIMapper: to glue the Generic Service Engine with the specific Java JNIWrapper (JNIMapper.jar).
JNIMapper extends Mapper for the specific JNIWrapper library.

To create the LibMappeur, use NetBeans and create a new Java project:LibMapper.
At the end of this topic the project will produce a LibMapper.jar file.


1.1. The WSDL parser

The WSDLParser will use the JAXB APIs to parse the any WSDL file.
To generate the JAXB classes we need to use the WSDL schema available at:
http://schemas.xmlsoap.org/wsdl/

To create the WSDLParser, use NetBeans and create a new Java project: WSDLParser.
At the end of this topic the project will produce a WSDLParser.jar file.

We need to use NetBeans to launch the JAXB wizard to generate the JAXB binding classes.


The illustration below shows the JAXB wizard.




The NetBeans wizard allows you to generate JAXB binding class from the wsdl schema:




Now we need to create a Java code to use the JAXB generated code.
We create a new Java class WSDLParser.class that will help us to manipulate the any WSDL data.


Three methods to manipulate the WSDL informations:

- unmarshall(String file);
- String finfOperationNameFromInput(String msgInput);
- String findMessageOutputNameFromOperation(String op);


For example unmarshall() method to parse the WSDL document:



We have created also a findOperationNameFromInput() method in the WSDLParser class.
This method allows us to find the operation name in the MyLib.wsdl from the input message provided by the NMR message. The operation name is the name of the method in the JNIWrapper library.




This WSDLParser + the generated JAXB binding code could be tested as a stand alone Java application:





For more details on JAXB see the JAXB jaxb.dev.java.net pages: https://jaxb.dev.java.net/


1.2. The Mapper

The Mapper component glues the Generic Service Engine with any Java Lib. (LibMapper.jar).
Mapper implements IMapper interface for dynamic loading from the SE. (JNIMapper.jar).

The IMapper interface is a common interface between the LibMapper and the LibWrapper Service Engine.
IMapper defines two methods:

- init(params): provides the wsdl name to the mapper.

- callLib(params): provides the:
DOM Node that content datas extracted from the NMR message.
messageInput name from the NMR message.


Any class that implement IMapper can be dynamically loaded by the Service Engine.

\* callLib(Params param) is the entrance point of the mapper from the Library Wrapper Service Engine.
The callLib method will be call at each NMR message dedicated to the Library Wrapper Service Engine.
The parameters of callLib provides the:

- method's name to call in the library.
- DOM that containt the parameters needed for the library method call.


\* Init(Params param); to perform initializations and called by the Service Engine when the Service Unit is deployed.


The Mapper class implements the IMapper interface and provides a:

- WSDL parsing by using the WSDLParser.


- libHandler(Params param) is an abstract method dedicated to any specific mapper that extends the Mapper class.
The libHandler method will be call at each NMR message dedicated to the Library Wrapper Service Engine. The parameter of the libHandler provide the:

- method's name to call in the library.
- DOM that contains the parameters needed for the library method call.


The illustration below shows the Mapper class that implements IMapper:




1.3. Build JNIMapper

The JNIMapper is specific for this use case, it implements the Mapper class to map the JNIWrapper library.

The abstract method libHandler must be implemented in the JNIMapper.
libHandler(String methodName, Node params) is an abstract method dedicated to any specific mapper that extend the Mapper class.
The libHandler method will be call at each NMR message dedicated to the Library Wrapper Service Engine. The parameter of the libHandler provide the:
- method's name to call in the library.
- DOM that containt the parameters needed for the library method call.

Inside the libHandler(Params param) we provide the code to call our specific JNIWrapper library methods.

The illustration below shows the implementation of the libHandler method:


See Part 6 ...

Friday Oct 31, 2008

JBI Component development (Part 8)

The specific JNI Mapper

1. The specific JNI Mapper


To test and call the JNIWrapper library previously developed, it's time to create the specific Mapper for the JNIWrapper library, the JNIMapper.

To create the JNIMapper, use NetBeans and create a new Java project: JNIMapper.
At the end of this topic the project will produce a JNIMapper.jar file.

The JNIMapper class will extend the Mapper class previously created in the LibMapper.jar
The only thing to do, is to implement the abstract method that will call by the super class:

- libHandler(String methodName, Node params);

The code will call the right methods in the JNIWraper using the methodName received as a parameter in libHandler.

The illustration below shows the JNIMapper implementation:





See Part 9 ...

Tuesday Oct 28, 2008

JBI Component development (Part 11)

er[Read More]
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