With the emergence of Web services into the mainstream the developer has to learn how to architect and build service-oriented systems. While service orientation isn't a new concept, the rapid convergence of the industry on Web services technology has brought the concept of service-oriented architectures (SOA) to the forefront of many developers' minds.

Over the last decade we learned how to construct software systems using patterns that adhered to the concepts of object orientation. Now, service orientation requires us to adapt to a new approach to system integration and application development. However, at the moment most of us are still learning about this new technology and so we tend to apply familiar patterns when building Web services–based applications.

Applying object-oriented patterns to service-based systems is generally a poor idea since the scale of a typical object-oriented application (generally within a single enterprise or department) is dwarfed by the scale of a Web services–based application (which may span many enterprises and departments). It is crucial to remember that the use of SOAP and WSDL in our applications does not constitute service orientation.

This article outlines the basics of (Web) service-oriented architectures and looks at the distinguishing features of SOA that make it the right approach to take when developing Web services–based applications. We define the concept of a service, compare the emerging service-oriented programming to object-oriented programming, and outline how to advance to SOA. Finally, we explore these concepts in the context of an example banking system.

What Is a Service?
In order to understand SOA, we must first understand what an individual service is. A service is a logical manifestation of some physical resources (like databases, programs, devices, or humans) grouped as a process that an organization exposes to the network. A Web service is therefore best thought of as a "user interface for computers" and, just like GUIs for human consumption, a Web service provides controlled access to some underlying computer system (see Figure 1).

 

A Web service is the set of actions that the hosting enterprise is prepared to execute. A Web service does not expose a set of operations, methods, or functions (though WSDL uses similar names). Instead, it advertises the set of structured messages that it will exchange. When a message is received by a Web service, the appropriate action is performed and a response message may be returned. There is no assumption that subsequent messages received are associated with prior ones (i.e., Web services are stateless), nor are services mutually dependent – the fact that we concentrate on message exchanges, rather than interfaces, supports this notion.

Service Orientation Versus Object Orientation
Perhaps the most important difference between service orientation and object orientation resides in the way software integration is achieved. Fundamental to object orientation is the concept of a type system that is shared among software components. In the general case, a hierarchy of interfaces has to be agreed upon in advance, before those software components can be integrated.

In contrast, services and their consumers achieve integration through the exchange of messages. The only thing that is shared between them is the vocabulary used to define the structure of those messages, which – in the case of Web services – are XML and XML Schema. The absence of a predefined type system enables loose coupling since no information needs to be shared among services and consumers, before implementation and deployment. Service orientation is more appropriate when (potentially heterogeneous) platforms are to be interconnected.

Furthermore, in object orientation, software entities (objects) are smaller units of abstraction than services (e.g., an account versus a bank). Hence, fine-grained interactions are encouraged between these objects and the formation of complicated webs of interrelations and dependencies between them (e.g., objects may hold references to other objects) cannot be avoided. Conversely, service orientation promotes coarse-grained interactions and the reduction of dependencies between services. In this view, we propagate "chunky" messages around a Web services–based application, which contains all the necessary information to invoke an action. Good service-oriented design mandates that all the information necessary to invoke an action is contained in a message, unlike object orientation where "chatty" interactions between client and serving object are the norm. Since Web services are likely to be remote from the application that consumes them, fine-grained interactions will perform poorly because of the overhead imposed by network communication (and indeed the additional XML infrastructure needed), and so it is imperative that coarsegrained interactions are supported. Once we have decomposed a problem domain into coarse-grained message exchanges supported by schemas to describe common vocabularies we are ready to step up to service-oriented architecture.

Stepping Up to SOA
The transition from object orientation to service orientation is not necessarily straightforward, because of inertia more than any real complexities of the approach. As developers and architects that have learned and used object-oriented patterns in distributed application design for more than a decade, we cannot expect to adapt overnight to this new architectural paradigm. Indeed, in the current world of Web services we see examples of old approaches to distributed application development presented as service orientation.

