RE: [dcml-frame] Meeting info

["Andre Kramer" <andre.kramer@eu.citrix.com>]

Please see attached for second action.

Regards,
Andre


-----Original Message-----
From: Tim Howes [mailto:howes@opsware.com] 
Sent: 01 March 2005 17:44
To: dcml-frame@lists.oasis-open.org
Subject: Re: [dcml-frame] Meeting info

Attendees: Tim Howes, Andre Kramer, Barak Perlman,
            Josh Sirota

Actions from today's call:

- Fred (in absentia) with assistance from Barak to
   produce concrete UML proposal for DCML.

- Andre to send to list idea for DCML's relationship
   to other standards (e.g., CIM, etc.).

- Tim to investigate face-to-face WG meeting at
   end of April OASIS meeting or earlier.

- Ajay (in absentia) to extend ITIL use cases to
   next level of detail, making clear where DCML
   comes in.

Tim Howes wrote:
> Hi all. We will be having our bi-weekly framework
> working group call tomorrow. Here's the info:
> 
> Time: 9:00am - 10:00am PST
> Dial-in: +1 888 772-1825
> Passcode: 4087447509
> 
> Agenda:
> 
> - Introduction and roll call
> - Agenda review
> - Partner recruitment update
> - Alternate proposal review
> - ITIL use case review
> - Any other business
> 
> See you all tomorrow.              -- Tim

Title: Towards a DCML Modelling Manifesto

Towards a Modeling Manifesto for DCML

Andre Kramer,

Citrix Systems, Inc.

 

A data center Model is central to automated data center management and the DCML Framework TC is chartered to “create an XML-based data model and exchange format for …data center … resources” (see TC page) to help achieve management automation. The input specification suggests using Semantic Web ontology, standardized as RDF/OWL. However, questions about Model representation and relationships to other standards keep being raised and are expected to continue to be the No. 1 FAQ topic.

 

 

In this note, we review some base requirements and start to develop a representation agnostic approach to the data center model, aimed at supporting mappings to multiple XML exchange formats in an open manner. Two observations are in order up front: Firstly, if we disagree about the listed requirements themselves, then we may wish to more fully work through our initial assumptions. Secondly, we do need a common conceptual framework in order to do shared semantic modeling: my (our?) initial assumption is that “Sematic Web”, as standardized by the W3C in RDF/OWL, is the one and only existing standard framework for such discussion!

 

But this shared conceptual model should not require that actual data center models (aka system models) are expressed in a particular representation internally (e.g. as an RDF/OWL model). Use of proprietary models (e.g. Microsoft’s SDM or HP’s SmartFrog) should be possible, which becomes our first (more a non) requirement:

 

+ Actual data center system models are not standardized by DCML.  (R1)

 

Such system models can themselves be modeled using Semantic Web ontologies, but we need to carefully limit the expressiveness for interoperable interchange. Not only do we risk computational completeness otherwise, we also risk specifying features not supported by the system models referred to by R1.

 

+ Advanced ontology features are optional for (non-automated / human) modeling.  (R2)

 

This would tend to limit our modeling to OWL DL or even OWL Lite, or risk expressing semantics that can’t be communicated interoperably. Later, we will see that OWL Lite (or RDF Schema or even XML Schema) is itself a valid model interchange format, so we may wish to adopt one of these as our semantic modeling mechanism. This obviously impacts the work of the other (non-Framework) DCML groups.

 

+ Models are encoded in XML and contained in XML documents for interchange.  (R3)

 

Data center model semantics must be encode-able in XML. DCML documents should clearly separate models and data center information in XML sub-trees (though XInclude like mechanisms could be used). In very concrete terms, the DCML XML Schema (XSD) could define <model> and <modelData> elements that allow “xsd:any” content. The DCML XML Schema then defines an annotated, sectioned document container for the exchange of models and model data. Both <model> and <modelData> must carry a type attribute and, optionally, a schema location can be given[1]:

 

<complexType name=”ModelType”>

    <sequence>

         <any namespace=”##other” processContent=”lax”/>

         <attribute name=”type” type=”xsd:QName” use=”required”/>

         <attribute name=”schemaLocation” type=”xsd:anyURI”/>

   </sequence>

</complexType>

 

This allows for the definition of concrete models for interchange between DCML entities.

 

Obviously, document producers and consumers must both understand the model representations, as determined by the type attribute and inline schema or schema referenced by schemaLocation, being exchanged, for DCML to be useful for automation. This can be greatly facilitated by defining an abstract “class and instance” model that captures communality expressed through our fourth requirement:

 

+ Concrete Models are class based and used to exchange instance property values & relations.  (R4)

 

Hopefully, this requirement is general enough to satisfy conventional “object-oriented” modeling approaches, as well as newer Semantic Web ontology based approaches. Note the overtly general “class based” and “property values and relations” weasel words. These are best addressed by defining a simple example semantic modeling language. Our suggestion is that this be very close to OWL Lite, RDF Schema or XML Schema. This language’s concepts would also be very similar to those found in more classic object oriented modeling:

 

Class, instance(Of), SubClassOf, Property

 

One concession to ontology based modeling is that a Property is not normally only associated with any one class but can have its domain restricted. The full list of simple constraints on properties is as follows:

 

domain, range, cardinality(includes optional & unbounded)

 

+ Concrete Model representations must have a mapping to DCML language. (R5)

 

It is expected that UML (or rather XMI as the “XML Metadata Interchange” XML serialization of UML), CIM, and other De Jure and De Facto models (hopefully including future, in development, modeling languages, such as Microsoft’s SDM) can be contained in DCML documents. Basically, they are used to define Class-es with (domain-restricted) Property templates and instance-s with Property values or named relationships for use in data center modeling.

 

+ DCML processors must provide metadata specifying languages they support for each phase of the data center lifecycle.  (R6)

 

Note that, different models and data sets may be used in different stages of lifecycle management, as necessarily described by metadata sections of a DCML document. This metadata is envisioned as a list of URIs, as also used by XML namespaces.

 

+ Direct use of XML Schema and RDF/OWL is encouraged but consumers of DCML will still require domain specific processors for these common model interchange formats.  (R7)

 

As already mentioned, RDF/OWL(Lite) and XML Schema are expected to be used very frequently in data center modeling. Direct use of these should therefore be encouraged for interoperability reasons. However, the author suspects that even OWL based modeling will require references back to human readable documentation and supporting processors, in order that the encoded semantics to be usefully employed.

 

 

It is hoped that the above, minimal set of requirements (R1-R7) provides a useful framework for the interoperable description of data center information. Other groups may, through these, re-use existing modeling standards with DCML, or define new domain specific standards, with DCML “Core” becoming the interoperable container language for data center management automation. It may be noted that automation rules can be expected to require similar support.

 

History, comments and isues:

 

Created 4^th March 2005, Andre Kramer, Citrix Systems Inc.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

[1] Both type and shemaLocation attributes are introduced and used in XML standards. The exact re-use of these attributes would need some clarification.