Geeks With Blogs

News Dave's Mug View David Oliver's profile on LinkedIn Add to Technorati Favorites Blog Directory for Guildford, Surrey
Dave Oliver's Blog Enterprise Technology Thought Leadership in a FTSE 100

Right, let’s talk more about SOA.

Many people have different visions of what SOA is, mine is actually very simple.

Don Box’s 4 tenets.

Tenet 1: Boundaries Are Explicit. Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services.


Tenet 2: Services Are Autonomous. Services behave reasonably as independent entities. We make no assumptions on the space between the service boundaries. There is no presiding authority in a service-oriented environment. Services are independently deployed, versioned, and managed. The topology in which a service executes can and will evolve. The service should expect that peer services can and will fail, and that it can and will received malformed or malicious messages. Services should be built not to fail, using (for example) redundancy and failover techniques.


Tenet 3: Services Share Schema and Contract, Not Class. Services interact solely on their expression of structures using schema, and behaviors using contract. The service's contract describes the structure of messages and ordering constraints over messages. The formality of the expression allows machine the verification of incoming messages, which allows us to protect the service's integrity. Contracts and schema must remain stable over time, so building them flexibly (for example, through use of xsd:any in schema) is important.


Tenet 4: Service Compatibility Is Based on Policy. Both service-providers and service-consumers will have policies—operational requirements—for interactions across boundaries. A simple example of provider-side policy is that a service may require that the invoker have a valid account with the service provider. From the consumer-side, an organization may require that service invocations across the Internet be encrypted, so it will only use services that offer the capability of bi-directional security-enhanced data exchanges. Services express their capabilities and requirements in terms of a machine-readable policy expression. Policy assertions are identified by a stable, globally unique name. Individual policy assertions are opaque to the system at large; services must simply be able to satisfy each other's policy requirements.


SOA doesn’t mean XML Web Services!

Web Services are most often used as in examples of SOA as it’s easy to implement the principles of SOA with this technology and we do like to follow the path of least resistance.

SOA has been around for along time as the principles are based on good practice and common sense. Just like ‘patterns’, some bright spark gave the practice a TLA (Three Letter Acronym) this alone in my opinion is enough to put people off, because most of the industry is heartily sick of TLA’s. Who can forget such classic as TCO (Total Cost of Ownership) which is a common financial principle, but thanks to Dr Kerwin of Gartner Group has a TLA to summaries what it means.

But does SOA get the imagination going as much as names Indigo or Avalon? Hmmm, perhaps we should rename SOA, something that gets the brain juices going? Have a go feedback I would love to hear your ideas.

Another reason is that in the I.T. industry we do have a habit of screaming “This is the next big thing” from the roof tops even when something is extremely ordinary to everyone else.

For a good example let’s talk about cars …

Say you buy a Ford Focus, you love it, because it’s your car and it affords you all the personal freedom a full-tank can offer, it’s also shiny and beautiful, has loads of cool features that are just great and labour saving. So you’re excited about it, but everyone else is seeing a Ford Focus, lots of people have them, but perhaps you don’t get it unless you have one, or have driven one.

Another reason is that your stark reality is that you have a push-bike, it gets you from A to B, but you have to put in one hell of a lot of energy to make that happen and you can’t afford to buy a Ford Focus, but boy when it rains and your getting wet do you want one then. Even in the days before Ford Focus’s human creativity was hard at work imagining how wonderful a Ford Focus could be!

Desire is a very strong human emotion, especially when COM, EJB or whatever, isn’t cutting it, oh and it’s when you really need it.

Have you been there?

So it frustrates the crap out of me when people don’t get it and can’t see the problem because they really haven't experienced the issues first hand.

I’m an old VB coder that made COM DLL’s in MTS for YEARS! Have you done that?

I think we should have quick straw-poll, if you have been where I’ve been, are you anti-SOA? Do you know, I seriously doubt it?!

“Tenet 3: Services Share Schema and Contract, Not Class” I could have hugged Don Box when I read that for the first time.

In the next instalments of my voyage in SOA we will be adding details to my vision and start putting aspests under the microscope an have a look at the good, bad and the darn ugly. We will also look at ‘Anti-Patterns’ and talking to people who have successfully implemented SOA.

Posted on Friday, May 20, 2005 10:34 PM | Back to top


Comments on this post: The first instalment of my personal voyage into SOA.

Comments are closed.
Comments have been closed on this topic.
Copyright © Dave Oliver | Powered by: GeeksWithBlogs.net