JBossESB

The JBoss ESB Beginner's Guide is officially published today!

2012-01-25T06:08:00.000-08:00

It's available at Packt now! http://www.packtpub.com/jboss-esb-beginners-guide/book

And at Amazon: http://www.amazon.com/JBoss-ESB-Beginners-Guide-DiMaggio/dp/1849516588/

A review of the book is here: http://rickwagner.blogspot.com/2011/10/book-review-for-jboss-esb-beginners.html

Packt Survey for JBoss Books - and a discount

2011-12-07T11:32:00.001-08:00

Packt, the folks publishing the JBoss ESB Begineers' Guide later on this month, have a new survey for JBoss users and books.

The survey is here: http://snipurl.com/21212r0

Packt is overseeing a community survey for JBoss users to find out what support they need to aid and enhance their JBoss experience. Packt want to make sure they are making the right offers to all JBoss users and are providing what they need and want.

The survey is about all of JBoss projects (Drools, AS, jBPM and more). The questions will help to provide a snapshot of how the community finds support, how they self-educate, help each other and what information they need now.As Packt think the results will be of genuine interest to the JBoss community, the results of the survey will be published.

Not only that but every JBoss user that completes the survey will receive a 25% discount off their next JBoss eBook purchase from Packt

JBoss ESB Book - in the Packt RAW Program

2011-09-29T20:08:00.000-07:00

And, the soon-to-be-published (by Packt) JBoss ESB Beginner's Guide is now in the Packt "RAW" program - so that the book can be purchased pre-release - and chapters are provided as they are completed.

http://www.packtpub.com/jboss-esb-beginners-guide/book

The JBoss ESB Guide is on Amazon

2011-09-12T17:23:00.000-07:00

And - the soon-to-be-published book just appeared on Amazon:

JBoss ESB Beginners Guide

JBoss ESB Beginner's Guide - Expected in November

2011-08-18T11:33:00.000-07:00

Packt is publishing the "JBoss ESB Beginner's Guide" in November!

http://www.packtpub.com/jboss-esb-beginners-guide/book

ESB 4.10 Released

2011-07-08T08:03:00.000-07:00

We are happy to announce the 4.10 release of JBoss ESB. It is now available for download at our project site listed below. The major features of this release are as follows:

Support for JBoss AS 6.0.0.Final
Drools 5.2.0
jUDDI 3.1.0 and the inclusion of the juddiv3.war
Scout 1.2.3
Smooks 1.4

and numerous bug fixes.

The project site is updated with binaries and documentation:

http://jboss.org/jbossesb/downloads.html
http://jboss.org/jbossesb/docs.html

Thanks to everyone who contributed to this release for your hard work!

Two JBossESB blog posts were just reposted to Dzone

2010-02-24T17:52:00.000-08:00

And, here they are:

"From HTTP to the ESB - JBossESB 4.7's New Servlet based HTTP Gateway," http://architects.dzone.com/news/jbossesb-http-gateways

"Message Alerts in JBossESB 4.7," http://soa.dzone.com/news/messagealerts-jbossesb-47

JBoss Tools Smooks Editor - Progress...

2010-01-15T02:43:00.000-08:00

We've been making some good progress with the JBoss Tools Smooks Editor. The following are two rough Screencasts (audio is poorly edited... apologies) illustrating two use cases that extend from each other.

EDI to Java

In this Screencast, we bind EDI Purchase Order data (but can also be XML, JSON etc) into an "Order" object model (Java). This Screencast was created a few weeks ago, using the v3.1.0.CR1 release of JBoss Tools.

See Screencast

EDI to XML (via XSD)

In this Screencast, we extend the example shown in the above Screencast, applying a template to the "Order" object model to produce an XML Purchase Order. The XML Purchase Order is defined in an XML Schema (XSD), but you'll see how the editor makes it very easy to work with the XSD. This Screencast was created recently, using one of the Nightly Builds of JBoss Tools.

See Screencast

Status

We are currently working towards the v3.1.0.CR2 release of JBoss Tools, which is due to be released in Feb (not sure of exact date). There are still a number of issues with the editor. We are working on these and will be resolving many of them for the 3.1.0.CR2 release.

We have purposely restricted the 3.1.0 version of the editor:

Supported Use Cases:
- Java Mapping/Binding: Drag & Drop mapping/binding of XML, JSON, CSV and EDI data to Java.
- CSV and XML Templating: Drag & Drop templating of Java Mappings (see #1 above) to produce CSV or XML (XML via XSD or XML Sample).
Supported Integration:
- JBoss Tools ESB Editor: Will have basic open and edit integration with the ESB SmooksAction.
Supported Versions:
- Smooks v1.2 Configurations: The Editor will only support Smooks v1.2 configuration namespaces. Therefore, if you have configurations using config namespaces from earlier (or newer v1.3) versions of Smooks, the editor will not open the configurations.

So, the editor will not support:

Direct Source to Result drag & drop templating e.g. XML to XML, EDI to XML, XML to CSV etc. We hope to support this in a future release (next one hopefully), but for now (in the v3.1.0 release), you need to define a Java Object model to use as the canonical form of the data being mapped i.e. v3.1.0 templating works as Source -> Java -> Result.
A number of features supported by the Smooks Runtime, such as Persistence, Validation etc. We will be adding support for these in future releases.
Smooks v1.1 (and before) configuration namespaces that have newer versions in Smooks v1.2. For example, Smooks v1.2 added a v1.2 javabean config namespace. It is this version of the javabean config namespace that is supported by the editor. The v1.1 javabean config namespace is not supported.
Smooks v1.3 (yet to be released) configuration namespaces.

Try it Out...

Please take the editor for a spin and let us know what you think. It can be downloaded (standalone, or as part of JBoss Tools) from the JBoss Tools Downloads Page. Please log any issues you find with the editor (against the "smooks" component), if not already logged.

From HTTP to ESB - JBossESB 4.7's New Servlet based HTTP Gateway

2009-12-22T18:13:00.000-08:00

One of the primary functions performed by JBossESB is the routing of messages between services. (Remember that, on an ESB, everything is either a message or a service.) The messages that JBoss ESB handles conform to org.jboss.soa.esb.message.Message. Service endpoints that can process messages in this format are described as being "ESB-aware." This is all well and good for services and applications that were designed and written with this message format in mind, but what about other services, including legacy applications, that communicate through other non-ESB aware data formats?

JBossESB handles connecting services that communicate in non-ESB aware message formats through its gateway listeners. These listeners route incoming messages from outside the ESB to ESB services. The ESB's set of gateway listeners (generally referred to as "gateways") support a variety of message formats such as files, FTP, and JMS. These gateways accept messages in a non-ESB aware format onto the ESB and then convert them (actually, they wrap the message payload) into ESB-aware messages before sending them to their service's action pipeline.

In this post, we'll take a look at JBossESB 4.7's new HTTP gateway ("http-gateway" ). [1]

You use an http-gateway to "expose" an ESB-unaware endpoint on the ESB. In other words, an http-gateway enables you to communicate to ESB services through HTTP endpoints, in the familiar format used by Java servlets. This servlet-based approach is made possible by the http-gateway leveraging the JBossESB Server or JBoss Application Server's HTTP container, just as any servlet would. This means that many of the HTTP configuration properties such as port addresses are already handled for you. You don't have to create the entire HTTP configuration for your http-gateway, as many configurations work right out-of-the-box. This is in keeping with other features of JBossESB, such as its rich set of out-of-the-box actions. [2]

A Very Basic Example

Let's take a quick look at a very basic http-gateway configuration. We'll take a longer look at variations of http-gateway usage later on in this post. To begin, let's start small. Here's a service definition taken from the JBossESB user guide [3] that you would create in your JBossESB application's jboss-esb.xml file:

1:  <service category="Vehicles" name="Cars" description="" invmScope="GLOBAL">
2:     <listeners>
3:       <http-gateway name="Http" />
4:    </listeners>
5:    <actions mep="RequestResponse">
6:    <!-- Service Actions.... -->
7:    </actions>
8:  </service>

Like a lot of things with JBossESB, you can do a lot with a little. Let's examine this example line-by-line:

Line 1: Service name and category are used to differentiate the services. Every service has a category and name attribute. JBossESB uses these attributes to register a service's listeners (gateway listeners or ESB-aware listeners) endpoints in a service registry. The InVM transport enables services to communicate using the same JVM and without having to go through a second non-gateway provider. This makes things more efficient as the services don't have use any networking protocols between JVM instances. The "GLOBAL" value indicates that the this service can be invoked using the InVM transport using the same JVM.
Line 3: Here's the definition of the http gateway.
Line 5: Remember that since the gateway is servlet based, it requires a request/response message exchange pattern (or "mep" for short).
Line 6: And, here's where the pipeline of actions would be defined.

Simple, right? Before we move on, did you notice what's not here? Dude, where's my service provider?

Since a provider is not defined, the service uses a the ESB's default HTTP provider. And, since there is no bus reference ID (the busrefid element in a provider definition and then referenced elsewhere in jboss-esb.xml files), the ESB builds the HTTP endpoint that it exposes out of these fields:

1:     http://<host>:<port>/<.esbname>/http/Vehicles/Cars

The host and port number come from the ESB server. The "<.esbname>" token is the actual name of the deployed .esb archive, minus the .esb extension. Note that while this string is an HTTP URL, it's also an endpoint. The prefix of "http" is actually a namespace that is used for all the http-gateway endpoints.

It's also important to note that the http-gateway listener captures all incoming HTTP requests that match the servlet mapping pattern expressed in the HTTP endpoint. You can make use of this mapping with the gateway's "urlPattern" property. For example, if we modify the service and gateway definition that we just looked at to include a urlPattern:

1:  <service category="Vehicles" name="Cars" description="" invmScope="GLOBAL">
2:    <listeners>
3:      <http-gateway name="Http" urlPattern="esb-cars/*" />
4:    </listeners>
5:    <actions mep="RequestResponse">
6:    <!-- Service Aactions.... -->
7:    </actions>
8:  </service>

Then, the service's exposed HTTP endpoint would capture incoming HTTP requests at this address:

1:    http://<host>:<port>/<.esbname>/http/esb-cars/*

Creating a Message From a Request

How does the http-gateway actually convert an incoming HTTP request into an ESB message? It depends on the request's MIME type. What controls this is the “core:org.jboss.soa.esb.mime.text.types” configuration property. This property is defined in your server's jbossesb-properties.xml as a semi-colon separated list of character MIME types. The default value of the property includes wildcard support and is set equal to this set:

text/*
application/xml
application/*-xml

The http-gateway uses this property to determine whether the request payload should be decoded into a Java String before it's given to the service, or if the payload should stay as a Byte array, and have the Service perform the decoding itself in an action. The http-gateway can also over-ride the default MIME type with the "payloadAs" attribute. This attribute enables you to have the gateway treat the payload as either “BYTES” or “STRING.” For text payloads, the gateway uses the same character encoding from the request.

What about the other information in the incoming HTTP request?

The request parameters are contained in the RequestParameterMap (a java.util.Map). These request query string parameters are stored as message properties on the ESB message created by the gateway. Full access to the URL arguments/query string is supported in that you can access the parameters in your service's actions by:

1:  Map params = (Map) message.getProperties().getProperty(“RequestParameterMap”);

The RequestInfoMap is another java.util.Map that contains request information such as authType, characterEncoding, HTTP Method, remoteHost, contentLength, etc.. You can access the parameters in your service's actions by:

1:  Map params = (Map) message.getProperties().getProperty(“RequestInfoMap”);

Let's switch gears now and look at a more extensive example.

The http_gateway Quickstart Example

JBossESB release 4.7 includes the aptly named "http_gateway" quickstart example application. (As I always tell people, the quickstarts included with JBossESB are both a great learning tool and a great starting point for developing your own ESB applications.) The http_gateway quickstart demonstrates multiple ways of using the gateway to pass HTTP requests onto ESB services:

Basic authentication
The default http bus
Mapping ESB exceptions to HTTP error codes globally for an http-provider...
...and how to over-ride that global setting
Setting up an asynchronous response that changes the default response code
Message-Level Security

We'll take these one at a time.

Basic Authentication

The quickstart uses the "java:/jaas/JBossWS" security domain, which is already installed in JBoss ESB/App Server out-of-the-box configuration. The login username is "kermit" and the password is "thefrog". You can see this username/password combination defined in the "server/[server profile]/conf/props/jbossws-roles.properties" file. Let's take a look at the security setting in the quickstart's jboss-esb.xml file:

1:  <globals>
2:    <!-- Security setting for all http-providers and all EBWSs in this jboss-esb.xml file.-->
3:    <war-security method="BASIC" domain="JBossWS" />
4:  </globals>

This "global" section is new with the http-gateway in JBossESB 4.7. Like the comment says, this defines the global security setting for all the http and EBWS providers in this application. The other supported settings for the war-security method are: DIGEST [4] and CLIENT-CERT.

And here's the http-provider definition:

1:  <http-provider name="http">
2:    <http-bus busid="secureFriends">
3:    <!-- Only users in the "friend" role are allowed
4:    access via the "GET" method. Unspecified
5:    methods are not protected (i.e. are allowed)... -->
6:      <allowed-roles>
7:        <role name="friend" />
8:      </allowed-roles>
9:      <protected-methods>
10:        <method name="GET" />
11:        <method name="POST" />
12:      </protected-methods>
13:    </http-bus>
14:    <!-- Global exception mappings file... -->
15:    <exception mappingsFile="/http-exception-mappings.properties" />
16:  </http-provider>

In this file fragment we see:

Line 2: Here's where the http-bus definition starts. Note the name chosen for the busid ("secureFriends"). We'll reference this in the definition of the http-gateway in a moment.
Line 5: The set of allowed roles starts here.
Line 8: And the set of HTTP methods that user in the allowed roles can use is defined here. Note that the http-gateway supports using these HTTP methods: GET, PUT, POST and DELETE
Line 14: Here's another global (global to the http-provider, that is) definition. We'll come back to the exception mappingsFile in a bit. This definition enables you to define status codes to be returned for exceptions.

Now, let's look at the actual http-gateway definition:

1:  <service category="Sales" name="List" description="" invmScope="GLOBAL">
2:    <listeners>
3:      <!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
4:      authenticate because the "sales" bus has basic auth configured (above)... -->
5:      <http-gateway name="sales" busidref="secureFriends" urlPattern="sales/*" />
6:    </listeners>
7:    <actions mep="RequestResponse">
8:      <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
9:    </actions>
10:  </service>

Here's where it all ties together:

Line 1: The service definition begins here. Note the "GLOBAL InVM scope that we talked about earlier.
Line 5: The http-gateway definition is here. Note the reference to the busidref that we defined in the http-bus. Also note the urlPattern. We'll use this pattern when we run the quickstart.
Line 6: The message exchange pattern (mep) is RequestResponse as, remember we're dealing with HTTP.
Line 7: Our customer action. This class prints out informatin from the request.

OK - let's run the quickstart and see the results.

Where's the client program that we run? Well, this quickstart is different from most of the other quickstarts in that you don't initial the test by generating a message. Remember how the http-provider we defined specified the GET and POST HTTP verbs? To run this part of the quickstart, you can just fire up your favorite browser and send an HTTP GET request by entering this URL:

http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c

For the sake of illustration, we'll use the lynx (text) browser.

1:  lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c
2:  Service: Sales:List
3: 
4:  ------------Http Request Info (XStream Encoded)-------------------
5:  <org.jboss.soa.esb.http.HttpRequest>
6:   <authType>BASIC</authType>
7:   <contextPath>/Quickstart_http_gateway</contextPath>
8:   <localAddr>127.0.0.1</localAddr>
9:   <localName>localhost.localdomain</localName>
10:   <method>GET</method>
11:   <pathInfo>/a/b/c</pathInfo>
12:   <protocol>HTTP/1.0</protocol>
13:   <remoteAddr>127.0.0.1</remoteAddr>
14:   <remoteHost>127.0.0.1</remoteHost>
15:   <remoteUser>kermit</remoteUser>
16:   <contentLength>-1</contentLength>
17:   <requestURI>/Quickstart_http_gateway/http/sales/a/b/c</requestURI>
18:   <scheme>http</scheme>
19:   <serverName>localhost</serverName>
20:   <requestPath>/http/sales</requestPath>
21:   <pathInfoTokens>
22:    <string>a</string>
23:    <string>b</string>
24:    <string>c</string>
25:   </pathInfoTokens>
26:   <queryParams/>
27:   <headers>
28:    <org.jboss.soa.esb.http.HttpHeader>
29:     <name>host</name>
30:     <value>localhost:8080</value>
31:    </org.jboss.soa.esb.http.HttpHeader>
32:    <org.jboss.soa.esb.http.HttpHeader>
33:     <name>accept</name>
34:     <value>text/html, text/plain, audio/mod, image/*, application/msword, application/pdf, application/postscript, application/x-java-jnlp-file, text/sgml, video/mpeg, */*;q=0.01</value>
35:    </org.jboss.soa.esb.http.HttpHeader>
36:    <org.jboss.soa.esb.http.HttpHeader>
37:     <name>accept-language</name>
38:     <value>en</value>
39:    </org.jboss.soa.esb.http.HttpHeader>
40:    <org.jboss.soa.esb.http.HttpHeader>
41:     <name>user-agent</name>
42:     <value>Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8e-fips-rhel5</value>
43:    </org.jboss.soa.esb.http.HttpHeader>
44:    <org.jboss.soa.esb.http.HttpHeader>
45:     <name>authorization</name>
46:     <value>Basic a2VybWl0OnRoZWZyb2c=</value>
47:    </org.jboss.soa.esb.http.HttpHeader>
48:   </headers>

The Default HTTP Bus in Action

In the next part of the QuickStart we'll take another look a service definition where the definition doesn't reference a bus definition (busidref) and instead uses the "default" http bus. The definition of this service looks like this:

1:  <service category="Index" name="List" description="" invmScope="GLOBAL">
2:    <listeners>
3:      <!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/index/*
4:             Uses the default http bus configuration... -->
5:      <http-gateway name="Index" urlPattern="index/*" />
6:    </listeners>
7:    <actions mep="RequestResponse">
8:      <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
9:    </actions>
10:  </service>

Well, there's not a great deal to look at here since the default http bus is being used. To access this service, you point your browser at this URL:

http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?a=1,b=2

Note that we discussed earlier in this post and that this URL shows, we're able to process request parameters in the URL. Here's what lynx shows us:

1:  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?a=1,b=2
2:  Service: Index:List
3: 
4:  ------------Http Request Info (XStream Encoded)-------------------
5:  <org.jboss.soa.esb.http.HttpRequest>
6:   <contextPath>/Quickstart_http_gateway</contextPath>
7:   <localAddr>127.0.0.1</localAddr>
8:   <localName>localhost.localdomain</localName>
9:   <method>GET</method>
10:   <pathInfo>/XXXX/yyy</pathInfo>
11:   <protocol>HTTP/1.0</protocol>
12:   <queryString>a=1,b=2</queryString>
13:   <remoteAddr>127.0.0.1</remoteAddr>
14:   <remoteHost>127.0.0.1</remoteHost>
15:   <contentLength>-1</contentLength>
16:   <requestURI>/Quickstart_http_gateway/http/index/XXXX/yyy</requestURI>
17:   <scheme>http</scheme>
18:   <serverName>localhost</serverName>
19:   <requestPath>/http/index</requestPath>
20:   <pathInfoTokens>
21:    <string>XXXX</string>
22:    <string>yyy</string>
23:   </pathInfoTokens>
24:   <queryParams>
25:    <entry>
26:     <string>a</string>
27:     <string-array>
28:      <string>1,b=2</string>
29:     </string-array>
30:    </entry>
31:   </queryParams>
32:   <headers>
33:    <org.jboss.soa.esb.http.HttpHeader>
34:     <name>host</name>
35:     <value>localhost:8080</value>
36:    </org.jboss.soa.esb.http.HttpHeader>
37:    <org.jboss.soa.esb.http.HttpHeader>
38:     <name>accept</name>
39:     <value>text/html, text/plain, audio/mod, image/*, application/msword, application/pdf, application/postscript, application/x-java-jnlp-file, text/sgml, video/mpeg, */*;q=0.01</value>
40:    </org.jboss.soa.esb.http.HttpHeader>
41:    <org.jboss.soa.esb.http.HttpHeader>
42:     <name>accept-language</name>
43:     <value>en</value>
44:    </org.jboss.soa.esb.http.HttpHeader>
45:    <org.jboss.soa.esb.http.HttpHeader>
46:     <name>user-agent</name>
47:     <value>Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8e-fips-rhel5</value>
48:    </org.jboss.soa.esb.http.HttpHeader>
49:   </headers>

Take special note of these lines:

1:   <queryParams>
2:    <entry>
3:     <string>a</string>
4:     <string-array>
5:      <string>1,b=2</string>
6:     </string-array>
7:    </entry>
8:   </queryParams>

Let's change the URL a bit and make sure that the query parameters can really be accessed by the service and its actions:

1:  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?param1=hello,param2=world
2: 
3:   <queryParams>
4:    <entry>
5:     <string>param1</string>
6:     <string-array>
7:      <string>hello,param2=world</string>
8:     </string-array>
9:    </entry>
10:   </queryParams>

Yup! It's them!

A Global Exception

In the description of the basic authentication example that we discussed earlier, we skipped over the definition of a global exceptions mapping for the http-provider:

1:  <!-- Global exception mappings file... -->
2:  <<exception mappingsFile="/http-exception-mappings.properties" />

As its name indicates, this feature enables you to define a status code that will be returned for all requests that are received by a service. Let's take a look at the http-exception-mappings.properties file:

1:  org.jboss.soa.esb.services.security.SecurityServiceException=401
2:  org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException=502

What this file indicates is that all requests that raise an exception of type org.jboss.soa.esb.services.security.SecurityServiceException will result in an HTTP return status code of 401 being returned to the client that sent in the request, and all requests that raise an exception of type org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException will result in an HTTP return sttaus code of 502 being returned. To illustrate how this, we'll invoke this service:

1:  <service category="Exceptions" name="Exception1" description="" invmScope="GLOBAL">
2:    <listeners>
3:      <http-gateway name="Exception2" />
4:    </listeners>
5:    <actions mep="RequestResponse">
6:      <!-- Uses the globally defined exception mappings defined on the <http-provider>... -->
7:       <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction"/>
8:    </actions>
9:  </service>

The MyExceptionAction class is minimal - just enough code to throw an exception:

1:  public class MyExceptionAction extends AbstractActionPipelineProcessor {
2: 
3:    public MyExceptionAction(ConfigTree config) {
4:    }
5: 
6:    public Message process(Message message) throws ActionProcessingException {
7:      throw new MyActionException("MyActionException!!!!");
8:    }
9:

To access this service, you point your browser at this URL: http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1

1:  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1 -error_file=error.txt
2:  org.jboss.soa.esb.couriers.FaultMessageException: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
3:      at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
4:      at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
5:      at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:675)
6:      at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:569)
7:      at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:359)
8:      at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
9:      at org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
10:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
11:      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
12:      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
13:      at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
14:      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
15:      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
16:      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
17:      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
18:      at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
19:      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
20:      at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
21:      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
22:      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
23:      at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
24:      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
25:      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
26:      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
27:      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
28:      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
29:      at java.lang.Thread.run(Thread.java:636)
30:  Caused by: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
31:      at org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction.process(MyExceptionAction.java:34)
32:      at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:634)
33:      at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
34:      at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
35:      at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
36:      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
37:      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
38:      ... 1 more

