On the one hand, this seems like a somewhat arbitrary name change – from System Defintion Model to Service Modeling Language. And the use of the term “Service” instead of “System” seems sketchy to me.

On the other hand, you gotta love this line from the press release: “The group plans to submit the draft specification to an industry standards organization later this year.” Given the companies involved in “the group” – MSFT, IBM, BEA, Sun, Dell, BMC, Cicso, Intel, HP and EMC – you gotta think SML has a bright future.

Here’s hoping that publishing the SML spec is the first step in a public-workshop-based revision process, a la the Web Services Protocol Workshops.

My old boss’s boss seems like he was in a downer mood yesterday. First, he blogged about the “Myth of Reuse in SOA“, then the “Achilles Heel of SOA“. Actually, truth be told, I agree with him on both counts.

I slam the door on the reuse argument every time it comes up in my new job. Actually, I slam the door on what I call “Naive Reuse”. When John talks factoring for agility, he’s talking about a form of reuse – similar to how use “reuse” code when you refactor. What does it mean to refactor service? How about refactoring your enterprise?

As for the Achilles Heel “data problem”, I think that’s an artifact of the prevailing stateless request/response mindset most people have about services that I touched on yesterday. I think Pat Helland described a very good approach for dealing with data in an SOA, but I haven’t seen it implemented broadly. Rest assured, many of the concepts Pat described are at the forefront of my thinking as my new project takes shape.

Speaking of Sam, he talks today about one-week iterations and having a “shippable” version of the code every week. Reminds me of Jim McCarthy’s classic book “Dynamics of Software Development”. One of the many rules from that book is “Get to a Known State and Stay There” – I’m sure that sounds familiar to Sam. Other classic rules include “Don’t Flip the Bozo Bit” and “When You Slip, Don’t Fall”.

I just noticed MS Press is putting Dynamics of Software Development back in print with a new cover and a DVD of the the original “21 Rules” presentation that begat the book. It’s a great book – I highly recommend it as well as his other book “Software For Your Head“. Also, Jim and his wife Michelle are doing a podcast called The McCarthy Show. Subscribed.

Last fall, I was presenting to a group of architects about SOA. The previous speaker – Rich Turner – was running way late. As I walked in, he was doing a WCF demo and wanted to show how easy it was to change transport by changing the config file. He wanted to change it to run over named pipes, but he couldn’t remember the name of the binding. He asked me, and I confessed that I didn’t know either. So he gave up on demoing named pipes, finished his presentation and went on his way.

After he left, I confessed to the assembled architects that I knew *nothing* about WCF beyond the high-level concepts. I hadn’t spent any time working with it at all. In fact, the only reason I had it installed was because it got installed automatically when you installed WPF which I was working with at the time. My reasoning, as I explained to them, was that WCF is a low-level abstraction. That is to say, WCF is nearer the bottom of the .NET Abstraction Pile than the top. I figured I’d let the people building the next generation of service-oriented infrastructure to worry about WCF.

Fast forward eight months, and my new job is about building service-oriented infrastructure. You know, the type that builds on WCF. Maybe it’s karma, but I’m having to learn a lot about WCF right quick.

So as I get back into the blogging saddle, expect to see a bunch of stuff about WCF.

BTW, Major thanks to Sam Gentile, who’s taken the time on email and the phone (on his vacation no less) to help talk some things thru. He suggested the WCF Hands On book, which is pretty good.

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.