Demystifying service-oriented architecture

Buzzwords, acronyms and payoff lines abound in our everyday lives, but none more so than in the IT industry. The most recent of these is SOA, or service-oriented architecture. Almost all leading software vendors are talking about SOA and how their technologies will enable the realisation of the benefits of the SOA promise.

Existing application architectures have failed to keep pace with changing business needs. As organisations build more software systems to respond to these needs, they typically become mired in complexity. The requirements to integrate their applications and systems with those of their partners, suppliers and customers are hampered by limitations of monolithic, tightly coupled applications. Changes in one system cause others to break. New APIs and interfaces associated with each system bring a new learning curve and skill set required by the developer.

In an attempt to gain agility, developers constantly strive to reuse the functionality from existing systems rather than build from scratch. As an example, a financial company may have many systems that need to authenticate a client`s credit history. Instead of building such logic from scratch in every system, developers would rather utilise a common business "service" for performing such authentication.

Not too long ago it was believed CORBA held many of the keys to the above challenges of integrating applications across heterogeneous environments. However, due to a lack of complete standardisation of object models and insufficient focus on loose coupling, CORBA failed to deliver the utopia of application integration.

The SOA philosophy or methodology aims at replacing monolithic, tightly coupled applications with modular and loosely coupled ones in order to facilitate reuse and agility. By adopting SOA, applications can be modified independently without impacting other services. This gives organisations the ability to change at the rate of business rather than force expensive retrofits for every business process change.

SOA is an architected approach, aimed at facilitating standard, simple and pluggable interfaces between applications.

Edward Lane, technical manager, BEA Solutions Africa

The first time I heard the SOA buzzword at a conference about six months ago, I turned to a colleague and said: "This is nothing new...I`ve heard this all before." With a degree of caution (and a larger degree of optimism), I have explored and continue to explore this `new phenomenon` in our industry. To be honest, it is hard not to explore, or rather not be aware of the SOA pitch. Wherever you turn, it is being hyped, by technology vendors and system integrators alike. The salesmen`s vocabulary of buzzwords has expanded and the likes of `TCO` and `ROI` have been augmented in every sentence by `SOA` and `SODA`.

As usual, one of the first points of reference, in deciding whether I actually need to know much about this, is the analysts.

According to Gartner, by 2006, more than 60% of enterprises will consider SOA a guiding principle in designing their new mission-critical business applications and business processes (0.7 probability). In addition, by 2006, more than 75% of midsize and large enterprises will have deployed SOA-enabled development tools and middleware (0.8 probability). (Introduction to Service-Oriented Architecture, 14 April 2003, Yefim Natis, Roy Schulte)

Now analysts are not always spot on, but their high probability ratings of the impact and adoption of SOA is enough to encourage me to delve deeper into the exact definition and promise of SOA.

Again, according to Gartner, SOA is "a best-practice architecture pattern for the systematic design of request/reply applications. Its primary intentions are business-level software modularity and rapid, non-intrusive reuse of business software in new runtime contexts."

In laymen`s terms, SOA is an architected approach, aimed at facilitating standard, simple and pluggable interfaces between applications (called services). More elaborately, it is a set of principles and practices for sharing, reusing and orchestrating business logic represented as services or components. These services are abstractions for units of work, made available by the provider to achieve desired results for the consumer. Its goal is to achieve a loose coupling among interacting pieces of software, by using standard interfaces that help mask the underlying technical complexity of the IT environment, so enabling greater re-use of IT assets.

SOA is actually all about interfaces. SOAs are about well-defined, well-structured interfaces. The one side of the interface offers up a service, and the other side consumes that service.

In its simplest form, SOA has three key role players:

1. The service provider - an application (system) or database, for example, that is exposing functionality.

2. The service consumer - the application or person looking to access the functionality.

3. The service broker - the agent or intermediary between the providers and consumers.

Where the definition of SOA becomes really interesting and powerful, is that it defines that services being provided are loosely coupled, asynchronous, platform independent, dynamically located and invoked, and are self-contained. This means that you can access (consume) any application, written in any language, running anywhere, at any time, using a standard interface or API. This standard interface or API is decoupled from the underlying implementation, which allows me as a consumer of the service to be confident that the interface will not be impacted by underlying changes to the application or service.

For once, the myriad of vendors in the software industry agreed to agree. We have a technology-agnostic architectural standard emerging, and have had (in Web services) for some time now, a realisation technology for the SOA vision.

* BEA sponsors ITWeb`s Java industry portal. Java has emerged as a premier technology for building and deploying Web-enabled and multi-tier applications for e-commerce. This technology does, however, present unique development challenges.