BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Updated Principles of Service Orientation

| Posted by Michael Poulin Follow 0 Followers on Nov 03, 2014. Estimated reading time: 23 minutes |

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 runtime2. 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

  1. Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”. Prentice Hall, Aug. 2005.
  2. Thomas Erl, “SOA Principles of Service Design”. Prentice Hall; 1st edition. Jul. 2007.
  3. Reference Model for Service Oriented Architecture. OASIS Standard. October, 2006.
  4. Reference Architecture Foundation for Service Oriented Architecture, Version 1.0. Committee Specification 01. 04 December 2012
  5. Anne Thomas Manes, “SOA is Dead; Long Live Services”. BLOGs, Burton Group. Jan. 2009
  6. Michael Poulin, Knight Rules of Ownership in Service-Oriented Ecosystem Business Ecology Initiative & Service-Oriented Solution, ebizQ, Jun 2012. 
  7. Service Oriented Architecture : What Is SOA?. The Open Group
  8. Michael Poulin, Architects Know What Managers Don’t. Butechcon-Troubador Publishing, Apr. 2013. ISBN-10: 0957519907 ISBN-13: 978-0957519909
  9. 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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

This could not be more wrong by Jean-Jacques Dubray

These principles could not be more flawed, they are the anti-patterns of SOA: from Reuse, to Autonomy, to loose coupling to Statelessness...

If you want to be successful at SOA, you need
1/ Intentional Interfaces
2/ Consistent implementations
3/ Compatible Versioning

In SOA, reuse happens the other way around, it is not new consumers who reuse existing services, it is existing consumers who reuse new versions of the service tailored to the needs of the consumers.

To support Jean-Jacques Dubray by Michael Poulin

Dear Jean-Jacques Dubray,
you might be surprised, but I do support your opinion on Reuse, Statelessness and some others. This is why I removed or re-defined those principles; please, read the article.

I think I addressed all your recommendations in my previous publications in Sys-con and InfoQ. Also, I would recommend you to find them under my name.

I think I clearly explained the topic or reuse and repeatable use in the article. IMO, the dominant majority of existing consumers apply repeatable use rather than reuse. They apply the service regardless its version to the same subject in the same executions context because... they are existing users with their continues assignments. In a contrast, I expect that new/potential consumers might find some new options of applicability of the service and reuse it for new business tasks in new executions contexts. Please, think about this.

Finally, SOA is an architecture of the SO Ecosystem that differs from other ecosystems by thinking, designing and behaving in services. Initially (then obfuscated by technology) services were not assumed for reusability; they were assumed to satisfy consumer's needs and it was up to the consumer community to reuse them, repeatedly use them or ignore at all.

Autonomy and Loose-coupling in this article are re-defined and I hope you will find some sense and value in these new definitions. Please, do not mistakenly take Web Service technology as Services; this trend was pronounced dead 5 years ago.

Re: To support Jean-Jacques Dubray by Jean-Jacques Dubray

Michael,

the updates go definitely in the right direction but far from what I would consider a proper update for 2015. I wrote this post recently "Everything I needed to know about SOA, I learned it at the gas station" which provide an explanation of the principles I stated above.

I am also concerned that you have no mention of the "Common Information Model" which is a major roadblock for SOA teams. I provided a working solution for here.

SOA is easy but very different from traditional software construction, there is no need to make it abstract, vague or pedantic.

Re: To support Jean-Jacques Dubray by Michael Poulin

Jean-Jacques,

I like your post and an analysis of an experience on a gas station, as a pure service oriented business, may be more valuable than in, e.g. bank or insurance; I agree. However, this experience is only a basis and a variety of business models requires a bit more complex model. For example, do you know that we have 3 types of Real World Effect in SO Ecosystem?

The OASIS SOA RM and RAF standards put a serious foundation for service orientation and I’d recommend reading these standards.

To your previous comment about “Intentional Interfaces” – it is good but still #2; the #1 are offered business functionality/capability and Real World Effect. A research for many years in the US and UK has shown that if a consumer does not get interested in offered business functionality/capability and promised results, it would not even look at your service. However, if these two aspects appear as useful/needed, the potential consumer would find ways to resolve interface issues if they come up. For example, in the rural UK, there are not so many gas stations as in the rural US; if you drive an American car in the UK, you will need to become a bit creative in the petroleum station because your car is “in a mirror” to the station interfaces.

