Understanding Service-Oriented Architecture

Introduction

It seems probable that eventually most software capabilities will be delivered and consumed as services. Of course they may be implemented as tightly coupled systems, but the point of usage—to the portal, to the device, to another endpoint, and so on, will use a service-based interface. We have seen the comment that architects and designers need to be cautious to avoid everything becoming a service. We think this is incorrect and muddled thinking. It might be valid right now given the maturity of Web Service protocols and technology to question whether everything is implemented using Web services, but that doesn't detract from the need to design everything from a service perspective. The service is the major construct for publishing and should be used at the point of each significant interface. service-oriented architecture allows us to manage the usage (delivery, acquisition, consumption, and so on) in terms of, and in sets of, related services. This will have big implications for how we manage the software life cycle—right from specification of requirements as services, design of services, acquisition and outsourcing as services, asset management of services, and so on.

Over time, the level of abstraction at which functionality is specified, published and or consumed has gradually become higher and higher. We have progressed from modules, to objects, to components, and now to services. However in many respects the naming of SOA is unfortunate. Whilst SOA is of course about architecture, it is impossible to constrain the discussion to architecture, because matters such as business design and the delivery process are also important considerations. A more useful nomenclature might be Service Orientation (or SO). There are actually a number of parallels with object orientation (or OO) and component-based development (CBD):

* Like objects and components, services represent natural building blocks that allow us to organize capabilities in ways that are familiar to us.
* Similarly to objects and components, a service is a fundamental building block that
1. Combines information and behaviour.
2. Hides the internal workings from outside intrusion.
3. Presents a relatively simple interface to the rest of the organism.
* Where objects use abstract data types and data abstraction, services can provide a similar level of adaptability through aspect or context orientation.
* Where objects and components can be organized in class or service hierarchies with inherited behaviour, services can be published and consumed singly or as hierarchies and or collaborations.

For many organizations, the logical starting place for investigating service-oriented architecture is the consideration of Web services. However Web services are not inherently service oriented. A Web service merely exposes a capability that conforms to Web services protocols. In this article we will identify the characteristics of a well formed service, and provide guidance for architects and designers on how to deliver service oriented applications.