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!


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.



Anonymous said...

Really looking forward to hearing more from you, Bill!

Anonymous said...

交友聊天找e爵,熊貓貼圖區,ut 聊天室,杜蕾斯成人,成人小說,正妹,成人文章,成人圖片,熊貓貼圖,jp成人,交友戀愛小站,色情遊戲,情色視訊,情色視訊,aio交友愛情館,成人視訊,tt1069同志交友網,成人影片,成人貼圖,男同志聊天室,0951成人頻道下載,交友104相親網,成人圖片區,ut男同志聊天室,18成人,成人韭南籽,視訊交友,交友104速配網,情色文學,交友覓戀會館,情色小說,情色貼圖,色情小說,美女,色情,成人,嘟嘟成人網,交友戀愛進行室,85cc成人片觀看,85cc成人片,

Anonymous said...


一高一低 said...

連接生與死這兩塊陸地的橋樑是愛…… ..................................................

寫真集 said...


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

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!

saket said...

nice posting.

awadh said...

very nice
Golden Triangle India
Travel Packages India
Kerala Holidays India

sandy said...

Nice blog
Places to Visit in Rajasthan
Rajasthan Hotels
Rajasthan Village
Tourist Destinations in Rajasthan
Rajasthan Fairs and Festivals
Holidays In Rajasthan
Rajasthan Tourism

Jones said...

Nice Blog
India Tour Packages
Holiday Destinations India
India Holidays Packages
Tour Packages India
Luxury Holidays India
Theme Holidays
Holidays In India
Wildlife Holidays India

akshada said...

Hello very Nice Blog,I Like It Blog
We are offer Goa Holidays and Golden Triangle India attractive information
Goa Holidays
Holidays to Goa
Goa tourism
Places to visit Goa
Goa Tours
Golden Triangle India
Golden Triangle Tours

Sonam said...

Monetary backing that can help you meet short-term needs until next payday.with

Tina said...

When our practice got started we needed medical billing companies in california help. These were the guys we turned to and they did a great job.

Fawad Tariq said...

This is very nice and informative blog thanks for sharing this informationareService Contractsfully insured to provide your belongings the extra cushion that they might need during the transit and giving you the peace of mind that your valuable possessions are in good hands.

James Anderson said...

Very Informative! This blog is great source of information which is very useful for me. Thank you very much for sharing this!
thue dj tai ha noi

Anonymous said...

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