Piyush Pant wonders if SML solves a problem that nobody has? He also points out SysML project, which recently got folded into the OMG. Well, that explains why we called it “Service” instead of “System” modeling language.

Now that I work in IT, I can definitely say that SML will eventually solve a problem that I have. Most people agree that operations today is way to dependent on manual processes to scale effectively. Now SML doesn’t solve that issue directly – as Piyush pointed out SML is a meta-modeling specification. However, SML is the foundation for the next generation of operational modeling tools like what we see in Visual Studio Team System for Architects. As I wrote several years ago, VSTS:A solves a very common problem – developers lack of understanding about the deployment environment. Piyush, haven’t you ever had a long weekend going back to the drawing board because the solution you had built was undeployable and you didn’t discover that fact until the operations team attempted to deploy it? If you haven’t, I envy you.

On the surface, I agree with Piyush when he says that “history of software is littered with unsuccessful attempts to impose monolithic modeling constructs”. However, the fact that it keeps happening indicates the problem hasn’t been solved. Wanting to solve a problem and being able to solve a problem are two different things. Furthermore, the history of software is also littered with very successful attempts to raise the level of abstraction by the introduction of new programming languages: C, C++, VB and Ruby are all examples of this. Given that Code is Model, what we have is a history of software littered with some successful and some unsuccessful modeling constructs. I would argue that the successful modeling constructs have taken a bottom up approach – build a language a small abstraction step above something that actually runs and compile down. These unsuccessful modeling constructs (*cough* UML *cough*) take a top down approach – build a language way above anything that actually runs and hope a miracle happens to keep it in sync with the stuff you actually build.

The question is whether SML will be top-down (i.e. a failure) or bottoms-up (i.e. a success). So far, it’s to early to tell, but I have high hopes.

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.

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.