by Esther Schindler

Open-Source SOA Proves Valuable to Business Processes

Jun 19, 20083 mins
BPM SystemsJavaWeb Development

A presenter from JBoss at the Red Hat Summit itemized the stages of service-oriented architecture, showed how businesses are benefiting today from the company's SOA platform and offered SOA predictions for two years in the future.

The Swedish railroad SJ had a bright idea: Integrate its ticket sales with online auctions. Any seat that hadn’t sold by 48 hours before the train was due to leave the station could be placed on the Nordic version of eBay called Even if the seat was auctioned for a lower-than-retail price, the railroad would get money it wouldn’t otherwise see, it would improve train utilization and consumers could get a hefty discount. Great deal. But how do you pull that off with existing IT services? Especially since this project would generate millions of SMS messages?

To get this project on track, the Swedish railroad (which has 100,000 passengers per day, 350 destinations and $1 billion in annual revenue) turned to service-oriented architecture (SOA)—and to the JBoss Enterprise Platform in particular.

The Swedish railroad’s technology challenge isn’t unique. Their experience is representative of enterprise IT needs and corporate evolution of SOA adoption, according to Pierre Fricke, director of SOA product line management for JBoss, speaking at the Red Hat Summit.

Fricke described several stages in how corporations evaluate and adopt SOA. For example, SOA adoption has to start with an understanding of how the business process works today, how IT currently serves those needs and how it might do so in the future. IT leaders have to discover their own answers to questions like:

  • What should be a service?
  • How will services, applications and people interact and communicate?
  • How should the services be built and deployed?

Then IT has to figure out how those services should be integrated into the business process infrastructure, and determine the processes and rules, which must be developed and deployed.

Most companies, said Fricke, are in the “infrastructure” stage. They have 10 or 20 services deployed and are discovering that the situation is veering toward the unmanageable. Those companies need a better way to register and manage services, he explained, and to govern them with SLAs and performance management.

Another example of an early adopter—the JBoss SOA platform was just released in February—is North State Communications, a 100-year-old telecom company in High Point, N.C., that was looking for a billing system transformation.

To accommodate demand for next-generation telecom products, Fricke said, the company automated the way it makes services available to customers, using enterprise service busses (ESBs) and the JBoss jBPM, an open-source workflow management system based on J2EE.

These solutions aren’t typical, Fricke acknowledged. Open source is “embryonic” in the SOA governance space today. But he sees that as a great opportunity because of a concurrent belief that SOA deployment is going to change by 2010. “Instead of point-to-point integration,” he said, “we’re going to do more business process management [with SOA].” SOA development will add more governance with large-scale implementations, he believes.

For example, a hypothetical 2010 SOA scenario he described would use an advanced business process management (BPM) suite, and would ensure that the SOA governance platform supported not just Web services but also BPEL, SCA and other business process standards. Fricke also expects to see more standardization in messaging technologies in a similar time frame.

This trend has clear business benefits for IT governance and compliance, Fricke emphasized. He cited one CIO who realized that “to comply with Sarbanes-Oxley, I just have to prove what happens in my business process!” As Fricke explained, the CIO could use event logs and an event-driven architecture to record everything that happened—and didn’t happen. And doing so could take away a huge amount of Sarbanes-Oxley complexity.