And - here's the return code that we wanted:

1:  cat error.txt
2:    URL=http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1 (GET)
3:  STATUS=HTTP/1.1 502 Bad Gateway

Over-Riding a Global Exception

It's good to be able to handle all exceptions at a global level. However, there may be times when you will want to receive a different return status code. To do this, you can over-ride that global setting. Here's a service definition to over-ride the global variable that we just discussed:

1:  <service category="Exceptions" name="Exception2" description="" invmScope="GLOBAL">
2:    <listeners>
3:      <http-gateway name="Exception1">
4:        <!-- Override the exception mappings defined on the <http-provider>... -->
5:        <exception>
6:          <mapping class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException" status="503" />
7:        </exception>
8:      </http-gateway>
9:    </listeners>
10:    <actions mep="RequestResponse">
11:      <!-- Uses the override exception mappings defined on the <http-gateway>... -->
12:      <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction"/>
13:    </actions>
14:  </service>

Line 6 is the one that we're interested in. Here's where we map the class that throws the exception to the code that is returned. And, here's what happens:

1:  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception2 -error_file=error.txt
2:  org.jboss.soa.esb.couriers.FaultMessageException: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
3:      at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
4:      at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
5:      at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:675)
6:      at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:569)
7:      at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:359)
8:      at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
9:      at org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
10:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
11:      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
12:      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
13:      at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
14:      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
15:      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
16:      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
17:      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
18:      at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
19:      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
20:      at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
21:      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
22:      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
23:      at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
24:      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
25:      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
26:      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
27:      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
28:      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
29:      at java.lang.Thread.run(Thread.java:636)
30:  Caused by: org.jboss.soa.esb.samples.quickstart.httpgateway.MyActionException: MyActionException!!!!
31:      at org.jboss.soa.esb.samples.quickstart.httpgateway.MyExceptionAction.process(MyExceptionAction.java:34)
32:      at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:634)
33:      at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
34:      at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
35:      at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
36:      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
37:      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
38:      ... 1 more
39: 
40:  cat error.txt
41:    URL=http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception2 (GET)
42:  STATUS=HTTP/1.1 503 Service Unavailable

An Asynchronous Response

So far, we've only seen synchronous responses to our requests. It's also possible to have the invoked service respond asynchronously. Here's the quickstart's service definition that illustrates this:

1:  <service category="Async" name="List" description="" invmScope="GLOBAL">
2:    <listeners>
3:      <!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/Async/List
4:              Uses the default http bus configuration... -->
5:      <http-gateway name="Async">
6:        <asyncResponse statusCode="202">
7:          <payload classpathResource="/readme.txt" contentType="text/plain" characterEncoding="UTF-8" />
8:        </asyncResponse>
9:      </http-gateway>
10:    </listeners>
11:    <actions mep="RequestResponse">
12:      <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
13:    </actions>
14:  </service>

Line 5: This is where the asynchronous response definition starts. Note that the return code is 202.
Line 6: And. we're also able to specify a file, the contents of which will be returned as a static payload in the response along with the return code.

1:  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/Async/List -error_file=error.txt
2:  Overview:
3:  =========
4:   The purpose of the http_gateway quickstart sample is to demonstarte how to
5:   configue a http gateway to pass the http request into ESB service.
6:  
7: 
8:  Running this quickstart:
9:  ========================
10:   Please refer to 'ant help-quickstarts' for prerequisites about the quickstarts
11:   and a more detailed descripton of the different ways to run the quickstarts.
12: 
13:  To Run '.esb' archive mode:
14:  ===========================
15:   1. In a command terminal window in this folder ("Window1"), type 'ant deploy'.
16:   2. Open the web brower and send http requests to the following addresses. Be sure to
17:     check the Server console after executing each request:
18:      a) http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c - Will be routed to the Sales:List
19:       service. Will return some details about the request. This Service's <http-gateway> references a
20:       "secureFriends" bus, which contains login configurations. The login username is "kermit" and the
21:       password is "thefrog". It usee the "java:/jaas/JBossWS" security domain, which is already installed
22:       in your JBoss ESB/App Server.
23:      b) http://localhost:8080/Quickstart_http_gateway/http/index/XXXX/yyy?a=1,b=2 - Will be routed to the Index:List
24:       service. Will return some details about the request. This Service's <http-listener> does not refer
25:       to any bus and so simply uses the "default" http bus.
26:      c) http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception1 - Will be routed to the
27:       Exceptions:Exception1 service. This service throws a "MyActionException", resulting in a
28:       502 (Bad Gateway) status being returned in accordance with the Exception to HTTP status code
29:       mappings defined globally on the <http-provider>.
30:      d) http://localhost:8080/Quickstart_http_gateway/http/Exceptions/Exception2 - Will be routed to the
31:       Exceptions:Exception2 service. This service also throws a "MyActionException", but the <http-gateway>
32:       on this service overrides the globally defined Exception to HTTP status code mappings defined globally
33:       on the <http-provider> to return a 503 (Service Unavailable) status for the "MyActionException" exception.
34:      e) http://localhost:8080/Quickstart_http_gateway/http/Async/List - Will be routed to the
35:       Async:List service, which responds asynchronously with a 202 (Accepted) response code and a static
36:       payload of this readme.txt.
37:      f) http://localhost:8080/Quickstart_http_gateway/http/soap/ - Will be routed to the
38:       Soap:List service, which requires message level seurity. An 401 error will occur. Now
39:       switch to the command line and run "ant soap". This POSTs a SOAP message, with login credentials
40:       to the gateway. The service should respond successfully this time!!
41:   3. In this folder ("Window1"), type 'ant undeploy'.
42: 
43:  cat error.txt
44:    URL=http://localhost:8080/Quickstart_http_gateway/http/Async/List (GET)
45:  STATUS=HTTP/1.1 202 Accepted

SOAP and Security

The quickstart finishes where it began; with an example of some basic security. Here's the service definition:

