SOA Principles

Reposting:

What is SOA?

This document provides a technical description of SOA and what it means for Architects and developers. Readers should have some familiarity with current technologies such as Web, XML, and Web services. This document provides a view of SOA as a broad set of architecture, design principles and choices used in building distributed systems. In essence, this document views SOA as a few core principles and a set design options or “knobs” that are set differently for each particular application depending upon the features required.

There are many reasons to follow SOA design principles and options. The usual main goal is to build software that provides components that are usable by a variety of other components in a distributed environment, aka re-usable software components. Other goals include optimizing functionality, costs and non-functional requirements like scalability, performance, extensibility and security.

There are as many definitions of Service Oriented Architecture as there are people in the technology industry. Despite the diversity of opinions, the community does have some commonly held beliefs about what SOA is and isn't. The "word on the street" is that SOA is all about building software components that can be easily created, accessed, discovered, and re-used using a variety of tooling and deployment environments and platforms. The environmental diversity requires that the distributed application has reliability, scalability, availability, extensibility, versioning, and configurability. These "-ilities" are often called non-functional requirements, and are formally called the architectural properties of key interest in Dr. Fielding's REST thesis (http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3). Successful distributed systems embody an appropriate mix of these properties and have been built for over 30 years. We merely stand on the shoulders of giants when we successfully deploy SOA based systems.

If there is one phrase that is the essence of SOA, it is “how to build composite distributed systems”. In order to be reusable, reliable, available, scalable, etc. - the properties of interest - the distributed components must reach an appropriate level of "loose-coupling". The realization of loose coupling, which is the ability to add, modify and delete components with minimal impact on other components, is done through the definition and description of interaction patterns between components, including the appropriate selection of technologies. There is no way to build useful distributed systems that are completely decoupled, rather there are a variety of choices that can be made in the system design that affect various aspects of the systems. Each of the properties of a system is a trade-off compared to other properties. For example, a synchronous service is usually more coupled in time with its client than an asynchronous service. On the other hand, an asynchronous service usually requires the client open up its address space for a "callback" which increases the coupling in shared distributed state included address space. More detail is at http://www.webservices.org/weblog/dave_orchard/async. There are numerous design choices made in a distributed system, and the collection of these choices result in the behavior and properties of the system. Effectively, loose coupling and SOA are phrases that represent the possible properties of a system.

SOA includes the technology and design choices for the system, but also includes the organizational processes around SOA. Much of the information available on SOA today focuses on the organizational and governance processes. This document is complementary to those aspects, and focuses solely on measurable technical aspects.

