The Anatomy of a Service (Part II)

With my last post, we began the journey into the anatomy of a service by restating the definition of a service in the context of SOA. In this post, we're going to dig a bit deeper into the elements that make up a service. These elements are illustrated below.


Note that the illustration above doesn't imply any kind of layering. There are three types of service elements depicted. The yellow elements are related to the service domain. This is the logic, information model and state that drives the behaviour of the service relative to the responsibilities it holds in the overall architecture.

The green elements relate to the service boundary. The service contract describes the messages managed by the service and the endpoints through which the messages are exchanged.

The blue elements are service resources. Note that the service contains human resources. This is because service logic may in part be executed by people. This is explained in more detail here. This is a very important point. Most discussions around SOA tend to describe services only as IT constructs. A service consumer is unaware and does not care whether the service functionality is provided by people at a keyboard or software running on a server.

In addition to the human resources, a service also will very likely contain software and hardware infrastructure. The hardware infrastructure refers to the physical hardware on which the service operates - e.g. servers, SANs and communication infrastructure.

The software infrastructure refers to software that supports the operation of the service, but doesn't implement the logic defined within the service domain. So for example, this software would include operating systems, application platforms and communication software.

The distinction between software infrastructure and service domain logic is an important one. Software infrastructure can be reused between services, whereas logic related to the service domain should not be. Domain logic should be implemented and deployed only once in one service. Why? Because otherwise we have low cohesion - a single concern addressed by multiple services - and that leads to coupling between services.

So why can we reuse software infrastructure between services? This is because such software is generic. It doesn't pertain to any specific service domain. Take UI rendering logic for instance. The logic required for rendering a window doesn't relate to any specific domain addressed by any service in your business.

Other examples of software infrastructure include rules engines and workflow systems. However the rules and workflows themselves would constitute service domain logic.

An interesting example is a CRM package. A CRM package comes with quite a lot of what would seem to be domain logic. For example, a CRM may be deployed in support of the Sales function of a business without a great deal of customisation. Here, a large number of the native application features will directly contribute to the service domain.

A CRM package does not however need to deal only with customers. Most CRM packages can be highly customised to hold custom entities with complex relationships. Custom logic can be added to the CRM package to implement specific business rules around these entities. In this case the CRM package is being leveraged as an application platform, and as such is not implementing the domain logic of the service.

Okay last but not least, we need to discuss the service information model and state. Pretty much every service will have state. That state will conform to the service information model and the service domain logic executes against that information model. To that end, the service information model, state and domain logic are all indelibly linked.

Note that any state leveraged by the software infrastructure is considered part of the infrastructure itself and not part of the service state in the above illustration.

Just like service domain logic, the service state and information model should not be shared between services as it introduces coupling. Services should share data only by way of message exchange, although this is not always possible when transforming an enterprise full of legacy applications to an SOA - at least initially; but more on that in a future post.

So everything in blue in the above illustration is reusable between services. The same people can participate in many services, and the same software and hardware infrastructure is reusable between services. Everything else should not be directly reused as it introduces coupling and reduces cohesion. Of course, domain logic within one service can be reused by other services through exchanging messages with that service.

Okay well that sums up the basic elements of a service. Stay tuned for my next post in this series!

The Anatomy of a Service (Part I)

It occurred to me that to date I've been heavily focussed on defining SOA, techniques for defining service boundaries, contracts and responsibilities, and the various flavours of SOA that we see in the wild, without giving much attention to what goes on inside the service boundary. So I thought it appropriate to begin a series of blog posts on the anatomy of a service.

So let us begin by restating the definition of a service. A service (in the context of SOA) is an autonomous coarse grained unit of logic that exposes functionality by way of exchanging messages conforming to its service contract with service consumers via its endpoints.

The service contract describes the syntax (not semantics) of messages exchanged via each service endpoint, as well as the means by which messages are carried between each endpoint and service consumers. Each endpoint is located and uniquely identified by its address.

A service provider may also consume other services, and a service consumer may in fact also be a service provider. As such, the terms service provider and service consumer describe roles in a specific interaction. The rules governing communication with a service are described by its policy.

What do we mean when we say a service is autonomous? Well we mean a few things actually. Firstly, services are in control of their own state. Services are not instantiated by their consumers. A service exists as a single autonomous entity.

