My teammate Dale and I are going to an SOA Workshop in Vancouver in mid September. The workshop is put on by SOA Systems, which was founded by “top-selling SOA author” Thomas Erl. I have a copy of his first book, but I’ve never really opened it. Dale let me borrow Erl’s second book. I figured since I was going to see him speak, I should at least flip through his books.

I was looking thru the chapter 9 “Principles of Service-Orientation”. Most of them are spot on, if not exactly news. Services are loosely coupled, autonomous and share a formal contract. Yep, with you so far. But then I got to this one:

Services are Stateless
Services should not be required to manage state information, as that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere.

This seems way wrong to me on several levels. Now I’m really looking forward to going to Erl’s workshop, so I can discuss this with him face-to-face.

First off, his terminology is confusing. I have a hard time believing he really think services in general should have no state at all. I’m sure there are some examples of completely state-free services, but I believe they are both very rare and fundamentally uninteresting. A simple calculator service has no state, but why would you actually build or use one (except as a demo)? I assume Erl means that service should be stateless in the same way HTTP is stateless. IMO, stateless is poor description of HTTP. Connectionless or sessionless would be more accurate.

Regardless of my opinions on poor terminology, the problem with stateless services is that many – perhaps most – business operations aren’t stateless. And while HTTP is stateless, as soon as you use cookies, it becomes a stateful protocol. If you don’t believe business operations are stateful, try buying something on your favorite ecommerce site with your cookies disabled. Most sites will give you a “Your computer must have cookies enabled” error message. Sites that still work are embedding a session ID in the URL instead of in a cookie (ASP.NET has built in support for this type of Cookieless Session State). Either way, state is required for even the simple task of ordering something from a web site.

If most business operations aren’t stateless, why should services that implement business operations be stateless? This seems like a violation of the “but no simpler” part of Einstein’s famous paraphrased quote.

After a six month silence, Dad posted about what he called Business Oriented Architecture (BOA?):

If I had to guess what a service oriented architecture will eventually look like, I would guess that it would reflect the business architecture – Business Oriented Architecture (BOA). Business organizations have evolved over many centuries into a number of common “departments” – sales, accounting, personnel, etc. Perhaps that is a good starting place for services.

John forwarded me a post from Richard Veryard where he comments on Dad’s post:

The issues addressed in my book are now becoming mainstream as the technological agenda of service-oriented architecture (SOA) starts to converge with the strategic agenda of the service-based business (SBB). This implies an approach to business strategy that involves dynamically managing the geometry of the business. (To achieve a fully adaptive enterprise we typically need to implement a variable geometry.) We can find elements of this thinking in some of the methodologies coming out of IBM and Microsoft, although from what I’ve seen so far I don’t think any of these methodologies go far enough.

Hal calls this Business Oriented Architecture. If anything, I’d prefer to call it Architecture-Oriented Business. As Hal indicates, this calls for architectural thinking at the business level, which need to be aligned with architectural thinking at the information/software level.

This comes back around to the whole SOA top-down vs. bottom-up argument. Something I’ll comment further on when I’m not up to my armits in moving boxes.

I met John Crupi – CTO of Sun’s Enterprise Web Service Practice – at OOPSLA last year. Very cool guy. I hadn’t realized he started blogging last month until Steve Vinoski linked to him. There seems to be some disagreement regarding using a top-down approach to SOA. Steve writes that SOA, like other “real-world development” is usually a mix of top-down and bottom-up. John writes that SOA is about a business driven architecture instead of an IT driven architecture. I liked this quote:

“[W]e cannot do SOA without a mutual effort between IT and the BU. Gone are the days of throwing the requirements over the fence and hoping it hits. Not only do these two groups have to work together, they have distinct roles and responsibilities. Basically, the BU runs the show and owns the business drivers, use-cases and processes. IT implements the BU requirements and owns the service definitions.  It’s unfortunate that we really do have to refer to this as a “shift”, because we should be doing this anyway. But, the reality is that IT and BU typical function as disparate groups and rarely work together to have the business use-cases drive the process and service definition.”

John Evdemon made two points  relevant to this issue several months ago:

• SOA does not enable or ensure the alignment of IT and business. The IT industry has been promising this for decades – there is no silver bullet for aligning IT and business. Alignment of IT and business is an organizational issue that will not be resolved by an architectural design philosophy alone.

• Service Orientation will happen in your organization in one of two possible ways: chaotically (typical approach) or in a disciplined manner. The path your organization takes (and the cost of later fixing that path) is up to you.

I’m with John on this one. Traditional approaches to new problems are rarely successful.

BTW, if you haven’t seen Steve’s entry on Isomorphism, go read it right now. He nails this whole services as contracts vs. services as code debate right on the head. The spot on nature of this post reminds me when he nailed the modeling problem on the head – another must read post if you haven’t already.

A couple of weeks ago, Paul Murphy pointed me at a SSB Wrapper Class that’s included in one of the SQL 2005 Beta 2 sample apps. That prompted an email from the SSB dev lead with a much better SSB library that they had written. You can get that library, along with two new samples that use it, up on the SQL Server Service Broker Developers Spot. The SSB Dev Spot is a community site dedicated to apps written on top of SSB. It’s run by Dan Sullivan of Developmentor, who is also hosting his new blog on the site. I hear Dan and fellow DM-ers Bob Beauchemin and Niels Berglund are all very excited about SSB. Nice to know I’m not the only one.