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.