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!


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


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

Anonymous said...

This is so nice post.
Very interesting post,

Anonymous said...

So post Thanks for sharing

Anonymous said...

Nice blogthnx for posting

Anonymous said...

Nice blogthnx for posting

Anonymous said...

thanks for sharing;

Kerala holidays
Kerala holiday packages
Kerala Backwaters Tours
Honeymoon in Kerala

Anonymous said...

Ohh Dear Really ExlentYours Blog

> Please visit on my Sites
Kerala Tourism
Kerala Tour packges


Long time i have just read this post. It help me more knowledge, more infomation and help me get more traffic. We are Trieu Gia Phat
See my site:

móc áo inox cao cấp
hộp giấy vệ sinh inox 304
phụ kiện phòng tắm inox 304 cao cấp
phụ kiện phòng tắm inox
phụ kiện nhà bếp inox

fortmyerscarwash said...

It is a Good article thanks for sharing.

hand car wash fort myers
fleet car cleaning services fort myers
auto car reconditionning near me
auto upholstery cleaning fort myers
auto upholstery cleaning near me
interior car shampoo near me
interior odor removal
professional car wash near me
interior shampoo car wash
interior vacuum car wash near me