Welcome!

Microservices Expo Authors: Liz McMillan, Zakia Bouachraoui, Elizabeth White, Pat Romanski, Yeshim Deniz

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

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

  • 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
    The now mainstream platform changes stemming from the first Internet boom brought many changes but didn’t really change the basic relationship between servers and the applications running on them. In fact, that was sort of the point. In his session at 18th Cloud Expo, Gordon Haff, senior cloud strategy marketing and evangelism manager at Red Hat, will discuss how today’s workloads require a new model and a new platform for development and execution. The platform must handle a wide range of rec...
    When building large, cloud-based applications that operate at a high scale, it’s important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. “Fly two mistakes high” is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee A...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and systems administration expertise. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine where she evaluated and tested application-focused technologies including app secu...
    Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure ...
    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...
    Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder and Chairman of Alfresco, described how to scale cloud-based content management repositories to store, manage, and retrieve billions of documents and related information with fast and linear scalability. He addresse...
    SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publishing company that develops products to help senior professionals in the world's most ICT dependent organizations make risk-based infrastructure and capacity decisions.
    Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true ...
    In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...