Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo

Microservices Expo: Article

Demystifying Service-Oriented Architecture

Demystifying Service-Oriented Architecture

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").

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.

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


  • Web Services Architecture: www.w3.org/TR/ws-arch
  • Foster, I., et al. (2002) "The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration". Global Grid Forum.
  • Parastatidis, S., et al. (2003) "A Grid Application Framework Based on Web Services Specifications and Practices. www.neresc.ac.uk/projects/gaf
  • OASIS Web Services Business Process Execution Language: www.oasisopen.org/committees/wsbpel.
  • WS-Coordination: http://msdn.microsoft.com/ws/2002/08/WSCoor.
  • Web Services Context (WS-CTX): www.iona.com/devcenter/standards/WSCAF/WSCTX.pdf
  • Web Services Composite Application Framework (WS-CAF): www.iona.com/devcenter/standards/WS-CAF
  • Purdy, D. (2003) "Service Oriented Architecture" (presentation): www.douglasp.com/talks/web400.zip

    Service Interactions
    Some interaction patterns are more sophisticated than those offered by plain stateless Web services. For example, when we stand in front of an ATM we don't have to identify ourselves as part of every request for an action. Instead, we establish our identity and the account we want to operate on at the beginning of the interactions. Subsequent action requests take place within the "context" that has been established between us and the banking service (a feature that is implicit in an object-based system since we bind directly to a serving object).

    However, we can achieve similar contextual semantics with service interactions. Back-end resources like the account remain hidden from the service consumer, but we establish a context that we can use at the application level to "group" actions together. There are two possible approaches rising to prominence in the Web services community:

  • Correlation based on message content: This is best exemplified by the correlation-set mechanism in BPEL, where parts of messages incident on a Web service can be used to form a unique identifier, implicitly linking related messages together on such "keys" as account number, date, or suchlike.
  • WS-Coordination or WS-Context (part of the WS-CAF suite of specifications: A context identifying related messages is embedded in a SOAP header block on each related message.

    Which approach we choose is determined by our deployment scenario since both broadly achieve the same goal. Where the simplicity and potential interoperability benefits of a standard, explicit context–based approach are appealing, we need additional infrastructure to deal with context generation and lifetime management. Conversely, with the implicit correlation-based approach, we need no external infrastructure, though we run the risk of altering message content solely to be able to generate uniqueness (e.g., by adding a unique "message id" field where there is no business-level requirement).

    Whichever context form is selected, the upshot is the same: context allows consumers to have "stateful" interactions with Web services, but does not require back-end objects to be exposed. This means the Web service has a free hand in deciding how to manage its back-end resources, since they remain encapsulated away from the consumer. This is in contrast to the object-based approach, where invocation context is set by references to objects and the invocation history of referenced objects. The big drawback with this scheme is that object references between enterprises are likely to be brittle and impose too tight a level of coupling between the client and the serving object.

    SOA Checklist

  • Service orientation focuses on shared message structure, not shared type systems.
  • Messages carry sufficient data to allow the action to be completed, and are coarse grained.
  • Service orientation encourages loose coupling, but does not guarantee it.
  • WSDL is a contract language that specifies message structure and permitted message exchange patterns, and is categorically not an object IDL.
  • More Stories By Jim Webber

    Dr. Jim Webber is a senior researcher from the University of Newcastle
    upon Tyne, currently working in the convergence of Web Services and Grid
    technologies at the University of Sydney, Australia. Jim was previously
    Web Services architect with Arjuna Technologies where he worked on Web
    Services transactioning technology, including being one of the original
    authors of the WS-CAF specification. Prior to Arjuna, Jim was the lead
    developer with Hewlett-Packard on the industry's first Web Services
    Transaction solution. Co-author of "Developing Enterprise Web Services -
    An Architect's Guide," Jim is an active speaker and author in the Web
    Services space. Jim's home on the web is http://jim.webber.name

    Comments (8)

    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.

    Microservices Articles
    Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
    "NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
    Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
    In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
    The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
    Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
    TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...