Creating a Hello World JBI Binding Component
| ATTENTION!
This tutorial page is a work in progress and it may contain outdated information or may not work at all. It will be reworked soon, so check back later for updates.
|
| Should I Create My Own JBI Components?
NOTE: Before beginning this tutorial, please take the time to read the FAQ entry titled Should I Create My Own JBI Components?. It is very important that you understand the reason for developing a JBI binding component and this FAQ entry will explain this. |
This tutorial describes how to create a very simple Hello World style of JBI binding component. This tutorial is as minimalistic as possible so as to focus on key concepts and not drown in details. The Hello World binding component will respond to all requests with the message:
<hello>Hello World! Message [<original message here>] contains [??] bytes.</hello>
The following sections will walk through the creation, packaging, testing and deployment of the Hello World binding component.
Prerequisites
- Maven 2.0.7 or higher
- If you have never used Maven previously the Maven Getting Started Guide explains some valuable concepts surrounding Maven
- ServiceMix 3.2.1 or higher
- A broadband internet connection so Maven can automatically download dependencies
A Very Brief Introduction to Java Business Integration
The Java Business Integration (JBI) spec provides a standards-based, service-oriented approach to application integration through the use of an abstract messaging model, without reference to a particular protocol or wire encoding. JBI introduces the concepts of Binding Components (BCs), Service Engines (SEs) to Service Units (SUs) and Service Assemblies (SAs) to define an architecture for vendor-neutral pluggable components. The purpose of this architecture is to provide standards-based interoperability amongst components/services.
JBI components are can be thought of as the smallest applications or services accessible in a service-oriented architecture. Each service has a very specific purpose and therefore a narrow scope and set of functionality. Components come in two flavors: Service Engines (SE) and Binding Components (BC). SUs must be packaged into a SA to be deployed to the JBI container. An SA is a complete application consisting of one or more services. By comparison, this is similar to the way that WAR files must be packaged inside of an EAR file to be deployed to a J2EE container.
See also the page providing information on working with service units
Below are some quick definitions the are dominant throughout the JBI spec:
- Component Architecture
- Binding Components - Components that provide or consume services via some sort of communications protocol or other remoting technology
- Service Engines - Components that supply or consume services locally (within the JBI container)
| The difference between binding components (BCs) and service engines (SEs) is definitely subtle and is not denoted by the JBI APIs. In fact, the only real true difference between the two is in the jbi.xml descriptor in the packaging. What it really boils down to is the fact that BCs are used to do integration with a service outside the bus and SEs are services that are deployed to and solely contained within the bus. Hopefully the JBI 2.0 spec will provide more distinction. |
- Component Packaging
- Service Units - Packaging for an individual service that allows deployment to the JBI container; similar to a WAR file from J2EE
- Service Assemblies - Packaging for groups of SUs for deployment to the JBI container; similar to an EAR file from J2EE
This tutorial focuses on both component architecture and component packaging. For further information and details on JBI, see the following:
Now let's move on to creating the Maven projects for the Hello World binding component.
Creating a Maven Project For the JBI BC
The focus of this section is on the creation of a JBI binding component. For this task, a Maven archetype will be used to create a Maven project skeleton to house the component. Maven archetypes are templates for Maven projects that jumpstart project creation via the automation of repetitive tasks by following standard conventions. The result of using an archetype to create a Maven project is a directory structure, a Maven POM file and, depending on the archetype being used, sometimes Java objects and JUnit tests.
Below are the steps to follow for creating the directory structure and project. All instructions are laid out to take place on a Unix command-line.
1) Create a directory named hello-world-smx and switch to that directory:
$ mkdir hello-world-smx
$ cd hello-world-smx
2) Use the servicemix-binding-component Maven archetype to generate a Maven project for the component.
To create a SE, execute the following command on the command-line:
$ mvn archetype:create \
-DarchetypeGroupId=org.apache.servicemix.tooling \
-DarchetypeArtifactId=servicemix-binding-component \
-DarchetypeVersion=3.2.1 \
-DgroupId=org.apache.servicemix.samples.helloworld.bc \
-DartifactId=hello-world-bc
The command above will create a directory named hello-world-bc that houses a Maven project for the JBI service engine being created here. The name of the directory is taken from the artifactId parameter.
The first three parameters to the mvn command (-DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeArtifactId=servicemix-binding-component -DarchetypeVersion=3.2.1) identify which Maven archetype to use for the archetype:create goal, while the last two parameters (-DgroupId=org.apache.servicemix.samples.helloworld.bc -DartifactId=hello-world-bc) uniquely identify the Maven project that is being generated. The groupId is used as the Java package and the artifactId is used as the project name. Therefore, only alphanumeric characters are valid values for the groupId and artifactId parameters.
| The value of the archetypeVersion parameter in the command above (3.2.1) may need to be updated to the current ServiceMix version in order for the command to work correctly. The latest version can always be found in the top level ServiceMix POM in the <version> element. |
The output from executing the archetype:create goal is shown below:
Again, Maven creates a directory using the artifactId provided as the directory name. Inside this directory resides the pom.xml and the src directory. If you see the BUILD SUCCESSFUL message, proceed to the next section. Otherwise see the note below about a BUILD ERROR.
| In case of a BUILD ERROR: Maven plugin version requirement
The maven-archetype-plugin 1.0-alpha4 or above is required for this tutorial. When an older version is installed, a build error will occur. The version of this plugin can be checked by verifying the name of the following directories:
~/.m2/repository/org/apache/maven/plugins/maven-archetype-plugin
C:\Documents and Settings\<USERNAME>\.m2\repository\org\apache\maven\plugins\maven-archetype-plugin
In case the only version available of the maven-archetype-plugin is an older one, a minimal pom.xml file will need to be created manually in the hello-world-bc directory. Below is a simple POM to use for this purpose:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http:
xmlns:xsi="http:
xsi:schemaLocation="http:>
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.servicemix.samples.helloworld</groupId>
<artifactId>hello-world-bc</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-archetype-plugin</artifactId>
<version>1.0-alpha-4</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
|
Compiling the Project
Since we just created this project, we should first compile it just to make sure nothing is wrong with what the archetype generated. To compile, package and test the project, execute the following command from the command-line:
$ cd ./hello-world-bc
$ mvn install
This command should produce the following output:
Your output may look slightly different because Maven will download the required artifacts. Again, the key here is to make sure you see BUILD SUCCESSFUL. This means that the project skeleton created by the archetype was compiled, packaged and tested successfully. Now we just need to add some custom functionality.
Creating the JBI Component
Before we create any custom functionality, let's first examine some of the items generated by the servicemix-binding-component Maven archetype in this simple component we're developing. These classes extend class from either the JBI spec APIs or from the servicemix-common package.
- pom.xml - This is the Maven POM] file. This XML file contains all the metadata related to the project so Maven can carry out its functionality.
- src/main/java/org/apache/servicemix/samples/bc/MyBootstrap.java -
Implements javax.jbi.component.Boostrap which is called by the JBI container as part of the component lifecycle (i.e.g, when the component is installed and uninstalled). This is where you place logic to set up and tear down things when the component is started and stopped. This class is no longer needed.
- src/main/java/org/apache/servicemix/samples/bc/MyComponent.java - Extends the DefaultComponent, a convenience class that makes creating JBI components much easier and provides some additional lifecycle management for the BC when it's deployed to the JBI container. This class should be fleshed out by overriding methods in the DefaultComponent to configure and initialize the component.
- src/main/java/org/apache/servicemix/samples/bc/MyConsumerEndpoint.java - Extends ConsumerEndpoint and implements MyEndpointType. If you'd like to create a BC that fulfills the consumer role, implement the process() method in this class.
- src/main/java/org/apache/servicemix/samples/bc/MyEndpointType.java - This class is simply an interface marker for Apache XBean so it can generate an XML schema document.
- src/main/java/org/apache/servicemix/samples/bc/MyProviderEndpoint.java - Extends ProviderEndpoint and implements MyEndpointType. If you'd like to create a BC that fulfills the provider role, depending on the MEP being supported, you will need to implement the processInOnly() method or the processInOut() method in this class.
- src/main/java/org/apache/servicemix/samples/bc/MyEndpointType.java - This is a marker interface used by XBean so it can generate a XML schema.
- src/test/java/org/apache/servicemix/samples/bc/MySpringComponentTest.java - A simple JUnit test class that extends a helper class to make configuring ServiceMix very easy.
- src/test/resources/spring.xml - A very simple and generic ServiceMix configuration file for use with the MySpringComponentTest.
Now that we've gotten a bird's eye view of what we're working with, let's proceed to adding the custom functionality.
Adding Custom Functionality
Before creating custom functionality for the BC, you need to understand the role of a JBI BC. A BC is simply a binding to a service that is external to the JBI normalized message router (NMR) using some type of communications protocol (e.g., FTP, HTTP, JMS, etc.). It's also the responsibility of the BC to handle any conversion of the message format into a normalized message so that can be sent along to the NMR. This is known as message normalization.
Just as an example, if we were to create a BC that uses SNMP as the application layer protocol, the SNMP RFC specifies the message format to be used with particular versions of SNMP. It would be the responsibility of the BC to handle not only the communication via the SNMP protocol but also to handling the marshalling of SNMP messages to/from JBI normalized messages. The BC would simply be a binding to a service external to the NMR that speaks SNMP messages via the SNMP protocol.
More on this later in the tutorial. For now, let's proceed with the custom functionality.
| Using an IDE
It is at this stage that you should employ the use of an IDE. An IDE can dramatically reduce the work necessary to import clases, override methods and so much more. Because Maven can easily generate project files for Eclipse or IntelliJ IDEA, either one can be used. Throughout this tutorial, Eclipse will be used. To generate project files for Eclipse, execute the Maven eclipse:eclipse goal from the command line and then import the project into your Eclipse IDE. |
The creation of a binding component is dependent upon the role that it will play. BCs are consumers, providers or both. Below are definitions of the two roles as they pertain to BCs:
- Consumer - A consumer BC receives requests from a service external to the JBI container and publishes those requests to the NMR.
- Provider - A provider BC receives requests from the NMR and publishes those requests to a service that is external to the JBI container.
This is why both the MyConsumerEndpoint.java and the MyProviderEndpoint.java files exist when using the servicemix-binding-component archetype to create a Maven project. This way the BC that you're creating can play either the consumer role or the provider role or both. For the sake of this tutorial, we will implement the provider role. Let's proceed to implement the provider functionality. To do so, open MyProviderEndpoint.java and let's take a look at he processInOut() method as shown below:
protected void processInOut(MessageExchange exchange, NormalizedMessage in, NormalizedMessage out) throws Exception {
throw new UnsupportedOperationException("Unsupported MEP: " + exchange.getPattern());
}
One important item of note before we get started is that this tutorial will not actually be accessing any services external to the JBI container. The reason for this is that setting up a service external to the JBI container would dramatically increase the complexity of this tutorial. Instead, we will just simulate such functionality by hard-coding some text to be returned.
The processInOut() method is just a stub that needs to be populated with our custom functionality. Below is the method body that can be copied and pasted into the method stub add some custom functionality. Following the display of this method, we will pick apart this method a bit to explain the various pieces of logic:
protected void processInOut(MessageExchange exchange, NormalizedMessage in, NormalizedMessage out) throws Exception {
SourceTransformer sourceTransformer = new SourceTransformer();
DOMSource inMessageXml = (DOMSource) sourceTransformer.toDOMSource(in);
CachedXPathAPI xpath = new CachedXPathAPI();
Node inMessageNode = xpath.selectSingleNode(inMessageXml.getNode(), "/hello");
String inMessage = inMessageNode.getTextContent();
String outMessage = "<hello>Message [" + inMessage + "] contains [" + inMessage.getBytes().length + "] bytes</hello>";
out.setContent(new StringSource(outMessage));
}
Adding this method will require the import of the following classes:
- javax.xml.transform.dom.DOMSource
- org.apache.servicemix.jbi.jaxp.SourceTransformer
- org.apache.servicemix.jbi.jaxp.StringSource
- org.apache.xpath.CachedXPathAPI
- org.w3c.dom.Node
All of these classes can be found in either the servicemix-core project or its transitive dependencies. If you're using Eclipse, you can tell Eclipse to automatically import them by selecting Source->Organize Imports.
| Important Information!
This tutorial will not be accessing any services external to the JBI container. Instead, we will just simulate such functionality by hard-coding some text to be returned. |
Now let's move on to testing this component and then we'll compile and test it.
Testing the Hello World Binding Component
Thanks to the Maven archetype, testing the component is very easy because it already created a test. The only change we'll make is to the string being sent by the client code. In the src/test/java directory is the org.apache.servicemix.samples.helloworld.bc.MySpringComponentTest test. Simply open this test and change line #36 from this:
me.getInMessage().setContent(new StringSource("<hello>world</hello>"));
to something more meaningful, like this:
me.getInMessage().setContent(new StringSource("<hello>Ski Colorado!</hello>"));
Also, add the following block of code to line # 40 below the comment:
if (me.getStatus() == ExchangeStatus.ERROR) {
if (me.getError() != null) {
throw me.getError();
} else {
fail("Received ERROR status");
}
} else if (me.getFault() != null) {
fail("Received fault: " + new SourceTransformer().toString(me.getFault().getContent()));
}
System.err.println(new SourceTransformer().toString(me.getOutMessage().getContent()));
client.done(me);
Though there are no asserts in the test, it is more about seeing visual confirmation of the message being output to the console when running the test. So to compile the source and to execute the test, simply run the Maven install goal on the command line from within the hello-world-bc directory like so:
Below is the output that will print to the console:
Notice that not only do we see that the build was successful, but also note the text in the output above that was printed by the test:
<?xml version="1.0" encoding="UTF-8"?><hello>Message [Ski Colorado!] contains [13] bytes</hello>
This is the message we were expecting to be output from the test. So if you see this, you just wrote a JBI component and tested your first JBI BC successfully.
Now let's look at how this component is deployed to ServiceMix.
Deploying the BC to ServiceMix
Thanks to Maven, this BC has already been packaged properly to be deployed to ServiceMix. Just take a look in the target directory of the project and you will see the zip file:
$ ls -l ./target | awk {'print $9'}
classes
hello-world-bc-1.0-SNAPSHOT-installer
hello-world-bc-1.0-SNAPSHOT-installer.zip
hello-world-bc-1.0-SNAPSHOT.jar
jbi.xml
surefire-reports
test-classes
xbean
This zip file contains everything needed to deploy the BC to ServiceMix. This can be done by simply copying the zip file to the ServiceMix component installation directory. By default, this is a directory named install. However, this does not complete the deployment of the BC.
In order to actually make use of the BC, you will need to create a JBI service unit (SU) that uses the BC. A SU is really just a configuration for a JBI component to tell it how to behave. Just like all the JBI components that come with ServiceMix, in order to use one, you will need to create a SU that configures it, telling the JBI container how the component should behave. But the situation with this component is a bit different. Because the Hello World BC contains a hard-coded message, there's not much configuration to be done other than just stating that it should be used. So let's create the SU for the Hello World BC and then we'll move on to testing it.
Creating a Hello World BC Service Unit
This is a work in progress
Wrapping the Service Unit in a Service Assembly
The component we created above and packaged as a SU cannot be directly deployed to a JBI container until it's wrapped in a SA. This can be done by creating a SA with a dependency on the SA. From within the hello-world-smx directory, execute the following commands to create the project for the SA:
$ pwd
/Users/bsnyder/src/hello-world-smx/hello-world-bc
$ cd ..
$ mvn archetype:create \
-DarchetypeGroupId=org.apache.servicemix.tooling \
-DarchetypeArtifactId=servicemix-service-assembly \
-DarchetypeVersion=3.2.1 \
-DgroupId=org.apache.servicemix.samples.helloworld \
-DartifactId=hello-world-sa
Upon successful execution of the archetype:create goal, look for the BUILD SUCCESSFUL output as displayed below:
The hello-world-smx directory should now contain the following two directories:
$ ls
hello-world-sa hello-world-bc
If you see the above directories, proceed to the next step below. If instead you see the BUILD FAILED output, you'll need to analyze the rest of the output to troubleshoot the issue. Assistance with any issue you might experience is available from the ServiceMix community via the ServiceMix mailing lists archive.
Now that we have a project for the SA, we need to edit the POM so that the project depends upon the JBI component we created above. This can be done by editing the POM for the SA to add a dependency upon the hello-world-bc as listed below:
<dependency>
<groupId>org.apache.servicemix.samples.helloworld.bc</groupId>
<artifactId>hello-world-bc</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
Upon adding this dependency to the POM, build the project using the command below:
$ cd hello-world-sa
$ mvn install
Incorporating the Projects Into a Top Level POM
Now that we have created the SU and SA projects, a top level pom.xml must be manually created and made aware of each subproject. This will allow all the projects to be built automatically without having to build each project in order manually. Maven will discover all the projects and build them in the proper order. In the hello-world-smx directory, create a file named pom.xml containing the following content:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http:
xmlns:xsi="http:
xsi:schemaLocation="http:>
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.servicemix.samples.helloworld</groupId>
<artifactId>hello-world-smx</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>Hello World JBI Component</name>
<modules>
<module>hello-world-sa</module>
<module>hello-world-bc</module>
</modules>
</project>
This POM will allow the example to be easily folded in to the ServiceMix samples. The <modules> element denotes the other projects that were created above using the Maven archetypes. Once the pom.xml file from above is saved into the hello-world-smx directory, you should now see the following:
$ ls
hello-world-sa hello-world-bc pom.xml
All projects can now be built using the following command on the command-line from the top level hello-world-smx directory:
The command above should display the output below:
As long as you see the BUILD SUCCESSFUL message in the output continue to the next section to give each project a unique name.
Give Each of the Maven Subprojects a Name
Notice in the output above that there are a two projects named A custom project. This is because the archetypes create projects with this generic name. Let's give each project a unique name via each component's pom.xml file. This name will allow Maven's output to denote a component's name in its output making our development work a bit easier. To name each project, simply edit each pom.xml and replace <name>A custom project</name> with an appropriate name. Below are the instructions for naming each component's project:
- Edit hello-world-sa/pom.xml and replace <name>A custom project</name> with <name>Hello World Service Assembly</name>
- Edit hello-world-bc/pom.xml and replace <name>A custom project</name> with <name>Hello World BC Service Unit</name>
Now when the projects are built you will no longer see a project named A custom project. Instead you'll now see Hello World SE Service Unit and Hello World Service Assembly. Rebuild the projects again using the mvn clean install command on the command-line to see the change.
Deploying the Component
Now that the SA is built, we're ready to deploy it to the JBI container.
This is a work in progress. I will finish this up very soon.
| Deploying Component Dependencies
When working with the jbi:projectDeploy you may want to disable dependency deployment. When deploying to a server which has other components sharing these dependencies, they can cause problems during deployment. To stop the Maven JBI plugin from undeploying and redeploying dependencies each time, alter its configuration by disabling the deployment of dependencies using the following:
<build>
<plugins>
<plugin>
<artifactId>jbi-maven-plugin</artifactId>
<configuration>
<deployDependencies>false</deployDependencies>
</configuration>
</plugin>
</plugins>
</build>
The configuration above introduces the deployDependencies element to the Maven JBI plugin and sets it to false.
For a few more configurable options on the Maven JBI plugin, see also Ability to configure jbi:projectDeploy goal to exclude updating dependencies. |
Additional Resources