Category Archives: Tech

The previously released SML 1.0 and SML-IF 1.0 specifications have been submitted to W3C for standardization (actually the submission happened on 2/28 but W3C has acknowledged it today). My guess is that the fact that this announcement comes on the same day that SCA 1.0 is released is not going to decrease the confusion between these efforts.

After taking the form of two early drafts (versions 0.5 and 0.65), the SML specification has now reached v1.0, along with its sidekick the SML-IF specification. You can find both of them at serviceml.org. This is where the happy bunch that assembled to create these specs would normally part ways. Not quite true in this case since there is related work about to be tackled by a very similar set of people (more on this later), but at least we are not going to touch SML and SML-IF anymore. They are ready for submission to a standards body where further modifications will take place (more on this later too).

SML is, if I simplify, XSD augmented with Schematron. For those, like me, who aren’t fond of XSD, this is not very exciting… until you try to look at things in a different light. Instead of another spec that forces you towards the use of XSD (like WSDL), maybe the fact that SML uses XSD is your ticket *out* of XSD-hell. Let me explain.

I wrote above that I am not fond of XSD, and yet I see the value of having SML make use of it. Like it or not, many people and organizations have made heavy use of XSD to define well-known and reusable XML elements. And there is a lot of tooling (design time and runtime) for it. Breaking away from XSD altogether is possible (and advisable in many cases), but hard to do in places like systems management that have already invested heavily in using XSD.

The problem is that XSD is a document description language. It works well when the “document” abstraction is a good match. So, when I retrieve an XHTML page from a Web site, I want the paragraphs to be in the right order. The “document” abstraction is a good match. On the other hand, when I retrieve the configuration of a server, I don’t necessarily care if the description of the CPU comes before or after the description of the network card. I am still retrieving a document though (because XML forces this abstraction). But I don’t have the same requirements on its structure that I have on a document meant for publishing (like a Web page). For the non-publishing kind of interaction, a contract (a bullet list of things you can count on) is a better abstraction than a document.

XSD works better for the publishing kind of scenario, where you want to control all aspects of the document. It doesn’t work as well in situations where you just have some constraints that need to be met (e.g., the memory size must be a number) but other things are not important to you (order of some of the elements). As a result of XSD quirks, people often end up arbitrarily fixing the order of elements where it’s not needed (using xsd:sequence) and even have to introduce unneeded elements (to escape the dreaded UPA rule). And things become even worse when you have to extend and/or version existing XSD because of all the arbitrary constraints. Other metamodels like RDF avoid a lot of these problems by focusing on the assertion, rather than the document, as the base concept but this is a topic for another post.

One nice thing about the syntax constraints usually imposed by an XSD is that it makes the serialization of a piece of XML into a Java (or other language) more efficient. It doesn’t really matter semantically if the zip code is before or after the city name. In the US the zip code typically comes after (in postal addresses), in France it’s the contrary. And for this (unlike for the stupid MMDDYY date format, don’t get me started on this) you can make a case either way since in some places a zip code includes several cities and in others a city contains several zip codes. But whichever way you choose, you may be able to write a faster parser if you know in what order to expect them.

So I don’t mind at all having an XSD that describes a reusable type for elements that are very often used as an information atom, like an address (on the other hand, serializing an entire XML document into a Java object is often the wrong way to handle it).

By now you are getting an idea of what I want as an XML contract language. I want reusable elements that are small and potentially tightly defined (XSD definitions for a set of GEDs). And I want assertions that describe rules that a set of such elements need to obey in order to be valid as a unit per the contract. Which is where SML comes in. Because it provides a way to package XSD and Schematron, I can’t help thinking of it as a possible alternative to an all-XSD view of the world. If people have the discipline to only use the XSD part to describe small reusable elements and to rely on the XPath-driven Schematron constraints to provide the contract rules that tie these GEDs into a meaningful unit.

A few notes:

