Motivation
Current Principles of Service Orientation (SO) were formulated about 15 years ago when Service-Oriented Architecture (SOA) fought its way up into the mainstream of enterprise IT. They are widely known from publications of Thomas Erl 1,2 where the vocabulary of SO was compromised for the sake of mass adoption of Web Service technology. A year after Erl’s first book publishing, the world SOA leaders issued an OASIS SOA RM standard 3, which mentioned Web Services only twice in the Introduction saying, “…Web services are too solution specific to be part of a general reference model” of SOA. However, since SOA was formulated in technology, the representation of the principles was tuned to become easily understood by IT specialists primarily.
As a result, thousands of developers worldwide believed that technologies like Web Services were SOA, though no architecture can be technology. Due to popularisation, the SO Principles had been articulated 1 in technology terms or for technology reasons, which defeated the purpose and value of SOA. Nuances such as ‘architecture is not the same as its implementation’ did not bother IT developers that much.
Since that time, industry has gained a lot of experience in SO and reached a new understanding of services, what service orientation means, what a SO ecosystem is and what it is for 4. These last 15 years have not been easy:
- in 2006, OASIS issued the first standard – Reference Model for Service Oriented Architecture 1.0 – that preserved the ‘letter and spirit’ of SO, regardless of development habits in technologies
- by 2009, implementation technologies compromised the SO concept so much – promising benefits of excellent business-viable architecture while doing simple standardized integrations with practically no business values at all – that SOA experts agreed that ‘Technology SOA’ dramatically failed and was pronounced “dead” 5.
Nevertheless SO, especially the idea of a SO ecosystem, progressed and reached the business domain in 2012. The official OASIS specification of the Reference Architecture Foundation for SOA (OASIS SOA RAF) had defined a SO ecosystem and stated, “The SO ecosystem described in this document [OASIS SOA RAF] bridges the area between business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither business, nor IT completely own, govern and manage this SO ecosystem” 4.
Our understanding of SO has reformed, but the wording of the SO Principles have not changed to reflect this new understanding. They remain too technology centric and become obsolete and confusing. In the following sections of this paper we review and update the SO Principles where necessary.
Understanding the SO Ecosystem
Service Orientation is understood as a general direction of thoughts, intentions and willingness of a person (or an abstract entity) or a group of people (entities) to act by providing valuable capabilities and Real World Effect (RWE) to those who need them. The OASIS SOA RAF defines an RWE as follows: “real world effect is the actual result of using a service” 4. Also, “Service providers offer capabilities that have real world effects that result in a change in state [of a SO ecosystem]” 4. A RWE may be direct – returned to the requestor or service consumer, shared – accessible to anticipated users other than the requestor, and shareable – accessible to unanticipated users.
A SO ecosystem is “a space in which people, processes and machines act together to deliver those capabilities as services”4. In a SO ecosystem, “there may not be any single person or organization that is really ‘in control’ or ‘in charge’ of the whole” 4 ecosystem. Services in the SO ecosystem are the means by which “the needs of a consumer are brought together with the capabilities of a provider”4. Services are the realization of business functionality accessible through defined service interfaces.
Service-Oriented Architecture is an architectural realization of the concept of Service Orientation in the SO ecosystem. SOA promotes Principles of Service Orientation via architectural modelling of business functionality, solutions and design into an implementation. SOA is a business-oriented consumer-centric architecture that natively presents in corporate business and whose technical parts may be constructed and realized by IT departments.
A SO ecosystem provides an environment for service-oriented behaviour for services and people within and outside of an enterprise. Everything people do in an enterprise may be explained and described as servicing each other and servicing external customers.
Principles of Service Orientation
We will review SO Principles in no particular order. All SO Principles are equally important in the context of this paper. The existing formulations of the SO Principles are provided after the definitions published by Thomas Erl2.
Principles Related to Service Usability
Service Discoverability
In a SO ecosystem, the only way for a service to survive is to attract consumers; the more, the better. This approach anticipates that the service use has or will have a ‘commercial’ basis, in other words an unutilized service will not exist for long. For a consumer to find a service it should be easily discoverable. For business services, such discovery takes place long before service interfaces are contacted.This principle currently states:
Service Discoverability Principle
Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
This formulation of the Service Discoverability Principle is adequate for the modern understanding of service ‘discoverability’. Also, the OASIS SOA RAF defines the content of the ”communicative meta data” specified as a Service Description4. The latter contains information that a potential consumer can use to make a decision as to whether this particular service can satisfy certain consumer’s needs. Among other things, a Service Description includes all publicly available, but not necessarily accessible, interfaces of the service.
Service Contract
A service requires all consumers to agree to the Service Contract before the service may be engaged. The OASIS SOA RAF defines Service Contract 4 as an explicit or implicit agreement between the service or service provider and each consumer. If the Service Contract is implicit, the Service Description can play a role of the contract. Otherwise, the consumer and the service/provider have to negotiate and agree on certain subsets of the service’s features and applicable Execution Context, which we will discuss below. A consumer may also bring its own policies into the Service Contract.
The current formulation of this principle is:
Standardized Service Contract
Services within the same service inventory are in compliance with the same contract design standards.
An existence of a “service inventory” is specific to a particular service governance implementation and thus, should not be a part of a general principle. Service contract defines an agreement between a service provider and a consumer. Many services are consumers at the same time. According to the OASIS SOA RAF, services are independent entities that may have different owners and exist in different judicial and operational environments. Requiring several different services to share the same standard on the Service Contract is, at least, unrealistic. Another thing is a set of standards for a particular type or technology of interfaces. This certainly may be done, but interface structure is only one among many other items of a Service Contract. In our opinion, T. Erl when choosing this formulation as a principle preserved only one type of service interface – programmatic use of Web Service technology. Use of only one type of interface for services may not be a principle of SO.
A Service Description enumerates the design standards that are followed by the service and, particularly, its interfaces.A Service Contract is derived (in the majority of its elements) from the Service Description and specific to each service-consumer relationship. What really would be helpful is a standardization of the types of information presented in Service Contracts. Every consumer should be able to choose what has to be in its Service Contract using standardized types, i.e. which of them to be included.
We replace the original principle articulated by T. Erl with the following:
Standardized Content Types of Service Contracts
Service Contracts are in compliance with the standardized contract content types and represent mutual agreements between the service provider and service consumers on what content is to be included.
By ‘standardized contract content types’ we mean standardized elements of Service Description listed in the OASIS SOA RAF specification such as Policies, Interfaces, Interface reachability, interface Informational Models, Interface Behavior Models, Interface SLAs, and so on. For example, if a consumer chooses a service that allows only one invocation per instance, the Interface Behavioural Model is trivial and may be omitted in the Service Contract.
Service Execution Context
In a SO ecosystem, each service operates within an Execution Context (EC). Both the consumer/service communication and the service execution take place within the EC.
An EC includes business and technical sub-contexts and is defined in the OASIS SOA RAF as a set of agreements between a consumer and a provider that define the conditions, under which a service may be engaged and executed 4. Usually, an EC comprises laws, policies, regulations, rules, customs, technology platforms, special security considerations and so forth. In essence, the behaviour of the service and its RWE depend on the EC.
The EC plays a significant role for business services, especially within those enterprises that are in regulated domains, for example banking, insurance, telecommunication, health care, and so on. We define a new SO principle which states:
Service Execution Context Principle
Service interactions and execution take place in the Execution Context. The Execution Context can affect service behaviour and lead to changes in the reachability and Real World Effect of the services.
Service Contracts link the service RWE with the EC per interface. For example, the same service used or applied in different jurisdictions or regulatory regimes may deliver different results.
Principles of Service Construction
Separation of Concerns
Separation of Concerns is a well-known Computer Science principle. In the SO ecosystem, this general principle is interwoven with the concept of ownership. The OASIS SOA RAF recognizes and outlines the fact that each service has an individual owner with specific rights and preferences. It is assumed that each service is totally independent from other services and utilizes the outcome of outer services on a contractual basis. For an enterprise, this means that it is not an IT Department who owns business services, but an individual business group, team or division. We have witnessed many cases where business owners prohibited IT from modifying their services.
The concept of ownership leads to the ‘Knight Rules of Services’ 6, which allow a service to concentrate on its own functionality and relationships with its immediate consumers only. Particularly, an orchestrating service is similar to a regular business process, but in contrast with business process owners, the service owners operate with supplemental service via contracts rather than aiming to acquire them or obtain control over them.
This is another new SO principle which states:
Service Separation of Concerns Principle
Services own and carry out only their own functionality, independent from providers of supplemental functionality and decoupled from information sources and original information structures as much as possible.
This principle results in an appreciation of intensive interrelationships and intercommunications between services. In order to guarantee its own business continuity, a service can contract alternate supplier services up-front; the service consumer can do the same – to contract a few alternate supplier services for the same task.
Another consequence of this principle is an ability to separate a business service from its data sources. To obtain data from sources or storages, special data access services may be used. This enables business services to realize the principle of Composability in full and participate in as many compositions/cooperations as they want without ‘an anchor’ or strong coupling with usually shared data sources.
Service Abstraction
We recognise two forms of abstraction where a description and interfaces abstract the service body/implementation. A Service Description (acting as an implicit contract), abstracts the actual realization of the service – the service body – and provides only the information, which can help a potential consumer to make a decision as to whether this service can meet certain consumer’s needs. A Service Description is the only form of public information about the service.
The service interfaces also abstract the service body/implementation. However this abstraction works for the purpose of service invocation of an already chosen service.
The current formulation of this principle is:
Service Abstraction
Service contracts only contain essential information, and information about services is limited to what is published in service contracts.
A Service Description, not Service Contract, is the only information about the service available to potential consumers. In some cases, Service Description can play a role of Service Contract; this is known 4 as an implicit Service Contract. If a consumer negotiates custom conditions with the service provider, it is known 4as an explicit Service Contract. In the former case, a consumer a priori agrees with everything written in the Service Description regardless if the consumer needs it. In the latter case, the consumer chooses what to include into the contract with the service provider (though there may be some mandatory standardized contract types). For example, a consumer can choose only one interface out of several ones offered by the Service Description. The explicit Service Contracts are private by nature and may not be publicly published. In programming, an interface between interacting entities is known as a contract. We can say the same about services, but in this case the term ‘contract’ should be an interaction or communication contract, which is only a small part of the real contract between the consumer and provider. Without such explanation, the use of the term ‘contract’ with regard to services becomes ambiguous.
Thus, the current formulation of this principle is not correct any more. We introduce two principles instead of the current one:
Service Abstraction Principle
Service interfaces abstract the service realization or body. Not all service functionality and capabilities may be visible through the service interfaces. Service interfaces cannot be reliable resources for understanding what the service does and its RWE.
Service Contract Abstraction Principle
A Service Contract abstracts the service. A Service Contract contains only information about the service that is agreed between the service provider and the service consumer(s). This information has to be sufficient for interacting with the service, utilizing agreed service functionality and reaching agreed Real World Effect in a particular Execution Context.
Service Composability
The current formulation of the principle of Composability is:
Service Composability
Services are effective composition participants, regardless of the size and complexity of the composition.
This principle does not support the popular opinion that a service “May be composed of other services”7. From the principle, it is unclear what “composition” means. We believe it is a composition of services, at least. Such a composition may have its own unique value; a composition outcome may be more than just an aggregation of an individual service outcome. Thus, a composition of services appears to the consumer of the composition outcome as a service in its own right. Usually, such compositions are indeed represented as services.
If a consumer creates a composition, holds and manages states of composed services, this composition is not a service overall. If a composition is created by an orchestrating service1, the latter involves supplementary services via contracts. Thus, an updated formulation of the principle is:
Service Composability Principle
Services are effective composition participants, as well as effective composition holders, regardless of the size and complexity of the composition.
This principle explains that a service may not be composed of other services. Instead, the principle allows the orchestrating service to be highly dynamic in contracting and using different supplementary services.
Autonomy
The current formulation of the autonomy principle is:
Service Autonomy
Services exercise a high level of control over their underlying runtime execution environment.
Erl’s commentary on this principle points to “an independence with which a service implementation can carry its logic and manage the resources it may need at runtime”2. If “a high level of control”may be interpreted as “an independence with which a service implementation can… manage the resources”, we may assume that such resources should always be individual, private. Otherwise, if a resource may be public and shared, there are no guarantees that two independent services can manage it concurrently and with integrity.
We believe that autonomy is about the ability of a service to operate by itself, on itself. The only thing a service needs is data; if all needed data is provided by the consumer, the service must be able to accomplish its work by itself.
We distinguish between management of a resource and interacting with it. An autonomic service interacts with others (consumers/suppliers) on a contractual basis and never manages anything that is outside of its own boundaries9. All these interactions take place in the EC, which can impact the service RWE.
The updated principle is as follows:
Service Relative Autonomy Principle
Services exercise a relative independence from their Execution Contexts, control their internal resources and if necessary, interact with external entities in the SO ecosystem on a contractual basis.
Reusability
The current formulation of the principle of reusability is:
Service Reusability
Services contain and express agnostic logic and can be positioned as reusable enterprise resources.
We believe that a service may be used multiple times or reused. For example, if a bus is used on multiple routes, this is a multiple time use – the bus behaves in the same manner and operates in the same EC. However, if that bus tows a trailer with construction materials, this is a reuse – the bus is used for a slightly different functionality and in the changed EC.
The purpose of the service is to be available for multiple use and reuse. In a company’s business landscape, there are not many functions that are used in different combinations and contexts, that is to say really reused. The reusability of the service is important for the future adoption of business changes rather than for the implementation of existing functionality. Redesigning and re-developing existing business functionality exclusively for the purpose of reusability is usually inefficient.
Since the multiple use of services totally depends on the business (consumer) needs, it cannot be a principle. However, reusability is a special quality of services. Hence we update the formulation of this principle to:
Service Reusability Principle
Services contain and express logic that can be reused in different Execution Contexts; services can be positioned as reusable intra- and inter-enterprise resources.
The reusability of a service is about a reuse of the service as a whole. It is not tied to the enterprise boundary. If a service is properly designed, it may be offered to external consumers or replaced, or outsourced.
Service State
Every service – business or technical – has a state because a service is a working entity. Another question is how this state is used? It would be senseless for a service to share its own state with consumers – they do not care how the service works. The Service Description’s Interface Behaviour Model defines how many times an instance of the service may be invoked by a consumer. If it is one time only, the service appears to the consumer as stateless while managing its state as needed. The text of the principle fully confirms presented logic by saying that “Services minimize resource consumption”, which is different from having no state at all. Thus a quality of service statelessness depends on which side of the interaction an observer resides.
A service does not necessarily execute on a computer and may have as many manual operations in its body/implementation as needed. Business services, which form the core of a SO ecosystem of an enterprise, manage their states as needed for the business functionality they provide – they may be statefull or stateless. A service can delegate management of its state within service boundaries, but delegating the service’s state to the service’s consumer is absolutely unacceptable from the consumer usability requirements. The current title and formulation of the principle promotes one particular software design pattern that supports a highly transactional scalable process:
Service Statelessness
Services minimize resource consumption by deferring the management of state information when necessary.
This formulation sounds trivial – indeed, if a service does not manage its state, it saves resources needed for such management. The question is only why a service should “minimize resource consumption”; why this is a principle of services and not of something else? We believe that the criteria in this case should be business efficiency or rationalism. What if the cost of minimizing resources is higher than the cost of consumed resources?
The aforementioned definition of the principle carries a trap for those (thousands and thousands of) people who think that the title of the principle is self-explanatory and its formulation (which includes “when necessary”) may be forgotten. Those people believe that any service must be stateless. We have seen on multiple occasions, for the sake of this principle, an enormous “wad” of state data being sent over to the stateless service, resulting in latency and service degradation. In our opinion, the title of this principle was chosen for the purpose of promoting services at that time. Statelessness is only one type of service applicability and it is driven only by technology. It is unclear why a SO principle has to be named in a way that promotes a particular implementation pattern.
Thus, this principle is in need of generalization. Here the updated title and formulation are:
Service State Management Principle
Services manage their own state as needed and may defer the management of their states in order to minimize consumption of service environment resources.
For example, if a company utilizes several Clouds that have to work together, the company can get into an inter-Cloud brokering role. The company now can manage the states of its Cloud services instead of paying a fortune for integration between those independent Cloud providers.
Loose Coupling
Loose coupling is one of the most important design principles of services. The current formulation of this principle states:
Service Loose Coupling
Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.
Based on the principles we have discussed already, the current wording of this principle appears erroneous. A Service Contract is an agreement between the service and its consumer, and it couples them as much as they want; there is no need to impose ‘low consumer coupling requirements’. Moreover, a consumer has to understand what Service Description and Service Contract says, i.e. they have to share the ontology and semantics. We do not have a measure of how much coupling such sharing creates. In general, business would never work with totally unknown (decoupled) service/provider – there would be no means of business trust between them.
Also, a Service Contract cannot be “decoupled from their surrounding environment” because in this case it will ignore the EC, which may carry business and technical risks. For example, a Financial Service working in the US, but compliant only with UK regulations, is likely to be illegal in the US and may be made legally liable.
The confusion with this principle is that a simple service interface has been renamed into ‘service contract’, and the ontology of this term has evolved over time. In reality, we certainly need to preserve a loose coupling between the service body/implementation and its interfaces, regardless of whether they are programmatic or manual. At the same time, we cannot reach a full decoupling between the service interface and the service – it is the service that exposes the interface while an interface has no business meaning without the service that exposes it. An actual service interface behaves differently in different EC driven by the surrounding environment.
All these lead to the following formulation for this principle:
Service Loose Coupling Principle
Services impose low coupling requirements between their interfaces and the service body, as well as between their interfaces and the service consumers in the Execution Contexts.
Service Boundaries
A combination of SO Principles that we have reviewed already shapes the conclusion that a service body/implementation should be self-contained and decoupled from consumers’ and supplementary services’ implementation as much as possible. While it sounds trivial, this principle is too frequently violated in practice, especially if the same development team creates a service and its consumers, or reuses the same software code for different services (for example, utilizing a legacy application). Though this is more typical of IT departments, it can be found in the sphere of inter-company collaboration design as well (based on a shared codebase).
Any service has its interfaces and internal communication means that are dedicated to interactions with interfaces of external entities in the SO ecosystem. A consumer has to provide the service with all information defined in the Service Contract. A service can obtain any additional information via its internal communication means by invoking public interfaces of supplementary services. No other channels of interaction between the service and the external world may be permitted if we preserve such principles as Separation of Concerns, Autonomy, Composability and Reusability. That is, service interfaces and internal communication means constitute service boundaries. A service ‘owns’ everything within its boundaries.
The concept of service boundaries impacts service implementation a great deal. Code used in the service body/implementation may not interact, communicate or inherit from code under different ownership. Otherwise, we will have service ‘coupling by implementation’9, which violates the aforementioned SO Principles. This principle states:
Service Precise Boundaries Principle
The means of service implementation may not cross service boundaries, neither via invocation nor via dependency on the resources that are out of the service’s ownership or explicit control.
We understand ‘explicit control’ as the right and ability of the service/provider to modify and move the resources independently from anybody else.
Conclusion
This paper has reviewed the existing principles of Service Orientation and found that some of them have become obsolete. An understanding of the Service Orientation concept, SO ecosystem and services existing in it significantly changed over the last 15 years. This relates to such new aspects as service EC and a re-defined notion of the Service Contract. Also, the Principle of Service Boundaries can finally segregate services development practice from application development, which a lot of developers are confused about.
We have restated several principles, renamed a few others and defined a few new ones. This work has been based on the first OASIS SOA RAF standard 4, which has bridged the gap between business and technology. We tried to avoid and eliminate technology specific wording in the formulation of these principles’. The paper has also included our reasons for particular revisions and a few explanations and examples.
References
- Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”. Prentice Hall, Aug. 2005.
- Thomas Erl, “SOA Principles of Service Design”. Prentice Hall; 1st edition. Jul. 2007.
- Reference Model for Service Oriented Architecture. OASIS Standard. October, 2006.
- Reference Architecture Foundation for Service Oriented Architecture, Version 1.0. Committee Specification 01. 04 December 2012
- Anne Thomas Manes, “SOA is Dead; Long Live Services”. BLOGs, Burton Group. Jan. 2009
- Michael Poulin, Knight Rules of Ownership in Service-Oriented Ecosystem Business Ecology Initiative & Service-Oriented Solution, ebizQ, Jun 2012.
- Service Oriented Architecture : What Is SOA?. The Open Group.
- Michael Poulin, Architects Know What Managers Don’t. Butechcon-Troubador Publishing, Apr. 2013. ISBN-10: 0957519907 ISBN-13: 978-0957519909
- Michael Poulin, A Domain Service-Oriented Modelling or How SOA Meets DDD, Parts 1-5, BLOG, ebizQ.
About the Author
Michael Poulin is Head of Enterprise Architecture at Clingstone Ltd., a consulting firm based in the UK and working with business Change Management and Enterprise/Solution Architecture. He has built up a wealth of experience architecture in both the UK and United States. His work focuses on bridging the gap between business architecture and modern technology.
Michael provides professional coaching and knowledge exchange on his Web Site www.mpoulin.com. Michael is actively engaged in the Enterprise Architecture realm having actively contributed to OASIS SOA standards. Michael has also authored two books – ”Ladder to SOE” and “Architects Know What Managers Don’t” – and various other publications. He can be contacted via michael.poulin@clingstone.co.uk.
1 A choreography of services is a form of collaboration, which assumes changes in the service bodies for the sake of the collective work, i.e. defeats the purpose of services in an SO ecosystem 8.
