Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

SOA for the real world

Transform your SOA experiment into an enterprise-grade implementation

By Ash Parikh and Murty Gurajada, JavaWorld.com, 11/29/06

Page 2 of 3

SOA implementation today

Now that we understand the goals of SOA, let's consider a couple of examples that underscore the need for a good SOA implementation. Several industries are facing mandate-driven regulatory pressures today, such as Sarbanes-Oxley and XBRL (Extensible Business Reporting Language) in the financial services industry or a drug "pedigree" in the pharmaceutical supply chain. These compliance measures require organizations to gather data from silos spread across a variety of IT systems and sometimes require integration with third-party Web services. This data often has to be cleaned and transformed to standard formats to enable data exchange.

Another example appears in the various supply-chain IT departments dealing with the introduction of Radio Frequency Identification (RFID) technology. RFID enables real-time monitoring of supply chains, leading to their improved efficiency and operation. However, most supply-chain IT applications are brittle and cannot use the real-time, granular data that RFID provides. As we know, SOA greatly reduces integration complexity and future-proofs solution evolution without greatly affecting production environments. Hence, SOA provides compelling advantages for RFID solutions through increased agility, flexibility, and reuse. Enterprises engaging in RFID-based solutions can thus increase their responsiveness and decrease integration costs using SOA as a technology base.

Non-SOA or halfhearted SOA approaches lead to custom integrations, which cost a lot of money and make the systems more tightly coupled, thus exacerbating the problem.

Most IT departments are simply testing the SOA waters today. Some are deploying services on a small scale for internal consumption. Many are building service wrappers on top of legacy applications to achieve reusability and reduction of operational costs. Either way, the focus of SOA implementations seems to be on the service layer.

Confusion abounds

The term SOA is really a misnomer. It is not so much an architecture as it is a methodology, and there are many ways to implement each layer of an SOA. A recent AMR Research survey reports that Web services are the predominant way organizations are building services, but integration frameworks, portals, application servers, and business process management servers are also actively being used. The broad landscape of options for building the service layer may be a good thing, but it is also a source of confusion for many organizations considering SOA. So much time and effort is spent on cutting through the techno-babble and identifying a suitable service implementation that organizations cut back on the other, equally important components of an effective SOA and decide to only build the service layer to get a feel for the benefits of their investment. As a result, these SOA implementations end up becoming mere proof of concepts. They are not well thought out and do not address important concerns such as scalability, security, and governance.

SOA prototypes demonstrate potential benefits, but the path to a true enterprise-grade SOA appears too daunting for most organizations to follow. Organizations must realize that a service layer is simply not enough to deliver the SOA promise. There should be a realistic mapping between the organization goals and the components required to fulfill them.

Limitations and challenges

We have already mentioned the gap that looms between the lofty expectations from SOA and the actual investment in the components that will serve those needs. Let's now examine the challenges associated with implementing a successful SOA.

Cultural barriers

The goal of breaking down organizational silos presents more than just technical challenges. Many companies are not prepared for the deep cultural changes that accompany this philosophy. Many people are accustomed to having complete control over every aspect of their particular application's requirements. Now they are dependent on services provided by other groups. If this change is not handled sensitively, it might lead to resentment at relinquishing control, or even apathy, because someone else owns the data and services. This problem is further exacerbated if you are sharing services not only within your organization, but also with your trading partners. Now you have to pay careful attention to the data and services you expose because they are external participants in your process.

Who is responsible?

A potential for confusion is possible regarding ownership of data and its veracity. Imagine an application that reuses a service owned or developed by another group. This service, in turn, might use other services belonging to several different groups. If the application does not work because the underlying service failed, imagine how difficult it becomes to follow the links to identify the problem's owner and how a fix must be percolated through the layers of services before it eventually repairs the application.

Implementation fatigue

Besides the cultural and logistical challenges, many technical challenges are involved in implementing SOA successfully. Organizations are taking tentative steps towards just the service layer implementation, which is but one component of SOA. Even with this limited scope, and typically applying the straightforward strategy of building service wrappers around legacy applications, people are discovering more complexities than anticipated. They are finding that the size, number, and complexity of legacy systems make business processes immensely difficult to configure, defeating one of the primary goals of SOA.

Burgeoning services lead to scalability issues with data management. A handful of services may be easy to publish to a registry and discover for consumption. But the true benefit and, indeed, a challenge of SOA, is when you have hundreds or thousands of services that must be published, discovered, and managed efficiently.

Bridging the business and IT divide, and achieving flexible configuration of business processes requires an investment in business process management solutions. The problem is that there is as much confusion and choice in BPM implementations today as there is in the service layer implementation. The standards are evolving, and the dust has yet to settle on the vendor claims and debates that invariably accompany such a new technology.

What challenges have you experienced in implementing SOA? Post your comments in the discussion thread that appears below.