Creating a Hello World JBI Service Engine
| Work In Progress
This tutorial is a work in progress and is not yet complete. Please check back 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 service engine and this FAQ entry will explain this. |
This tutorial describes how to create a very simple Hello World style of JBI service engine. This tutorial is as minimalistic as possible so as to focus on key concepts and not drown in details. The Hello World 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 service engine.
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 service engine.
Creating a Maven Project For the JBI SE
The focus of this section is on the creation of a JBI service engine. 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 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-service-engine 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-service-engine \
-DarchetypeVersion=3.2.1 \
-DgroupId=org.apache.servicemix.samples.helloworld.se \
-DartifactId=hello-world-se
The command above will create a directory named hello-world-se 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-service-engine -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.se -DartifactId=hello-world-se) 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-se 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-se</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-se
$ mvn install
This command should produce the following output:
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-service-engine 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.
- 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 not longer needed
- MyComponent.java - Extends the DefaultComponent, a convenience class that makes creating JBI components much easier and provides some additional lifecycle management of components deployed to the JBI container. This class should be fleshed out by overriding methods in the DefaultComponent to configure and initialize the component.
- MyEndpoint.java - Extends Endpoint and implements ExchangeProcessor. Endpoint provides a referencable resource for the component and the ExchangeProcessor provides the ability for the JBI container to process a message exchange with the component. The ExchangeProcessor.process() method is where we will add custom functionality to print out the Hello World message.
- MySpringComponentTest.java - A simple JUnit test class that extends a helper class to make configuring ServiceMix very easy.
- src/test/resources/spring.xml - The very simple and generic ServiceMix configuration file.
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 we proceed to creating some custom functionality for the SE, you need to understand the role a JBI SE is meant to fulfill. A SE is an engine that provides a service that is local to the JBI normalized message router (NMR). It does not communicate directly with anything external to the NMR. If communication needs to occur with a service that is external to the NMR, this should take place using a JBI binding component (see the Hello World BC for a tutorial on creating a JBI binding component). The SE is deployed to the JBI container and provides a service directly to the NMR by communicating with the NMR using Normalized Messages.
For example, consider a BPEL engine like Apache Ode. It's job is to handle the execution of BPEL processes. Ode can be deployed to the JBI container as a JBI SE through the use of the servicemix-bpe SE. In this capacity, Ode communicates via JBI normalized messages. Ode handles all of the processing of a given BPEL flow via it's engine and to communicate outside the engine, it speaks normalized messages. It's the responsibility of the Ode SE to handle the execution of processes defined using BPEL and in its capacity as a JBI SE it only communicates outwardly via normalized messages.
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 generate project files for Eclipse and 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 and then import the project into your Eclipse IDE. |
When creating a JBI component, how a message exchange is handled depends on whether a component is a consumer or a provider. Because the Hello World SE will not be consuming any other service (i.e., sending a message to another service), it is a provider (i.e., it will only be providing its service via a return message). As mentioned above, the ExchangeProcessor.process() method is of interest because it is where the message exchange is handled, so let's examine this method:
public void process(MessageExchange exchange) throws Exception {
if (exchange.getRole() == MessageExchange.Role.PROVIDER) {
if (exchange instanceof InOut == false) {
throw new UnsupportedOperationException("Unsupported MEP: " + exchange.getPattern());
}
if (exchange.getStatus() == ExchangeStatus.DONE) {
return;
} else if (exchange.getStatus() == ExchangeStatus.ERROR) {
return;
} else {
if (exchange.getMessage("in") != null) {
NormalizedMessage in = exchange.getMessage("in");
NormalizedMessage out = exchange.createMessage();
out.setContent(in.getContent());
exchange.setMessage(out, "out");
channel.send(exchange);
} else if (exchange.getFault() != null) {
exchange.setStatus(ExchangeStatus.DONE);
channel.send(exchange);
} else {
throw new IllegalStateException("Provider exchange is ACTIVE, but no in or fault is provided");
}
}
} else if (exchange.getRole() == MessageExchange.Role.CONSUMER) {
if (exchange.getStatus() == ExchangeStatus.DONE) {
return;
} else if (exchange.getStatus() == ExchangeStatus.ERROR) {
return;
} else {
if (exchange.getMessage("out") != null) {
exchange.setStatus(ExchangeStatus.DONE);
channel.send(exchange);
} else if (exchange.getFault() != null) {
exchange.setStatus(ExchangeStatus.DONE);
channel.send(exchange);
} else {
throw new IllegalStateException("Consumer exchange is ACTIVE, but no out or fault is provided");
}
}
} else {
throw new IllegalStateException("Unkown role: " + exchange.getRole());
}
}
The implementation of the method above was provided by the servicemix-service-engine Maven archetype. This method is very generic and contains a conditional block for handling either a consumer or a provider role. But this method will still require us to make the decision of which style of Message Exchange Pattern (MEP) to handle. In the case of the Hello World SE, we know that it is a provider so it will need to send a return message. Therefore it will need to handle an In-Out MEP. So instead of having MyEndpoint extend the very basic Endpoint class and implement its own process() method, we're going to extend a different class that is specifically for provider endpoints named
ProviderEndpoint.
Notice the diagram above showing the class hierarchy of Endpoint. The ProviderEndpoint supplies some additional conveniences for provider components beyond what the Endpoint class provides and will make the job of implementing MyEndpoint as a provider much easier. So let's make some changes to the MyEndpoint class. First remove the process() method shown above. Second, change the definition of the MyEndpoint class from this:
public class MyEndpoint extends Endpoint implements ExchangeProcessor
to this:
public class MyEndpoint extends ProviderEndpoint implements ExchangeProcessor
By the way, making this change will require the import of the full class (org.apache.servicemix.common.endpoints.ProviderEndpoint). This class can be found in the servicemix-common project.
Third, because the ProviderEndpoint.process() method already handles an In-Out MEP (and other MEPs), MyEndpoint will simply need to override the ProviderEndpoint.processInOut() method. Below is the content for implementing this method. Copy/paste this method:
protected void processInOut(MessageExchange exchange, NormalizedMessage in, NormalizedMessage out) throws Exception {
SourceTransformer sourceTransformer = new SourceTransformer();
String inMessage = sourceTransformer.toString(in.getContent());
out.setContent(new StringSource("<hello>Hello World! Message [" + inMessage + "] contains [" + inMessage.getBytes().length + "] bytes</hello>."));
}
| Changes to example code
NOTE: You may have problems running above code. In this case remove <? ... ?> string from inMessage. ServiceMix validates XML on every step. So simple concatenating of two xml message will not work.
Also use logger to view actual message you send to StringSource, you may find invalid xml. |
Adding this method will require the import of the following classes:
- org.apache.servicemix.jbi.jaxp.SourceTransformer
- org.apache.servicemix.jbi.jaxp.StringSource
These classes can be found in the servicemix-core project.
This method is the custom functionality for the Hello World SE. We're not doing anything complex here at all in order to keep this tutorial very simple. Apache Ode was mentioned earlier as an example of an engine that can be deployed as a JBI SE, this class is where Ode would be referenced and called. If you're interested to see how Ode is called, see the BPEEndpoint class for the details. Now it's time to test the Hello World SE.
Testing the Hello World Component
Thanks to the 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.se.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>"));
To execute the test, simply run the Maven install goal from within the hello-world-se 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 (<hello>Hello World! Message [<hello>Ski Colorado!</hello>] contains [28] 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 it successfully. Now this SU needs to be wrapped in a SA so it can be deployed to the JBI container.
Deploying the Component
Now it's time to deploy this component to the JBI container. Because the component was just built above, you should now see a filed named hello-world-se-1.0-SNAPSHOT-installer.zip in the target directory of the project. This is the component all packaged up and ready to be deployed. To deploy the component, simply copy the ZIP file to the ServiceMix install directory. You can do this before starting ServiceMix or while ServiceMix is running.
As long as the component deploys properly, you're now ready to create a deploy a configuration for the component.
Deploying a Service Unit That Depends Upon the Component
In order to actually make use of the component, you will need to deploy a configuration for the component. Once JBI components are deployed to the JBI container, they're just hanging out there waiting for a configuration to be deployed to them. This is why JBI is often referred to as a container of containers. The JBI container accepts deployment of JBI components and JBI components accept deployment of service units (SUs) that configure them. This is very similar to the way RAR files work in JavaEE-land. RAR files are generic components that are deployed to the JavaEE container that accept the deployment of a configuration file to tell it how to run. This is exactly how JBI components work. To achieve this, you need to create a JBI SU that depends on the JBI component in it's pom.xml file and to deploy the SU to the JBI container as well.
In the case of the Hello World SE, we're lucky that there are no configuration options really, so all we need to do is create SU that depends on the Hello World SE and deploy that. To do this, use the command below:
$ cd ..
$ mvn archetype:create \
-DarchetypeGroupId=org.apache.servicemix.tooling \
-DarchetypeArtifactId=servicemix-service-unit \
-DarchetypeVersion=3.2.1 \
-DgroupId=org.apache.servicemix.samples.helloworld.se \
-DartifactId=hello-world-su
This creates a directory named hello-world-su. Now edit the hello-world-su/pom.xml file to add the following dependency on the Hello World SE:
<dependency>
<groupId>org.apache.servicemix.samples.helloworld.se</groupId>
<artifactId>hello-world-se</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
This tells Maven that the hello-world-su project depends upon the hello-world-se project. After compiling the hello-world-su, copy the JAR file to the ServiceMix deploy directory. As long as it starts up without error, you're ready to begin sending messages to it.
Configure hello-world-su
Create a file hello-world-su/src/main/resources/xbean.xml with the following contents:
<beans xmlns:hwse="http://org.apache.servicemix.samples.helloworld.se/1.0"
xmlns:xyz="http://companyxyz.com">
<hwse:endpoint service="xyz:helloWorld" endpoint="helloWorld"/>
</beans>
| TODO: explain |
Create a Service Unit for HTTP Binding Component
This service unit will configure the servicemix-http binding component so we can issue some soap-over-http requests for testing purposes.
$ mvn archetype:create \
-DarchetypeGroupId=org.apache.servicemix.tooling \
-DarchetypeArtifactId=servicemix-http-consumer-service-unit \
-DarchetypeVersion=3.2.1 \
-DgroupId=org.apache.servicemix.samples.helloworld.se \
-DartifactId=hello-world-http-su
There should now be a hello-world-http-su directory under hello-world-smx.
Configure hello-world-http-su
Create configuration for http binding component in hello-world-http-su/src/main/resources/xbean.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:http="http://servicemix.apache.org/http/1.0"
xmlns:hwse="http://org.apache.servicemix.samples.helloworld.se/1.0"
xmlns:xyz="http://companyxyz.com">
<http:endpoint service="xyz:helloWorld"
endpoint="helloWorld"
role="consumer"
locationURI="http://localhost:8192/Service/"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out" />
</beans>
| TODO: explain |
Create a service assembly to wrap all of the SUs
$ mvn archetype:create \
-DarchetypeGroupId=org.apache.servicemix.tooling \
-DarchetypeArtifactId=servicemix-service-assembly \
-DarchetypeVersion=3.2.1 \
-DgroupId=org.apache.servicemix.samples.helloworld.se \
-DartifactId=hello-world-sa
There should now be a hello-world-sa directory under hello-world-smx.
Add the following dependencies to hello-world-sa/pom.xml
<dependency>
<groupId>org.apache.servicemix.samples.helloworld.se</groupId>
<artifactId>hello-world-su</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.apache.servicemix.samples.helloworld.se</groupId>
<artifactId>hello-world-http-su</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
Build and Deploy the SA
The easiest way to build all the projects is to create a top level POM file that will tell Maven to build everything for you. The following section describes how to do this.
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://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<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-su</module>
<module>hello-world-http-su</module>
<module>hello-world-se</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-http-su hello-world-sa hello-world-se hello-world-su 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-se/pom.xml and replace <name>A custom project</name> with <name>Hello World SE 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 and the SU
Now that the SA is built, we're ready to deploy the Hello World SE, the dependency components and the Hello World SA to the JBI container.
$ cp hello-world-se/target/hello-world-se-1.0-SNAPSHOT-installer.zip $SERVICEMIX_HOME/install/
$ cp $SERVICEMIX_HOME/components/servicemix-shared-3.2.1-installer.zip $SERVICEMIX_HOME/install/
$ cp $SERVICEMIX_HOME/components/servicemix-http-3.2.1-installer.zip $SERVICEMIX_HOME/install/
$ cp hello-world-sa/target/hello-world-sa-1.0-SNAPSHOT.jar $SERVICEMIX_HOME/deploy/
This is a work in progress
End-to-End Testing
This is a work in progress
Additional Resources