– I am fully aware (being part of it) that SML wasn’t created as a generic contract language for XML-based interaction, but as a desired state modeling language. The usage I am suggesting here is clearly a hack that abuses the syntax provided by SML (actually SML-IF). And I am not even sure that the SML-IF packaging would be an entirely convenient vehicle for this approach. I haven’t done the experimentation needed to validate that. It just seems to hit the ballpark of the requirements.

– I find it ironic that the approach to an XML contract language that I described above is already how many XML specs are defined in their human-readable section (at least in the SOAP world): a list of pseudo-XPath statements with a description of what to expect at the end of each one. But somehow at the bottom of each of these specs we get a huge XSD that imposes a lot of extra constraints that have no justification in the semantics of the spec. Rather than having a set of XPath-driven schematron statements that provide a machine-readable equivalent of the human-readable rules described used pseudo-XPath. Like the Queen song (almost) says “Fat bottomed specs you make the SOAPin world go dumb”.

The question I hear most often when talking about SML, is how it relates to CIM. The easy part of the answer is to explain that SML is a metamodel, like MOF, not a set of model elements/classes like CIM. SML per se doesn’t define what a blade server or a three tier application looks like. So the question usually gets refined to comparing SML to MOF, or comparing an SML-based model to the CIM model. Is it a replacement, people want to know.

Well, you can look at it this way, but whether this is useful depends on your usage model. Does your usage model include a distinction between observed state and desired state? You can use SML to model the laptop in front of you, but if all you’re doing is reading/writing properties of the laptop directly you don’t get much out of using SML rather than CIM, definitely not enough to justify modifying an existing (and tested) manageability infrastructure. But if you change your interaction model towards one where there is more automation and intermediation between you and the resource (at the very least by validating the requested changes before effectuating them), then SML starts to provide additional value. The question is therefore more whether you would benefit from the extra expressiveness of constraints (through schematron) and the extra transformability/validation/extensibility (through the use of XML) that SML buys you. If you’re just going to assign specific values to specific properties then CIM is just as good. And of course keep in mind that a lot of work has already gone into defining the domain-specific semantics of many properties in CIM and that work should, to the extent possible, be leveraged. Either directly by using CIM where SML doesn’t provide additional value, or indirectly by carefully surfacing CIM-defined elements inside an SML model. Finally, CIM defines operations while SML doesn’t have such a concept. The most natural way to do a “start” using SML is not to invoke a “start” operation as it is in CIM, it is to request the configuration to be changed to a state in which the resource is started. In conclusion, there is a lot more to the “CIM versus SML” question than a direct replacement. Those who just look at ways to do syntactical translation between the two approaches will repeat the same errors that created (and still create) so many problems for those who saw Web services as just another way to do object to object RPC. The usage model (some would say the architecture) is what matters, not the syntax.

BEA, BMC, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft and Sun just published a new modeling specification called SML (Service Modeling Language). This is the next step in the ongoing drive towards more automation in the management of IT resources. The specification makes this possible by providing a more powerful way (using Schematron) to express system constraints in a machine-readable (and more importantly machine-actionable) way. It also has the advantage (being based on XSD) to align very well with XML document exchange protocols and the Web services infrastructure.

Here is the SML spec on the HP site. Very soon there will be an HTML version of the spec there in addition to the PDF. In addition, the serviceml.org Web site is a basic but vendor-neutral home for the spec.

Those familiar with the QuarterMaster work will see a lot of commonality and know that HP has a lot of experience to contribute in this domain: paper 1, paper 2 and paper 3.

This is an initial draft, not a final specification. The major hole in my mind at this time is the lack of support for versioning. Something to address soon.

There are many good things about this specification, but unfortunately not the name. Just for kicks, here are some better candidates:

• ITSOK (IT Systems Operational Knowledge) “it’s ok”
• ITSON (IT Systems Open Notation) “it’s on”
• ITSUP (IT Systems Upkeep Profile) “it’s up”