Monday, October 20, 2008

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!

14 comments:

Anonymous said...

Can't wait for the next one in this series !
Keep up the good work

Anonymous said...

Thanks for your postings, Bill, and please keep it up! I (and many others, I hope) are very much looking forward to your writing more on these topics.

Many thanks,
Na'im Ru

Anonymous said...

Hope you haven't given up blogging, Bill. You're one of my favorites.

Cheers,

Peter

Anonymous said...

Really looking forward to hearing more from you, Bill!

Intelestream said...

Great outline of the elements that make up service. At Intelestream we developed an on-demand CRM software called intelecrm. Additional information on the differences of on-demand and on-premise CRM systems can be read in our recently published whitepaper by visiting http://intelestream.net/en/lp-online-versus-on-premise.html

Adam said...

I would love to see an update or 3rd installment after all the CQRS/ES things that have happened in the last couple of years thanks to Greg Young.

Anonymous said...

What happened to Bill? It has been years since we last had a post. Creative Abrasion was one of my favorite blogs, come back Bill!

Anonymous said...

Hi Bill, We are starting our SOA journey in good ole kiwi land. Very good articles.

Ezy Cash for Cars said...

Much thrilled to read your blog well-written article with the most wanted topics are covered all your post submission and really looking forward to more blogs. We are cash for car removal with cash for junk cars Brisbaneservice given to customers to are looking to sell any type of cars at any condition we are ready to buy it.

Adrians said...

If you have a car that is damaged beyond repair, have been resting and rusting in your backyard for many years, or simply don’t want to go through the hassle of selling then Cash for Cars Gold Coast is the right place.

Anayza Feloz said...
This comment has been removed by the author.
Anayza Feloz said...

I must say it is full of informational blogs. Thumbs up! It’s good to see so many positive customer reviews and happy clients! By choosing Cash for Cars Hobart near me you can get your Cash for Unwanted Cars Hobart
and receive cash up to $9,999. With minimal paperwork and free towing, rest assured your car is in good hands. So, why wait to avail the best cash for cars Hobart offers.

charliesmith said...

While a Virtual Office can be a great way to increase your business's legitimacy, you should choose one with a physical address. Most companies offer free virtual office addresses and are available in more than 2200 cities in the U.S. For more information on virtual office support services click here now.

jason smith said...

Connect Resources is the UAE’s leading Recruitment and Staffing Agency in Dubai and an official alliance of Randstad. We offer supreme HR consultancy services and staffing solutions to our clients in the Middle East. We foster an unparalleled industry insight and a sophisticated consultative approach for both partners and job seekers to meet all your HR consultancy Dubai needs and solutions
outsourcing companies in dubai
Professional Employer of Organization Dubai
Freelance Visa Dubai
UAE golden visa benefits