[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> 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> 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> 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> 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> 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 > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]