Secondly, we mean that services may be under different ownership domains. Those parties responsible for the service and its management may very likely be different to those responsible for other services. Services may be versioned and deployed independently of each other.

And thirdly, we mean that services should not be dependent upon the availability of other services in order to function without failure - even if that is in some limited capacity.

I'd also like to point out that there is the view that a service contract should not be devoid of semantic definition. There is the thinking that a service contract should also describe the semantics of the messages exchanged by the service, as well as the state the expected behaviour of the service.

Okay so now we've defined a service, what does a service look like? Well that's the beauty of SOA - because service implementations are encapsulated within their service boundaries, consumers don't (or shouldn't anyway) have any visibility or knowledge of the service provider's implementation.

But that doesn't really help us much as architects that need to design these things. That's the reason for this series of blog posts. We as architects need to understand the different ways to go about designing services - not just their boundaries and responsibilities, but their implementations as well.

Over the next few posts I intend to go through various different flavours of service anatomy in order to bring some clarity to the various options that exist for implementing services. So stay tuned!

SOA, EDA and MPI.NET

I had another good question from Miguel, this time referring to my post on SOA and EDA where he asked whether distributed systems built using MPI.NET conform to the SOA or EDA style of architecture.

MPI.NET is a platform for building a single distributed application where different parts of the application run on different nodes within a cluster of machines. Often, the same program runs on different nodes, but takes on different roles on each node. The role each program instance takes on each node can be determined by a unique rank assigned by the MPI environment to each MPI process.

Messages can then be passed between different processes to coordinate their activities. Often the program detects if it is rank zero and if so takes on the "root" responsibility, handing data and control messages to the other nodes, coordinating their activities and aggregating their results.

The message exchange patterns offered by MPI.NET are point-to-point, all-to-one (gathering data), one-to-all (broadcast) and all-to-all. These message exchange patterns differ from the message exchange pattern inherent to EDA, publish-subscribe.

With publish-subscribe, systems subscribe to specific topics or topic specifications. Messages published onto a given topic are routed to all subscribers that have subscribed to a matching topic specification. Alternatively, subscriptions may be defined based on message content-based rules.

With MPI.NET, there are no subscriptions as such. Messages may be broadcasted to every node, which then decides whether the message is relevant. This is a subtle difference, and perhaps one might argue it represents a highly simplified form of EDA.

With regards to SOA, it is extremely bad practice for services to share the same business rules or data representation as it couples services too tightly. The fundamental principle of MPI.NET is that the same logic can/will run on multiple nodes. The purpose is quite different from SOA.

With MPI.NET, you are distributing execution of the same logic across multiple servers for the purpose of increasing performance. With SOA each service is responsible for its own logic, encapsulated behind its service boundary.

Furthermore, the number of nodes allocated in an MPI.NET application is dynamic by design. With SOA, each service has specific rules and responsibilities. The number of services cannot be dynamically increased or decreased.

Certainly within a service the number of nodes allocated to handle messages could be dynamically adjusted based on load. However, these nodes are not directly addressable. They are not visible to the consumers of the service.

Another difference is that MPI.NET nodes do not have the concept of endpoints. One cannot deliver messages to an MPI.NET node across a variety of different bindings via different endpoints.

MPI.NET should be seen as a way to implementing a single service internally across multiple machines for the purpose of improving performance.

I would say therefore that MPI.NET is not a platform for implementing SOA. It could be considered as supporting the EDA style of architecture, but only in a very simplistic sense.

Business Agility

Business agility (along with business-IT alignment) is often touted as one of the key benefits of SOA. The problem is that more often than not no explanation is given for what business agility actually is, why it is important, or how SOA contributes to achieving it.

Firstly, it is important to note that business agility is a relative goal as opposed to an absolute one. Even the most agile business can strive for greater agility.

So what is business agility? Business agility is the degree to which an organisation can effectively innovate and respond to market forces.

In any given undertaking within an organisation, there are the traditional project management constraints of time, resource, scope and quality. For a fixed scope if we wish to decrease time to delivery, we must increase resource or decrease quality. For fixed resource if we wish to decrease time to delivery, we must decrease scope or quality.

Note that scope refers to the amount of work that needs to be done to deliver the agreed outcome. But as always, there is more than one way to skin a cat. The business objectives targeted by the project can be met in any number of different ways. A talented Solution Architect can design a solution to a business problem that requires less work to deliver.

Really what we are talking about here is contrasting business value with effort. If an organisation has a highly complex IT architecture that is very tightly coupled with a large number of interdependencies, then a change will take more effort to achieve, but deliver the same business value.

In order to have an agile organisation, we must have the ability to enact change with less effort. SOA helps simplify the IT architecture of an organisation by making systems more loosely coupled. Of course, there are varying degrees of loose coupling with different SOA implementations.

The SOA architectural style reduces coupling through message based interactions conforming to explicitly defined service contracts that encapsulate the implementation details of services away from consumers. This gives us the ability to make changes to service implementations without impacting their consumers.

We reduce coupling further by designing our services with appropriate granularity and cohesion, based on publish-subscribe messaging with stable service contracts.

The IT architecture of an organisation however is only one piece of the business agility puzzle. Once a business need has been identified, the business requirements must be extracted. The speed, efficiency and accuracy with which this activity is performed also contribute to business agility. There is very little business value in delivering a solution that doesn't meet the identified business objectives.

Furthermore once we have extracted our business requirements, assuming they are accurate, we need to produce a solution architecture that meets those requirements. So an organisation's proficiency in Solution Architecture is also significant here.

We also want to ensure that as each solution is delivered, the complexity of the business and IT architecture is not adversely affected. As such, we need the proper architecture governance processes in place to protect the broader enterprise architecture.

It is important to strike the right balance with governance however. Inefficient governance processes slow the rate at which projects can be delivered, thus harming business agility. Insufficient governance however will result in the gradual increase of architectural complexity, thus harming business agility in the long run.

Simply developing an effective solution architecture is still not enough. We must of course then go about implementing the solution. Here, the effectiveness of the organisation's project and programme management function is relevant, as well as the proficiency of the people that build and deploy the solution.

And finally once the solution is ready to deploy, there must be effective change management processes in place to ensure that affected workers are properly trained and informed to support the change. If the solution is not embraced by the people it affects, then the change will be ineffective.

So why all the fuss about business agility? Simply put, an organisation that doesn't respond to its changing environment will eventually become uncompetitive. Granted that some industries are more volatile than others, however all business environments change over time. Those businesses that are able to embrace this change in order to generate competitive advantage will be more successful.

Innovation is also a key consideration in generating competitive advantage. The ability to be able to take an idea and turn it into reality in less time, with less cost and lower risk certainly generates competitive advantage.

So in conclusion, SOA as a style of architecture contributes towards business agility through reduction of enterprise architectural complexity, but by no means guarantees it.

SOA and EDA

So far I've posted a large amount of material on SOA, pushing very heavily for an event driven approach - with specific attention to business services, where business-relevant events are surfaced as event messages published over a service bus.

There has been an ongoing discussion in the public forum around the relationship between SOA and EDA (Event Driven Architecture). Are they in fact separate architectural styles? Are they separate concerns? Do they complement each other? Does SOA subsume EDA?

SOA and EDA are in fact separate architectural styles. However they describe different concerns of an architecture. They each bring their own benefits. As such, it is possible (and in fact good practice) for the two styles to overlap. An architecture can indeed both be service oriented and event driven. Likewise it is possible for an architecture to be service oriented but not event driven, or event driven and not service oriented. This is illustrated below.


An architecture consisting of services with no endpoints with a publish-subscribe binding conforms to the service oriented style of architecture, but is not event driven. An architecture consisting of messages published over topics, but where there is no notion of services is event driven, but not service oriented. For example, EAI can be achieved by having a number of applications publishing and subscribing over a set of topics, without explicitly defining any services, endpoints or service contracts.

Where SOA and EDA come together, a topic corresponds to a specific endpoint of a specific service. A topic cannot be shared between endpoints or services, and messages published onto a topic must conform to an explicitly defined service contract. SOA brings benefits to EDA and vice versa. Therefore we get the best result when the two architectural styles are combined.

Service Composition (continued...)

In my last post we talked about service composition in SOA. Miguel posted a good question about whether composition in SOA is analogous with composition in Component Oriented Programming. This really got me to thinking about whether composition actually has any real meaning in SOA at all.

One of the key differences between components in Component Oriented Programming and services in SOA is that components must be instantiated. A client must instantiate a component before the component is used. Furthermore, multiple instances of a component can and usually do exist at the same time.