As of "Common Information Model" – this was a subject of multiple debates in (my) past. Here is the approach set in line with the OASIS SOA RAF specification: a service idea and following design aims a category of consumer’s needs and a category of consumers rather than particular requirements of one stakeholder. The business functionality/capability of the service is narrowed to those needs as well as interfaces. This, however, for not preclude the service expose as many different interfaces for different consumer communities as need for good commerce (utilisation). All these are recommendations of best practice, not a principle because every service owner manages its wellbeing as wishes. In an interface is wrong, potential consumers will go away and the service finally gets extinguished, but this is the business of the service owner or provider.

It is assumed that a service owner or provider would do the best to make the Service Description and, then, Service Contract appealing to the consumers and a shared informational model plays a big role in this. However, the service owner or provider may not assume that the consumers would be obliged to establish a "Common Information Model". When a service owner or provider announces a service, there is a risk of misunderstanding of the informational model (ontology and semantic) – it is known since CORBA time. This risk is taken, but then the consumer and provider can agree on an intermediary translator between two informational models. This is how the world behind a gas station works.

In your “provided a working solution”, you talk about API, i.e. programmatic interface; I am talking about _any_ type of interfaces. Also, as of the shared informational model, please, allow me to refer to my old publication that manipulated with XML schema and allowed to update Web Service for new consumers while leaving the existing consumers, who had shared that XML schema already, unaffected when the schema changed: soa.sys-con.com/node/523434.

Re: To support Jean-Jacques Dubray by Jean-Jacques Dubray

Michael,

I don't see a need to clutter SOA with all kinds of weird principles and pointless RM/RA. In the end two systems communicate via the exchange of strings. The question is how do you construct that string to achieve certain qualities and trade-offs.

For instance the fact that most practitioners do not make a difference between an integration point (into a system of record) and a service leads to major architectural mistakes.

I also believe (from experience) in a bottom up approach, whereby a service is designed for a consumer and changed over time, as new consumers need the same kind of functionality/data. This why compatible versioning is so important, but never talked about by the SOA/Microservices hipsters. IMHO, not talking about consistency is also a major issue in your "updated" principles.

If you are interested as to how I view SOA, from a practical, point of view, you can take a look at chorus.js's docs. CIM, Versioning, SDL, Mediation, Orchestration, CI... is all baked in.

Why we need to distinguish architecture from its implementation by Michael Poulin

Jean-Jacques,

I think you are a half-way to meet me on my ground when saying “For instance the fact that most practitioners do not make a difference between an integration point (into a system of record) and a service leads to major architectural mistakes.” This is absolutely correct in my opinion. This was the cause of the death of “Technical-“ or “Practical-SOA” in 2009.

At the same time (the not-walked half-way), your comment “I don't see a need to clutter SOA with all kinds of weird principles and pointless RM/RA. In the end two systems communicate via the exchange of strings” outlines that you still see SOA in technology.

About 10 years ago, some SOA leaders understood that Service Orientation had and has much more potential than dealing with systems – this is what OASIS RM and RAF as well as HL7 standards are about. SOA is not a technology or about technology, as we understand it today; it is the architecture (abstraction) of Service-Oriented Ecosystem that includes people, their operations and, then, systems. That is, Service-Oriented Ecosystem and SOA can and does cover Business.

It is not difficult to find that the essence of _any_ business organisation of _any_ size and industry is servicing consumers, i.e. it is orientation on service. Everything else that business organisations and their processes do is nothing more than an implementation of Service Orientation (see my book “Architects Know What Managers Don’t” www.mpoulin.com/architects-know-what-manager-dont/). Yes, “In the end two systems communicate via the exchange of strings” but this has nothing to do with SOA.

I believe you know, but I have to say it to those who might read this dialogue, that IT/systems exist in any business to enable or support the corporate business and it is the business that sense, define, direct and design the tasks for the company to go forward. Business (at that level) operates with business capabilities that, by definition of services, are presented to consumers as business services, i.e. saying business capability we say business service. This simply means that service orientation and tasks or requirements for services cascade top-down. The bottom up approach does not and cannot see the corporate objectives and strategic consumers or related consumer societies. It is OK - everyone has to mind own business.

If business architects understand service orientation and define functional and operational needs correctly, the requirements to systems will come in the forms that would dictate what and even how the technical implementation of the services should be done. For example, I can enumerate a few of such requirements: 1) service interfaces should allow backward compatibility of the versions for those consumers who do not need changes delivered by new versions of the service; 2) consistency of the service versioning is a must have, but it is the consumer who should be able to decide which version of the service to use; 3) service implementation (code and sources) may not cross service boundaries other way than via predefined end-points, i.e. service coupling via implementation – via shared programmatic code and resources – is prohibited. Any potential sharing should be implemented as a service in its own; and so forth.

Well, I’ve written about the most of these already in different publications.

Dear Jean-Jacques, I am very thankful to you for this discussion anyway.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT