RE: [dcml-frame] Meeting info

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

Andre,

Comments to your comments embedded below.  This is getting
a bit long, but I don't know another way to be clear.

Fred

> -----Original Message-----
> From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
> Sent: Wednesday, March 09, 2005 5:16 AM
> To: Cummins, Fred A; Tim Howes; dcml-frame@lists.oasis-open.org
> Subject: RE: [dcml-frame] Meeting info
> 
> 
> Fred,
> 
> See <ak/> comments inline. I've renamed my (1), (2), (3) uses for
> modeling languages as (ak1) etc to avoid clashing with your 
> enumeration.
> I suspect these thoughts will be a complex topic for the next 
> conf call.
> 
> 
> Regards,
> Andre
> 
> -----Original Message-----
> From: Cummins, Fred A [mailto:fred.cummins@eds.com] 
> Sent: 09 March 2005 05:28
> To: Andre Kramer; Tim Howes; dcml-frame@lists.oasis-open.org
> Subject: RE: [dcml-frame] Meeting info
> 
> 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.
> 
> <ak> That's largely my (ak1). Agree UML is useful here, but 
> RDF/OWL does
> have it's own modeling advantages. It may be best to leverage all the
> tools we have at hand. However, I see (ak2) as the main question for
> DCML Framework, being concerned with interchange between DCML 
> tools and
> not humans and their UML modeling tools.
> </ak>

[fac]My goal is to keep it simple and practical.  I don't know anybody
that uses RDF/OWL to design systems.
> 
> 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.  
> 
> <ak> This is my (ak2) and I agree the containers exchanged 
> should be XML
> documents (conforming to DCML schema) but I do not see why we should
> limit to just XML schema for the included models. One issue is that we
> have no mapping from UML to XML schema (XMI is too complex IMHO).
> OWL/RDF does, but my suggestion is that DCML documents can contain
> different flavors of (ak2). I also think a simple (RDF/OWL like) class
> based model as I proposed will help with such mappings.
> </ak>

[fac] I don't see a way to generate the DCML schama from either a UML
model or an RDF/OWL model.  A DCML document is a view (in database
terms) of the more comprehensive model, and the specific structure
will involve choices in the conversion from a network structure to
a hierarchical structure (i.e., XML).  XMI is not relevant hers.
> 
> 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).
> 
> <ak> We agree that (ak3) is outside the scope of the DCML spec. </ak>
> 
> 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.
> 
> <ak> I see database exchange as valid part of (ak2), as the 
> requirement
> is for import/export of both models and databases! The data 
> center model
> is a database, as it aims to provide a complete description of the
> deployed computing environment. I do think events are 
> relevant, as they
> impact such databases, but we should take care not to 
> duplicate WSDM or
> other management frameworks. I think events as data center model (i.e.
> database) updates may be a better metaphor. </ak>

[fac] I don't see any reason to define a database export/load format.
there are other ways to do that and I don't see it as an issue for 
DCML.  The event inputs and queries are what are important.
> 
> 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.
> 
> <ak> I would view this as a large part of the shared understanding of
> (ak1). I would also note that such architectural models are often
> expressed (diagrammed) informally. UML can be usefully employed but it
> is not really an architectural description language.
> </ak>

[fac] While an overall architecture may not be part of the DCML spec,
DCML should be defined in terms of the inputs and outputs of components
of the architecture, and the definitions of the components should at
least be supporting information included in the specifications.
> 
> 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.
> 
> <ak> That is what I scoped would imply a lot of work to achieve, if we
> wanted to do this as part of (ak1). RDF/OWL ontologies provide a much
> simpler, incremental approach but, as I said, we should leverage all
> tools at hand. </ak>

[fac] I doubt that RDF/OWL would accomplish the purpose of such models.
I would expect these models to provide specific viewpoints and support
certain kinds of operations used to understand and make decisions
about data center operations, for example, network or server
configuration.
> 
> 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
> > > > 
> > > 
> > 
>