RE: [dcml-frame] Meeting info

["Cummins, Fred A" <fred.cummins@eds.com>]

Andre,

I'm afraid I don't understand your classifications.

1) there is a need for the DCML contributors to have
a common data model on which to base the DCML specifications.
This is a tool for the development of the specifications,
and the data model or segments of it could provide documentation
for the associated XML specifications.  This is the only
use I am recommending for UML and XMI.  XMI would be only
for exchange of these models between UML tools.

2) There is a need to specify the DCML documents/messages
exchanged for particular purposes.  This is a combination
of XML schema with text and examples.  

3) There will be applications/services that consume or produce 
the DCML messages.  The design of these is not part of the 
DCML specifications except to define their interfaces 
(i.e., the operations/requests supported).  These might be viewed 
as tools or models, but they are not models for developlng 
specifications or designing systems, they are models that 
represent aspects of the data center for certain purposes.  Again,
what these applications/services do and the associated interfaces
are probably part of DCML, but how they do it is not (that's the
responsibility of an implementer/vendor).

4) Data about a datacenter may be stored in a repository 
(e.g., a CMDB).  This is, in general terms, a database, and like
any database, it could be construed to be a "model" of the
data center.  I suppose there could be a DCML specification for
exporting and importing the entire contents of such a database,
but I don't see that as a particular concern.  What is more
important is that the messages input to this database be defined
in DCML to communicate various events for which the database
should be updated.  The database might support a variety of
queries as databases do, with a standard query language--not
to be defined by DCML.  The common data model would define the
database schema which would also be a composite of all of the
inputs--the inputs must also to be consistent with the data model.

5) There probably should be an architecture model for the data
center that identifies the applications/services that manage and
operate on data center information.  The architecture should
identify these components and their relationships.  The same
or a related model should define the events that cause messages
to be produced or consumed by these components.  This reference
architecture provides a context for the DCML specifications, 
but should not be part of the standard since it should be 
possible for the architecture to evolve without breaking the
DCML body of standards.  I suppose this could be a UML model
but I'm not particularly concerned about that.

6) It would be possible to define a modeling language (or maybe
multiple modeling languages) for modeling aspects of a data center.
If this is a goal, I would recommend that these be MOF models
(the meta language of UML) to take advantage of the related 
technology such as the model transformation language that is
expected to be finalized soon by OMG.  Such models would
be implicitly exchangeable using XMI.  However, I see this
as a different purpose from DCML that I expect to be more
event oriented for monitoring and managing a data center.


Fred

