I very much agree with Eric Newcomer’s recent post about service-oriented tooling. In discussions around SML, when people debate the decision of creating yet another metamodel I usually make three points:
- Need for powerful mechanism to convey constraints beyond the structure of the model
- Need for alignment w/ XML-based messaging
- It’s not really a new metamodel anyway since it borrows so much from XSD.
The second bullet resonates well with Eric’s argument. One of the consequences of using OO for modeling is the difficulty of mapping it to XML processing.
Now, despite its name SML is not really a service modeling language. What Eric has in mind is something more like SCA. SML is less specialized than that. Surely it can be used as a foundation for modeling services. But if you give just the SML spec to two persons and ask them to model services with it, don’t expect much useful interoperability between them. At least until common service modeling elements are defined on top of SML. Which begs the question, how does this relate to what SCA already provides?
In a very simplified way, what we see happening between SCA and SML is a smaller scale version on what is happening between SOA and ITIL. ITIL came from an operations perspective, with the goal of increasing the flexibility and responsiveness of the IT infrastructure. SOA came from a software design perspective, with similar goals. ITIL covers the whole spectrum of IT resources while SOA is focused on services. Similarly, SML came from an operations perspective and is generic enough to potentially apply at all levels of the IT infrastructure. While SCA came from the software design side of the house and is focused on software services.
This still doesn’t answer the question of the relationship between SML and SCA (e.g. can SCA be an SML-based model?) though. Stay tuned.