We have been working with SOA technologies and solutions in the commercial and open-source arena for some years now and I would like to start a new series with this post covering the developments of two mayor standardisation efforts in this area, SCA (Service Component Architecture) and JBI (Java Business Integration).
While for some time SCA and JBI were presented and considered competitors, it is now a quite accepted idea in the industry that these standards cover different standardisation areas. They can be used separately but also used together to get the best of breed solutions.
SCA main benefit is that provides a technology-agnostic generic programming model that decouples the components implementation from their communication, allowing high level of reuse. Applications developed following the SCA model should be able to be deployed without changes in different SCA vendor platforms and following different integration and deployments patterns, depending on project needs. This would help to clearly separate application concerns, allowing developers to focus on services business logic while integration and deployment issues can be handled by architects and integrators.
In the other hand, JBI standarises a Java-based integration infrastructure where components of different vendors can interact in a standard fashion. In many ways, this standard is currently used to implement standarised ESBs and can provide the integration platform where SCA applications can run.
I was especially interested in solutions implementing the mix, offering SCA to provide the level of standardisation at application composition level while using JBI to provide the standard integration and runtime infrastructure, in the form of an Enterprise Service Bus (ESB). Examples of JBI implementations of ESBs are Apache ServiceMix, OpenESB or OW2 PEtALS.
In this area, we can find several efforts, mainly the Eclipse Swordfish project and OW2 PEtALS.
Eclipse Swordfish looks a very promising project, mixing JBI and OSGI to implement a fully distributed Enterprise Service Bus infrastructure where SCA-based applications can be run. However, at this moment SCA support is quite limited. OW2 PEtALS offers also a distributed ESB solution based on JBI only, and has a SCA service engine to run SCA composed applications based on OW2 Frascati. To know more about how this is implemented, have a look to this presentation from PEtALS guys.
So I decided to try and use OW2 PEtALS to run a simple SCA calculator, similar to the Apache Tuscany calculator sample. My objective was to verify the value of developing a SOA solution with SCA, using the integration features of JBI as a mediator ESB, exploring the possibilities of distributed ESB features and the extensibility via new JBI components, as JBI4Corba.
In order to follow this post, it will be helpful that you are familiar with the JBI and SCA concepts.
To support the development I used the latest Eclipse 3.5 Galileo fully loaded with SOA Tools, that include the SCA Tools. These tools provide a nice graphical environment to develop SCA composites as we will see.
Additionally, PEtALS offers a series of Eclipse plugins that make developer´s life easier for creating JBI Service Units (SU) and JBI Service Assemblies (SA). I was nicely surprised to see that they give the user the possibility to setup simple projects or maven projects. Also, it is nice to see the use of maven archetypes all over the place.
As you can imagine, I decided to go the maven way, making my life much easier. They offer a quite good developer manual providing all the information to setup the development environment.
So, the complete list of the required gear is:
Overview
We want to deploy a SCA Calculator implemented as Java components and deploy it in the PEtALS ESB (as depicted below), using a SOAP Binding Component to expose the application as a WS to the external world. We will use SOAPUI to test the application.
SCA Calculator exposed as SOAP WS in PEtALS.
In order to deploy this we need to configure and develop the following artifacts:
- Install necessary PEtALS components into the ESB, the SOAP BC and the SCA SE.
- Create a JBI Service Unit (SU Provide) containing the SCA composite to be deployed against the SCA SE.
- Create a JBI Service Unit (SU Consume) to expose the SCA composite via SOAP WS.
- Create a JBI Service Assembly (SA) containing the two SU, ready to be deployed into the ESB.
The complete sources of the article can be found here (Maven Projects).
Install necessary PEtALS components into the ESB
Starting with the quickstart PEtALS distribution makes everything really simple. You need to simply start the bus with the command:
<PETALS_QUICKSTART_HOME>/bin/startup.sh -C (Will start in console mode, very handy)
If you are in Windows there is a typo in the documentation and needs to be started with a lowercase -c.
To install the SOAP BC and the SCA SE is as simple as copying the two zip files for the components into the “install” directory of the PETALS_HOME. The components will be automatically deployed into the bus.
You can also deploy any BC, SE or SA using the terminal console or via the web console.
Make sure you read the limitations (e.g. redeployment of SU) and apply the required changes that are currently needed for the SCA Service Engine (i.e. isolatedClassLoader) as described in the documentation of the component
The webconsole will be available in http://localhost:7878/.
Let´s start with the difficult bit creating the SCA SU. The others, the SOAP SU and SA, will be very simple.
Create a JBI Service Unit (SU Provide) containing the SCA composite
Generate Maven Project
We can generate an empty maven Service Unit project in several ways, using maven archetypes from the command line of via the PEtALS Eclipse plugins. I found the Eclipse plugins more complete (see picture below) as they are able to create empty projects already targeted to work as consume/provide SU for existing PEtALS components.
PEtALS Eclipse plugins
For this SU, we need to define a new project that deploys into the SCA SE, therefore we need to select “Use PEtALS technical service -> Use SCA“.
You will have to fill some fields like name of the Composite (e.g. “Calculator”), the target namespace (e.g. “http://demo.sca.theserverlabs.com”).
This will create a maven project (you need to select it), let´s call the project “su-SCA-Calculator-provide”. You will need to fill the specific pom.xml entries related to the SU (i.e. groupId, modelVersion and version). Also, remove the parent definitions added by default.
Make sure to have a “description” on the pom.xml as it will be used later by the Service assembly to populate some fields.
Create SCA Composite
The wizard has already created the SCA composite, called “Calculator.composite” under “/src/main/jbi” directory. The composites must be defined in this directory so the files will be kept at root level of the SU when building the project, and not included in the jar file created with the SCA artifact code.
To associate a SCA Composite diagram to the xml configuration file, right click in the SCA composite file and select “SCA->Initialize SCA Composite Diagram file”. This will create a “.composite_diagram” file that will be always on sync with the xml configuration and viceversa.
Once the composite is created we can modify it via xml or via the designer. The SCA Composite for the Calculator would look something like this:
Calculator SCA Composite
As you can see our composite is very simple and has a CalculatorService which interface is exposed as a service out of the composite and has four references to other composite components, providing the add, subtract, divide and multiply implementations.
The SCA composite configuration file, would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:frascati="http://frascati.ow2.org" xmlns:sample="http://sample"
name="Calculator" targetNamespace="http://demo.sca.theserverlabs.com">
<service name="CalculatorService" promote="CalculatorServiceComponent/CalculatorService">
<interface.java interface="calculator.CalculatorService" />
<frascati:binding.jbi interfaceName="calculatorInterface"
interfaceNamespace="http://demo.sca.theserverlabs.com" serviceName="CompositeInterface"
serviceNamespace="http://demo.sca.theserverlabs.com" endpointName="calculatorPortType"
wsdl="calculator.wsdl" />
</service>
<component name="CalculatorServiceComponent">
<implementation.java class="calculator.CalculatorServiceImpl" />
<service name="CalculatorService">
<interface.java interface="calculator.CalculatorService" />
</service>
<reference name="addService" target="AddServiceComponent/addService">
<interface.java interface="calculator.AddService" />
</reference>
<reference name="subtractService" target="SubtractServiceComponent/substractService">
<interface.java interface="calculator.SubtractService" />
</reference>
<reference name="multiplyService" target="MultiplyServiceComponent/multiplyService">
<interface.java interface="calculator.MultiplyService" />
</reference>
<reference name="divideService" target="DivideServiceComponent/divideService">
<interface.java interface="calculator.DivideService" />
</reference>
</component>
<component name="AddServiceComponent">
<implementation.java class="calculator.AddServiceImpl" />
<service name="addService" />
</component>
<component name="SubtractServiceComponent">
<implementation.java class="calculator.SubtractServiceImpl" />
<service name="substractService" />
</component>
<component name="MultiplyServiceComponent">
<implementation.java class="calculator.MultiplyServiceImpl" />
<service name="multiplyService" />
</component>
<component name="DivideServiceComponent">
<implementation.java class="calculator.DivideServiceImpl" />
<service name="divideService" />
</component>
</composite>
Note that at the beginning of the file, the CalculatorService interface is promoted as a composite service. The SCA binding defined for this is the frascati JBI binding, which will register the service in the PEtALS bus as an internal JBI endpoint. The CalculatorService references are wired with the rest of the components via “target”.
Create required WSDL files for promoted SCA services
JBI message exchange Model is based on WSDL and as described in the SCA SE documentation, the SU package must contain a WSDL describing for each composite the promoted services. In our case, we need to provide a WSDL for the CalculatorService.
Currently, the WSDL must be provided in document/literal wrapped style and it is not automatically generated. However, there are tools like Java2WSDL of Apache axis that allow us to create it in a simple way.
The example apache axis command to generate the WSDL would be:
java org.apache.axis.wsdl.Java2WSDL -y WRAPPED -u LITERAL -l localhost calculator.CalculatorService
This will generate a WSDL that should be copied in the “/src/main/jbi” directory under the name provided in the composite file, section “frascati:binding.jbi”, in our case “calculator.wsdl”.
We need to do a few changes in the generated WSDL to make it to work:
- Change the request message definitions from for instance “addRequest” to “add”, so it complies to wsdl “wrapper” style, having the same name for the input wrapper as the operation name.
- Align this change for the operations port type and binding sections.
I don´t include the final WSDL file as it is a bit long. You can find it in the sources package.
Configure jbi.xml file
Everything is ready and we just need to define which services are provided or consumed by this SU. In this case, the SU provides Services, so the jbi.xml file would look like:
<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jbi="http://java.sun.com/xml/ns/jbi" xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-4.0"
xmlns:scaSU="http://petals.ow2.org/components/scaSU/version-1.0-SNAPSHOT">
<jbi:services binding-component="false">
<jbi:provides interface-name="calculatorNS:calculatorPortType"
service-name="calculatorNS:calculatorService" endpoint-name="calculatorServicePort"
xmlns:calculatorNS="http://demo.sca.theserverlabs.com">
<petalsCDK:wsdl>calculator.wsdl</petalsCDK:wsdl>
<scaSU:composite-file>Calculator.composite</scaSU:composite-file>
</jbi:provides>
</jbi:services>
</jbi:jbi>
For each provided service we need to define the interface-name, service-name and endpoint-name. It is important to match the calculator.wsdl binding definitions with this information. Therefore, interface-name must match the wsdl portype name and the endpoint-name must match the wsdl port..
We also need to inform PEtALS of which is the wsdl file that describes the service provided, and specifically for the SCA component, which is the composite file.
Build the project
The last step to do is to build the project with a simple:
Make sure you have included the PEtALS maven repository into your maven configuration, so it will find the required artifacts. This is well described in their development guide.
Create a JBI Service Unit (SU Consume) to expose the SCA composite via SOAP WS
This SU is much simpler. The component just needs the information for the JBI internal service that must consume and it will do the rest for us.
Using again the PEtALS Eclipse plugins, we create a new maven project (”New->Other->Petals->Expose Service from PEtALS->use SOAP”) called “su-SOAP-calculatorService-consume”. The wizard will allow you to define the Service you want to expose, so if you select the SCA SU Eclipse project, the rest of the fields will be automatically populated.
SOAP SU Consume Wizard
As previously done in the other SU, you will need to define the specific fields of the pom.xml related to this project, and don´t forget to define a “description” field.
This SU only contains the jbi.xml, defining which service must be exposed (consumed). We need to make sure that the consume section contains the references to the previously defined SCA SU. This would be the required jbi.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!--
JBI descriptor for the PEtALS' "petals-bc-soap" component (SOAP).
Originally created for the version 3.2 of the component.
-->
<jbi:jbi version="1.0"
xmlns:generatedNs="http://demo.sca.theserverlabs.com"
xmlns:jbi="http://java.sun.com/xml/ns/jbi"
xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-4.0"
xmlns:soap="http://petals.ow2.org/components/soap/version-3.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- Import a Service into PEtALS or Expose a PEtALS Service => use a BC. -->
<jbi:services binding-component="true">
<!-- Expose a PEtALS Service => consumes a Service. -->
<jbi:consumes
interface-name="generatedNs:calculatorPortType"
service-name="generatedNs:calculatorService"
endpoint-name="calculatorServicePort">
<!-- CDK specific elements -->
<petalsCDK:mep xsi:nil="true" />
<!-- Component specific elements -->
<soap:address>CalculatorService</soap:address>
<soap:remove-root>false</soap:remove-root>
<soap:mode>SOAP</soap:mode>
<soap:rest-add-namespace-prefix>soapbc</soap:rest-add-namespace-prefix>
</jbi:consumes>
</jbi:services>
</jbi:jbi>
All fields are defined at the moment of project creation. The only important thing to make sure is to provide in the “consumes” section, the proper the interface-name, service-name and endpoint-name. These must much the ones those defined in the SCA SU, so the can talk to each other. If you selected the SCA SU Eclipse project in the SOAP SU creation Wizard, all these fields should be already correctly filled.
Once this is done you can build the project with a maven install.
Create a JBI Service Assembly (SA) for deployment
The deployment in the JBI ESB is performed via Service Assemblies, which can contain many SUs, each one bounded to different components (BC, SE, etc…). In our case we have a the SCA SU bounded to the SCA SE Component and the SOAP SU bounded to the SOAP BC Component. This is defined in the jbi.xml of the Service Assembly.
As before, we can use the PEtALS Eclipse plugin to create an empty SA maven project (”New->Other-PEtALS->SA Maven Project”), called “sa-SCA-Calculator”. The wizard will allow as to add the SUs we want into the SA so no more configuration is needed.
Once created, as on previous artifacts we need to be defined in the pom.xml the specific project parameters. Make sure you defined a description.
The SA project defines the SUs to be included via standard maven dependencies. That´s the only configuration step to perform (automatically done by the wizard) and the jbi.xml will be automatically created. The pom.xml of the SA would then look like:
<?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">
<name>sa-SCA-Calculator</name>
<description>A description of sa-SCA-Calculator</description>
<version>1.0-SNAPSHOT</version>
<packaging>jbi-service-assembly</packaging>
<artifactId>sa-SCA-Calculator</artifactId>
<groupId>com.tsl.sca</groupId>
<modelVersion>4.0.0</modelVersion>
<dependencies>
<dependency>
<artifactId>su-SCA-Calculator-provide</artifactId>
<groupId>com.tsl.sca</groupId>
<version>1.0-SNAPSHOT</version>
<type>jbi-service-unit</type>
</dependency>
<dependency>
<artifactId>su-SOAP-calculatorService-consume</artifactId>
<groupId>com.tsl.sca</groupId>
<version>1.0-SNAPSHOT</version>
<type>jbi-service-unit</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.ow2.petals</groupId>
<artifactId>maven-petals-plugin</artifactId>
<!-- <version /> -->
<extensions>true</extensions><!--
<configuration>
<artifactNameMapping>${artifactId}</artifactNameMapping>
</configuration>
--></plugin>
</plugins>
</build>
</project>Run a maven install to build the SA.
Deploy SA into PEtALS
The generated zip file, “sa-SCA-Calculator-1.0-SNAPSHOT.zip”, just needs to be copied to the PETALS_HOME/install directory and the SA will be automatically installed and started.
The PEtALS console should show information regarding the compilation and creation of required classed for the SCA and SOAP SUs:
SCA Calculator deployed in PEtALS
Test the Service
The only thing left is to test that everything works. For that I used SOAUP, loading the WSDL from the SOAP WS services page (provided by the PEtALS component in http://localhost:8084/petals/services/CalculatorService?wsdl).
Testing SCA Calculator with SOAPUI
Future Posts
In future posts I will explore transparent deployment of SCA applications across a distributed ESB (such as PEtALS) and the usage of external references to services using Corba (e.g. replacing the add service by a external CORBA based service).
The later will also explore the usage of third party JBI components (as JBI4Corba) into PEtALS, as there is no PEtALS native JBI BC Component for Corba.
