Service Modeling Language

I'd long ago put up a very thick lens for looking at any news from the SOA space. With analysts and hungry vendors flinging the buzzword around in a mindless frenzy it came to the point where one out of twenty bits of information using the term were pure drivel. I do believe there is some substance to SOA, but it's definitely veiled in a thick cloud of the vapors. This week Service Modeling Language caught my eye through said thick lens, and I think it may be one of the more interesting SOA initiatives to emerge.

One problem is that the SML blurbs and the SML spec seem to have little substantive connection. It's touted as follows:

The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex IT services and systems. These models typically include information about configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on.

The second sentence reads at first glance as if it's some form of ontology of systems management, basically an actual model, rather than a modeling language. No big deal. I see modeling languages and actual models conflated all the time. Then I catch the "typically", and read the spec, and it becomes evident that SML has much more to it than "models of complex IT services and systems". It's really a general-purpose modeling language. It builds on a subset of WXS and a subset of ISO Schematron, adding a handful of useful data modeling constructs such as sml:unique and sml:acyclic (the latter is subtle, but experienced architects know how important identifying cyclic dependencies is to risk assessment).

I'm still not sure I see the entire "story" as it pertains to services/SOA and automation. I guess if I use my imagination I could maybe divine that an architect publishes a model of the IT needs for a service, and some management tool such as Tivoli or Unicenter generates reports on a system to flag issues or to assess compatibility with the service infrastructure need? (I'm not sure whether this would be a task undertaken during proposal assessment, systems development, maintenance, all of the above?). I imagine all the talk of automation in SML involves how such reports would help reduce manual assessment in architecture and integration? But that can't be! Surely SML folks have learned the lessons of UDDI. Some assessment tasks simply cannot be automated.

SML shows the fingerprints of some very sharp folks, so I assume I'm missing soemthing. I think that much more useful than the buzzword-laden blurbs for SML would be an document articulating some nice, simple use cases. Also, I think the SML spec should be split up. At present a lot of its bulk is taken up defining WXS and ISO Schematron subsets. It seems a useful profile to have, but it should be separated from the actual specification of SML modeling primitives.

[Uche Ogbuji]

via Copia
3 responses
The SML spec defines the syntax and semantics of the modeling language. The WG plans to publish a scenario and sample models document, as well as modeling guidelines document later.

SDM (which was the input from Microsoft to the SML WG) is already being used in management products such as MOM, SMS, and Service Desk to use models for automating some management tasks. I expect SML to play an important role in automating and simplifying the management of complex IT services and systems, but it will not replace smart and experienced IT administrators. Rather, it will be an important tool for them to manage IT services and systems.

Last, but not the least, I am flattered by your comment "SML shows the fingerprints of some very sharp folks".
aah, you are missing the key point.

What you can do with a service modeling language is actually automate deployment. not just validate it, but roll stuff out to lots of machines.

The goal is to eliminate the entire hand-install-oracle on machine A, app server on host B, try and get the passwords consistent across both, etc, diagnose that someone mistyped the ipaddrs in the hard coded hosts table, etc, etc.

Have a look at some presentations of mine to see examples of the smartfrog deployment system in action. First for classic multi-tier config/deploy

then for deploying a real distributed system -here junit tests- across boxes, collecting the results back in later.

I dont know whether SML can be used for this level of config/deploy; I am sure I will find out when I return to work in september.
The SML WG welcomes feedback on the SML specification from Uche and the readers of this blog. The SML Feedback workshop will be held in Mountain View, CA, USA on September 12,2006, so that community members can present their feedback to the SML WG.

A feedback agreement must be signed before submitting feedback. Please visit for details.