Let’s start by looking at what the term Service Oriented Architecture actually means.

The original definition of the word “architecture” can be described as “the art and science of designing and constructing physical structures”. Typically we associate the word “architecture” with the style of buildings, be it the Art Deco style of the Chrysler Building in New York, the modernist formalism of the Bank of China Tower in Hong Kong, or the grand scale of the gothic Milan Cathedral.

Recently the IT industry has used the term Architecture more and more frequently to describe how building blocks of hardware, software and interface protocols can be put together to create systems. The best recent description of its usage that I have seen described Architecture as:

“a subjective mapping from a human perspective (that of the user in the case of abstract or physical artifacts) to the elements or components of some kind of structure or system, which preserves the relationships among the elements or components.”

When it comes to Service Oriented Architecture (SOA), the term means designing a system where each system component provides access to its computational or business resources as a service to other components.

By way of explanation, let’s say that we have a simplified system which receives an order, generates an invoice and faxes it to the purchaser. The workflow of that function can be broken down into four distinct services:

1) Stock availability and pricing service
2) Order creation service
3) Document creation service
4) Faxing service

The theory is that by creating these distinct, separate and self contained services for each of the components we gain greater flexibility. Each of these services could be called from other business functions allowing re-use in subsequent areas of the business.

For example, the business could offer potential clients access to its stock availability and pricing information rather than utilising its own sales staff to process queries. Or it could expand the faxing service to cover email without changes to multiple larger systems - saving money, time and resources.

That, put very simply, forms the basis of all SOA. Those of you familiar with software development will recognise the re-use advantages of this approach which has been the main-stay of functional and object oriented design for many years.

So if this concept of re-use is not new, why all the hype surrounding SOA?

Although the concept is not new, software re-use traditionally required the code to be “tightly coupled”, meaning that the programmers had to understand how both the new code and the re-usable code could be linked together to create an interface which tied them explicitly together. Vendors are now trying to promote the technology, tools and standards that have been developed to allow services to be “loosely coupled” with each other, reducing the complexity of integrating services together. To understand how this works we need to look at how the service industries work in the real world.

Over the past few decades we have seen a growth in the service industry sector, driven partly by economic constraints. Companies have increasingly analysed their strengths and been concentrating on their core expertise, outsourcing those functions that they see as non-core and awarding contracts to companies to service those contracts. Remember in the 1980’s when the telephone sanitiser companies had the contract for wiping telephone handsets, or in the 1990’s when plant maintenance companies came in to water the peace lilies in the foyer?

Usually, each of these contracts would have an associated cost negotiated before the contract was awarded, and was subject to procurement rigours for value for money. They would also of had predefined deliverables and be monitored to ensure the service matched those promised. Finally, each contract commonly had a point of contact for efficient communication with that service organisation.

By building similar capabilities into SOA, the IT industry now has a way of creating re-usable services which can be used by third parties seeking “buy not build” functionality for their applications or for the support of their business functions. By implementing a standard contract approach into the implementation of services, they can be used without a detailed knowledge of bespoke interface considerations. As such, it is relatively easy to decouple from one service provider and move to another, hence the term “loosely coupled” as opposed to “tightly coupled”.

As well as adhering to a contract model and having the ability to be loosely coupled, services generally also allow abstraction, reusability, autonomy, statelessness, discoverability, and composability – depending on the specification and design brief of the service.

Architecture

When an architect is commissioned to design a building his first requirement is a design brief. As well as understanding the style of the building, he must also gain knowledge of budget, environmental considerations, location specific requirements, building usage, decision authority, material availability, reasons for embarking on the project etc.

The answers to these questions will determine how the building will look and feel. It will also, however, determine the tools and equipment needed to undertake the task, the best approach to take, what skills are required to deliver the project, the scope of work, bill of materials and project timescales.

The same is true of SOA. Just as there is more than one way to design and construct a building, and more than one set of tools which can be used, so with SOA there are many technologies and methodologies which can be used to deliver an SOA solution and all have different advantages and disadvantages.

In the construction industry there are some people who prefer sustainable hardwood construction rather than metal. Within the proponents of metal construction, there are some which prefer aluminium to steel. Within the advocates of steel, some prefer rivets to welding.

Similarly, in the SOA community some advocates prefer SOAP/web services to CORBA, DCOM, REST, RPC or JINI. Some prefer complex messaging backbones and others simple state protocol transmissions. Some prefer closely coupled, others loosely coupled. Some use a top-down approach to architectural design, whilst others suggest bottom up.

Does it matter? Yes it does.

Which is best? Unfortunately that depends on your design brief.

SOA Architecture Principles

There are some well defined specific SOA architectural principles governing service design and service definition, namely:

• Service encapsulation - Many web-services are consolidated to be used under the SOA Architecture. Often such services have not been planned to be under SOA.
• Service loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
• Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
• Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
• Service reusability - Logic is divided into services with the intention of promoting reuse
• Service composability - Collections of services can be coordinated and assembled to form composite services
• Service autonomy – Services have control over the logic they encapsulate
• Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
• Service discoverability – Services are designed to be outwardly descriptive so that they can be found and accessed via available discovery mechanisms such as service repositories or directories

Further information about these principles can be found here.

There are two approaches to Service Orientated Modelling – “top-down” and “bottom-up”. The top-down approach starts with analysis at a business process level to evaluate re-engineering and workflow, ensuring that service delivery matches business requirements. The “bottom-up” approach starts in the IT stack, analysing systems and system functionality, before existing systems are wrapped using Web services to create a service layer.

In reality, despite much debate over a number of years, success will not come from “top-down” OR “bottom-up”. It is only a mixture of the two which will work effectively, a view shared by Neil Ward-Dutton in his recent post “Which comes first: process or service?”

Next Page: A Real-Life example...