For example, early SOAP toolkits unwittingly encouraged an object view of the world by making SOAP RPC extremely easy to use, an approach that has been deprecated by the community through the WS-I basic profile. Current SOAP toolkits make it very easy to create a one-to-one association between a Web service and the implementing object (e.g., expose EJBs as Web services or create a WSDL of a Web service from a single class). A Web service should be more than that; it should be a front end to a set of objects, programs, databases, humans, etc. A particular symptom of this mindset is the use of the term "operation" in WSDL to describe the set of messages that are related to a particular action of a Web service. This is unhelpful since it has the same kind of connotation as terms like "method" and "function", where it is better to think in terms of messages. Thinking in terms of messages not only forces designers to think in terms of coarser granularities, but also detracts from the problematic notion of shared type systems where messages, not typed interfaces, are shared between components.

Stemming from this mindset, it is not uncommon to see Web services technologies used to violate enterprise encapsulation by exposing internal resources to the Web service consumers. This inevitably results in an integration nightmare and fragile applications where easily broken interrelationships can be formed that cross enterprise boundaries. We have seen examples of this in particular application domains, like the grid, where Web services are used to support characteristics like stateful interactions, service transience, factories, publicly visible state, and introspection, which are borrowed from object-based systems like CORBA and J2EE and applied to Web services in a manner that carries the danger of tight coupling. Effectively, a common component model is built on top of Web services when one is not required. Component models are ideal for building closed systems but are not suitable for enterprise-to-enterprise integration. The dangers of layering an object model on top of Web services technology are shown in Figure 2.

 

The Bank Service Example
The best way of demonstrating these concepts is by an example taken from our day-today lives, the "banking service." A banking service is an abstraction of a set of actions that are offered by the bank to authorized users. We may be able to open/close accounts, deposit/withdraw money, get/repay loans, transfer money from one bank to another, pay/cash checks, establish financial agreements, finance a business, and so on.

As customers of the bank, we don't have to see any of the underlying technologies, methodologies, resources, and practices that the bank uses in offering its services. We are free to use any of the available interfaces to access the same offerings albeit at different levels of quality of service. For example, we can use our computer at home, the telephone from work, one of the many ATMs on a street, or even walk into any of the branches of the bank whose service we want to access, as depicted in Figure 3. In all of these cases, the business logic is controlled by the banking service. We are merely presented with a human-toservice interface.

 

When interacting with our banking service through one of these interfaces we use a common problem domain vocabulary like the terms "account" and "money" or the actions "deposit" and "borrow" as the basis for message exchanges with the bank.

For example, when we want to withdraw money from our account, we are not presented with the actual account "object" and asked to withdraw the money via a "method call" on that object. We don't know, or need to know, how the information about our account is maintained by the bank. Instead, we interact with the bank through message exchanges that result in some money being withdrawn.

Taking this approach one step further, we can consider message exchange patterns provisioned through Web services technologies that enable other computing systems to interact with the bank. The way the bank manages its infrastructure and resources and the way it operates does not have to change – it's business as usual. Remember that Web services is an enabling technology for computer-to-computer interaction rather than a radical new way of doing business. So, even though our bank has deployed a set of Web services as a way to access its business logic, it still does not have to expose its internal resources, implementation details, or practices. What Web services have brought to our banking example is the ability to automate interactions that cross its administrative boundaries.

Now it's possible for programs running on computers that are not controlled by the bank to consume the banking service and, perhaps, combine it with business logic that is unknown to the bank. We can envisage a personal finance application that can talk directly to our bank through Web services and at the same time combine information from our credit card provider and stock broker to offer us an up-to-date view of our financial situation. Of course, a Web services–based approach enables us to scale this application up to enable the integration of our banking service into larger processes and its participation into automated business-to-business activities (see sidebar, "Service Interactions").

Conclusions
The advent of Web services means another paradigm shift for the development community. As with the previous paradigm shift to object orientation, we are going to have to learn (sometimes by our mistakes) how best to apply this new paradigm to designing and building our applications.

Though it is tempting to view this new style as objects-plus-XML, this is a strategy that will hamper the development of truly scalable and loosely coupled services. Instead, we should aim to deliver services that expose coarse-grained processes to our partners (and not simple get/set operations); we should build stateless services for loose coupling; and we should not expose (even conceptually) any resources from a service back end directly to a consumer because this makes applications brittle, and unable to cope with change.

Though these are simple rules of thumb (see sidebar, "SOA Checklist") and we expect our understanding of how to deploy this technology will become vastly more sophisticated in time, for now we believe these constraints are a good starting point to making applications truly service oriented.

Acknowledgements
We would like to thank Mike Sick from Serene Software for his valuable comments.

References