The RiftSaw team is pleased to announce the availability of 2.0-M2.
This release provides early access to the new JAX-WS (using JBossWS) based integration, that replaces the Axis2 transport layer in the previous release, and the new admin console based on GWT.
This release is based on Apache ODE 1.3.3, and therefore if you had previously installed RiftSaw-2.0-M1, you will need to undeploy that version prior to installing M2. This is because M1 was based on the ODE 2.0 branch, which does not yet have a stable release. As the database schema changed between ODE1.x and ODE2.x, it will also be necessary to remove any database that had been configured for RiftSaw-2.0-M1 (BPELDB in the default/data folder if using derby).
Full release notes are available in the binary distribution.
Wednesday, November 25, 2009
Wednesday, November 18, 2009
Friday, November 13, 2009
Thursday, November 12, 2009
From ESB to BPEL - Continuing with the RiftSaw-JBossESB Integration
In the previous post to this blog, we looked at orchestrating JBossESB services from a RiftSaw BPEL process. In this post, we'll look at the other side of the RiftSaw-JBossESB integration; invoking a RiftSaw BPEL process from an ESB service.
Invoking a RiftSaw BPEL Process - From the JBossESB's Perspective, it's a Web Service
There are a couple of ways to do this. Remember, that from the JBossESB's perspective, a RiftSaw BPEL process is a web service. This means that a JBossESB service action can invoke a BPEL process in the same way that it can invoke any other web service that exposes a WSDL definition. There are multiple examples of this approach illustrated in the JBossESB quickstarts. For example, in the "webservice_consumer1" quickstart, the action used to invoke a web service is defined as:
In jboss-esb.xml:
But wait! We're not done yet. The RiftSaw-JBossESB integration also supports another way to invoke JBossESB service actions from a RiftSaw BPEL process without using HTTP, web services and WSDL.
A Different Way - the BPELInvoke Action
One of the JBossESB's features is an extensive set of predefined ("out of the box") actions that can be incorporated into your applications. These actions support a wide variety of tasks including:
JBossESB also supports a new out-of-the-box action that can be used to directly invoke a RiftSaw BPEL process. This action (org.jboss.soa.esb.actions.bpel.BPELInvoke) can be used if RiftSaw is installed and running in the same Java VM as the JBossESB and if the target BPEL process is deployed to the local RiftSaw instance. If your configuration meets these requirements, then it can be simpler to use the BPELInvoke action. You should also see better performance than using web services, as the RiftSaw BPEL process and JBossESB service actions are running in the same JVM.
The BPELInvoke action enables you to specify not just the RiftSaw process to be invoked, but also the specific operation within that process. You configure the BPELInvoke action with these properties:
BPELInvoke in a Quickstart
I can't say it often enough; the quickstarts are a great resource for learning how JBoss products work, and as a starting point for developing your own code. The BPELInvoke action is used in the "bpel_helloworld" quickstart. This quickstart is installed into your JBossESB server's /samples/quickstarts directory as part of the RiftSaw installations we walked through in this blog post: (hint - it's in step 6).
This quickstart relies on the riftsaw-2.0-SNAPSHOT/samples/quickstart/hello_world quickstart. Specifically, the bpel_helloworld quickstart invokes the RiftSaw BPEL process defined in the hello_world quickstart. So, before you run the bpel_helloworld quickstart, you have to deploy the hello_world quickstart.
The interesting part of the bpel_helloworld quickstart for us is this section of the jboss-esb.xml file:
Before we run the quickstart, there's one more thing to look at; the client. In the case of the quickstart, this is the SendEsbMessage.java program. This program is invoked when you execute the "ant sendesb" ant target as defined on lines 11-20 in the quickstart build.xml file:
The command parameters are passed to SendEsbMessage.java. If we look at line 18 in that program (see below), we'll see that the client sends a message and receives a response. (Remember that with BPEL, all traffic follows a synchronous message exchange pattern.)
OK, let's deploy and run the quickstart. Here are the ant commands and the output displayed by the client:
Closing Thoughts
The fact that from the ESB's perspective, a RiftSaw BPEL process is a web service, makes orchestrating ESB processes a straightforward task. The corollary is also true, in that a JBossESB action can also invoke a RiftSaw BPEL process in the same manner as a web service. It's also possible, however, to invoke a RiftSaw BPEL process with one of the JBossESB's out-of-the-box actions, BPELInvoke. In the next post to this blog, we'll look how exceptions are handled across the RiftSaw-JBossESB integration.
Acknowledgments
As always, I want to thank the RiftSaw community (especially Kurt Stam and Gary Brown), both for creating RiftSaw, writing the user guide on which this blog entry is based, and for their timely review input for this blog post!
Invoking a RiftSaw BPEL Process - From the JBossESB's Perspective, it's a Web Service
There are a couple of ways to do this. Remember, that from the JBossESB's perspective, a RiftSaw BPEL process is a web service. This means that a JBossESB service action can invoke a BPEL process in the same way that it can invoke any other web service that exposes a WSDL definition. There are multiple examples of this approach illustrated in the JBossESB quickstarts. For example, in the "webservice_consumer1" quickstart, the action used to invoke a web service is defined as:
In jboss-esb.xml:
<actions mep="OneWay">
<action name="request-mapper"
class="org.jboss.soa.esb.samples.quickstart.webservice_consumer1.MyRequestAction">
</action>
<action name="soapui-client-action"
class="org.jboss.soa.esb.actions.soap.SOAPClient">
<property name="wsdl"
value="http://127.0.0.1:8080/Quickstart_webservice_consumer1/HelloWorldWS?wsdl"/>
<property name="responseAsOgnlMap" value="true" />
<property name="SOAPAction" value="sayHello"/>
</action>
<action name="response-mapper"
class="org.jboss.soa.esb.samples.quickstart.webservice_consumer1.MyResponseAction">
</action>
<action name="testStore" class=
"org.jboss.soa.esb.actions.TestMessageStore"/>
</actions>
- Line 6: The SOAPClient class makes the call to the webservice.
- Line 9: The parameter responseAsOgnlMap tells the JBossESB move the SOAP reponse data into that OGNL-based map and attach it to the message.
- Line 10: The reference to the method to be invoked in the web service.
But wait! We're not done yet. The RiftSaw-JBossESB integration also supports another way to invoke JBossESB service actions from a RiftSaw BPEL process without using HTTP, web services and WSDL.
A Different Way - the BPELInvoke Action
One of the JBossESB's features is an extensive set of predefined ("out of the box") actions that can be incorporated into your applications. These actions support a wide variety of tasks including:
- Transformers and Converters - converting message data from one form to another
- Business Process Management - integrating with JBoss jBPM
- Scripting - automating tasks in supported scripting languages
- Services - integration with EJBs
- Routing - moving message data to the correct services
- Notifier - sending data to ESB unaware destinations
- Webservices/SOAP - the name says it all - support for Webservices
JBossESB also supports a new out-of-the-box action that can be used to directly invoke a RiftSaw BPEL process. This action (org.jboss.soa.esb.actions.bpel.BPELInvoke) can be used if RiftSaw is installed and running in the same Java VM as the JBossESB and if the target BPEL process is deployed to the local RiftSaw instance. If your configuration meets these requirements, then it can be simpler to use the BPELInvoke action. You should also see better performance than using web services, as the RiftSaw BPEL process and JBossESB service actions are running in the same JVM.
The BPELInvoke action enables you to specify not just the RiftSaw process to be invoked, but also the specific operation within that process. You configure the BPELInvoke action with these properties:
- service - This mandatory property references the service name, as defined in the WSDL, for the target RiftSaw BPEL process.
- operation - The name says it all. This mandatory property references the operation, also defined in the target Riftsaw BPEL process WSDL, to be invoked.
- requestPartName - This property defines the WSDL message part that the message content for the JBossESB-aware message processed by the JBossESB action should be mapped to. This property is optional and is used when the incoming JBossESB message does not already represent a multi-part message.
- responsePartName - And finally, this property is used to extract the content of a response multi-part WSDL message, and insert it into the JBossESB-aware message that is passed to the next JBossESB action in the action pipeline. This property is optional and if it is not defined, the complete multi-part message value will be used in the JBossESB-aware message.
- Document Object Model - If the content in the incoming message is a DOM document or element, then it can be used as the complete multi-part message, or as the content of a message part as defined with the optional requestPartName action property. If, however, the message content is a DOM text node, then it can only be used if a multi-part name has been defined in the optional requestPartName action property.
- Java String - If the content in the incoming message is a string representation of an XML document, then the requestPartName property is optional. If this property is not defined, then the document must represent the complete multipart message. If, however, the message content is a string that does not represent an XML document, then the requestPartName is not optional and must be specified.
BPELInvoke in a Quickstart
I can't say it often enough; the quickstarts are a great resource for learning how JBoss products work, and as a starting point for developing your own code. The BPELInvoke action is used in the "bpel_helloworld" quickstart. This quickstart is installed into your JBossESB server's /samples/quickstarts directory as part of the RiftSaw installations we walked through in this blog post: (hint - it's in step 6).
This quickstart relies on the riftsaw-2.0-SNAPSHOT/samples/quickstart/hello_world quickstart. Specifically, the bpel_helloworld quickstart invokes the RiftSaw BPEL process defined in the hello_world quickstart. So, before you run the bpel_helloworld quickstart, you have to deploy the hello_world quickstart.
The interesting part of the bpel_helloworld quickstart for us is this section of the jboss-esb.xml file:
<service
category="HelloWorldBPELESB"
name="SayHello"
description="Hello World">
<listeners>
<jms-listener name="JMS-Gateway"
busidref="quickstartGwChannel"
is-gateway="true" />
<jms-listener name="helloWorld"
busidref="quickstartEsbChannel" />
</listeners>
<actions>
<action name="action1" class="org.jboss.soa.esb.actions.SystemPrintln">
<property name="printfull" value="true"/>
</action>
<action name="action2" class="org.jboss.soa.esb.actions.bpel.BPELInvoke">
<property name="service" value="{http://www.jboss.org/bpel/examples/wsdl}HelloService"/>
<property name="operation" value="hello" />
<property name="requestPartName" value="TestPart" />
<property name="responsePartName" value="TestPart" />
</action>
<!-- The next action is for Continuous Integration testing -->
<action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
</actions>
</service>
- Line 16: Here's where we start the definition of the BPELInvoke action.
- Line 17: The service in the Riftsaw BPEL process to be invoked.
- Line 18: And the operation.
- Lines 19 and 20: The request and response WSDL parts.
Before we run the quickstart, there's one more thing to look at; the client. In the case of the quickstart, this is the SendEsbMessage.java program. This program is invoked when you execute the "ant sendesb" ant target as defined on lines 11-20 in the quickstart build.xml file:
<project name="Quickstart_esb_bpel_hello_world" default="run" basedir=".">
<description>
${ant.project.name}
${line.separator}
</description>
<!-- Import the base Ant build script... -->
<import file="../conf/base-build.xml"/>
<target name="sendesb" depends="compile"
description="Will send an esb Message">
<echo>Runs Test ESB Message Sender</echo>
<java fork="yes" classname="org.jboss.soa.esb.samples.quickstart.helloworld.test.SendEsbMessage" failonerror="true">
<arg value="HelloWorldBPELESB"/> <!-- service category -->
<arg value="SayHello"/> <!-- service name -->
<arg value="Hello World via ESB to BPEL"/> <!-- Message text -->
<classpath refid="exec-classpath"/>
</java>
</target>
</project>
The command parameters are passed to SendEsbMessage.java. If we look at line 18 in that program (see below), we'll see that the client sends a message and receives a response. (Remember that with BPEL, all traffic follows a synchronous message exchange pattern.)
public class SendEsbMessage
{
public static void main(String args[]) throws Exception
{
// Setting the ConnectionFactory such that it will use scout
System.setProperty("javax.xml.registry.ConnectionFactoryClass","org.apache.ws.scout.registry.ConnectionFactoryImpl");
if (args.length < 3)
{
System.err.println("Usage SendEsbMessage <category><name> <text to send>");
System.exit(1);
}
Message esbMessage = MessageFactory.getInstance().getMessage();
esbMessage.getBody().add(args[2]);
Message respMessage = new ServiceInvoker(args[0],args[1]).deliverSync(esbMessage, 5000);
System.out.println("REPLY: "+respMessage.getBody().get());
}
}
OK, let's deploy and run the quickstart. Here are the ant commands and the output displayed by the client:
And here's the information written to the server log )I've truncated this a bit...)
sendesb:
[echo] Runs Test ESB Message Sender
[java] REPLY: Hello World via ESB to BPEL World
BUILD SUCCESSFUL
Total time: 10 seconds
22:57:05,591 INFO [STDOUT] Message structure:OK, it's not exactly thrilling, but, if you look closely, you'll see that the client sent this message:
22:57:05,592 INFO [STDOUT] [ message: [ JBOSS_XML ]
.
.
.
context: {}
body: [ objects: {org.jboss.soa.esb.message.defaultEntry=Hello World via ESB to BPEL} ]
fault: [ ]
attachments: [ Named:{}, Unnamed:[] ]
properties: [ {org.jboss.soa.esb.message.byte.size=3920,
org.jboss.soa.esb.message.time.dod=Tue Nov 10 22:57:05 EST 2009,
javax.jms.message.redelivered=false} ] ]
Hello World via ESB to BPELAnd the RiftSaw BPEL process replied with this:
Hello World via ESB to BPEL WorldThat's right. The hello operation in the RiftSaw BPEL process did its thing and appended "World" to the message!
Closing Thoughts
The fact that from the ESB's perspective, a RiftSaw BPEL process is a web service, makes orchestrating ESB processes a straightforward task. The corollary is also true, in that a JBossESB action can also invoke a RiftSaw BPEL process in the same manner as a web service. It's also possible, however, to invoke a RiftSaw BPEL process with one of the JBossESB's out-of-the-box actions, BPELInvoke. In the next post to this blog, we'll look how exceptions are handled across the RiftSaw-JBossESB integration.
Acknowledgments
As always, I want to thank the RiftSaw community (especially Kurt Stam and Gary Brown), both for creating RiftSaw, writing the user guide on which this blog entry is based, and for their timely review input for this blog post!
Tuesday, November 3, 2009
From BPEL to the ESB and Back - Introduction to the Riftsaw-JBoss ESB Integration
One of the great strengths of the JBoss software is in the integrations between projects. In this post, we'll examine the Riftsaw - JBoss ESB integration to connect Riftsaw BPEL processes to ESB services.
Background - JBosssESB
Service Oriented Architecture (SOA) is not a single program or technology. It’s really a matter of software architecture or design. In hardware terms, a “bus” is a physical connector that ties together multiple systems or subsystems. Instead of having a large number of point-to-point connectors between pairs of systems, you connect each system to the bus once. An Enterprise Service Bus (ESB) does the same thing, logically, in software.
Instead of passing electric current or data over the bus to and from the connections (or “endpoints”) on the ESB, the ESB logically sits in the architectural layer above a messaging system. The messaging system allows for asynchronous communications between services over the ESB. In fact, when you are working with an ESB, everything is either a service (which in this context is your application software) or a message being sent between services. It’s important to note that a “service” is not automatically a web service. Other types of applications, using transports such as FTP or JMS, can also be services. Is an ESB the same thing as SOA (Service Oriented Architecture)? Not exactly. An ESB does not provide a Service Oriented Architecture, but it does provide the tools than can be used to build one–especially loose-coupling and asynchronous message passing. SOA is a series of principles, patterns, and best practices.
JBossESB[1] is an open source ESB implementation that supports multiple transports, protocols, a listener-action model for loose coupling of services, content based routing with JBoss Rules (Drools), and BPEL process management with Riftsaw.
The Riftsaw-JBoss ESB Integration
In reviewing the Riftsaw-JBossESB integration, the three topics to consider are:
We'll take these topics one at a time. Let's start with: Orchestrating ESB Services From BPEL in Riftsaw to the ESB.
You might think that a feature as powerful as the orchestration of ESB services would be difficult to configure, but actually, it's very straightforward. Remember that from the JBoss ESB's perspective, the BPEL process is a web service. The ESB can receive messages from a Riftsaw BPEL process just as it would from any web service. Let's illustrate this by modifying the Riftsaw BPEL "hello_world" quickstart to orchestrate a service as defined by the JBoss ESB "helloworld" quickstart.
Modifying the Quickstarts
In the BPEL "hello_world" quickstart process definition, we have to modify this file:
File: samples/quickstart/hello_world/bpel/HelloWorld.wsdl
The change to note is on line 58: Since we want the ESB application to define a listener to "listen" for incoming http traffic, we have to change the port for the BPEL process to not conflict with the JBoss AS server itself. We've selected port 8081 as the new port for the BPEL process. Remember, that as far as the ESB is concerned, the BPEL process is a web service.
In the JBoss ESB "helloworld" quickstart, we have to modify these 4 files:
File: jbossesb-4.6/samples/quickstarts/helloworld/jboss-esb.xml
The fact that from the ESB's perspective, a Riftsaw BPEL process is a web service, makes orchestrating ESB processes a straightforward task. In the next post to this blog, we look going back the other way and making calls from the JBossESB to a BPEL process definition in Riftsaw.
References
As always, I want to thank the Riftsaw community (especially Kurt Stam and Gary Brown), both for creating Riftsaw (and its documentation and examples) and for their timely review input for this blog post.
Background - JBosssESB
Service Oriented Architecture (SOA) is not a single program or technology. It’s really a matter of software architecture or design. In hardware terms, a “bus” is a physical connector that ties together multiple systems or subsystems. Instead of having a large number of point-to-point connectors between pairs of systems, you connect each system to the bus once. An Enterprise Service Bus (ESB) does the same thing, logically, in software.
Instead of passing electric current or data over the bus to and from the connections (or “endpoints”) on the ESB, the ESB logically sits in the architectural layer above a messaging system. The messaging system allows for asynchronous communications between services over the ESB. In fact, when you are working with an ESB, everything is either a service (which in this context is your application software) or a message being sent between services. It’s important to note that a “service” is not automatically a web service. Other types of applications, using transports such as FTP or JMS, can also be services. Is an ESB the same thing as SOA (Service Oriented Architecture)? Not exactly. An ESB does not provide a Service Oriented Architecture, but it does provide the tools than can be used to build one–especially loose-coupling and asynchronous message passing. SOA is a series of principles, patterns, and best practices.
JBossESB[1] is an open source ESB implementation that supports multiple transports, protocols, a listener-action model for loose coupling of services, content based routing with JBoss Rules (Drools), and BPEL process management with Riftsaw.
The Riftsaw-JBoss ESB Integration
In reviewing the Riftsaw-JBossESB integration, the three topics to consider are:
- Orchestrating ESB Services From BPEL in Riftsaw to the ESB
- Making Calls From the ESB to the BPEL process definition in Riftsaw
- Exception Handling
We'll take these topics one at a time. Let's start with: Orchestrating ESB Services From BPEL in Riftsaw to the ESB.
You might think that a feature as powerful as the orchestration of ESB services would be difficult to configure, but actually, it's very straightforward. Remember that from the JBoss ESB's perspective, the BPEL process is a web service. The ESB can receive messages from a Riftsaw BPEL process just as it would from any web service. Let's illustrate this by modifying the Riftsaw BPEL "hello_world" quickstart to orchestrate a service as defined by the JBoss ESB "helloworld" quickstart.
Modifying the Quickstarts
In the BPEL "hello_world" quickstart process definition, we have to modify this file:
File: samples/quickstart/hello_world/bpel/HelloWorld.wsdl
1 <?xml version="1.0" encoding="utf-8" ?>
2 <!--
3 ~ Licensed to the Apache Software Foundation (ASF) under one
4 ~ or more contributor license agreements. See the NOTICE file
5 ~ distributed with this work for additional information
6 ~ regarding copyright ownership. The ASF licenses this file
7 ~ to you under the Apache License, Version 2.0 (the
8 ~ "License"); you may not use this file except in compliance
9 ~ with the License. You may obtain a copy of the License at
10 ~
11 ~ http://www.apache.org/licenses/LICENSE-2.0
12 ~
13 ~ Unless required by applicable law or agreed to in writing,
14 ~ software distributed under the License is distributed on an
15 ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
16 ~ KIND, either express or implied. See the License for the
17 ~ specific language governing permissions and limitations
18 ~ under the License.
19 -->
20 <wsdl:definitions
21 targetNamespace="http://www.jboss.org/bpel/examples/wsdl"
22 xmlns="http://schemas.xmlsoap.org/wsdl/"
23 xmlns:tns="http://www.jboss.org/bpel/examples/wsdl"
24 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
25 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
26 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
27 xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype">
28
29 <wsdl:message name="HelloMessage">
30 <wsdl:part name="TestPart" type="xsd:string"/>
31 </wsdl:message>
32
33 <wsdl:portType name="HelloPortType">
34 <wsdl:operation name="hello">
35 <wsdl:input message="tns:HelloMessage" name="TestIn"/>
36 <wsdl:output message="tns:HelloMessage" name="TestOut"/>
37 </wsdl:operation>
38 </wsdl:portType>
39
40 <wsdl:binding name="HelloSoapBinding" type="tns:HelloPortType">
41 <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
42 <wsdl:operation name="hello">
43 <soap:operation soapAction="" style="rpc"/>
44 <wsdl:input>
45 <soap:body
46 namespace="http://www.jboss.org/bpel/examples/wsdl"
47 use="literal"/>
48 </wsdl:input>
49 <wsdl:output>
50 <soap:body
51 namespace="http://www.jboss.org/bpel/examples/wsdl"
52 use="literal"/>
53 </wsdl:output>
54 </wsdl:operation>
55 </wsdl:binding>
56 <wsdl:service name="HelloService">
57 <wsdl:port name="HelloPort" binding="tns:HelloSoapBinding">
58 <soap:address location="http://localhost:8081/bpel/processes/helloWorld"/>
59 </wsdl:port>
60 </wsdl:service>
61
62 <plnk:partnerLinkType name="HelloPartnerLinkType">
63 <plnk:role name="me" portType="tns:HelloPortType"/>
64 <plnk:role name="you" portType="tns:HelloPortType"/>
65 </plnk:partnerLinkType>
66 </wsdl:definitions>
The change to note is on line 58: Since we want the ESB application to define a listener to "listen" for incoming http traffic, we have to change the port for the BPEL process to not conflict with the JBoss AS server itself. We've selected port 8081 as the new port for the BPEL process. Remember, that as far as the ESB is concerned, the BPEL process is a web service.
In the JBoss ESB "helloworld" quickstart, we have to modify these 4 files:
File: jbossesb-4.6/samples/quickstarts/helloworld/jboss-esb.xml
The changes are:
1 <?xml version = "1.0" encoding = "UTF-8"?>
2 <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">
3
4 <providers>
5 <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
6 <jms-bus busid="quickstartGwChannel">
7 <jms-message-filter
8 dest-type="QUEUE"
9 dest-name="queue/quickstart_helloworld_Request_gw"
10 />
11 </jms-bus>
12 <jms-bus busid="quickstartEsbChannel">
13 <jms-message-filter
14 dest-type="QUEUE"
15 dest-name="queue/quickstart_helloworld_Request_esb"
16 />
17 </jms-bus>
18
19 <jms-bus busid="quickstartEsbReplyChannel">
20 <jms-message-filter
21 dest-type="QUEUE"
22 dest-name="queue/quickstart_helloworld_Request_esb_reply"
23 />
24 </jms-bus>
25
26
27 </jms-provider>
28
29 <jbr-provider name="JBR-Http-1" protocol="http" host="localhost">
30 <jbr-bus busid="Http-1" port="8081"/>
31 </jbr-provider>
32 </providers>
33
34 <services>
35 <service
36 category="FirstServiceESB"
37 name="SimpleListener"
38 description="Hello World">
39
40 <listeners>
41 <jms-listener name="JMS-Gateway"
42 busidref="quickstartGwChannel"
43 is-gateway="true"
44 />
45 <jms-listener name="helloWorld"
46 busidref="quickstartEsbChannel"
47 />
48 <jbr-listener name="Http-Gateway" busidref="Http-1" is-gateway="true"/>
49
50 </listeners>
51
52 <actions mep="RequestResponse">
53 <action name="action1"
54 class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction"
55 process="displayMessage"
56 />
57 <action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
58 <property name="printfull" value="false"/>
59 </action>
60 <!-- The next action is for Continuous Integration testing -->
61 <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
62 </actions>
63 </service>
64 </services>
65
66 </jbossesb>
- Lines 29-31, and 48: Here's where we define the HTTP gateway listener that will watch for the message (request) sent by the BPEL process.
- Line 52: This is an important change. In the original ESB helloworld quickstart, the message exchange pattern (mep) was set to "OneWay." In our modified quickstart, we need to have a response sent back to the BPEL process to complete the request/response sequence.
- Lines 19-23: What's this all about? For each ESB-unaware gateway channel, the ESB requires a corresponding ESB-aware channel. In this context, "ESB-aware" refers to a channel communicating via messages in the org.jboss.soa.esb.message.Message format, and "ESB-unaware" refers to communicating via messages in a format other than (org.jboss.soa.esb.message.Message). We also have to add this ESB-aware channel to these files:
1 <jbossesb-deployment>File: jbossesb-4.6/samples/quickstarts/helloworld/jbm-queue-service.xml
2 <depends>jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb_reply</depends>
3 <depends>jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb</depends>
4 <depends>jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_gw</depends>
5 </jbossesb-deployment>
1 <?xml version="1.0" encoding="UTF-8"?>Finally, we have to modify build.xml to reference the changed port number for the web services - only one line is changed:
2 <server>
3
4 <mbean code="org.jboss.jms.server.destination.QueueService"
5 name="jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb_reply"
6 xmbean-dd="xmdesc/Queue-xmbean.xml">
7 <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
8 <depends>jboss.messaging:service=PostOffice</depends>
9 </mbean>
10
11 <mbean code="org.jboss.jms.server.destination.QueueService"
12 name="jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb"
13 xmbean-dd="xmdesc/Queue-xmbean.xml">
14 <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
15 <depends>jboss.messaging:service=PostOffice</depends>
16 </mbean>
17 <mbean code="org.jboss.jms.server.destination.QueueService"
18 name="jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_gw"
19 xmbean-dd="xmdesc/Queue-xmbean.xml">
20 <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
21 <depends>jboss.messaging:service=PostOffice</depends>
22 </mbean>
23 </server>
33 <arg value="http://localhost:8081/bpel/processes/helloWorld"/>After we deploy both the quickstarts, we can initiate the ESB service orchestration by executing the "ant sendhello" command for the Riftsaw BPEL hello_world process. The server log shows this output:
22:38:51,690 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&And the Riftsaw BPEL hello_world process client shows this output:
22:38:51,700 INFO [STDOUT] Body: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.jboss.org/bpel/examples/wsdl">
<soapenv:Header/>
<soapenv:Body>
<wsdl:hello>
<TestPart>Hello</TestPart>
<TestPart2>Hello</TestPart2>
</wsdl:hello>
</soapenv:Body>
</soapenv:Envelope>
22:38:51,701 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
22:38:51,716 INFO [STDOUT] Message structure:
22:38:51,716 INFO [STDOUT] [<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.jboss.org/bpel/examples/wsdl">
<soapenv:Header/>
<soapenv:Body>
<wsdl:hello>
<TestPart>Hello</TestPart>
<TestPart2>Hello</TestPart2>
</wsdl:hello>
</soapenv:Body>
</soapenv:Envelope>
$ ant sendhelloClosing Thoughts
Buildfile: build.xml
sendhello:
[echo] Send test message to: Quickstart_bpel_hello_world
[java] <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.jboss.org/bpel/examples/wsdl">
[java] <soapenv:Header/>
[java] <soapenv:Body>
[java] <wsdl:hello>
[java] <TestPart>Hello</TestPart>
[java] <TestPart2>Hello</TestPart2>
[java] </wsdl:hello>
[java] </soapenv:Body>
[java] </soapenv:Envelope>
[java]
[java]
BUILD SUCCESSFUL
Total time: 2 seconds
The fact that from the ESB's perspective, a Riftsaw BPEL process is a web service, makes orchestrating ESB processes a straightforward task. In the next post to this blog, we look going back the other way and making calls from the JBossESB to a BPEL process definition in Riftsaw.
References
- [1] http://www.jboss.org/jbossesb
- [2] http://jboss-soa-p.blogspot.com/2009/06/hanging-together-on-soa-platform.html
As always, I want to thank the Riftsaw community (especially Kurt Stam and Gary Brown), both for creating Riftsaw (and its documentation and examples) and for their timely review input for this blog post.
Subscribe to:
Posts (Atom)