A difficulty emerges in describing Service-oriented architecture because there are many different views on what architecture is. My view of architecture is that it is a set of principles, constraints or decisions that yield the desired functional and architectural properties. The W3C Architecture of the World-Wide Web follows this architectural model (http://www.w3.org/TR/webarch/) to describe the World-Wide Web. This is unlike other definitions of architecture which are intentionally vague and do not provide any constraints, principles or decisions.

Another difficulty that emerges is defining what a service is, as compared to other computation units such as component or object. How does one distinguish between these things and say “this is a service” and “that is an object”? The answer is difficult because there are few hard and fast rules to differentiate between them. Can a CORBA component that uses XML, HTTP with a WSDL description be called a Service? Can a SOAP/WSDL/WS-Addressing endpoint that requires a Factory Operation to get an Endpoint Reference with Reference Parameters (eerily similar to CORBA architecture) and Metadata that indicates an X.509 certificate is required for authentication be called a service?

We must be clear about what we mean by a Service. I adopt the convention that a Service is software that follows SOA design principles, which roughly means that it is intended for use across varied and distributed software platforms. This highlights the need for interoperability, platform independence and planning for widely distributed access.

SOA Trade-off Principle: SOA deployment is a trade-off between properties of interest.

The properties of interest, such as Reusability, Reliability, Availability, Serviceability, Extensibility, Versioning, cannot all be achieved. There is a trade-off between them. An analogy is that there is a dial for each of the properties. The dials can be adjusted, potentially changing other dials. Each decision made, such as asynchronous services, affects the dials. Any successful deployment of an internet scale distributed system must account for the property dial settings. This paper will describe further details on the trade-offs between these “ilities” or properties.

SOA defined message format Principle: Services have well defined message formats.

Well defined message formats decouple the execution environment of systems because the message parsing software can be decoupled from the application and the platform. XML is the obvious technology as the basis for well-defined message formats. Using XML enables software components, like editors, parsers and toolkits, to be re-used across platforms.

When XML is used to communicate with distributed software, we call these Web services. We attempt to avoid the difficulties in relating SOA, Web services and technology choices such as WSDL and SOAP. Instead, we offer the view that Web services are services with an XML interface. Web Service specifications, such as SOAP, WSDL, WS-Addressing, etc. are technology choices but not the embodiment of deployed Web services.

SOA Interface Principle: Services have described interfaces.

SOA requires that the services have described interfaces. Without a described interface, all the software components are coupled to each other and it is difficult to scale to many different potential users and platforms. A described interface reduces the coupling between two or more systems by making the software components depend upon the explicit interface description, rather than the software with implicit assumptions. The more precisely the software's behavior is described in an interface description, the fewer implicit assumptions are made and thus the looser the coupling is between the software components. SOA's use of described interfaces provides a measure of loose coupling because the service dependency isn't a software to software dependency; rather it is N software to interface dependencies. This is predicated on the fidelity of the individual interface contracts. If an interface contract is basically anything allowed, then there is still tight coupling between components.

Again, interface description languages for XML are the obvious choice. XML has description languages like DTDs, XML Schema, and RelaxNG for defining the contract. When used in the Web services context, an important description language is WSDL, which provides specific contract details. Interfaces, operations, schemas, etc. can all provide loose coupling if they are designed properly.

This is not to say that SOA requires XML Schema or WSDL. There are downsides to these technologies, such as complexity. Many services can be described in textual documentation, templates, RelaxNG, Schematron, etc. However, as widely deployed standards, XML Schema and WSDL provide a number of advantages for widespread deployment of services. The benefits for tooling, automated processing, standardized discovery are clear.

SOA Interface Fidelity Principle: The richness of the interface description relates directly to the amount of coupling.

An interface can have a wide range of fidelity or richness, from lightly described to very detailed. The simplest interface is that a message with any parameter is received and a response is produced. This lack of information means that the consumer of the interface will have to find the information about the message contents from some other source, perhaps a phone call or trial and error. The more that interface specifies the types of inputs and outputs, the relationships between the messages and the semantics of the messages, the less that a human or software must do to interact and find the "real" information. System designs should endeavor to provide the richest or highest fidelity interface description that is useful to interact with the service.

Compliance with the interface, including extension, affects coupling. A service that does not fully comply with the interface description will probably not perform as expected by the client. To interact with the service, the client has to determine the amount of non-compliance, which will invariably be very time consuming. This will result in the most tightly coupled implementation because the client is coupled to an undocumented and unsupported aspect of the service, which might change at the service provider’s discretion without any warning or notification.

The interface description may include information about the “qualities” of the service, such as the availability, reliability, etc. These are often called Qualities of Service (QOS) and comprise a Service Level Contract. The more that the quality of service is described, the less the service consumer has to make assumptions about the service.

Richness or fidelity of the description does not mean that unnecessary or inappropriate information should be included in the description. The goal of an interface description is to provide the highest possible chance of continued interoperability with minimal human intervention. Care should be taken to prevent inappropriate information from or “noise” from the interface description. An oft-quotes expression is, “as much information as necessary and no more”.

SOA Composite Behavior Principle: The actual behavior is the sum of all the behaviors in the software

An interface description can never fully and completely describe a system’s behavior. A single component or node in a software system invariably consists of multiple components, like a servlet engine using a J2EE component in front of a relational database. Each of these components has their own interface descriptions, constraints and behavior. The actual interface to the component will be the sum of each of the components. For example, if the interface allows extensibility to the servlet, but the J2EE component does not, then the system as a whole is not completely extensible.

The effect of this principle is that each of the components within the system should be designed with the overall systems properties in mind. If extensibility is a goal for the system, then each of the components should be designed for extensibility.

SOA Interface Coupling Principle: Software should be as loosely coupled as possible to the interface

The interface definition is one aspect of loose coupling between systems, and the implementation of software of the interface is a component of coupling. For a given interface, implementations can vary widely. The variations can range from languages to platforms to hardware and more. Each implementation will be coupled to the interface differently. One implementation might remain unchanged for a particular interface change, whereas another implementation would need to be changed. And looking the other way, some implementation changes may require an interface change and other implementation changes don’t.

The two types of coupling to an interface are: what interface changes require software changes, and what software changes require interface changes? The design of the software that implements the interface affects the resiliency to changes in software or interface. For example, XML Beans enables the Java software to handle some changes in the XML data (interface) without breaking the software. However, this is predicated upon the interface allowing these changes. Hence for systems to be loosely coupled, it is necessary that the interface AND the software to permit the changes. To a degree, the interface and software must align.

SOA Distributed Principle: Services should be designed for existence in a widely distributed and heterogeneous computing environment.

We will adopt the view that SOA is about delivering services to widely distributed clients. The assumption is that services can be deployed at a global, or internet scale.

There are many SOA communities that are not intended for delivery to a global or internet scale. Some SOA communities exist in non-distributed and homogenous environments. Other SOA communities are global in distribution, heterogeneous and internet scale but are closed, such as an intranet. Many of these communities may not need to pay the costs for designing for distributed environments. However, it is often the case that local services are often deployed for a wider and wider set of clients and environments. Planning for distributed interactions up front can result in dramatic savings compared to redeveloping a service. From here on, we will associate SOA with distributed services, rather than closed communities. Closed communities will often benefit from designs that are structured as distributed services.

As we've been building distributed systems for many decades now, there are a number of canonical "lessons learned" that we choose to acknowledge and embrace. Peter Deutsch wrote up 8 seminal fallacies in building distributed systems (http://today.java.net/jag/Fallacies.html). They are:

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The network is homogenous

Earlier attempts at distributed computing, such as distributed objects, made some erroneous assumptions about the environment the services operated in, such as reliable networks and no latency. A SOA does not make the assumptions that Peter Deutsch listed. The essence of the fallacies is that software components should make as few assumptions as possible. That isn’t to say that each component has to deal with the fallacies itself, rather the components combined with their environment should not suffer any of the fallacies. For example, a software component might be built assuming a reliable network with the commensurate knowledge that the reliability would be provided, such as by JMS or WS-ReliableMessaging. In general, the more fallacies that are followed, the more the systems are coupled and frail.

The existence of Services in a distributed environment requires that the service providers and consumers construct their software and systems with specific constraints to avoid the fallacies and hence be more loosely coupled. There are variable technical and business costs to sending messages across security, network, and computing environments. The assumptions of each environment must be accounted for in the design of the Services. In this view, the Web is a SOA and CORBA "could" be a SOA though most implementations aren't. SOA is not new or anything radical, and in fact does not actually preclude many existing technologies. The same way that CORBA services may be built in a SOA fashion, Web services applications may be built in a non-SOA and tightly coupled manner.

SOA Decentralization Principle: Services should be designed and planned for decentralized administration

Services can span fiefdoms of administrative control. This can be between companies, between departments within a company, between individuals and companies, and further. The administration of the components that comprise and use the service is by many people. The web is a brilliant example of SOA with respect to decentralized administration. Browsers, Servers, and applications can all evolve on different time scales. This principle avoids the pitfalls of Myth #6, which states "there is one administrator". The interface and software design should account for this separate and distributed evolution of software. This does not mean that there is some federated management system that handles the disparate administration rather that each Service within its administrative domain plans to use and be used by Services that are separately managed.

One aspect of this is planning for extensibility and versioning of services. The more that each Service can evolve without affecting other Services, the more loosely coupled they are. Some useful reading materials on extending and versioning languages are:

• How to use XML Schema 1.0 for extensibility and versioning (http://www.xml.com/pub/a/2004/10/27/extend.html)

• A set based model for how to design any language for compatible versioning (http://www.xml.com/pub/a/2006/12/20/a-theory-of-compatible-versions.html)

• W3C TAG finding on Versioning (http://www.w3.org/2001/tag/doc/versioning ) and XML Versioning (http://www.w3.org/2001/tag/doc/versioning-xml )

• Guide to versioning using the upcoming Schema 1.1 (http://www.w3.org/TR/xmlschema-guide2versioning/ )

• A personal collection of links (http://www.pacificspirit.com/Authoring/Compatibility/)

As service components and clients can be deployed independently, it also regularly occurs that the topology of the services evolves. This can be through service evolution or the introduction of new layered services, aka composite services, aggregators or portals. An interesting example of a topology change is the rapid deployment of search engines. The web topology is flexible enough to account for search engines as a new service that consumes other services. If the web had allowed only web browsers to interact with web sites, then search engines wouldn’t have been able to index the site and provide their own service. Thus the original topology of human user interacting with web site was extended to service interacting with web site and human user interacting with the new service THEN the web site. The topology change is highlighted in myth #5, which states "Topology doesn't change".

Decentralized administration implies that some clients cannot be stopped from joining the network topology, so potentially malicious components may exist on the network. A service must be designed with this knowledge, and it must be secured appropriately. The appropriate security stance is a design choice and is listed as myth #4, which states "the network is secure".

We have listed a number of principles that underlie SOA. There are also design choices that are made in the context of SOA. We call these decisions “techniques” and detail a number of them.

SOA WS-* Technique: Services should make appropriate use of Web services specifications such as SOAP.

Web services specifications can enable loose coupling between applications, though they increase coupling between toolkits. An application that uses a Web service specification does not have to implement that functionality itself, such as implementing asynchronous callbacks. This means that the n applications do not each have to implement the functionality, rather they can rely upon the underlying web service stack to provide the functionality. The rough argument is to re-use Web services specifications rather than recreate their functionality. The application is tightly coupled to the Web service specification, but hopefully the web service specification will be well developed with thorough interoperability testing, saving the application developer the process of testing and debugging. Any change in a Web service specification will probably affect the implementation of a service - say the change from SOAP 1.1 to SOAP 1.2 - but these specifications typically evolve in slower cycles than the service. Thus the service can evolve faster than the specifications and implementations.

Web services can provide increased loose coupling with SOAP, because SOAP provides an extensible format and processing model that can allow an application to be decoupled from other software such as infrastructure components. A SOAP header block can be used for a security token, which means the application language does not have change. Without the soap header construct, the application must provide for or be coupled to all particular extensions. Non-SOAP XML services may be loosely coupled but this only happens when they never need to have a well-defined and layered programming model such as SOAP handler-chains.

The interface has other factors that contribute to loose coupling, such as synchronous or asynchronous, the granularity of the messages, the evolvability of parts of the contract (such as separating the address from the interface to evolve the address differently than the interface), and the constraints on the interface. An arbitrarily open interface typically increases coupling because there is no opportunity for re-use across the interfaces. An example of a closed interface is HTTP GET. This restriction of the interface enables many software components to understand the interface and be deployed against different services without changes, i.e. they are decoupled.

SOA Asynchronous Technique: use Asynchrony.

There are very well-known trade-offs between synchronous and asynchronous messaging. In broad terms, these come to a trade-off between coupling in time versus coupling in space. In synchronous messaging, resources are dedicated in one party while the other party and/or network are processing the message. The classic is obviously request-response where the client keeps a connection open while waiting for the response. These two systems are coupled in time.

Asynchrony relaxes the coupling in time but adds a coupling in space. In asynchronous messaging, the message sender spreads out the resources devoted to the message exchange pattern over time, potentially increasing efficiency of resources. The simplest is a one-way message, where the sender puts the message into the transport and continues. Request-response is often layered onto asynchronous messaging by using of a "callback", sometimes called asynchronous request-response. A request contains an address for the receiver to send a message to.

The trade-off between coupling in space and time is that the resources that are used for synchronous communications, such as socket connections, program and CPU threads, may be inefficiently allocated. Asynchrony allows the sender to free up these resources for other tasks. While there are resources that must be allocated for waiting for the callback, these are invariably less than the synchronous resources. In situations where the resources are not effectively used, asynchrony increases the scalability and performance of applications. Additionally, it is usually easier to add reliable message delivery to asynchronous messaging than to synchronous messaging systems. This makes it easier to avoid the first fallacy of assuming the network is reliable.

When Asynchrony

The next question is when to use Asynchronous versus Synchronous communications. As with all trade-offs, there are no hard and fast rules. Clearly communications that will take hours or days to answer are candidates for asynchrony. But how many minutes or seconds would suggest using asynchrony? Most web sites have a guideline that a web page must respond within 30 seconds. Perhaps this is a good guideline for the line between synchronous and asynchronous.

If you believe that Asynchrony is a vital component in building scalable distributable systems, then SOAP and a few other WS-* specs provide suitable infrastructure. There are 2 constraints that are emerging in the WS-* stack that enable a more asynchronous messaging world than we have with the current web. These constraints are support for Asynchrony and protocol messages as headers, aka flattened network layers. It has happened before that the architectural constraints of a new system have been described after the technology has been deployed. Perhaps in the same way that the REST thesis came after the first versions of HTTP and URIs, we will have an "Asynchronous" thesis after the first versions of SOAP, WS-Addressing and WS-ReliableMessaging, are widely deployed.

SOA State Technique: State location and management

The design and location of state, particularly application and connection state, in a distributed system is another trade-off. A detailed description of the trade-offs in a Web context is at http://www.w3.org/2001/tag/doc/state

SOA Coarse Grained Technique: Coarse grained interfaces

Coarse grained interfaces are those interfaces that have comparatively few operations with larger amounts of information in each message. The goal is to have a model of where each operation receives a sufficient amount of information to do a useful amount of work. This is contrasted with distributed-object style interfaces that have fine-grained interfaces where there are many operations with smaller amounts of information in each message. A canonical example of a coarse grained interface is an operation that handles Purchase Orders. The main operation is a submitPO operation with a Purchase Order parameter. Contrasting with this is a fine grained interface that would have operations for manipulating parts of the Purchase Order such as setting or getting Billing Information, ShipTo Address, Line Items, Purchaser Name, etc.

The advantages of coarse grained are many-fold. They include increased network performance and scalability by having fewer operations, increased security by needing to secure fewer operations, simpler ease of design, and simpler administration. There are potential downsides if the types of operations are themselves fine grained, i.e. control type operations, and they are inappropriately combined to achieve coarse grained interfaces.

Summary

SOA is a broad set of architecture and design principles and choices used in building distributed systems. The very fundamental part of building distributed systems is requiring that there is a described interface, or contract, between components and this contract is one step towards loose coupling. There are a variety of interface technology selections that provide further loose coupling, such as XML, WSDL and SOAP and other Web services specifications. The implementation of software, and the extent to which its internal contracts affect the published interface, has significant impacts on coupling, arguably as much as the interface technologies.

Acknowledgements

Thanks to Ed Cobb, Jeff Davies, Zulah Eckert, Yaron Goland, Gilbert Pilz, Michael Rowley, and Ken Tam for their reviews.