Service Modeling Language


Service Modeling Language ' and Service Modeling Language Interchange Format ' are a pair of XML-based specifications created by leading information technology companies that define a set of XML instance document extensions for expressing links between elements, a set of XML Schema extensions for constraining those links, and a way to associate Schematron rules with global element declarations, global complex type definitions, and/or model documents. The SML specification defines model concepts, and the SML-IF specification describes a packaging format for exchanging SML-based models.
SML and SML-IF were standardized in a W3C working group chartered to produce W3C Recommendations for the Service Modeling Language by refining the “Service Modeling Language” Member Submission, addressing implementation experience and feedback on the specifications. The submission was from an industry group consisting of representatives from BEA Systems, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, and Sun Microsystems. They were published as W3C Recommendations on May 12, 2009. In the market and in applying by vendors, SML is seen as a successor/replacement for earlier developed standards like DCML and Microsoft's proprietary System Definition Model or SDM. See for a historically helpful relation between SDM and DCML, and for the joint pressrelease announcing SML. In the Microsoft section of it the sequel role to SDM is mentioned.

Fast Formal Facts about SML

The Service Modeling Language is a language for building a rich set of constructs for creating and constraining models of complex IT services and systems. SML-based models could include information about configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on.
An SML model is a set of interrelated XML documents. An SML model could contain information about the parts of an IT service, as well as the constraints that each part must satisfy for the IT service to function properly. Constraints are captured in two ways:
; XML Schema documents : constrain the structure and content of the XML instance documents in a model. SML uses XML Schema 1.0, but allows later versions as well. SML also defines a set of extensions to XML Schema to constrain references, and identity constraints that apply to sets of documents.
; Rule documents : constrain the structure and content of documents in a model. SML uses Schematron and XPath 1.0 for rules, but allows later versions as well.
Once a model is defined, one of the important operations on the model is to establish its validity. This involves checking whether all model documents satisfy the XML Schema and rule document constraints.

SML-Based Models

One anticipated use for SML is to define a consistent way to express how computer networks, applications, servers and other IT resources are described or modeled so businesses can more easily manage the services that are built on these resources. This enables a hierarchy of IT resource models to be created from reusable building blocks rather than requiring custom descriptions of every service, thus reducing costs and system complexity for customers.
Models provide value in several important ways:
  1. Models focus on capturing all invariant aspects of a service/system that must be maintained for the service/system to be functional. They capture as much detail as is necessary, and no more.
  2. Models are units of communication and collaboration between designers, implementers, operators, and users; and can easily be shared, tracked, and revision controlled. This is important because complex services are often built and maintained by a variety of people playing different roles.
  3. Models drive modularity, Re-use, and standardization. Most real-world complex services and systems are composed of sufficiently complex parts. Re-use and standardization of services/systems and their parts is a key factor in reducing overall production and operation cost and in increasing reliability.
  4. Models represent a powerful mechanism for validating changes before applying the changes to a service/system. Also, when changes happen in a running service/system, they can be validated against the intended state described in the model. The actual service/system and its model together enable a self-healing service/system – the ultimate objective. Models of a service/system must necessarily stay decoupled from the live service/system to create the control loop.
  5. Models enable increased automation of management tasks. Automation facilities exposed by the majority of IT services/systems today could be driven by software – not people – for reliable initial realization of a service/system as well as for ongoing lifecycle management.