Introduction to integration and Open ESB, part I: Open ESB serverside artifacts.

First lets look more closely at integration as the problem which the ESBs (Enterprise Service Bus) are here to resolve. Integration headache is the result of having many different applications with different channel of communication and almost no common format for information which these application need to receive or send. Usually several applications from different vendors or in-house developed applications drive the enterprise good enough to prevent it from falling down. But when it come to competition with other competitor in the same industry, having a good sight of information is the first requirement. In addition to being able to smoothly communicate with other companies which can help in providing better services for the customers is a big plus.

Some of the stoppers for an easy integration between these group of software is different data format, communication channels and their no integration in mind architecture; solving these problems has lead to a set of patterns, software and standards for integration.

Although when it come to articles and tutorials we have very simple scenarios which we implement the solution for them, but in large and complex systems many other requirement will rise which will prevent one from using any other previous total solution to achieve the required integration. These headache of having many proprietary solutions lead to the JSR-208, the Java Business Integration(JBI), to make the Java community united behind a single model for addressing integration problems.

There are two major way for integrating different software, one is the way that is implemented in ESBs in which one central software (ESB) will perform all transformation and transportation between different components of the architecture, in the other way the ESB or its place holder will only route and deliver the messages instead of converting them between different formats, end point itself is responsible for changing the format from what it is to what it needs.

What is the difference between these two solutions, what are advantages and disadvantages? In the formal ESB model, a vendor need to implement many transformation algorithms and must understand how to deal with many formats like: COBOL copybook, MDDL, XBRL, RIXM, etc. which is not an easy to cope with task. On the other hand, Every message which is travelling within the BUS (NMR) should be converted to XML even if the receiver end point can process the original message format; this can introduce additional processing burden over the integration server(s). Using this way you, the integrator, have no concern about different format and converting them. But the vendor need to implement many engines to cover every customer requirement. In the second way, you, as the integrator, are responsible for converting messages from available format to the format you need in the way that you think is more suitable for your workload and semantic of message content.

Open ESB, an open source JBI implementation sponsored by Sun Microsystems and hosted in Java.net, is one of major open source ESBs which integrator or SOA developers may try to utilize in their integration or SOA. Open ESB can be deployed into Jboss, GlassFish and Websphere Application Server along with possibility to run it as a Java SE application. Open ESB is pre-bundled with many binding components and Service Engine which almost make you free from looking for binding components or service engines which you may need in a typical integration scenario.

In addition to the plenty of Service Engines and Binding Components, Open ESB has a very good development IDE closely integrated with Open ESB, NetBeans IDE 6.1 has many features which ease development of composite applications based on Open ESB's capabilities. It come with a visual designer which support drag and drop, connectivity, configuration of binding components and required web services. Each binding component in the Open ESB has a design time representation in the IDE which let you easily design your integration scenario in the IDE based on the server's facilities.

In this series of article I will try to demonstrate some capabilities of NetBeans 6.1 for developing composite applications on top of Open ESB.

This part is devote to introducing you to the Open ESB in the server side, the following parts introduces different Open ESB binding components and service engines in context of a continues example.

To download Open ESB you should point your browser to https://open-esb.dev.java.net/Downloads_OpenESB_Addons_NB6.html and get the suitable distribution for your operating system. After installing this package you will have, a mega bundle of NetBeans, Access Manager, Open ESB, Portlet Container and several other projects well integrated and ready to be used for developing your SOA solution.

During the installation procedure you can customize the capabilities that you need to install. You can choose to have or not to include several packages and capabilities as shown in figure 1.

You will be asked to provide some configurations like IDE installation path as shown in figure 2 and Application server installation path and basic configurations as shown in figure 3.

Now that installation is finished, fire up a terminal console (command window) and navigate to Open ESB server installation folder, navigate to server_home/bin and execute asadmin batch or shell script based on your operating system.

Start the application server by executing start-domain domain1

In order to access to web based administration console Open a web browser and point your browser to http://localhost:4848 , use admin/adminadmin credentials to log-in into the application server administration console. (the port number depends on your configuration during the installation, by default it is 4848 and the credentials are as above by default)

This article will explain server side artifacts of the Open ESB in order to make you familiar with what we have in the server which you can utilize to build your integration solutions or SOA.

After Opening the administration console you will see a page similar to figure 4. Every annotated number in the screen shot shows a functionality related to Open ESB.

Composite Application Manager: The Composite Application Manager provides management and monitoring functionalities for composite applications and components (SE and BC) deployed in the JBI container. It provides a runtime view of the composite applications and components and allow you track the health, performance and message recovery of your JBI system. We will discuss CAM in part III of the article. Java Business Integration: This node act as the parent of all JBI related artifacts deployed in the application server. Artifacts like Service Assemblies which are JBI applications that you developed and deployed into the server, Components which are Service Engines, Binding Components, And shared libraries. For a discretion of Service Engine and Binding Components take a look at Figure 5 descrition. A sample application deployed into Open ESB, you can see that the this JBI application has two artifacts (Service Unit) each of these Service Unit is interconnected with a Service Engine or Binding Components based on its deployment target. All Service units of the application is packaged as a Service Assembely. This node contains all available Binding Components, Service Engine and any deployed units into them. Figure 5 shows available Binding Components and Service engines in details. Shared Libraries includes any dependency that other JBI artifacts may have.

Figure 4: Open ESB related artifact in GlassFish installation

A Binding Component is: A binding component is the communication point which make it possible for other applications to communicate with the NMR and other BCs or SEs. In one side it understand the NMR and on the other side it can communicate in a protocol depended way, for example from the NMR to a JMS queue or to an SMTP server. A service engine is: A service engine facilitate execution of some specific tasks inside the JBI run-time. for example a Transformation SE facilitate transformation of an XML file based on the XSLT instructions or a BPEL execution engine make it possible to execute and manage BPEL processes. Application Deployment: As You have seen before each service assembly is composed of several Service Unit and each service unit helps you to use a BC or a SE. Each SU has a configuration file to make it possible for the SU to either be a BC consumer or producer or uses the SE. The service Assembly itself has a configuration file which has description of SUs, endpoints, etc. Each service unit which is a jar file has the same META-INF folder in addition to one more file named catalog.xml inside it. the jbi.xml file which is inside the SU's META-INF folder describe how this SU is connected with the BC or SE. Other folders or files can be included in SUs directory structures, for example BPEL, WSDL, XSDs or other files which are required for the SUs operations. Structure of an standard Service Assembly is as figure 6: figure 6: Service Assemblies directory structure As you can see in the image there are plenty of Binding Components and Service Engine available in the Open ESB installation out of the box, although all of them are not developed by Sun Microsystems but most of the artifacts are their own products. In your administration console you will not find any children for any node because you have not deployed any artifact into the Open ESB. I have deployed a sample in order to show you how each artifact will be deployed and get interconnected with the BC or SE that it is connected with. For example the any BPEL process will get deployed into the BPEL service Engine. any HTTP endpoint (web service end point for example) will deploy into the Http BC.

Figure 5: Open ESB SEs and BCs

By selecting Components (shown by number 4 in figure 4) you can see status of all components in addition to being able to start, stop or shutdown a component. Selecting each component provides you with the administration facilities related to that components, items like configuration, deployed SUs, monitoring, logging, etc.

Every administration facility that is available in the administration console is also available in GlassFish CLI (./asadmin environment) so in order to get familiar with JBI's CLI commands you can navigate to Open ESB GlassFish installation bin folder and execute ./asadmin now need only to type jbi and hitting the enter button. it will shows you a list of all JBI related commands, to get help for each command you can use help <command-name> in asadmin environment.