1:  <service category="Soap" name="List" description="" invmScope="GLOBAL">
2:    <listeners>
3:      <!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/soap/*
4:        Execute "ant soap" on command line.... -->
5:      <http-gateway name="soap" busidref="secureFriends" urlPattern="soap/*">
6:        <exception>
7:          <mapping class="org.jboss.soa.esb.services.security.SecurityServiceException" status="401" />
8:        </exception>
9:      </http-gateway>
10:    </listeners>
11:    <actions mep="RequestResponse">
12:      <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.MyAction"/>
13:    </actions>
14:  </service>

Line 5: Here's the http-gateway definition. Note that we're using the "secureFriends" busidref again. (This means that kermit will have to login again.)
Line 7: And, here's the exception that we'll throw, with a return status code of 401.

Sure enough, when we send a request, we get that exception and return code:

1:  lynx -dump -source http://localhost:8080/Quickstart_http_gateway/http/soap -error_file=error.txt
2:  HTTP: Access authorization required.
3:      Use the -auth=id:pw parameter.
4: 
5:  Looking up localhost:8080
6:  Making HTTP connection to localhost:8080
7:  Sending HTTP request.
8:  HTTP request sent; waiting for response.
9:  Alert!: Access without authorization denied -- retrying
10: 
11:  lynx: Can't access startfile http://localhost:8080/Quickstart_http_gateway/http/soap
12: 
13:  cat error.txt
14:    URL=http://localhost:8080/Quickstart_http_gateway/http/soap (GET)
15:  STATUS=HTTP/1.1 401 Unauthorized

Now, we could just provide login credentials manually through the browser UI, but we want our client code to be able to do this programatically. The answer to avoiding this exception, is ot have request that we send has to include login credentials. The quickstart's build.xml file provides an ant target to do this for you by invoking the JBossESB HttpRouter action (org.jboss.soa.esb.actions.routing.http.HttpRouter). This action is one of the JBossESB's large set of "out-of-the-box" actions.

1:  <target name="soap" depends="compile" description="sends a SOAP HTTP request to the http gateway">
2:    <echo>Http Client</echo>
3:    <java fork="yes" classname="org.jboss.soa.esb.actions.routing.http.HttpRouter" failonerror="true">
4:      <arg value="endpointUrl=http://localhost:8080/Quickstart_http_gateway/http/soap/"/>
5:              <!-- The EBWS is secured with container level security -->
6:      <arg value="configurators=HttpProtocol,AuthBASIC"/>
7:      <arg value="method=POST"/>
8:      <arg value="auth-username=kermit"/>
9:      <arg value="auth-password=thefrog"/>
10:      <arg value="authscope-host=localhost"/>
11:      <arg value="authscope-port=8080"/>
12:      <!-- The actual payload to POST -->
13:      <arg value="payload=soap-login.xml"/>
14:      <classpath refid="exec-classpath"/>
15:    </java>
16:  </target>

The actual message payload that is sent is defined in the soap-login.xml file is:

1:  <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
2:              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3:              xmlns:xsd="http://www.w3.org/2001/XMLSchema">
4: 
5:   <soap:Header>
6:   </soap:Header>
7: 
8:   <soap:Body>
9:   </soap:Body>
10: 
11:  </soap:Envelope>

And, the successful results look like this:

1:  soap:
2:     [echo] Http Client
3:     [java] Request payload:
4:     [java] <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
5:     [java]           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6:     [java]           xmlns:xsd="http://www.w3.org/2001/XMLSchema">
7:     [java]
8:     [java]  <soap:Header>
9:     [java]  </soap:Header>
10:     [java]
11:     [java]  <soap:Body>
12:     [java]  </soap:Body>
13:     [java]
14:     [java] </soap:Envelope>
15:     [java]
16:     [java] --------------------------
17:     [java]
18:     [java]
19:     [java] Response Status Code: 200
20:     [java] Response payload:
21:     [java] Service: Soap:List
22:     [java]
23:     [java] ------------Http Request Info (XStream Encoded)-------------------
24:     [java] <org.jboss.soa.esb.http.HttpRequest>
25:     [java]  <authType>BASIC</authType>
26:     [java]  <characterEncoding>UTF-8</characterEncoding>
27:     [java]  <contentType>text/xml;charset=UTF-8</contentType>
28:     [java]  <contextPath>/Quickstart_http_gateway</contextPath>
29:     [java]  <localAddr>127.0.0.1</localAddr>
30:     [java]  <localName>localhost.localdomain</localName>
31:     [java]  <method>POST</method>
32:     [java]  <pathInfo>/</pathInfo>
33:     [java]  <protocol>HTTP/1.1</protocol>
34:     [java]  <remoteAddr>127.0.0.1</remoteAddr>
35:     [java]  <remoteHost>127.0.0.1</remoteHost>
36:     [java]  <remoteUser>kermit</remoteUser>
37:     [java]  <contentLength>268</contentLength>
38:     [java]  <requestURI>/Quickstart_http_gateway/http/soap/</requestURI>
39:     [java]  <scheme>http</scheme>
40:     [java]  <serverName>localhost</serverName>
41:     [java]  <requestPath>/http/soap</requestPath>
42:     [java]  <pathInfoTokens/>
43:     [java]  <queryParams/>
44:     [java]  <headers>
45:     [java]   <org.jboss.soa.esb.http.HttpHeader>
46:     [java]    <name>content-type</name>
47:     [java]    <value>text/xml;charset=UTF-8</value>
48:     [java]   </org.jboss.soa.esb.http.HttpHeader>
49:     [java]   <org.jboss.soa.esb.http.HttpHeader>
50:     [java]    <name>user-agent</name>
51:     [java]    <value>Jakarta Commons-HttpClient/3.0.1</value>
52:     [java]   </org.jboss.soa.esb.http.HttpHeader>
53:     [java]   <org.jboss.soa.esb.http.HttpHeader>
54:     [java]    <name>content-length</name>
55:     [java]    <value>268</value>
56:     [java]   </org.jboss.soa.esb.http.HttpHeader>
57:     [java]   <org.jboss.soa.esb.http.HttpHeader>
58:     [java]    <name>authorization</name>
59:     [java]    <value>Basic a2VybWl0OnRoZWZyb2c=</value>
60:     [java]   </org.jboss.soa.esb.http.HttpHeader>
61:     [java]   <org.jboss.soa.esb.http.HttpHeader>
62:     [java]    <name>host</name>
63:     [java]    <value>localhost:8080</value>
64:     [java]   </org.jboss.soa.esb.http.HttpHeader>
65:     [java]  </headers>
66:     [java] </org.jboss.soa.esb.http.HttpRequest>
67:     [java] --------------------------
68:     [java]

Closing Thoughts

The JBossESB's new http-gateway provides great flexibility in integrating HTTP applications across the ESB. The http_gateway quickstart illustrates some of this flexibility, and, incidentally, shows just how much you can do without writing a lot of custom code. Did you notice while eading this post, that we didn't have to write support routines to handle authentication, exception handling, and dealing with URL patterns? The http-gateway and the JBossESB did the heavy lifting for us.

Acknowledgements

Thanks to the JBossESB community and its contributors (see http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/Contributors.txt) - and to Kevin Conner for his timely review comments!

References

[1] http://www.jboss.org/community/wiki/HTTPGateway
[2] http://jboss-soa-p.blogspot.com/2009/09/works-great-right-out-of-box.html
[3] http://www.jboss.org/jbossesb/docs/4.7/manuals/html/ProgrammersGuide.html
[4] http://en.wikipedia.org/wiki/Digest_access_authentication

Proxying SOAP Web Services in JBossESB 4.7

2009-11-30T05:23:00.000-08:00

JBossESB supports SOAP web services via various mechanisms:

SOAPClient for invoking external web services.
SOAPProducer for invoking internally-deployed JBossWS services.
EBWS (ESB-Based Web Services) for decorating service requests/responses with a SOAP Envelope.
HttpRouter can be used to manually invoke an HTTP endpoint.
Explicit support for web service proxying via the SOAPProxy action.

Why would I want to proxy a web service from the ESB?

To provide loose coupling between the client and the proxied service: the client no longer needs to have a direct connection to the remote host.
The WSDL contract can be transformed to modify it's parameters or change the service's declared capabilities.
A transformation of the SOAP envelope/body can be introduced via the ESB action chain both for the inbound request and outbound response (via XsltAction or SmooksAction). Other custom processing can also be introduced in the chain.
Service versioning is possible since clients can connect to 2 or more proxy endpoints on the ESB, each with its own WSDL and/or transformations and routing requirements, and the ESB will send the appropriate message to the appropriate endpoint and provide an ultimate response.
Complex context-based routing via ContentBasedRouter.

Here is a figure of a basic web service proxy in the ESB:

As you can see, the ESB action chain can perform any number of out-of-the-box or custom actions before or after the call to the proxied web service. Also, the client of the ESB as well as the proxied web service do not have to be Java-based.

Show me how to configure the ESB to proxy to a .NET-based SOAP web service.

Here it is in 15 short lines:

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.2.0.xsd" parameterReloadSecs="5">
3:    <services>
4:      <service category="Stock" name="Quote" description="Stock Quote" invmScope="GLOBAL">
5:        <listeners>
6:          <http-gateway name="StockQuote-GwListener"/>
7:        </listeners>
8:        <actions mep="RequestResponse">
9:          <action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy">
10:            <property name="wsdl" value="http://www.webservicex.net/stockquote.asmx?WSDL"/>
11:          </action>
12:        </actions>
13:      </service>
14:    </services>
15:  </jbossesb>

Line 8 specifies a request/response message exchange pattern. Line 9 adds the SOAPProxy action to the processing pipeline. Line 10 is the only required property: the wsdl location. In this example, we are proxying to a .NET-based stock quote service. Line 6 specifies the use of the newly supported HTTPGateway, introduced in JBossESB 4.7.

When a .esb archive is deployed with this configuration, you will see output like this in the server console:

07:17:51,789 INFO [SOAPProxy] mapped soapaction ["http://www.webserviceX.NET/GetQuote"] to binding [{http://www.webserviceX.NET/}StockQuoteSoap]
07:17:51,790 INFO [SOAPProxy] mapped binding [{http://www.webserviceX.NET/}StockQuoteSoap] to transport [org.jboss.soa.esb.actions.soap.proxy.HttpSOAPProxyTransport] with endpoint address: [http://www.webservicex.net/stockquote.asmx]

At this point, the SOAPProxy has transformed the wsdl by rewriting it's soap:address location to the ESB server, so clients of the ESB will invoke it rather than the proxied service itself (line 3 below):

1:  <wsdl:service name="StockQuote">
2:    <wsdl:port binding="tns:StockQuoteSoap" name="StockQuoteSoap">
3:      <soap:address location="http://192.168.1.103:8080/sample/http/Stock/Quote"/>
4:    </wsdl:port>
5:  </wsdl:service>

With the introduction of the new HTTPGateway, the wsdl is available at the well-known location of the endpoint URL + "?wsdl" (or "?WSDL"), as shown in the following screenshot of the ESB contract application, available at http://host:port/contract/

In our case, the wsdl URL is http://192.168.1.103:8080/sample/http/Stock/Quote?wsdl
To invoke the ESB, we can use a tool like soapUI to send a test request to http://192.168.1.103:8080/sample/http/Stock/Quote

1:  <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://www.webserviceX.NET/">
2:    <soapenv:Header/>
3:    <soapenv:Body>
4:     <web:GetQuote>
5:       <web:symbol>RHT</web:symbol>
6:     </web:GetQuote>
7:    </soapenv:Body>
8:  </soapenv:Envelope>

The HTTPGateway will receive the request, the SOAPProxy action will invoke the proxied .NET stock quote service, and the following response will be returned:

1:  <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
2:    <soap:Body>
3:     <GetQuoteResponse xmlns="http://www.webserviceX.NET/">
4:       <GetQuoteResult><![CDATA[<StockQuotes><Stock><Symbol>RHT</Symbol><Last>26.80</Last><Date>11/27/2009</Date><Time>1:00pm</Time><Change>0.00</Change><Open>N/A</Open><High>N/A</High><Low>N/A</Low><Volume>0</Volume><MktCap>5.032B</MktCap><PreviousClose>26.80</PreviousClose><PercentageChange>0.00%</PercentageChange><AnnRange>8.30 - 28.94</AnnRange><Earns>0.448</Earns><P-E>59.82</P-E><Name>RED HAT INC</Name></Stock></StockQuotes>]]></GetQuoteResult>
5:     </GetQuoteResponse>
6:    </soap:Body>
7:  </soap:Envelope>

Why can't I just use HttpRouter to do this?

HttpRouter can only talk to one endpoint. One WSDL can specify multiple soap:address locations. With the SOAPProxy, you just config the one location of the WSDL, and it can dynamically route the request to the correct soap:address location.
To use HttpRouter with SOAP, you have to always configure a MappedHeaderList (usually "Content-Type, Accept, Authorization, SOAPAction"). This is unnecessary with the SOAPProxy.
The SOAPProxy allows you to specify a wsdlTransform, which allows you to transform the original WSDL to something else you want the SOAPProxy to expose. (This handles the "versioning" use case, and also usually means you'll want to use XsltAction or SmooksAction in the action pipeline.)
If you are proxying to a BASIC Auth secured web service, the "clientCredentialsRequired" property of the SOAPProxy allows you to specify if the credentials should be passed into the SOAPProxy from the client (the default, in which case the credentials are propagated), or if you want the proxy to be wide-open, but it will handle the authentication to the proxied service for you.
SOAPProxy is designed to talk to more than just HTTP endpoints, although HTTP is all that is implemented right now.
When using the new HTTPGateway to front the SOAPProxy, the ESB will automatically transform and cache the WSDL and make it available at the well-known location of ${endpoint}?wsdl (or ?WSDL).

Tell me more about security.

As mentioned in #4 above, the SOAPProxy can invoke external web services that are protected by BASIC Auth. In addition, these services can also be encrypted using SSL. Here is an example configuration taken from the webservice_proxy_security quickstart which comes bundled with JBossESB 4.7:

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.2.0.xsd" parameterReloadSecs="5">
3:    <globals>
4:      <war-security method="BASIC" domain="JBossWS"/>
5:    </globals>
6:    <providers>
7:      <http-provider name="HTTP-PROVIDER">
8:        <http-bus busid="HTTP-BUS" transportGuarantee="CONFIDENTIAL">
9:          <allowed-roles>
10:            <role name="friend"/>
11:          </allowed-roles>
12:        </http-bus>
13:      </http-provider>
14:    </providers>
15:    <services>
16:      <service category="Proxy_Security" name="Proxy" description="Security WebService Proxy" invmScope="GLOBAL">
17:        <listeners>
18:          <http-gateway name="HTTP-GATEWAY" busidref="HTTP-BUS" urlPattern="ProxyWS/*"/>
19:        </listeners>
20:        <actions mep="RequestResponse">
21:          <action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy">
22:            <!-- property name="wsdl" value="https://localhost:8443/webservice_proxy_security/HelloWorldWS?wsdl"/ -->
23:            <property name="wsdl" value="internal://jboss.ws:context=webservice_proxy_security,endpoint=HelloWorldWS"/>
24:            <property name="endpointUrl" value="https://localhost:8443/webservice_proxy_security/HelloWorldWS"/>
25:            <property name="file" value="/META-INF/httpclient-8443.properties"/>
26:          </action>
27:        </actions>
28:      </service>
29:    </services>
30:  </jbossesb>

Lines 3-14 configure the HTTPGateway for BASIC Auth and SSL support. Line 24 overrides the endpointUrl. This is an example of an HttpRouter property (Note: the SOAPProxy wraps usage of HttpRouter), a useful property when domain name matching is important for SSL certs. Line 25 specifies a properties file for httpclient configuration.

What's with the "internal" wsdl location?

Line 22 (a "normal" http URL) is commented out and instead, on Line 23, you see an "internal" URL. In JBossESB 4.7, the value can reference a location based on five different schemes: http, https, file, classpath or internal (JBossWS jmx mbean object name). Here are some examples:

http://localhost:8080/Quickstart_webservice_proxy_basic_ws/HelloWorldWS?wsdl
https://localhost:8443/webservice_proxy_security/HelloWorldWS?wsdl
file:///tmp/HelloWorldWS.wsdl
classpath://META-INF/HelloWorldWS.wsdl
internal://jboss.ws:context=Quickstart_webservice_proxy_basic_ws,endpoint=HelloWorldWS

I want to learn more...

Other quickstart samples available are webservice_proxy_basic, webservice_proxy_routed (an example using the ContentBasedRouter to route to one of two proxied endpoints) and webservice_proxy_versioning (an example showing support for old and new versions of the same endpoint via transformation).

Of course, you are always welcome to ask questions in the JBossESB project forum.

MessageAlerts in JBossESB 4.7

2009-11-23T17:58:00.000-08:00

Is One of My Services or Actions Clogging Things Up?

JBossESB 4.7 includes some great new features. In this post, I wanted to highlight a feature that can help answer the above question.

The new feature feature is "MessageAlerts" (org.jboss.soa.esb.listeners.message.MessageAlerts). This feature enables you to collect fine grained information on the processing time or number of bytes that a specific service, or a specific action in a service requires to process a single message.

You use MessageAlerts by defining processing time and byte total thresholds on a per service and/or action basis. When the service or action in question takes longer than the defined time threshold to process a message, a WARNING is written to the server log and made available in the JMX console. You define the thresholds with these properties:

alertTimeThreshold="420"
alertLengthThreshold="10"

The time-related threshold is measured in milliseconds. The length-related threshold is measured in bytes.

When would you use the byte total threshold? This can be useful if, for example, the service or action that you are watching performs transformations, and suddenly begins processing way more bytes than you're expecting that it should.

An Example in a Quickstart

The MessageAlerts feature is demonstrated in a quickstart named, appropriately enough, "messagealert." If you've ever run the "helloworld" quickstart, then this quickstart should be familiar. The only changes are the addition of the org.jboss.soa.esb.samples.quickstart.messagealerts.DelayAction action class (as you can guess by the name, this class introduces a delay to cause the alertTimeThreshold to be reached, and the changes in the jboss-esb.xml file listed below:

1:   <services>
2:    <service
3:     category="FirstServiceESB"
4:      name="SimpleListener"
5:      description="Hello World"
6:      alertTimeThreshold="420"
7:      alertLengthThreshold="10"
8:      >
9:     <listeners>
10:      <jms-listener name="JMS-Gateway"
11:       busidref="quickstartGwChannel"
12:       is-gateway="true"
13:      />
14:       <jms-listener name="helloWorld"
15:        busidref="quickstartEsbChannel"
16:      />
17:     </listeners>
18:     <actions mep="OneWay">
19:      <action name="action1"
20:       class="org.jboss.soa.esb.samples.quickstart.messagealerts.MyJMSListenerAction"
21:       process="displayMessage"
22:      />
23:      <action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
24:      <property name="printfull" value="false"/>
25:     </action>
26:     <action name="action3"
27:      class="org.jboss.soa.esb.samples.quickstart.messagealerts.DelayAction"
28:      process="delayMessage"
29:      alertTimeThreshold="30"
30:      alertLengthThreshold="50">
31:     </action>
32:    </actions>
33:   </service>
34:  </services>

The changes related to MessageAlerts are:

Lines 6-7: These set the service thresholds at 420 milliseconds in time and 10 bytes in length.
Lines 29-30: And, these set the action thresholds at 30 milliseconds in time and 50 bytes in length.

When we deploy and run the quickstart, the following is written to the server.log:

 22:00:28,833 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
22:00:28,837 INFO [STDOUT] Body: Message Alerts
22:00:28,837 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
22:00:28,850 INFO [STDOUT] Message structure:
22:00:28,850 INFO [STDOUT] [Message Alerts].
22:00:31,852 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service, action3 action alert time 3001 took longer than 30 ms
22:00:31,853 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service, action3 action message size 2960 was larger than 50 bytes
22:00:31,853 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service alert time 3007 took longer than 420 ms
22:00:31,854 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service message size 2960 was larger than 10 bytes

And, the same information is available in the JMX log under jboss.esb, service=MessageAlerts:

As you can see in this screenshot, you can reset the counters through the JMX console. (And, yes, as you can also see in this screenshot, I'm staying up way too late at night writing about this stuff.)

You can also access the same information from the jboss.esb mbean directly:

sh ./twiddle.sh get "jboss.esb:service=MessageAlerts"

And, for extra credit, you can access the MessageAlerts service programatically. To do this, first, we'll modify the quickstart's jboss-esb.xml file to move the action that prints information to the server log to happen after the delay (and therefore after the MessageAlerts have been generated).

Then, we'll replace the code in MyJMSListenerAction.java with this:

1:   package org.jboss.soa.esb.samples.quickstart.messagealerts;  
2:    
3:   import org.jboss.soa.esb.actions.AbstractActionLifecycle;  
4:   import org.jboss.soa.esb.helpers.ConfigTree;  
5:   import org.jboss.soa.esb.message.Message;  
6:    
7:   import javax.management.ObjectName;  
8:   import javax.management.MBeanServer;  
9:   import javax.management.MalformedObjectNameException;  
10:    
11:   import org.jboss.mx.util.MBeanProxyExt;  
12:   import org.jboss.mx.util.MBeanServerLocator;  
13:   import org.jboss.soa.esb.actions.AbstractActionPipelineProcessor;  
14:   import org.jboss.soa.esb.actions.ActionProcessingException;  
15:    
16:   import java.util.Vector;  
17:    
18:   public class MyJMSListenerAction extends AbstractActionLifecycle  
19:   {  
20:    
21:   protected ConfigTree _config;  
22:    
23:   public MyJMSListenerAction(ConfigTree config) { _config = config; }  
24:    
25:   public Message displayMessage(Message message) throws Exception{  
26:    
27:   MBeanServer server = org.jboss.mx.util.MBeanServerLocator.locateJBoss();  
28:   Vector theAlertsVector = (Vector)server.getAttribute(new ObjectName("jboss.esb:service=MessageAlerts"), "Alerts");  
29:    
30:   for (int i = 0; i < theAlertsVector.size(); i++ ) {  
31:   System.out.println("******Data returned from MessageAlert[" + i + "] = " + theAlertsVector.elementAt(i) + "\n" );  
32:   }  
33:    
34:   System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");  
35:   System.out.println("Body: " + message.getBody().get()) ;  
36:   System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");  
37:   return message;  
38:   }  
39:    
40:  }

Line 27: Locates the MBeanServer - this is easy as we are running in the same JVM as the server
Line 28: Retrieves the Vector of MessageAlerts from the jboss.esb MessageAlerts service
Lines 30-33: and prints them out

Closing Thoughts

The ability to building your own services and custom actions with JBossESB is one characteristic of its overall flexibility. With MessageAlerts, you can more easily track the efficiency of those services and actions, at a fine grained level. The message alert feature makes it simple.

Acknowledgements

Thanks to Tom Cunningham for his input to this post and his patient responses to my many questions!

Content Based Routing in JBossESB Just Got Easier

2009-10-02T06:05:00.000-07:00

One of the main tasks that the JBossESB performs is that of routing messages to the correct services. (As I never tire of telling people, in the context of the ESB, everything is either a message or a service. ;-) The ESB supports multiple types of message routing, including routing based on the content of the message itself. This Content Based Routing (CBR) was originally implemented in the ESB by means of using JBoss Drools.[1]

JBoss Drools is a complete enterprise platform for rules-based application development, workflow, administration, and event processing. It also provides an integration with JBossESB to support content based routing. You define the content based routing algorithm in a set of rules.

But, Drools might be a larger tool than you may want to use for some routing tasks.

Two additional (and simpler) approaches for content based routing were just added to the JBossESB project. (Note that these were added to the JBoss ESB project in trunk here: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk and should be in the next project release.) Let's take a look at these new approaches for content based routing as illustrated in the "jbos-esb.xml" file of the "fun_cbr" quickstart sample application:

XPath Content Based Routing

To configure XPath content based routing you define a service like this:

32  <service category="Fun_CBRServices_ESB" name="XPath_FunCBRService_ESB" description="ESB Listener - for the native clients" invmScope="GLOBAL">
33      <listeners>
34          <!-- Gateway -->
35          <jms-listener name="TheGateway" busidref="xpathQuickstartGwChannel" is-gateway="true" />
36       </listeners>
37       <actions mep="OneWay">
38          <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
39              <property name="cbrAlias" value="XPath"/>
40              <property name="destinations">
41                  <namespace prefix="ord" uri="http://org.jboss.soa.esb/Order" />
42                  <route-to service-category="BlueTeam"  service-name="GoBlue"  expression="/ord:Order[@statusCode='0']" />
43                  <route-to service-category="RedTeam"   service-name="GoRed"   expression="/ord:Order[@statusCode='1']" />
44                  <route-to service-category="GreenTeam" service-name="GoGreen" expression="/ord:Order[@statusCode='2']" />
45               </property>
46          </action>
47      </actions>
48  </service>

The "cbrAlias" property defined on line 39 indicates that one of the new approaches for content based routing is to be used. On line 41 the namespace is defined and lines 42-44 define the actual routes. Note that this is completely defined in the jboss-esb.xml file. No additional configuration files are needed.

Regex Content Based Routing

52  <service category="Fun_CBRServices_ESB" name="Regex_FunCBRService_ESB" description="ESB Listener - for the native clients" invmScope="GLOBAL">
53      <listeners>
54          <!-- Gateway -->
55          <jms-listener name="TheGateway" busidref="regexQuickstartGwChannel" is-gateway="true" />
56       </listeners>
57       <actions mep="OneWay">
58          <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
59              <property name="cbrAlias" value="Regex"/>
60              <property name="ruleSet" value="/regex-rules.properties"/>                  
61              <property name="ruleReload" value="true"/>
62              <property name="destinations">
63                  <route-to destination-name="blue"  service-category="BlueTeam"  service-name="GoBlue" />
64                  <route-to destination-name="red"   service-category="RedTeam"   service-name="GoRed" />
65                  <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" />
66              </property>
67          </action>
68      </actions>
69  </service>

Again, Line 59 defines the cbrAlias property and lines 63-65 define the actual paths. On line 60, we have a reference to the external file that contains the XPath expressions that will govern the routing. That file looks like this:

1  blue=.* statusCode="0".*
2  red=.* statusCode="1".*
3  green=.* statusCode="2".*

It's important to note that any applications built with Drools-based content based routing will continue to function without needing any changes or migrations.

To sum it up, content based routing has always been a flexible way to route messages to services. With these changes to JBossESB, it's even easier to use.

References
[1] http://jboss-soa-p.blogspot.com/2009/07/when-content-knows-way-content-based.html

JBoss Tools Editor for Smooks… Let us hear what you think…

2009-09-30T06:46:00.000-07:00

Of late, we've been making more of a push on the Eclipse Tooling for Smooks within JBoss Tools. Prior to a few weeks ago, Dart Peng was “more or less” left to his own devices on this work, without much help from myself or anyone else. More recently, Brian Fitzpatrick and I have been more actively contributing to the great work being done by Dart.

Brian has been blogging about this work here on the JBoss Tools blog. Please take a look and contribute your throughs and ideas!!!

In time, this work will feed back into the ESB Configuration Editor, making it a lot easier to perform transformations (and other data manipulation processes) on the ESB.

Integrating jBPM + JBoss ESB + POP3

2009-03-01T00:33:00.000-08:00

POP3 JCA Inflow example. It's in Portuguese. Here it is translated to English.

Smooks Persistence: Reusing your Hibernate, Ibatis and JPA resources to persist XML, EDI and more

2009-02-26T04:17:00.000-08:00

Maurice Zeijen posted an very interesting blog on how to leverage existing Hibernate, JPA and Ibatis persistence resources to easily persist XML, EDI, CSV, JSON and more, using Smooks.

This functionality should eventually make its way into the ESB.

See the full blog here. Don't forget to vote for it ;)

Podcast on SOA Patterns

2009-02-24T05:56:00.001-08:00

In case you don't read the SOA Platform blog (why not?! ;)

CICS integration with JBossESB

2009-02-16T00:38:00.001-08:00

We've been working with LegStar to integrate CICS through JBossESB. InfoQ has recently published an article on the subject, so check it out if you're interested in this situation.

JBossESB and Camel

2009-02-15T02:51:00.000-08:00

Edgar has written a nice article on JBossESB 4.5 and Camel. If you haven't seen it already, then check it out.

WSTF retrospective

2009-01-18T12:22:00.001-08:00

I forgot to mention that we've been working with IBM and others for a while on the Web Services Test Forum. For more information take a look at the InfoQ article.

SOA Design Patterns

2009-01-18T12:18:00.000-08:00

About a year ago I mentioned that we were helping Thomas Erl with his (then) latest book on SOA Design Patterns. Well the book has been published. For more information take a look at the SOA Platform blog entry.

Smooks on InfoQ

2008-11-26T04:06:00.000-08:00

Our very own Tom Fennelly has had a great article on Smooks published on InfoQ. Take a look.

Stonehenge

2008-11-21T01:33:00.000-08:00

We just helped start Apache Stonehenge. As I've said elsewhere several times, interoperability is very important for Web Services, so hopefully this will help the industry as a whole as well as our projects.

SOA Platform 4.3 is released!

2008-10-31T09:57:00.000-07:00

We're pleased to announce that version 4.3 of our SOA Platform has just been released. We've made quite a few improvements since the first release, including closer integration with JON to provide runtime governance of services, improved Web Services support, better performance, reliability etc. SOA-P 4.3 GA is based on JBossESB 4.4 CP1, so you can grab the source from the repository. As always, give us feedback so we can improve it even more in subsequent releases!

Wise as a JBoss project

2008-10-24T03:41:00.000-07:00

We've been working with the Wise project for a while and it's offered us some really nice capabilities. So it's with great pleasure that I can now announce that Wise has moved to become a JBoss Project. Welcome to the entire Wise community! I'm sure we've all got great things ahead!

Evaluating & Getting Started with JBoss ESB

2008-10-15T15:59:00.000-07:00

I am personally a learn by example, learn by demonstration kind of person. I prefer to see the technology running before I'm willing to invest time into downloading it, reading the documentation and trying it out. The following items offer a great introduction into the capabilities of the JBoss ESB. Please review them and if you have questions get after us in the online forums.

1) jBPM and ESB 4.2 Demo: http://www.redhat.com/v/webcast/SOAdemo2/SOADemo2.html
A Flash-based recording of just the demonstration portion of the Apr 17th webinar. This is your best starting point if you only have 17 minutes for an immersion into SOA the JBoss way. This demo includes the Spring AOP trick of "eavesdropping" (aka wiretap) on the JPetstore so that the order is routed through the ESB and into a jBPM process which orchestrates the services & manages the human tasks. Drools handles the business logic and Smooks takes care of the XML to POJO transformation. We even show a bit of the JBoss Tools project which has an jboss-esb.xml editor.

2) ESB 4.4 and SOA Platform 4.3 - Deep Dive Webinar
(Oct 2 2008)
This presentation focuses on what's new and cool in the latest versions of JBoss ESB and has live demonstrations of:
- multi-language scripting: a service created via JRuby, Jython, Beanshell, and Groovy
- an Excel spreadsheet for service business logic (decision tables from Drools)
- a declarative model for Web Services & XSD validations, including Visual Basic.NET consumption
- a declarative model for service security based on JAAS
- JBoss Operations Network (JON) management & monitoring tools which now available at: http://www.jboss.org/jopr
Note: Some of these demonstrations require the use of trunk in the JBoss ESB SVN.

3) ESB 4.2 & SOA Platform 4.2 - Deep Dive Webinar
(Apr 17 2008)
SOA: Serivce Oriented Agility - this session introduces the IT challenges that SOA and an ESB address and focuses on the demonstration of how jBPM, Drools & JBoss ESB can be used synergistically to create a service oriented and agile solution. The demonstration portion is same as above, however, there is valuable content in the general presentation and Q&A session.

JBossESB customer visit

2008-09-24T03:54:00.000-07:00

I've been spending a fair bit of time recently talking with and visiting customers. Last week it was Amsterdam where we had a really good couple of days. It was fun and informative to meet everyone.

Zero-code Web Services addition

2008-08-11T06:52:00.000-07:00

We've had Web Services support in JBossESB for a long time (relative to the age of the project), but it has often required users to code more than they may have liked. Well in recent months we've been working more and more with Stefano Maestri of the wise project to improve things. Stefano has just posted a blog entry on where things now stand with the latest ESB 4.4 release. Well worth taking a look at the posting as well as the ESB!

JBossESB wins InfoWorld Bossie award

2008-08-11T04:15:00.000-07:00

It's always nice to get recognition from others in the industry and particularly from InfoWorld. So congratulations to everyone involved in the ESB and SOA Platform efforts!

Smooks released as one of the "Open-Source-Tools" in JavaMagazine

2008-07-07T06:19:00.000-07:00

Not sure how "big" this German magazine is, but anyway... their latest edition includes Smooks as one of the distributed "Open-Source-Tools". See article ("Leser-CD" tab).

Writing Integration Tests with the AbstractTestRunner

2008-06-21T07:02:00.000-07:00

Writing integration tests around your ESB Services can be a bit of a pain in the head under the current 4.x codebase (5.0 will be fixing many of these issues). A number of resources are managed statically. This is "OK" under normal running conditions, but a major head wrecker when trying to write multiple isolatable tests i.e. tests where you can easily dump/create clean environments for each test, without one test magically screwing with another.

A while ago I created the ESBConfigUtil test utility class (dumb name), which went some way towards making it a little easier to write tests, but was still a bit painfull. The latest addition is the AbstractTestRunner class, which I think is a bit better again. It wraps the ESBConfigUtil class, setting up the test env (ESB deployment, Registry, ESB properties ala the beloved PropertyManager), starting the ESB Controller, running the test and then shutting down the Controller and ensuring that the test env is returned to it's state from before the test run (or at least tries to ;-) ), which hopefully helps to avoid leakage between tests.

The AbstractTestRunner tries to allow you to write Integration level tests more easily. You can define a full ESB configuration and run it through the ESB Controller class, run tests (invoke endpoints etc).

As an example from the InVM transport tests, we have the following ESB configuration named "in-listener-config-01.xml":


<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd">

  <services>
      <service category="ServiceCat" name="ServiceName"
             description="Test Service">
          <actions mep="RequestResponse">
              <action name="action"
                class="org.jboss.soa.esb.mock.MockAction" />
          </actions>
      </service>
  </services>

</jbossesb>

Writing some test code around this, with the configuration deployed in the ESB Controller (quite near to the full running env):


public void test_async() throws Exception {
  AbstractTestRunner testRunner = new AbstractTestRunner() {
      public void test() throws Exception {
            ServiceInvoker invoker =
            new ServiceInvoker("ServiceCat", "ServiceName");
            Message message = MessageFactory.getInstance().getMessage();

            message.getBody().add("Hi there!");
            invoker.deliverAsync(message);

            sleep(50);
            assertTrue(message == MockAction.message);
      }
  }.setServiceConfig("in-listener-config-01.xml");

  testRunner.run();
}

So as you can see, the test method creates an anonymous instance of the AbstractTestRunner class. It implements the "test" method, in which the actual test code is placed. The Service config file is set on the anonymous instance through the setServiceConfig method (the String param version of this method looks up the resource using getClass().getResourceAsStream()). The ESB properties file can be set through the setEsbProperties method (supports the same mechanisms as the setServiceConfig method). Both setServiceConfig and setEsbProperties methods return the instance of the anonymous inner class (i.e. "return this;"), so you can string the config calls together e.g.:


public void test_async() throws Exception {
  AbstractTestRunner testRunner = new AbstractTestRunner() {
      public void test() throws Exception {
          .... test code....
      }
  }.setEsbProperties("jbossesb-properties.xml")
   .setServiceConfig("jboss-esb.xml");

  testRunner.run();
}

Of course, you need to call the run() method to run the actual test code. You can do this as above, or you can just string it onto the end of the anonymous inner class:

public void test_async() throws Exception {
  AbstractTestRunner testRunner = new AbstractTestRunner() {
      public void test() throws Exception {
          .... test code....
      }
  }.setServiceConfig("jboss-esb.xml").run();
}

Calling the run() method:

Parses the Service configuration, creating the Controller instance.
Installs the specified ESB properties (recording the currently installed properties)
Installs and configures the Registry.
Starts the Controller
Calls the "test()" method to run the test code.
Stops the Controller
Uninstalls the Registry.
Resets the ESB properties to their pre-test state.

You may ask why I didn't just implement a base TestCase class. Well... it just ends up getting in the way when you're trying to write your own test code. You end up having to be contious of what you're inheriting, making sure you call super.xxx() at the appropriate times etc. You end up not being able to extend another TestCase base impl (if you need to do that). Basically, as a solution it sucks for many of the same reasons that other inheritance based solutions suck!

Would be great if people could try it in their tests so we can evolve it and fix any issues. I hope it can make integration testing a bit easier in the 4.x codebase.

Complex Splitting, Enriching and Routing of Huge Messages

2008-06-18T07:25:00.000-07:00

ESB Administrators sometimes have a requirement to split message payloads into smaller messages for routing to one or more Service Endpoints (based on content: Content Based Routing). Add Endpoint based Transformation, Message Enrichment and the fact that these messages can be Huge in size (GBs)... you end up with some interesting problems that need solving!

I've just added a new Quickstart to the 4.4 codebase that demonstrates one approach (set of approaches) to solving some of these issues with JBossESB. I uploaded the readme, so people can read the details (as well as look at the flash demo) without going to too much trouble.

JBossESB 4.3 is released

2008-05-31T06:47:00.000-07:00

In case you hadn't noticed, the team released JBossESB 4.3. This is the first community release since the SOA Platform came out and contains many of the great features available there, including InVM transport, Smooks 1.0 support, more BPM specific quickstarts, performance improvements, support for the SOA Software registry as a replacement for jUDDI and many many more. But most of all this version has had much more stress testing applied to it. So if you're using an earlier version of JBossESB then we recommend you give this release a try!

More CDL work

2008-05-14T08:08:00.000-07:00

We've been making progress.

Come meet us at JavaOne

2008-05-05T07:30:00.000-07:00

As well as having a presence in the Pavilion, we're presenting at a couple of sessions this year. The first is a panel session around SCA/OpenCSA standardisation efforts and the second is a BOF on OSGi and SOA (very relevant to our ESB 5.0 architecture). If you're around and just want to say 'hi', come on over.

Something I forgot to mention earlier, but we were also represented on the Program Committee for JavaOne this year: a interesting experience and definitely something to repeat if possible.

Smooks improvements and futures

2008-04-12T03:11:00.000-07:00

If you're a JBossESB user then you've probably used Smooks, which is our default transformation engine. Unlike other ESBs that may only give you XSLT based transformations (perhaps as an afterthought to their architecture), Smooks provides much more than this, and transformation has been at the heart of our architecture since the start. Anyway, Mr Smooks (aka Tom) has been describing the future for Smooks and within our ESB. Definitely worth a read. It's nice to see that others are getting in on the act. What's that they say about imitation and flattery ;-)?

Cloud Computing and the ESB

2008-04-11T06:26:00.000-07:00

Whether you call it Cloud Computing, Grid, utility computing, ubiquitous computing, or just large scale distributed systems, computing devices are everywhere. These days I have a mobile phone that is more powerful (processor and memory) than the laptop I had 10 years ago. I suspect my fridge is more powerful than my old BBC Model B computer! Having spent a lot of time working in large-scale distributed systems, the basic requirements are pretty similar: develop objects/services, publish, locate and use. Doing this in a transport agnostic manner is very important as well: how many services running on a mobile phone support JMS? But as a service developer do I really need to tie my service to a specific transport? That breaks reusability: the service logic (excluding transport) should be useable in a variety of different deployments, assuming its dependencies on 3rd party bindings are present (e.g., no good deploying a service on a mobile phone if it needs a local Oracle instance to execute!)

What you need to support cloud computing (for want of a better term) is an infrastructure that allows you to develop your services without having to worry about where they will be deployed. Furthermore, if you can compose services from other services and (re-)deploy them dynamically as your requirements change, that would be a benefit. Many service deployments need to change over time, if for no other reason than machines may fail or performance improvements mean that you want to move a service from one machine to another. Or you may need to deploy more (or less) service instances over time to improve availability. Interestingly some of this overlaps with governance.

You also need to be able to cope with dynamic routing (service locations change and you want to route inflight messages or messages sent to the old address, to the new location). Transformations of data are pretty important too: sending Gigabytes of data to my services that has been deployed on the mobile phone might get a bit costly, but maybe my infrastructure can prune that information while it is inflight and only send a synopsis (or some portion of it that is sufficient for the service do do meaningful work).

Ultimately the service deployments and how they are related to the devices that are available to the infrastructure should be handled automatically by the infrastructure, with the capability to override this or provide hints as to more appropriate deployment choices (e.g., "please don't deploy this service on a mobile phone!") The infrastructure then becomes responsible for managing those services, guaranteeing specific SLAs (so it may mean migrating a service from one device to another, for example, to maintain a level of performance or availability), pulling in more devices or distributing more instances of the service across multiple devices, again to maintain policies and SLAs.

Overall the infrastructure and the way it supports development of services assists in the realisation of loosely coupled, non-brittle applications. By this point you may see where I'm going with this. In my opinion a good infrastructure for cloud computing is also a good infrastructure for SOA, i.e., an SOI. In our case, that would be JBossESB as it continues to evolve and improve. Stay tuned!

JBossWorld 2008 update

2008-02-19T07:10:00.000-08:00

Lots of activity at JBossWorld 2008! As you can find elsewhere, this was the biggest JBW ever and all of the presentations I attended were packed. The ESB/SOA Platform related presentations will be uploaded soon and we'll cross post links here as soon as possible. But in the meantime you may be interested in another announcement about the SOA Platform.

SOA-P now available

2008-02-15T06:58:00.000-08:00

Yesterday at JBoss World the availability of the JBoss Enterprise SOA Platform was officially announced. I don't know how long this webcast is going to be available but a recording can be found here.

SOA Patterns Announcement

2008-02-03T13:36:00.000-08:00

We just announced the patterns work. Definitely worth a look.

SOA + BPM = Killer Combination

2008-01-29T20:26:00.000-08:00

Kurt's recent posting prompted me to put down here what I've been putting off for a while: my thoughts on BPM and SOA. Hopefully it's apparent to everyone that BPM != SOA: they solve different problems. However, that does not mean they cannot compliment each other. The recent work on combining jBPM with JBossESB should illustrate that, but let's go further.

One of the key aspects of SOA is about agility: the ability to react more quickly to changes in the way IT systems need to be deployed and used, as well as being able to leverage existing IT investments. At this level agility is something that is definitely a concern of T-Shirt And Sandle Man, i.e., IT folks and not Men In Suits, i.e., business folks, which is primarily where BPM resides. Where BPM works well is in ensuring that business goals and efficiently aligned with how they are translated into processes, making those processes more reliable, faster and compliant with the businesses policies and practices. Fairly obviously, for business folks, these are just as important as IT agility.

SOA and BPM do not compete with one another: they are natural compliments. A good combination of SOI (Service Oriented Infrastructure) and BPM will make it natural to orchestrate services (or more likely tasks) as second nature within the deployment and not as some bolt-on which is there simply for compliance reasons. I think the combination of SOA and BPM is a "killer app" because:

BPM promotes a model-based approach to task definitions, which, if used right, should ensure that what the business wants is what they get. Importantly it's defined by the business folks and not by the infrastructure. It encourages a top-down approach to service orchestration and requirements: you don't develop what you don't need. I know this sounds pretty obvious, but you'd be surprised!

BPM and tooling are natural allies, as they are with SOA.

Remember that SOA is not a product: it does not come in a shrink-wrapped box. So you shouldn't think that it is simply an ESB or some other technology. It is not purely a technology driven initiative. A good SOI will allow the right people in an organisation to take ownership of the components (technology and business) that are important to them. This is one of the reasons why loosely coupled systems work. SOA does not belong to a single group of people (e.g., the typical developer), but to the business as a whole. That's why SOA+BPM work so well together: it is a natural fit.

Service Orchestration using jBPM

2008-01-25T14:43:00.000-08:00

Service Orchestration is the arrangement of business processes. Traditionally BPEL is used to execute SOAP based WebServices, and in the Guide 'Service Orchestration' you can obtain more details on how to use ActiveBPEL with JBossESB. However, if you want to orchestrate JBossESB services regardless of their end point type, then it makes more sense to use jBPM. Figure 1 shows an order process in jBPM Designer view which is part of JBoss Developer Studio. In this post we will describe what it takes for you to start using jBPM for Service Orchestration.

Figure 1. 'OrderProcess' Service Orchestration using jBPM

Step 1. Create the Process Definition

To create the process definition from Figure 1 you drag in components from the left menu bar. To start you'd drag in a Start node, followed by a regular 'node' type, which we gave the name 'Intake Order'. You can now connect the two boxes by selecting a 'transition', and by first clicking on the start node and then on the Intake Order node. Next we need to tell jBPM which JBossESB service backs this node. This is done by attaching a special 'EsbActionHandler' action to the node and configuring it to go out to the service 'InTakeService'. For now you will need to click on the 'source' tab to drop into the XML representation of this node (see Figure 2).

Figure 2. XML Source of the 'OrderProcess' Service Orchestration

In this case the configuration for the Intake Order the XML looks like

The first two subelements esbServiceName and esbCategoryName specifiy the name of the service, where the other two elements: bpmToEsbVars and EsbtoBpmVars specify which variables should be carried from jBPM to the ESB Message and back respectively. Koen Aers has been working on a special EsbServiceNode so all the configuration can be done in design view.

Creation of the rest of the process definition goes in a similar fashion, ending with an 'End' node, which when reached will terminate the process.

Step 2. Deployment

JBossESB deploys the jBPM core engine in a jbpm.esb archive. This jbpm.esb archive contains the jBPM core engine as well as the configuration and the jbpm-console. To deploy the process click on the 'deployment' tab in the IDE, selecting the files you wish to deploy and clicking on the 'Deploy Process Archive' button.

Figure 3. Deployment of the 'OrderProcess' Service Orchestration

Besides deploying the process definition we also need to deploy the services themselves. Your services are deployed in a yourservices.esb archive. For deployment order you need to specify a depends 'jboss.esb:deployment=jbpm.esb' in the deployment.xml.

Note that deployment of process definitions and esb archives is hot and does not require a server restart.

Step 3. Starting and Running the process

There a multiple ways to start an instance of the process that was deployed in step 2. For instance you can start one from your own code, the jbpm-console, but perhaps the easiest way is to start on using an out-of-the-box service. For instance when your store front receives the order you can create an EsbMessage with the invoice and drop it on the 'StartProcess' service.
You can define a StartProcess service (one for each process definition) in the jboss-esb.xml in yourservices.esb. For instance it can look like

where we use the 'StartProcessInstanceCommand' to invoke a new process instance of the type 'OrderProcess' and with the invocation we insert a business key (invoice ID) and the invoice itself into the jBPM process instance context. Now when a message hits this service a new instance of the shipping process is created and we can look at its state using the jbpm-console (by default running on http://localhost:8080/jbpm-console)

Figure 4. State of an instance of the 'OrderProcess' Service Orchestration

In Figure 4 the 'Review Order' process is highlighted because the process is waiting for a human to review the order. So here we now have integrated human work flow, see Figure 5!

Figure 5. 'Review Order' Human Work Flow Integration

Conclusion
We demonstrated that it is a three step process to use jBPM for Service Orchestration and how to integrate it with Human Work Flow. To get more details you can read the jBPMIntegrationGuide.

Have fun,

--Kurt

JBoss DNA

2008-01-18T01:16:00.000-08:00

Related to our governance story, you should definitely take a look at the new JBoss DNA project.

Tooling and governance

2008-01-17T03:39:00.000-08:00

All good SOA platforms need a good SOA governance solution. Governance covers a number of factors and interacts at different levels of the SOA architecture. For example, there are tooling requirements (displaying the important information, customizing the view on the data, etc.) and infrastructure support (for enforcing SLAs, checking when they are [about to be] violated, etc.) The best governance implementations will perform well across these levels. However, you shouldn't be persuaded just by the gloss of a governance solution: don't judge a book by its cover.

So far we've been concentrating on the low-level infrastructure support for governance, both with JON and more native support within the ESB and other projects. Plus, from the start we've made the registry (UDDI in our case) a central component within the ESB. Plus, the Drools team have been making waves with their BRMS implementation, which is important in governance too. And of course there's the tried and tested jBPM Graphical Process Designer (not directly related to governance, but definitely to tooling) and our friends from MetaMatrix. However, what we haven't been able to do until now is discuss where we are going (both with in-house development as well as with partners).

As well as tools from the individual projects within the SOA Platform, here is a brief synopsis of architectural requirements on SOA-P specific tooling and governance. I don't want to go into details about how these tools (and the necessary supporting infrastructure) are implemented. Depending upon the role of the user or component (more in another posting) it makes more sense for some of them to be Eclipse based, whereas others will be Web console based. There will be some tools that ideally would have representations in both arenas. It's important to realise that some of the capabilities I'm going to mention will have to be duplicated across different tooling environments. For instance, sometimes what a sys admin needs to do is also what a developer needs to do (e.g., inspect a service contract). We won't require the sys admin to have to fire up the developer tool in order to do that. And vice versa.

Governance of SOA infrastructures is critically important. If any of you have tried to manage distributed systems in a local area before, you'll understand how difficult that can often be. Imagine expanding that so it covers different business domains where you (the developer or deployer) do not control all of the underlying infrastructure and cannot work on the assumption that people are trustworthy. With SOA governance, there is a runtime component that executes to ensure things like SLAs are maintained, but there is also a tooling component (runtime for management and design time).

With the JBoss governance/tooling effort, you'll be able to graphically display:

MTTF/MTTR information on behalf of specific nodes and services on those nodes. Also for all nodes and services that are deployed.

throughput for services.

time taken to process specific types of messages (e.g., how long to do transformations, how long to do transformations on behalf of user X).

number of requests services during the lifetime of the service/node (in general, it is always important to distinguish between services and the nodes on which they execute).

number of faults (service/node) in a given duration.

information about where messages are being received.

information about where messages are being sent (responses as well as faults).

potential dependency tracking data. This can be used to determine sources of common failure. Can also be used when deciding whether or not (and where) to migrate services, for improved availability or performance.

what versions of services exist within a specific process (VM).

Includes sending probe messages that can test availability and performance on request. However, this functionality needs to be duplicated into the design-time tooling.

Note, you can do some of this with the current releases!

All of this information may be obtained periodically from a central (though more realistically a federated) data store or direct from the services themselves. However, both sys admins and developers (more of them later) will need to be able to connect to services (and composites) and inspect their governance criteria, e.g., when was the last time they violated a contract, why and under what input messages/state, at will: the dynamic factor is incredibly important. This information needs to be made available across individual services as well as the entire SOA-P deployment.

Going back to what I mentioned earlier about governance. We're working on a separate and dedicated governance console that is used to receive alarms/warnings when contracts/SLAs are violated or close to being violated. Obviously the console is only one such destination for these alerts: sys admin inboxes are just as important. However, that's where the infrastructure comes into play: remember that JBossESB has a very flexible architecture.

Traditional management tooling (e.g., via JMX) would include:

start/stop a service.

suspend/resume a service.
add/update restriction lists for services. This limits the list of receivers that a service considers valid and will process messages from. A similar list of destinations for responses will exist. This plays into the role/relationship concept because although a developer may not consider the issue of security (maybe can't, given that services could be deployed into environments that did not exist when the developer was building the service), the sys admin (or service container admin) will have to.

migrate services (and potentially dependent services).

inspect service contract.

update service definition.

attach and tune specific service parameters.

Design time tooling includes:

defining the service definition/contract, which includes specifying what message types it allows. This is tied into the service implementation in order that the ESB infrastructure can verify incoming messages against this contract for validity. Part of the contract will also include security and role information which will define who can interact with the service (may be fine grained based on time of day, specific message type, etc.) Policies are attached at this level on a per service or per operation basis (if not defined on an operation basis, the service level policy is taken if defined).

policy definition/construction, tracking and enforcement. Not just part of the development tool, but also an integral part of the underlying ESB infrastructure. Policies need to be shared so that other developers can utilise them in their own service construction. Typically these will be stored in the repository.

service construction from other services, i.e., composite services. This has an input on SLA and on governance enforcement. In some cases a physical instance of the service may not exist either and the infrastructure becomes responsible for imposing the abstraction of a service by directing interactions accordingly.

inspecting the registry and repository during design time to locate and inspect desired services for composition within applications. Also ties into runtime management so that the user can inspect all running services. This would also tie into our graphical process flow tool, by allowing a drag-and-drop approach to application construction.

service development then into service deployment. The tool will allow the user to view a list of available nodes and processes. The availability, performance etc. of those nodes will also be displayed (more tooling and infrastructure support). Then you can drag a service implementation on to the node and deploy it, either dynamically or statically. This ties into the runtime management tool that allows the user to view deployed services on nodes (see previously).

Service implementation tool:

from the client perspective you go to the registry and select the right service based on requirements (functional as well as non-functional). The associated contract defines the message format, as mentioned earlier. The tool will either auto-generate an appropriate stub for the client code or provide a way of tying state variables (from the application code, or incoming messages etc.) in to the outbound invocations on the service. Fairly obviously we cannot prevent developers from ignoring the design-time tools and coding their applications without that support, which is really where the need for stubs comes in. At the tooling level, we're really looking at defining client tasks that the developer writes and defines the output instance variables that are hooked into the service's input variables. As far as the client tool is concerned, we are simply tying together these variables. Under the cover, the tool generates the right set of service-specific messages. The ESB infrastructure sends and receives and dispatches accordingly. Capabilities such as security and transactions may be exposed to the client.

from the service developer perspective, we are defining services as compositions of tasks, actions, dispatchers etc. In the graphical designer we specify the input variables that are required for each operation type (defined as specific messages). This also plays into the contract definition effort mentioned earlier, since the message formats accepted by a service are implicitly defined by the requirements on input state variables.

there's a separate discussion to be had about the term "task". The OPENflow work that originated within Arjuna can help here.

WS-CDL tooling here as well.

the need to be able to deploy services into a virtual environment to allow it to be tested without affecting a running system. A service has to be able to be deployed in a test mode. What this means is that at a minimum the service is not available to arbitrary users. Test services should also not be deployed into a running process/container that is being used by other (non-test) services and applications in case they cause it to fail and, worst case scenario, take the entire process with them.

Some things that I have not had a chance to write up yet include roles and relationships between roles, and (related) security and ACLs. Task definitions (lots of notes on that). Diagrams illustrating the kinds of things I want to see. So expect more later.

JBossESB in the press

2008-01-14T01:44:00.001-08:00

This got lost in the end of year celebrations.

Making SOA a science and not an art

2008-01-09T05:08:00.000-08:00

Over 5 years ago, around the time BPEL4WS came out, WSCI was released. Because this was just at the peak of the IBM/MSFT versus everyone else wars the uneducated observer saw this as yet another attempt by Oracle et al to fight the beast. However, WSCI was a far different type of animal. It went to W3C under the guise of the WS-Choreography group and eventually WS-CDL was born. WS-CDL is one of those standards that I've been observing from a far: I was involved at the periphery in the early years of WS-T and OASIS WS-CAF, because of the influence of transactions (and context), but apart from being on the mailing list I've had no further input. But WS-CDL is also one of the nicest, most powerful and most under-rated standards around. So although I've been watching from a far, I've also been waiting for the right moment to use its power in whatever way makes sense.

In Arjuna there were limited opportunities for this. I tried with a few of our engagements, but the "Why do I want this when there's BPEL?" question kept coming up. As a result in some ways WS-CDL is also one of the most frustrating standards: you really want to shake the people who ask those questions and force them to read up on WS-CDL rather than believe the anti-publicity. I also wish that some of the bigger players involved in its development had done a lot more. Oh well, such is life in the standards world.

However, once I joined JBoss and was put in charge of the JBossESB development, things started to change. Here was a great opportunity! Here was a distributed system that was under development, would use Web Services and SOA at its heart, would be about large scale (size of participants and physical locality) and where you simply did not control all of the infrastructure over which applications ran.

Now many people in our industry ignore formal methods or pay lip service to them, believing they are only of use to theoreticians. Unfortunately until that changes Computer Science will always be a "soft" science: more an art than anything. That's not a good thing because it limits efficiency. In a local application (everything on one machine) you can get away with cutting some corners. But in a distributed system, particularly one that needs to be fault tolerant, it's worse. For example, how do you prove the correctness of a system when you cannot reason about the ways in which the individual components (or services) will act given specific expected (or unexpected) stimuli? Put another way, how can you ensure that the system behaves as expected and continues to do so as it executes, especially if it has non-deterministic properties? As the complexity of your application increases, this problem approaches being NP-complete.

Rather than just throwing together an "architecture" diagram and developing services in relative isolation, and trusting to luck (yes, that's often how these things are developed in the real world), we decided that something better had to exist for our customers. Now there are formal ways of doing this using PetriNets, for example. WS-CDL uses Pi-Calculus to help define the structure of your services and composite application; you can then define the flow of messages between them, building up a powerful way in which to reason effectively about the resultant. On paper the end result is something that can be shown to be provably correct. And this is not some static, developer-time process either. Because these "contracts" between services work in terms of messages and endpoints, you can (in theory) develop runtime monitoring that enhances your governance solution and is (again) provably correct: not only can you reason successfully about your distributed system when it is developed and deployed initially, but you can continue to do so as it executes. A good governance solution could tie into this and be triggered when the contract is violated, either warning users or preventing the system from making forward progress (always a good thing if a mission-critical environment is involved).

Now this is complex stuff. It's not something I would like to have to develop from scratch. Fortunately for JBoss (now Red Hat), there's a company that develops software that is based on WS-CDL: Hattrick Software, principle sponsors of the Pi4 Technologies Foundation. Fortunately again, one of the key authors of the standard (my friend/colleague Steve Ross-Talbot) is both CTO of Hattrick Software and Chair of the Pi4 Technologies Foundation. Steve has been evangelizing WS-CDL for years, pushing hard against those doors that have "Closed: Using BPEL. Go Away." signs on them. We're starting to see the light as users see the deficiencies of BPEL (the term "Use the right tool for the right job" keeps coming to mind) and look for solutions. But it's been a long, slow process. But when like minds come together, sometimes "something wonderful" can happen. People at Hattrick have been working with us at Red Hat for several months, to integrate their product (which is open source and lets you develop scenarios to test out your deployments and then monitor them for correctness once they go live) with JBossESB and the SOA Platform. This work is almost complete and it will offer a significant advantage to both companies customers.

I can't really go into enough detail here to show how good this combination is, but here are a few example images. The example scenario is a distributed auction, with participants including a seller and several buyers. With the WS-CDL tooling you can define your scenarios (the interactions between parties) like this

You can then use the tool to define the roles and relationships for your application:

And then you can dive down into very specific interactions such as credit checking:

Or winning the auction:

We're hoping to offer a free download of the Hattrick Software for the SOA Platform in the new year, and maybe even for the ESB. Since it's all Eclipse based, it should be relatively straightforward to tie this into our overall tooling strategy as well, providing a uniform approach to system management and governance. But even without this, what this combination offers is very important: you can now develop your applications and services and prove they work before deployment. Furthermore, in the SOA world of service re-use, where you probably didn't develop everything, a suitable WS-CDL related contract for each service should allow developers to re-use services in a more formal manner and prove a priori that the composite application is still correct, rather than doing things in the ad hoc manner that currently pervades the industry.

SOA Patterns

2007-12-19T08:54:00.000-08:00

I'm in the middle of writing a book on SOA and ESB with Thomas Erl. One of the things to come out of that collaboration was the donation of the SOA Modeler (that should be going into our repository soon). Another is the fact that Thomas is working on a new book around SOA Design Patterns and I've been contributing some of them along with my other co-authors on the SOA/ESB book. This should be an excellent source of SOA knowledge. The site has all of the current material and a form for providing feedback. If you're interested in SOA and patterns then you should definitely check it out.

JBoss Innovation Awards

2007-12-13T04:04:00.000-08:00

Submit for the JBoss Innovation Awards: www.jbossworld.com/jbia. Enter your JBoss use case in one of eight categories. Each category winner gets a free Complete Conference Pass. If you've already paid for your pass, you will be reimbursed. And, one case will be selected from all of the category winners as the Innovator of the Year. The Innovator of the Year will receive a $1000 stipend for team-building or reward for team involved in the winning innovation project, as well as 3 free passes to a future JBoss World or Red Hat Summit 2008 conference. Simply fill out the form. Deadline to submit is December 14th!

JavaPolis update

2007-12-13T04:01:00.000-08:00

Just back from JavaPolis, where I spoke in front of about 400 people on the SOA Platform and JBossESB. It went down very well with the audience and yet again I found out that there are quite a lot of people going into production with the ESB. Very cool.

JavaPolis

2007-12-10T00:09:00.000-08:00

I'm off to JavaPolis tomorrow to present on SOA and JBossESB. I hope to be able to pepper the talk with some indications of what we'll be working on in 2008 for the SOA Platform. Once it's uploaded, I'll post a link to the presentation.

Transactions in a Service Oriented Architecture

2007-12-08T00:57:00.000-08:00

If you want to see some of the things we have in mind for future releases, then you may want to check out this interesting cross post about the evolution of transaction processing and how it has been shaped by Web Services and SOA.

Help required ...

2007-12-07T11:15:00.000-08:00

We're getting closer to releasing the JBoss SOA Platform, which is based on JBossESB 4.2.1GA, with patches. If you haven't already, it would be really useful if people could try to download the ESB and kick the tyres so we can as much feedback as possible. If you want to try the bleeding edge, check out and build the Cumulative Patch for 4.2.1. If you find anything to report, let us know through the forum. Thanks.

Did we ever ...

2007-12-07T10:39:00.001-08:00

I'm not sure if we ever cross linked Burr's overview of JBossESB 4.2 and it's quicker to type this entry than look through the back posts.

Swedish Railways and JBossESB

2007-11-28T06:06:00.000-08:00

In May 2006, Swedish Railroads (SJ) was looking to upgrade its internal software delivery system in order to provide a shared platform for all IT systems. The integration of the IT systems is essential for SJ as it uses a diverse range of applications ranging from HR to sales, which need to be accessed across a range of interfaces, from PCs to PDAs. Within SJ, a new department was established with the task of building an integration platform and delivering new services for the business to operate on the platform. Swedish Railways is the national railway operator in Sweden. The company has around 350 stations, carrying 70,000 passengers per day. The company employs approximately 3200 staff and has a turnover of approximately $1 billion.

SJ put the contract out to tender, receiving proposals from many of the large SOA/ESB vendors, including JBoss. After extensive trial period SJ selected JBoss middleware solutions for its integration platform, due to its satisfaction with the product, its use of open standards and the impressive performance when compared to the other solutions.

Working with Redpill, the JBoss-based Integration Platform was launched in January 2007. The first major project, in May 2007, was the creation of a ticket auction system to sell unsold tickets on Tradera.com, the Swedish auction website owned by Ebay Inc. Using the ESB, any tickets which have not been sold by SJ with 2 days of departure are automatically transferred to the Tradera system, where they are available for auction until 6 hours before departure. On the 4th of October 2007 SJ went live with JBossESB! SJ's CEO did a live demo at a press conference to announce the release. The news was reported by every major paper and news channels, so this is a great success for SR, Redpill and JBossESB.

As the first test of the new SJ Integration Platform, the Tradera.com integration project based on JBossESB was a resounding success, and completed within only 4 months. SJ is now able to sell thousands more tickets per week, which previously went unsold. The entire process is automated, with the details of the unsold tickets being passed directly to the Tradera system.

Now that the Integration Platform is up and running, SJ plans to deliver a new project every 2 months. The upcoming projects come from both internal and external demand, for projects which could either be consolidating existing systems or creating new products.

A satisfied JBossESB user

2007-11-22T05:24:00.000-08:00

I meant to reference this a few weeks back. It's always nice to get feedback from users who are deploying JBossESB in the field. I spoke with Igor about his application and why he chose JBossESB and this is what he had to say:

"I designed a complete framework for a health/wellness startup. It provides health and wellnes services to individuals and corporations/partners via the web and mobile phones. All requests from users go through a business process manager, which in turn orchestrates the process by invoking appropriate services via JBoss ESB. In some instances the logic routes the request to a local Spring managed POJO to execute the service. The same POJOs are actually handling requests via ESB. I created what I called SpringJbossEsbActionProxy to actually grab appropriate Spring managed POJO instead of instantiating a new service class for every invocation.

Though I am not a JBossESB expert, but I am happy I decided to use the product and will recommend it to my future clients."

Thanks for the blog entry Igor. If there are any others out there like this, let us know.

JBossESB 4.2.1 GA is out!

2007-11-01T09:02:00.000-07:00

The JBossESB team have done it again and released another great update to JBossESB. Although this release is primarily to catch bugs and improvements to reliability and performance, there are a few new features that you may find interesting. Take a look: it's well worth it.

Congratulations to the whole team!

Interesting article

2007-10-19T09:24:00.001-07:00

Worth a look.

JBossESB 4.2 GA released

2007-09-08T16:49:00.001-07:00

In case this has gone unnoticed, the team just released JBossESB 4.2 GA. This is a significant milestone for Red Hat, as something very close to this release will be the basis of the up coming SOA Platform. Furthermore, 4.2 GA is a huge leap on from our last GA, 4.0, which was over 6 months ago! Some of the things you'll find in there have been blogged about already by the team (and expect more blog entries as soon as I can persuade them to write up a few!), but you'll find:

New clustering and fail-over capabilities (thanks to Kurt).

Much better fault handling and reliability (thanks to Kevin).

Built-in monitoring and management (thanks to TomC).

Yet more transport support, including OracleAQ.

Web Services through JBossWS (thanks to TomF).

Some very nice integration with jBPM (Kurt) and WS-BPEL (TomF).

More examples (thanks to Burr and the team)!

Although we're not selling support for this version (that will come once the SOA Platform is released), we are running an Early Adopter Program. If you want to participate, or just want more details, let me know.

So if you haven't already, I'd encourage you to go take a look and give us feedback (as usual). Congratulations to Kevin and the entire JBossESB team, which definitely includes our fantastic community developers!

Service Clustering

2007-08-23T08:00:00.000-07:00

In mission critical systems it is important to design with redundancy in mind. JBossESB 4.2.GA will be the first version with build-in fail-over, load balancing and delayed message redelivery to help you build a robust architecture. When using SOA it is implied that the Service has become the building unit. JBossESB allows you to distribute service instances across many nodes. Each node can be a virtual or physical machine running one or more instances of JBossESB. In this article it is shown how you can go about setting up Distributed Services, Protocol Clustering, Fail-over, Load Balancing and Message Redelivery.

--Kurt

Services, services, services

2007-08-04T00:24:00.000-07:00

A really good discussion to a nice post from Kurt on where to start with service development. The advice differs from what I said in an earlier post, but as you'll see from the comments to Kurt's post, they're not mutually incompatible. Taken together, they represent the top-down and bottom-up development approach I mentioned:

top-down (business logic development): do as Kurt suggests and develop your business logic using whatever tools and methodologies you think are appropriate. From a high level perspective, this is as critical to your success as ever.

bottom-up (service development): do as I suggest and think about the contract you want your service to expose and how that would map into message exchanges (content, sync versus async etc.); try to keep it as agnostic to the backend business logic implementation as possible (e.g., don't go exposing individual objects on to the bus). The service is your route into SOA: get it right and you'll be able to leverage all of the benefits the industry keeps pushing.

You can develop these two aspects sequentially or concurrently (even by different teams, which allows each team to concentrate on the right skill sets needed for each role). This is an aspect of what's traditionally called the service lifecycle part of governance. It isn't easy to get it right first time without appropriate tools and patterns. Plus experience helps a lot here: even with tools/patterns, you'll find it easier to do the more you do it.

How to design new services? Best practices.

2007-08-02T08:59:00.000-07:00

If you have existing applications out there that need integration, then the problem space is fairly well understood. But what if you you are building a NEW application? Here is a question I received:

We have a big project here. It doesn't involve integrating existing software, but does involve a lot of parts that I think could best be written as web services so that they can be reused by other parts of the business, etc. Is it good to break up a project into services or is SOA better when you are trying to integrate things that aren't meant to go together or stuff that has remote components, etc. Basically, what I'm saying, is that I could put all this stuff into nicely organized java code, or I could break it out into services, and I don't know which to do.

I think the answer is that you should keep on writing your application like you always did. Write a tiered application, and make sure the business logic ends up in the (stateless) middle tier. Now this middle tier will exist of EJBs or POJOs. Next you will have to do two things:

1. Turn them into a service.
2. Register the service with the ESB.

There are multiple ways to go about achieving the above:

EJB

Use EJB annotations to turn your POJO into an EJB. You can now register the EJB with the ESB by writing a custom action which calls the EJB. This is demonstrated in the bussines_service quickstart. The action receives a message, some objects can be pulled out and used to send to the EJB. The return value of the EJB can be used to update the message.

WebService

Add JSR-181 annotations to bring up a WebService. Now if you do this using JBossWS something cool happens. If the ESB runs on the same instance it auto-discovers these services and registers them with the ESB. Now can can send a soap message to a gateway and the ESB will forward this message to your WebService. So, for example, you can now send SOAP messages in a file to an ftp server. See the webservice_producer quickstart.

Seam

If you have used seam to build your app, you can take take a look at Michael Yuan's write up called "Seam-and-SOA" when he attended a JBESB training earlier this week. Also we have an integration example with the Seam DVD store that Burr created. Be on the lookout for this to become a quickstart too.

Spring POJO

Use Spring annotations to turn your POJO into a Spring enabled POJO. Now write a custom action to call the bean. See the Spring_OAP quickstart.

I hope this demonstrates the pattern. To be clear on why you should take the extra step to register your service to an ESB, this is to obtain capabilities like routing to multiple destinations, content-based-routing, message transformation, service orchestration (jBPM or BPEL), service-human workflow integration (jBPM), bringing up services over different protocols (ftp, file, etc). I guess that list is pretty well documented on the project page.

--Kurt

Where to start with services

2007-07-30T13:34:00.000-07:00

If you ask 100 people what they mean by SOA applications you'll probably get 100 different answers. However, there are some common requirements:

i) they should scale from several to hundreds and thousands of participants/services.
ii) they should be loosely coupled, so that changes of service implementation at either end of an interaction can occur in relative isolation without breaking the system.
iii) they need to be highly available.
iv) they need to be able to cope with interactions that span the globe and have connectivity characteristics like the traditional Web (i.e., poor).
v) asynchronous (request-request) invocations should be as natural as synchronous request-response.

Scalability and availability are possible with other technologies, such as CORBA. Although (ii) and (iv) can certainly be catered for in those technologies as well, the default paradigm is one based on an implementation choice: objects. Objects have well defined interfaces and although they can change, the languages used to implement them typically place restrictions on the type of changes that can occur. Now although it is true that certain OO architectures, such as CORBA, allow for a loosely coupled, weakly types interaction pattern (e.g., DII/DSI in the case of CORBA), that is not typically the way in which applications are constructed and hence tool support in this area is poor.

There is no objective way in which to approach the question of whether SOAs can be catered for in traditional environments. The answer is obviously yes, because no new language has been invented for SOAs and current tools are used to develop them. However, the real question is what is the best paradigm in which to consider an SOA that allows it to address all 5 points above.

Concentrating on the message and making it the central tenant of the architecture is the key to addressing the 5 points. How this is mapped onto a logical architecture (objects, procedures, etc.) and ultimately onto a physical implementation (objects, methods, state, etc.) is not important. The fact is that many different implementations and sub-architectures could be used. So what is the fundamental concept or mind-set in which to work when considering SOA?

The answer is that this is not about request-response, request-request, asynchrony etc. but it's about events. The fundamental SOA is a unitary event bus which is triggered by receipt of a message: a service registers with this bus to be informed when messages arrive. Next up the chain is a demultiplexing event handler (dispatcher), that allows for sub-services (sub-components) to register for sub-documents (sub-messages) that may be logically or physically embedded in the initially received message. This is an entirely recursive architecture.

JBossESB does not impose restrictions on what constitutes a service. The ideal SOA infrastructure encourages a loosely coupled interaction pattern between clients and services, where the message is of critical importance and implementation specific details are hidden behind an abstract interface. This allows for the implementations to change without requiring clients/users to change. Only changes to the message definitions necessitate updates to the clients.

As such, JBossESB uses a message driven pattern for service definitions and structures: clients send Messages to services and the basic service interface is essentially a single doWork method that operates on the Message received. Internally a service is structured from one or more Actions, that can be chained together to process incoming the incoming Message. What an Action does is implementation dependent, e.g., update a database table entry, or call an EJB.

When developing your services, you first need to determine the conceptual interface/contract that it exposes to users/consumers. This contract should be defined in terms of Messages, e.g., what the payload looks like, what type of response Message will be generated (if any) etc.

Clients can then use the service as long as they do so according to the published contract. How your service processes the Message and performs the work necessary, is an implementation choice. It could be done within a single Action, or within multiple Actions. There will be the usual trade-offs to make, e.g., manageability versus re-useability.

Hello World

2007-07-28T07:10:00.000-07:00

How do you get going with JBossESB? If you need a place to start take a look at the Hello World demo. It is a five minute introduction in which you learn

how to start and stop JBossESB in debug mode from within the JBossIDE,
how to deploy your first service: Hello World!

The Hello World Service is actually one of the QuickStarts in the provided samples. The prerequisites are JBossIDE (2.0 beta2), and JBossESB-server-4.2MR3. Both of which can be downloaded from jboss.org. The wiki provides a good start, and please help us keep it up to date. Our project has lot of contributors, the number of features is growing rapidly and there is nothing like accurate up-to-date documentation. You're invited!

--Kurt

"Introducing" JAXB Annotations on Unannotated Java Typesets

2007-07-04T10:28:00.000-07:00

Over the past few weeks we worked on migrating the SOAPProcessor (formerly known as "JBossWSAdapter") up to the JBossWS 2.0.x codebase. This was important for us because we wanted to get away from our dependency on a non-public JBossWS 1.x API. JBossWS has introduced a new SPI into the 2.x codebase. Changing the JBossESB SOAPProcessor action component to depend on this public SPI was a no-brainer.

However, the native SOAP stack in JBossWS 2.x depends on JAXB for SOAP<->Java binding. This raised an issue for us because JAXB is 100% driven by annotations on the Java binding classes. If your Webservice Java bindings are not JAXB annotated, JAXB will not marshal/unmarshal SOAP<->Java properly (see JAXB forum post).

A classic JBossESB usecase is one where the ESB is used to expose a Webservice interface for an existing Java based Service that doesn't already expose a Webservice interface. In this situation, you can use the ESB to define a "wrapper webservice" that maps calls to the target Service (we'll be automating this in a future release). In this situation you'll also want to use the Java types that define the target Service, when defining the "wrapper webservice" e.g. use an EJB's remote interface, without modification, to define a JSR 181 wrapper service.

So, in the usecase outlined above, the Java types that define the target Service are obviously not going to be JAXB annotated (or at least they typically will not be). At this point, using JAXB (and therefore JBossWS 2.x) is no longer an option, since JAXB will not work against an unannotated interface.

The JAXB RI API supports setting a RuntimeInlineAnnotationReader during JAXBContext creation. We've used this feature to support "Introduction" of the JAXB annotations, from an XML configuration, for interfaces that are not JAXB annotated. It works by creating dynamic proxies for the annotations as they are requested by JAXB RI, with the dynamic proxies being fed via an XML configuration. See "JAXB Annotation Introductions" for more details.

Having done this, and having talked with the JBossWS guys, it would appear as though users of JAXB are not the only ones that run into trouble as a result of not having an alternative to a purely annotation driven configuration model (JSR 181 being another example that Thomas Diesler and Hieko Braun have pointed out). Is there room for a general purpose mechanism that can be used to manually "Introduce" annotations in situations like this? Obviously you could suggest that implementations should just support 2 configuration models - internal (annotations) and external (something else - fed by XML, or whatever). But surely a single underlying configuration/metadata "access" mechanism (the Annotations API) is preferable.

The Annotation Reader approach (ala JAXB Introductions) seems to offer something along these lines, but it would be nice if it could be done without requiring the annotation reader i.e. it would be nice if we could introduce annotations directly on the Annotations API (AOP style).

Webservices and WS-BPEL Process Orchestration - A Follow Up

2007-07-04T10:01:00.000-07:00

We've done quite a bit of work in the Webservice/SOAP area since I posted Webservices and WS-BPEL Process Orchestration.

Since then we've added the SOAPProcessor (SOAP onto the bus) action to complement the SOAPClient action (SOAP off the bus). Check out the Webservices/SOAP components and let us know what you think.

We had some fun upgrading to JBossWS 2.0 after we ran into issues with JAXB and how it doesn't allow us to use Java bindings that are not JAXB annotated. More on that in another blog.

Webservices and WS-BPEL Process Orchestration

2007-05-29T09:16:00.000-07:00

We've just added some functionality to the ESB in support of making invocations on external Webservice Endpoints from within the ESB. This functionality is available right now from SVN and will be officially released in the 4.2GA release (July '07).

The main feature is the ability to construct SOAP requests and consume SOAP responses without having to generate proxy code. All that's required is configuration of the “SOAPClient” action class, specifying the location of the Endpoint WSDL and the name of the operation to be invoked.

Get all the details about the SOAPClient action from the WIKI.

This functionality is very important because it supports SOAP unaware endpoints making invocations on SOAP endpoints. This is only half of the new Webservices functionality being added for 4.2GA. We're also adding functionality to support exposing Webservice interfaces for Webservice unaware endpoints. Milestone Release 2 (MR2) of JBossESB 4.2 prototyped this functionality in the JBossWSAdapter action class. We are about to rework and enhance parts of that prototype for the GA release. More on this later.

With both of these pieces of functionality in place for 4.2GA, not only do we have strong support for Webservices in general, but we also open the door to supporting WS-BPEL style orchestration of Webservice unaware Services through the ESB. To this end, JBoss has partnered with Active Endpoints. Active Endpoints have developed a 1st Class WS-BPEL Engine called ActiveBPEL.

To see how well JBossESB and ActiveBPEL work together, see the flash demos available on the ESB labs pages.

Dive Deep into JBoss ESB

2007-05-17T05:37:00.000-07:00

Yesterday Burr hosted a great webinar called "Dive Deep into JBossESB". In typical Burr style he was able to transfer an incredible amount of information. He started of with an overview of all the currently available features in JBossESB tying them to real world scenarios, while sketching out how you would convert your existing applications to get them to play nicely using SOA. The demos showed how easy this really has become. I do have to say that the webinar platform was tough on displaying the jboss-esb.xml file. It would flash by too quickly, but the good thing is that all these demos are part of the JBossESB download, so you can pick them apart and replay them on your own pace. I thought the demos themselves worked very well to demonstrate the capabilities, and they all went off flawlessly. The best demo by far was the jBPM integration demo where he moved a few arrows in the flowchart editor and having the message flow be altered. Great visual!

The questions showed that people really understood the presentation as well as the product, and almost half the people hung around for another 45 minutes to interact with the team to get their questions answered. If we ended up not answering your question, then please take them to the forum, and we'll try to answer it there. The slides have been attached to the wiki , see the link under the 'Presentations' header. If you missed it, there is another session next week May 22nd. You can sign up at the same place in the wiki. A recording of the webinar will be available next week. Don't hesitate to give us any feedback right here in the blog.

I hope you enjoyed it as much as I did :).

--Kurt

JBI 2.0

2007-05-17T05:03:00.000-07:00

I was asked to give a BOF at JavaOne around JBI 2.0. Here's what I had to say.

JBossESB 4.2 MR2 released

2007-05-08T07:17:00.000-07:00

We've just released Milestone Release 2 of JBossESB 4.2. This is quite a significant update for us with a number of significant changes that the team will blog about later, including:

WS-BPEL support: now have your BPEL processes exposed through JBossESB.

Web Services support through JBossWS integration.

More integration with EPRs for messages, such that faults and replies can be routed via the message header information.

Support for Oracle AQ as one of the JMS transports.

Some cool new quickstarts.

Closer jBPM integration.

If you haven't taken a look at JBossESB yet, then I'd encourage you to do so now and give us feedback. This is a community development effort, so come and get involved however you can.

XSLT via Smooks - Comparisons

2007-03-28T05:37:00.000-07:00

As you may already know, JBoss ESB uses Smooks to perform message transformation. One of the design goals of Smooks is to support fragment based transformations i.e. targeting transformation logic at a fragment of an XML message/document as opposed to the whole message. The good thing about this approach is that it not only means you can perform more componentization of your transformation logic, but it also means (often more importantly) that you can easily mix and match different types of transformation logic (XSLT, Java, Groovy, StringTemplate etc) within the context of a single message transformation. This is a very powerful feature. From a purely XSLT perspective, this also means you can have functionality equivalent to XSLT Extensions (Xalan Extensions), but maintain portability across XSL Processors.

I recently performed some performance profiling of Smooks based XSL transforms, comparing them against standalone XSLT. This was done in order to get a better idea of the overhead incurred by using Smooks to perform XSL based transforms. I'll attempt to answer the question of why you'd bother applying XSLT via Smooks in future blog.

The comparisons were run on a Dell Latitude D820 (2GHz Dual Core), 2 GB of RAM, running Windows XP, running jdk1.5.0_10.

For this round of comparisons (I hope to do more some time in the future):

I selected a very simple message format (an with multiple ), as well as a very simple set of XML to XML transformations to be performed on that message. I wanted to keep it simple in order to keep the resulting XSLTs as simple as possible. This way I hope I can get a "worse case scenario" re the overhead incurred while using Smooks to perform XSL transforms. The tests are available here.
I compared the number of messages transformed in a 6hr time period.
I compared the results produced by using the following XSLT processors: Sun XSLTC (JDK 1.5), Xalan 2.7.0, Saxon 8.7.
I compared the results produced by a DOM Source and Result for XSLT Standalone versus a DOM Source and Result on Smooks.
I compared the results produced by streaming both the Source and Result for XSLT Standalone versus a DOM Source and Result on Smooks (Smooks only supports DOM based XSLT).
I tested against 10 input messages ranging in size from 20K to 200K. That is, 10 threads running concurrently, continually transforming, each pausing for 10ms between iterations.
The message bytes were read and buffered in memory so as to avoid File IO variabilities.
During the timed test runs, I didn't compare the transformation output against the expected output. However, I did perform preliminary test runs on all processors and verified that the output produced across the board was consistent. The one exception to this was Xalan 2.7.0, which has a concurrency bug that results in the transformed output not being consistent when the XSL is not applied in a synchronized fashion. I still ran the tests against Xalan unsynchronized, so as to get an idea of how it would perform, assuming the absence of this bug.

The test results (listed below) clearly show that streaming XML into an XSL processor makes a huge difference in terms of throughput. The fact that streaming is faster did not surprise me, but the extent of the difference did. In some cases the whole process (taking the input stream, transforming it and producing the output stream) was up to 4 times faster than the poorest performing alternative (taking the input stream, paring it to a DOM, transforming the DOM to a DOM using the XSL Transformer and finally serializing the resulting DOM to the output stream).

In summary, the performance figures are as follows....

DOM based XSLT Vs Smooks based XSLT (also DOM based):

	Total Bytes - XSLT	Total Bytes - Smooks/XSLT	Smooks Relative Performance
Sun XSLTC	70953094656	59952608928	84.50%
Saxon 8.7	31988047248	29874631032	93.39%
Xalan 2.7.0	40090038120	38571310512	96.21%
			(full details)

Stream based XSLT Vs Smooks based XSLT (DOM based):

	Total Bytes - XSLT	Total Bytes - Smooks/XSLT	Smooks Relative Performance
Sun XSLTC	223776189216	59952608928	26.79%
Saxon 8.7	146482894440	29874631032	20.39%
Xalan 2.7.0	86316614136	38571310512	44.69%
			(full details)

To understand what this means for JBoss ESB Transformation, you first need to understand what it means for Smooks. At the top of this blog I mentioned how Smooks implements a fragment based approach to message transformations (including some of advantages of that approach). The down side to this fragment based approach is that Smooks currently supports this via a DOM based model.

So what does all this mean for JBoss ESB Transformation. Well, because JBoss ESB Transformation relies on Smooks to manage and apply transformation logic (including XSL transforms), it means that JBoss ESB cannot currently avail of the performance advantages offered by streaming messages into an XSL Processor. So, for a transformation where you don't need to features offered by Smooks (fragment based transforms etc) and you want to implement the transformation in XSLT, the performance hit is quite significant.

Luckily, this is not all that difficult to work around for JBoss ESB because we can simply implement a native XSLT ActionProcessor that can apply XSLTs using streaming. This is just a couple of lines of code - no big deal. From a Smooks perspective, there's a little bit more involved, but I don't think all that much. In short, Smooks could simply check the resources targeted at the message exchange in question, and if there's only one, which is targeted at the "docroot" fragment, and it's a stream supporting resource, then stream it - no need to DOM'ify. This would enable JBoss ESB to have the best of both worlds again... stream based XSLT + management and exchange based selection of transformation resources (via Smooks). We'll keep this for another blog :-)

JBossESB 4.2 Milestone Release 1 is out!

2007-03-24T07:32:00.000-07:00

We've just released MR1 for the 4.2 version of JBossESB. It's surprising how much work we've managed to cram into the time between the 4.0 GA release and this! We've increased the developer community size yet again (we're averaging 1 new contributor a week) and Bill Burke has begun to get involved too. Welcome Bill!

There have been quite a few changes between 4.0 GA and 4.2 MR1, including:

jBPM integration: you can now invoke a service, use an ESB action to start a new process and signal a process, all from within the ESB.

Groovy scripts can be embedded within the ESB via the action framework.

Configure your ESB graphically, via a community donated editor.

Scoped deployments within the same ESB server; see Kurt's earlier posting.

JBoss Messaging 1.2.0GA is now the recommended JMS implementation, both for standalone and embedded operation.

We've improved the performance of the ESB, particularly if you use JMS as your transport.

There's now a Dead Letter Queue for the CBR; if it can't route your message then at least it can be persisted for later offline management.

There's more to come too as we move towards JBossESB 4.2 and 5.0. Hopefully this will give you a flavour of what's to come. Over the next few days, members of the team will post a few entries here on different topics of interest around our ESB. If there's anything specific you'd like to see an entry on, just let us know and we'll try to accommodate you.

The esb archive does not end in ar.

2007-03-22T15:47:00.000-07:00

After jar, war, ear, sar and har we now have a new type of archive called esb! An esb archive is one of the new features of our upcoming release and it packages up both your configuration and your custom code (action classes) in one neat package. The structure of the esb archive looks like:

├───META-INF
│   └───jboss-esb.xml
│   └───MANIFEST.MF
├─── classes
├─── queue-service.xml

What used to be called jbossesb.xml is now called jboss-esb.xml and it lives in the META-INF directory of the archive together with the MANIFEST.MF. Your custom action classes go in the root of the archive and optionally you can add a queue-service.xml definition to bring up any Queues or Topics that are specific to this ESB package.

All the ESB libraries and property files are now consolidated into one jbossesb.sar archive and you can simply deploy the esb archives to the deploy directory. Yes archives (plural), you can deploy multiples of them!

W3C Workshop Day 2

2007-03-05T09:12:00.000-08:00

The second day of the workshop was even more interesting then the second one. The theme of this day was "Separate or Together? (i.e. one Web or two?)". The "mashup" technology has demonstrated you can offer up a Service on the Web and people can use it their applications just fine. Think of the Google maps - Greg's List integration alone. What does this mean for WebServices? Should the W3C create a REST Description language (e.g. standardize WADL)? Mark Baker went as far as saying we don't really need WebServices at all, but I think the general consensus was that some form of integration of the two world would be a better alternative. Both technologies have their own strengths, but it would be nice of WebService technology would still 'work' on the Web. In other words WebService should at least support the HTTP/GET, and the URI should be identifying address.

This brought up a nice discussion on EPRs, which was interesting for me, since JBossESB is using EPRs. EPRs look a lot like URIs, but they can contain more information, and they are not identifiers like URIs are. In fact an EPR should be able to "fall back" to a URI is its simplest form, in a manner that is consistent with REST. Let's learn from the Web and try to make the Web and Web Services live in Harmony. Both architectures are in use and the market place will determine where these technologies develop. Maybe use the URI part of the EPR as identifier. The Web has taught us the power of the URI. Let's see what WADL can do for REST.

Finally I wanted to mention a presentation by David Booth on Resource Description Framework (RDF). His point is that to (automated) service interaction is hindered by non-consistent data naming ('babelonization'). And RDF provides a framework to describe a piece of data in a standardized manner such that data integration can be automated. Such a framework would reduce the complexity of service integration dramatically. Maybe something our Smooks engine can take advantage off by generating transformations on the fly.

It looks like time and the marketplace will tell if and how the two Webs will converge.

W3C Workshop Day 1

2007-03-02T08:31:00.000-08:00

Well last Tuesday I was at a workshop of the W3C. A first for me, and I enjoyed it a lot, after I got the acronyms down that is. I loved having the wikipedia at my fingertips I have to say!

The first day was titled "What's missing from the picture - new stuff to consider". The gist of that day was that some people fully embraced Web Services with SOAP and WSDL. The speed of development is great, and there are a great number of extension standards to make Web Services into first class Services. I actually presented a paper by Mark to push towards a general context standard in Web Services.

However other voices were calling to "Stop making standards and let's make things work". This quote is from Paul Downey from BT and it resonated with a lot of other people in the meeting. Basically vendors are still working out some interoperability issues and there are no 'best practices' available on how to really use SOAP with all it's WS-* extensions. They were calling on the w3c to provide somekind of test suite and knowledge base. In my humble opinion I see a huge oppertunity for the Open Source community to jump in here, and for the JBossESB in particular. I think we should lead the way to bring WS-* to the developer community. JBoss has always been very much in touch with the developers, and I think there is an opportunity for the JBossESB team to show how these standards can be used to right way.

Well I'd love to hear what you think. Stay tuned for what happened on day 2 of the workshop!

CORBA with angle brackets?

2007-02-27T12:51:00.000-08:00

After many years of relative success CORBA gave way to Web Services. Showing my age, I was at the first OMG meeting where SOAP was introduced and at the time it was generally accepted as a cool way of getting past the firewall and not a lot more. There was no Web Services architecture and certainly no grand plans along the lines of the CORBA architecture. At that time most people were worried about CORBA versus DCOM or CORBA versus J2EE, and not whether XML over HTTP would become a serious challenger in the EAI space.

However, over the years SOA has become more widely accepted and Web Services as the preferred implementation choice. The loosely coupled, long duration nature of inter-organisation interactions suits SOA well and the amount of vendor support for Web Services (as well as using HTTP) makes them a natural fit. The weaknesses of the CORBA and DCOM distributed object models have been well reported over the years (and firewall vendors didn't help) and both SOA and Web Services proponents have talked about not falling into the same pitfalls.

So it is with some surprise thatI came across this from the W3C TAG. I don't have a problem with defining state in Web applications, but it's got to be done right or we will revert to the closely-coupled nature of the past. It's nice to see Dave saying that his company's application server uses WS-Addressing and yet is scalable and fault tolerant, but that doesn't address the point we've been making: the general notion of context is a better approach. It is more scalable and much better suited to loosely coupled interactions. That's why JBossESB has had the notion of context at its core from the start.

Sure, you can use a tightly coupled interaction pattern like object keys in your favourite application server or ESB, but that doesn't necessarily make it right. What it does do is make it more complex from implementation, management, scalability, fault tolerance and flexibility perspectives. You may be convinced by your favourite sales person today, but without a suitable loosely coupled architecture at the heart of your SOA infrastructure or ESB, you may repent at leisure!

JBossESB, Web Services, Context and W3C

2007-02-25T14:50:00.000-08:00

Back in December, I was asked to be on the program committee for the W3C Web of Services for Enterprise Computing workshop. There were some great submissions on a variety of topics, one of which is on the need for a general context approach for Web Services. Unfortunately plans change and I can't attend the workshop, but Kurt has agreed to stand in. Hopefully he'll post a summary of the workshop here, because I think it'll be a great gathering of the various Web Services clans. Furthermore, I'm sure it will influence some of the work we have ahead of us in the JBossESB project.

Welcome

2007-02-19T13:48:00.000-08:00

Welcome to the JBossESB blog site. The team will be updating this regularly with articles and view on ESB, SOA and our product. Enjoy.