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

Sunday Nov 02, 2008

JBI Component development (Part 6)

Build the generic Service Engine

1. Build the generic Service Engine

We will create the Generic Library Wrapper Service Engine component: LibWrapperServiceEngine:

The component LibWrapperServiceEngine will implement the IMapper interface.

We need to use NetBeans and the CDK to create a LibWrapperServiceEngine.

1.1. 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 need to be downloaded and installed into NetBeans6.1:
http://wiki.open-esb.java.net/Wiki.jsp?page=JbiComponentDevTools


The illustration below shows the Service Engine wizard.







The NetBeans Service Engine wizard generates a full Service Engine project:




The code generator provides a great starting point with:

- NMR interface
- WSDL interface
- Multithreaded code
- XSLT Service Engine sample code

In fact, this wizard has generated in fact a fully fonctionnal XSLT Service Engine.
We only need to code in the placeholders and remove the specific XSLT parts.

At this time it's mandatory to understand the JBI component specification.


1.2. Theory of JBI components:

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


1.3. Start to implement the Lib Wrapper Service Engine

Customisation of the LibMapperServiceEngine project:

Modification from the generated XSLT SE project the following file:

- Refactor the XSLTFileLocator.java as SELibService.java
- Refactor the XSLTService.java as SEMapperFileLocator.java


Create a new package com.sun.se.lib.mapper that will contain custom classes:
This package will contain the following files:

Create into com.sun.se.lib.mapper:
- IMapper.java
- Params.java

Copy into com.sun.se.lib.mapper the previous renamed files:
- SELibService.java
- SEMapperFileLocator.java

Refactor the package com.sun.jbi.se.xltserviceengine as com.sun.se.lib.provider

The illustration shows the updated LibMapperServiceEngine project:





First we need to check the jbi.xml descriptor.

The refactoring of the package com.sun.jbi.se.xltserviceengine as com.sun.se.lib.provider impact the ProviderSERuntime class.
Edit the jbi.xml descriptor to update the ProviderSERuntime name.





Browse on LibMapperServiceEngine classes:

Package com.sun.se.lib.mapper:

IMapper:

Declaration of the two methods:
init(String rootPath, String wsdlName);
callLib(Params params);



Params:

Creation of the Params class that handles NMR message data.
Creation of four variables:

- Node node;
DOM that will contain the MyLib method parameters transferred from the NMR.

- String messageInputType;
Will contain the messageInputName (from WSDL def) transferred from the NMR.

- String messageOutputType;
Will contain the messageOutputName (from WSDL def) transferred from the NMR.

- String version;
Version of the NMR message.


The illustration below shows the Params class:




SELibService:

SELibService will implement:

NMR parsing code.
Creation of the DOM that parse the NMR and extration of the method parameters.

The method callMapper() that will call the right external Mapper class.
The name of the Mapper class have been loaded by the SEMapperFileLocator by reading the semap.properties file available on the SU associated to the Lib Wrapper Service Engine.


The illustration below shows the DOM creation and extraction data:





The illustration below shows the call to the libCall() methods implemented into the callMapper method of the SELibService:






SEMapperFileLocator:

SEMapperFileLocator will implement:

The Mapping properties that will loaded from the semap.properties file.


The illustration below shows the loadMappingProperties method:




Package com.sun.se.lib.provider:

ProviderSEServiceUnit:

Creation of the custom init code that lauch at the SU init:

Instanciation of the mapper class;
Call to the init method of the mapper to perform initialization at the mapper level as the unmarshlling of the dedicated WSDL associated with the library.


The illustration below shows the custom init code:






ProviderSEMessageExchangeHandler:

Creation of the custom code that call the callMapper() method of the SELibService class.

This code is implemented into the processInMessageOnProvider() method of the ProviderSEMessageExchangeHandler class.


The illustration below shows the callMapper code:





ProviderSEEnpoint:

This class contain the following variables:

SEMapperFileLocator mSEMapperFileLocator;
SELibService mseLibService;

The doInit() method of the ProviderSEEnpoint will instanciate the two following classes: SELibService and SEMapperFileLocator.

1.4. Build and deploy the Service Engine:
Use the NetBeans LibMapperServiceEngine project menu to build the full project.
After the successful build, deploy your new LibMapperServiceEngine on the JBI-Glassfish implementation.

The illustration below shows the NetBeans6.1 Glassfish service JBI par with the LibMapperServiceEngine deployed:



See part 7...

Saturday Nov 01, 2008

JBI Component development (Part 7)

JBI Deployment Module for the LibMapperServiceEngine

1. Build the JBI Deployment Module for the LibMapperServiceEngine

After the build and deployment of the LibMapperServiceEngine on JBI, we need to create the JBI DeploymentPlugin (.nbm) dedicated to the LibMapperServiceEngine.
This specific module will appear on the NetBeans SOA project wizard:

The illustration below shows the NetBeans SOA wizard:



Open in NetBeans 6.1 the JBI DeploymentPlugin [LibMapperServiceEngine] project.


1.1. package libmapperserviceengine.project.wizard.resources:

The package libmapperserviceengine.project.wizard.resources needs to contain the following ressouces files:

- jbi.xml
- semap.properties
- SampleJNICalls.wsdl

The semap.properties file contains the following parameters:

- wsdl=SampleJNICalls
- mapper=libmapper.JNIMapper

The wsdl field must contain the name of the WSDL that describe the interface of the Java library.

The illustration below shows the SampleJNICalls.wsdl file:




The mapper field must contain the name of the specific class that extends the Mapper file. This class will be dynamically loaded by the LibMapperServiceEngine.