> -----Original Message-----
> From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
> Sent: Tuesday, March 08, 2005 4:33 AM
> To: Cummins, Fred A; Tim Howes; dcml-frame@lists.oasis-open.org
> Subject: RE: [dcml-frame] Meeting info
> 
> 
> I see three distinct uses for modeling:
> 
> 1) Human modeling (we, as TC members or spec adopters).
> 2) For interchange of data center models.
> 3) Internal to management tools.
> 
> I would still champion ontologies for (1) but we (humans) 
> certainly have
> the ability to use other techniques. I suspect that UML could be
> specialized to provide a (customized sub-set) language for data center
> modeling by humans, but that would be quite a bit of work 
> that may be on
> the same order as developing a specialized language without 
> the benefits
> that such a domains specific language brings (see
> http://msdn.microsoft.com/architecture/overview/softwarefactories/ for
> some interesting work on special v.s. general (UML) models and Grady
> Booch's 
> http://www.booch.com/architecture/blog.jsp?archive=2004-12.html
> Dec 3rd dissenting blog). Note that RDF/OWL brings along 
> tools that help
> with reasoning about (1).
> 
> More germane for DCML, my proposal for (2) is that we allow for
> different kinds of models to be exchanged, contained in XML. 
> I still do
> not see why we would force spec adopters to use XMI or for (2)
> necessarily to be equal to (1). My suggestion is that we develop a
> simple class based modeling syntax to help interoperability, backed by
> RDF/OWL standard semantics but allow different kinds of 
> models and data
> to be exchanged.
> 
> I strongly feel we should not mandate (3) at all, but do need 
> to address
> the ease of mapping (2) to (3), as well as facilitating human
> understanding (1). 
> 
> As you can see, I'm not at all sure that UML is the right approach.
> Could you develop an example that uses UML for (1) and (2), without
> assuming tools are UML based (3)? That would give us a 
> concrete proposal
> (based on UML).
> 
> Maybe then we should revisit the requirements I identified (R1-R7) and
> see where the dragons are hiding?
> 
> Regards,
> Andre
> 
> -----Original Message-----
> From: Cummins, Fred A [mailto:fred.cummins@eds.com] 
> Sent: 07 March 2005 18:06
> To: Andre Kramer; Tim Howes; dcml-frame@lists.oasis-open.org
> Subject: RE: [dcml-frame] Meeting info
> 
> Andre,
> 
> See my comments, below.
> 
> Fred
> 
> > -----Original Message-----
> > From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
> > Sent: Monday, March 07, 2005 12:18 PM
> > To: Cummins, Fred A; Tim Howes; dcml-frame@lists.oasis-open.org
> > Subject: RE: [dcml-frame] Meeting info
> > 
> > 
> > Hi Fred,
> > 
> > Just to note that your scheme fits into my proposal at some 
> level, as
> > XML is used to exchange models defined using some OO modeling 
> > language.
> > But the proposal is open to diverse approaches, based on 
> the existing
> > "Semantic Web" modeling as a unifying abstraction tool.
> 
> While I appreciate the potential power of ontologies, particularly
> for classifaction and search of information on the web, I see a need
> for a practical and proven approach to the development of DCML 
> standards and the systems that will support them.
> > 
> > I agree we could define such a single model, or leverage one 
> > of several
> > existing standards, but a framework based on ontologies would 
> > be able to
> > handle more than one such language - opening the door to others.
> 
> There is no need to handle more than one language--UML is widely
> accepted, tools are readily available, and there is a large community
> of people who understand it.
> > 
> > Which leads me to the question that I think the first 
> action requested
> > answered. Exactly how is UML to be used here? XMI (and MOF) 
> > seems to be
> > overly sophisticated (express general "programming" OO 
> > models) and if we
> > (or others sub-set UML encoded as XML) don't we just invent our own
> > language?
> 
> XMI and MOF come with UML for the sharing/exchange of models. 
>  Modeling
> tools understand it.  That does not mean that XMI should be used for
> DCML.  XMI has a specific purpose--exchange of models.
> 
> Of course it could be argued that DCML will model the data 
> center.  But
> any object-oriented application "models" the subject domain.  There
> is overhead in a robust modeling environment that is not appropriate
> for production applications and data exchange. 
> > 
> > This, I claim, would not be too different to the "Class, SubClassOf,
> > instanceOf, Property" language I mentioned in the proposal. 
> > But I would not force all user of DCML to use this exact modeling 
> > approach (not very rich).
> 
> The common data model is for the purpose of achieving consistency in
> the various standards produced under the DCML umbrella.  The standard
> that users of DCML will use is the XML specification that defines the
> form for exchange of data for particular purposes.  If these
> specifications
> are not well documented, then there may be a need to refer to 
> the model.
> 
> Furthermore, most users of DCML will never see the DCML, but will use 
> it implicitly to integrate the services that run their data centers.
> > 
> > On the other hand, if we have a concrete single proposal for a data
> > center modeling language based on reuse of an existing management
> > standard then DCML as framework may also be in danger of too much
> > overlap with the existing std (if it is to be the only one 
> supported).
> 
> This sounds like you are suggesting a different approach so that an
> overlap with other standards is obscured.  I think it is important to
> make overlaps evident and resolve them.  If you are suggesting that
> there
> might be a problem defining the bounds of DCML, I think the 
> problem will
> be much greater if you are trying to start with an ontology.
> > 
> > Regards,
> > Andre
> > 
> > -----Original Message-----
> > From: Cummins, Fred A [mailto:fred.cummins@eds.com] 
> > Sent: 07 March 2005 16:39
> > To: Andre Kramer; Tim Howes; dcml-frame@lists.oasis-open.org
> > Subject: RE: [dcml-frame] Meeting info
> > 
> > I'm not sure what is expected in response to the first item
> > in Tim's action list.  I thought my comments in an earlier
> > message, attached for reference, were pretty clear.
> > 
> > I disagree with Andre's manifesto.  While it may be interesting
> > and avant guard to develop a data center ontology, this is not
> > current practice in developing systems or data standards.  Such
> > an effort can take on a life of its own and still fail to 
> > provide the necessary foundation for consistent standards.
> > 
> > What is needed is a consistent data model.  Such a model will
> > be more flexible and consistent with current implementation 
> > technology if done with classes (i.e., OO model).
> > 
> > XML is not a data modeling language--it's a language for 
> > specification and expression of records or messages.  There
> > is no way you can develop and manage a consistent data center
> > data model in XML.
> > 
> > As a practical matter, develop of a comprehensive data model
> > will only delay development of standards since there is no
> > way to get it right or complete the first time.  It's fine
> > to start a data model with the more obvious things, but after
> > that let specific standards drive its refinement.
> > 
> > It seems to me that CIM and WSDM have proven an approach.
> > They both appear to have used UML to develop their shared data
> > models and XML to specify the data to be exchanged.  Use of
> > UML would then also make it easier for DCML to be consistent
> > with these existing standards.
> > 
> > Fred
> > 
> > Fred
> > 
> > 
> > > -----Original Message-----
> > > From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
> > > Sent: Monday, March 07, 2005 10:25 AM
> > > To: Tim Howes; dcml-frame@lists.oasis-open.org
> > > Subject: RE: [dcml-frame] Meeting info
> > > 
> > > 
> > > 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
> > > 
> > 
>