Composition makes a lot of sense in Component Oriented Programming because we have one or more child components supporting a parent component. Every new instance of the parent component contains new instances of the child components.

Without instancing, composition wouldn't really make a great deal of sense in Component Oriented Programming. Just because a component uses or references another component, doesn't make those components a composite. What makes a set of components a composite is the lifetime of the child components being indelibly tied to that of the parent component. The children are created with the parent and destroyed when the parent is destroyed. The children have no purpose other than to meet the needs of the parent.

SOA is a different ballgame however. There is only ever one and only one instance of every service. All services for all intents and purposes are always running (except for the odd moments of downtime) until those services are retired. So what is a composite in SOA terms? If I have a service A which consumes services B and C, is A a composite of B and C? I would say no. Otherwise all services in our enterprise would simply one big composite.

I would suggest that composition in SOA refers to the bringing together of lower level services in order to support one or more higher level services. It seems we need to have services at different levels in order for composition to make sense in SOA. So if services B and C are lower level services that form part of the implementation of service A, then I would say that services B and C have been composed to form service A.

As I mentioned in my last post, with all the hype around Layered Service Models, where lower level services (like task and entity services) are composed to form higher level process services, we see service composition taking centre stage in SOA discussions far more than it really should.

As I've previously discussed, the type of reuse central to Layered Service Models (functional reuse as opposed to reuse of events) doesn't really work very well in practice. Functions exposed at the service level generally are too coarsely grained to be reused in different contexts. As such, the notion of having a registry of lower level services that can be composed together in support of higher level services is somewhat flawed.

We may have lower level services such as integration services, UI services or B2B services that support a higher level business service, but those lower level services should not be reused between the higher level services. As such, in this case the service composition is really just an implementation detail of the higher level services and as such not really architecturally noteworthy.

So I say again, service composition in SOA is only really a noteworthy concept if you're pursuing a Layered Service Model which as I've said before is not ideal.

Service Composition

Quite often we hear of service composition as one of the key benefits of the service oriented style of architecture. With service composition, we are referring to the creation of new services from wiring up of existing services in new ways to deliver new value.

According to the standard reading material, service composition is best achieved through orchestration. This is usually achieved through the use of middleware such as an ESB or integration broker. A workflow orchestrates the invocations of a number of services in order to achieve some particular outcome.

As such, we find that a service may comprise some of its own logic (including the orchestration logic), as well as a number of lower level services.

This concept of service composition is central to the Layered Service Model where lower level task and entity services are composed into higher level process services. As you will have gleaned from my previous posts on the topic, I'm not a supporter of the Layered Service Model approach. One of the issues of this approach is that lower level services are reused by many higher level services, resulting in high coupling between those higher level services.

In the past, I have highly recommended that people pursue what I call a Self-Contained Process-Centric Service Model. Here, services are centred around autonomous business functions such as Sales, Marketing and Billing. What I probably didn't emphasise about this approach however is that it refers only to the top-level service model. Each business service may be composed of lower level services.

Note that these lower level services are not business services. They are services that serve a particular function in support of the business service. They are an implementation detail of the business service. In fact, they are actually really just distributed components or integration points. However if the means of communication with the distributed component or integration point is the exchange of messages via endpoints in conformance with a service contract, then we technically have a service by the strict definition of SOA.

In a green fields implementation where the software supporting each business service is built from scratch, there may be no lower level services involved. That is, there is no service composition. Alternatively, the service software may be implemented with a smart client application that interacts with some back end components via the exchange of messages in conformance to a service contract. Thus, those back end components technically expose a service to the smart client application.

Say in support of this business service, the back end components also interact with a Web service provided by another organisation. Now we have another service added to the mix. Here we can see services being composed in support of the larger business service.

Where a business service is supported by a number of legacy applications we see even more composition. When the business service receives a message, it must invoke one or more of these legacy applications appropriately. This may be achieved by invoking Web services exposed by these applications, thus constituting further service composition.

So we see that services certainly can be composed in support of larger services. However I would hesitate to name this as a benefit of the SOA style of architecture. It is merely an implementation choice of any given service. Service composition has only come to be viewed by many as a key benefit of SOA due to the reuse promised (falsely in my opinion) by the Layered Service Model approach.