SOA Patterns

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

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

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

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

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 ...

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 ...

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

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

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!

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

Worth a look.

JBossESB 4.2 GA released

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

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

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.

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

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

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

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

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

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

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

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

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

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):

1. 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.
2. I compared the number of messages transformed in a 6hr time period.
3. I compared the results produced by using the following XSLT processors: Sun XSLTC (JDK 1.5), Xalan 2.7.0, Saxon 8.7.
4. I compared the results produced by a DOM Source and Result for XSLT Standalone versus a DOM Source and Result on Smooks.
5. 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).
6. 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.
7. The message bytes were read and buffered in memory so as to avoid File IO variabilities.
   
8. 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!

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.

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

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

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?

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

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

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