The illustration below shows the semap.properties file:




1.2. package libmapperserviceengine.project.wizard

The package libmapperserviceengine.project.wizard contains the following Java class:

- SEPluginProjectWizardIterator.java

- SEPluginProjectWizardIterator:

Edit this class to add the ressource files name to set the following variables on the suArtifacts:
String table.

- String[] suArtifacts = {"semap.properties","SampleJNICalls.wsdl"};

These ressources file will appear later under the LibMapperServiceEngine JBI Module project.

The illustration below shows the suArtifacts String table:




1.3. Build and deploy the plugin


Use the NetBeans JBI DeploymentPlugin [LibMapperServiceEngine] project menu to build the full project.
After the successful build, create the JBI DeploymentPlugin [LibMapperServiceEngine] module NBM plugin.
Now we need to install this new JBI DeploymentPlugin [LibMapperServiceEngine] module NBM plugin into NetBeans 6.1.
Use the NetBeans plugin tool to install the plugin.


The illustration below shows the NetBeans plugin tool wizard:




The illustration below shows the NetBeans plugin tool with the installed JBI DeploymentPlugin [LibMapperServiceEngine]:





At this point the JBI DeploymentPlugin [LibMapperServiceEngine] will appear on the NetBeans SOA wizard that will generate a LibMapperServiceEngine Module.




At this step of development the:

LibMapperServiceEngine is deployed on JBI.
JBI DeploymentPlugin [LibMapperServiceEngine] is available in NetBeans and ready to use.

See Part 8 ...

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

Thursday Oct 30, 2008

JBI Component development (Part 9)

JBI shared library

1. the JBI shared library


The last step is the packaging of a couple of jar files:

Generic JAR files:

- LIBMapping.jar (Implementation of the IMapper interface)
- WSDLParser.jar (Parsing any WSDL file)

Specific JAR file associated to a specific library:

- JNIWrapper.jar (specific code: JNI wrapper code using MyLib C)
- JNIMapper.jar (specific code: Implementation of the Mapper to call the library JNIWrapper)

These four jars will be packaged in a JBI shared library as a a se-mapper-library and deployed on JBI.
A JBI shared library is a zip or jar file that contain the four jar files and a jbi.xml descriptor.

The illustration below shows the jbi.xml descriptor for the se-mapper-library:




The illustration below shows the deployed shared library as a se-mapper-library:

See part 10 ...

Wednesday Oct 29, 2008

JBI Component development (Part 10)

How to use the LibMapperServiceEngine

1. How to use the LibMapperServiceEngine

1.1. Build a test case

1.1.1. Notion of Service Unit and Service Assembly
The official JBI term used for component and composite application are:

- Service Unit - a component of a container type;
- Service Assembly - a composite application of components.

A service engine that uses the service engine wizard,
A Service Engine module that plugs in the NetBeans environment to create service units (JBI modules).




1.1.2. The test case

The test case for the LibMapperServiceEngine will based on a simple BPEL process that will call the two methods setPolicyRule and getPolicyRule implemented in C code inside the MyLib.
The test case need two WSDL files:

- TestSampleJNICalls.wsdl: input partner at BPEL level using the HTTP binding Binding Component
- SampleJNICalls.wsdl: description of MylLib interface.

The illustration below shows the SampleJNICalls.wsdl:




The illustration below shows the TestSampleJNICalls.wsdl:




1.1.3. BPEL test case for the LibMapperEngineService

TestLibMapperBpelModule:

To create the TestLibMapperBpelModule, use NetBeans and create a new BPEL project with the wizard:




Import the two WSDL in the process file folder:

- TestSampleJNICalls.wsdl
- SampleJNICalls.wsdl


Create a BPEL process with the NetBeans wizard:




The illustration below shows the BPEL process that will call the JNIWrapper library through the LibMapperServiceEngine:





The illustration below shows the BPEL assignation variable through the mapping graphic tool:




Choose in the NetBeans6.1 TestLibMapperBpelModule's menu, the build item to create the SU of the TestLibMapperBpelModule.
This module will be use in the creation of the composite application (Service Assemby).

1.1.4. LibMapperServiceEngine module

At the end of this topic the project will produce a LibMapperServiceEngineModule.
This module will be the Service Unit for the LibMapperServiceEngine.

To create the LibMapperServiceEngineModule, use NetBeans and create a new Service Engine project with the wizard:




The generated project embed three files:

- jbi.xml
- semap.properties
- SampleJNICalls.wsdl

Theses files are templates files that have been embedded in the previous JBI DeploymentPlugin [LibMapperServiceEngine] project.
You need to edit these files jbi.xml file to be compliant for the test case.

- jbi.xml is the descriptor of the service unit

- semap.properties

The semap.properties file contains the following parameters:

- wsdl=SampleJNICalls
- mapper=libmapper.JNIMapper

The mapper field must contain the the name of the specific class that extends the Mapper file. This class will be dynamically loaded by the LibMapperServiceEngine.

The wsdl field must contain the name of the WSDL that describe the interface of the Java library.

- SampleJNICalls.wsdl

this the file that describes the interface of the Java library.


The illustration below shows the LibMapperServiceEngineJBIModule:



Choose in the NetBeans6.1 LibMapperServiceEngineJBIModule's menu, the build item to create the SU of the LibMapperServiceEngineJBIModule.
This module will be used in the creation of the composite application (Service Assemby).

See part 11 ...

Tuesday Oct 28, 2008

JBI Component development (Part 11)

er[Read More]
About

Christophe Vaille

Search

Categories
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