Thursday, October 16, 2008

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!


miguel said...

The anatomy, yes, thats what I'm really looking to sink my grey cells into.

One quick point though, "Services should not be dependent on other services to function without failure" -- so in the case of Service Composition does this mean the if the "service" is composed, that it should have logic to respond to the occasion where "composition" services are unavailable. So it doesn't actually fail, but it tells you it can't do its thing yet. Or does it mean that "service composition" is a bad idea where you can't garantuee QoS on all elements of the composite?

Anyhow, have fun at the bbq and I'll keep my eyes peeled here for updates :)

Bill said...

Hi Miguel,

The former is true. A composed service certainly should have logic to compensate for failures.

A service can/should also leverage asynchronous messaging to interact with other services to eliminate temporal coupling - i.e. the need for all services to be available at the same time in order to function.


Nathan said...

Hi Bill,

I just wanted to thank you for creating this blog. I hadn't heard much about SOA before and I feel quite fortunate that this has been my introduction.

I look forward to your future posts.

Colin Jack said...

"The former is true. A composed service certainly should have logic to compensate for failures."

Looking forward to reading more about the particular strategies you use to achieve this.

saket said...

nice blog.

Goa Holidays said...

This is so nice post.
Very interesting post,

Sarwar Tch said...

This is so lovely Blog posted

Sarwar Tch said...

So post Thanks for sharing

pratima giri said...

Nice blogthnx for posting

pratima giri said...

Nice blogthnx for posting

pratima giri said...

Ohh Dear Really ExlentYours Blog.....

Sarwar said...

thanks for sharing;

Kerala holidays
Kerala holiday packages
Kerala Backwaters Tours
Honeymoon in Kerala

Sarwar said...

Ohh Dear Really ExlentYours Blog

> Please visit on my Sites
Kerala Tourism
Kerala Tour packges