Related Topics: SOA Best Practices Digest, SOA & WOA Magazine, VITO Report

SOA Best Practices: Article

SOA and the Rise of WOA

A lightweight version of SOA has arrived: Web-Oriented Architecture or WOA

Let’s take a look at a real life example:

Oncology Hematology Associates (OHA) is a company based in Southwest Indiana, USA, and provides coordinated patient-centred plan for cancer diagnosis and treatment. They have about 100 employees including physicians, nurses and other healthcare professionals.

Before obtaining a little help from Microsoft, OHA had many manual paper based business processes. The nature of their cancer care business meant dealing closely with third party companies, such as testing labs, with much of the information being faxed back and forth.

OHA wanted to find a way to integrate its multiple business processes to improve efficiency, support collaboration, serve patients better, and increase profitability – clear business reasons for adopting SOA.

So with two developers they set about building web services onto their six medical industry preparatory backend systems. They adopted an iterative approach – exposing services through a composition layer to give access to a broad variety of platforms – and integrated all the faxing systems.

They integrated external partners into the systems, such as testing labs, to consume their services. The integration was done with a perspective of maintaining business value rather than redesigning the whole IT architecture.

Creating web services has enabled them to add a new range of medical care products to their business portfolio, obtain results in days rather than weeks, provide better communications amongst physicians and much more. In short, they have increased productivity, increased business opportunity, reduced operating costs and enabled better governance and compliance.

You can read more about their case study here.


At this point I considered talking about the tools and technologies that are available to create SOA services. However, this article is really concentrating on the principles of SOA, so I’ll discuss the tools and technologies in more detail in a future blog. Here is a list of some of them with links to their definitions:


What I would say is that it is hardly surprising that there has not been widespread adoption of SOA. Many IT people, never mind the business, must be confused by the proliferation of marketing initiatives, acronyms, conferences etc. relating to the topic. The latest ingredients added to the mix are Web Oriented Architecture (WOA) and Platform Oriented Architecture (POA). Did you know, that SOA + POA + WOA = SOA?

On page 27 of the current issue of Information Age (UK) there is an advert for the SOA & Application Development and Integration Summit 2008 which states that “The question is no longer ‘Should we go SOA?’, its ‘How do we measure the value?’” and that “SOA is changing everything.”

To me these are bold statements to make, considering there has been, in the words of one prominent UK CIO, “no truly successful SOA application”.

The question of how we measure SOA value is key, but without a sound and rational business case those metrics can’t be put in place. Mechanisms to track the contribution SOA makes to the business post-implementation are extremely difficult to establish, but nigh on impossible if it was a technology solution that has been sold to the business. In her post “Looking for SOA success stories”, Anne Thomas Manes identifies this problem when she says:

I've talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings. They've deployed the best technology the industry has to offer -- including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out. The techies just can't sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.”

Service Discovery

When services have been designed to be used together within a single organisation the architect may elect to explicitly link the known services together. Although this is the easiest way to connect services, it is not always possible – especially between geographically (or domain) disparate systems.

Services which have been created for consumption by third parties also need a way to be discovered, so they can be used by third parties.

In order to facilitate this, mechanisms have been introduced to allow services to be discovered across networks, such as the internet. There are numerous protocols which have been created for this and their use depends on the technology used to create the service. Three noteworthy examples are:

Universal Description, Discovery and Integration (UDDI) which provides a way for Web Services to list themselves as discoverable on the internet. Businesses who have created web services can register them within a UDDI, which is split into three central directories:

White Pages — address, contact, and known identifiers

Yellow Pages — industrial categorizations based on standard taxonomies

Green Pages — technical information about services exposed by the business

JINI from Sun Microsystems can be used to advertise and discover Java based Web Services. One limitation with JINI is that it uses multicasts to advertise and discover and as such can only really be used within a local network.

SLP has been used for many years to advertise network resources such as printers and file shares. SLP can also be used to advertise web services, but does not have a facility to maintain a repository of services with descriptions, unlike UDDI.

Identity Management

One of the challenges to be overcome for successful SOA deployment between third parties is that of identity management. When services are made available for use online, it is fair to assume that a payment mechanism will be built into the service contract description, or that sensitive information could be passed between the services.

In order for this charging mechanism to work effectively there is a requirement for an assurance that whoever consumes the service is the same entity that contracted the service. If a third party can assume the identity of the service requestor or the service provider (or both) there is the potential for serious security breaches. Once a transaction over the service begins, information about that transaction needs to be maintained at both ends of the transaction. When a connection between the service requestor and the service provider is terminated and needs to be re-established, protocols must be adopted to ensure the state of the transaction is not lost.

The problem identity management introduces is a need for tightly bound security on loosely bound services, and such tight security can defeat the purpose entirely of having loosely bound services. There are a number of security standards being driven forward to try to address these issues and an article by Eric Roch on IT Toolbox, which was written to specifically cover the security risks of SOA, is an excellent place to find out more background information on SOA security measures.


In its simplest form SOA can be used to put service wrappers around existing functionality to create a re-usable software infrastructure, which can help businesses move quickly in changing market conditions. It can simplify integration of existing legacy systems and help align IT services with business operations, as can be seen in the real-world example given above. SOA, when implemented on a small scale, can give benefits that can be easily demonstrated to the business.

But SOA can also be rolled out as an architectural vision across the enterprise, and many large software vendors and integrators are positioning themselves with products to try and achieve this vision.

As vendors try to differentiate themselves in the market place we see, yet again, the emergence of new abbreviations and technology-based terminology. Although this stimulates and progresses a technological debate within the IT industry, not for the first time a perception has grown in the business community that IT is overhyping a new technology.

The nature of IT is that it is continually evolving, and trying to sell a long term IT vision to the business has always been a stumbling block to adoption of new technologies. For SOA to succeed, the business has to believe that IT, having committed to an SOA strategy, will not be re-seduced by the finer points of some new technology.

Joe McKendrick at ZDNet recently wrote that:

The business side needs to be educated that SOA is a goal worthy of shooting for. And key performance indicators need to be tied into SOA efforts. But SOA is a journey, not a destination, and organizations that expect overnight benefits to the business are bound to be disappointed.”

Even though SOA could generate huge flexibility and long term savings, there is an associated increased cost to large SOA implementations over and above non-SOA solutions.

At a time of short-term financial planning, entering a long-term technology relationship can be a step too far for the business, and I fear one of the first budgets to be cut will be SOA.


More Stories By Paul Wallis

Paul Wallis is Chief Technology Officer at Stroma Software Limited. He blogs at, where he tries to bridge the understanding gap between business and IT.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.