Jun, I have updated the Component Model to include your comments. Some of them I will clarify here:
"A component has two analogues...." does it mean: A language component <-(implements)- a deployment component <-(instance of)- a CDDLM component object
No, this is not correct. The CDL document can declare many elements that are not for the purpose of instantiating a component. You have defined constructs that allow placeholders and other elements to be used within the language. My desire is to clarify the relationship between what is defined in the CDL document and what is acted upon by the Deployment Framework. If an XML element is a child of the <cdl:system> node, it is a component. But, it is not a deployment component unless there is a physical or logical software/hardware resource attached to it.
(b) if they have "interface"-"impelmentation" relationship, there may be better name than "language"/"deployment" components.
This is not the proposed relationship. A language component is defined to exist only in the CDL language document. If the language component is declared to implement the appropriate properties in the CDL document, then it is a deployment component as well.
(c) I don't know why we need to say "CDDLM" component objects. can we just say a deployment component instance?
The idea was to ensure that we don't imply anything about the implementation of a valid CDDLM component. I felt that using the term instance would imply that it is an instance of an object in some OO kind of way. It doesn't matter how a component is realized as long as it implements the correct interfaces and operations defined in the model.
(d) I would like to see the UML diagram in Figure 3 earlier since it also explains the above relationship.
The UML is not meant to be a normative specification, thus it is just used to summarize the concepts. Not define them.
My understanding is that: From the CDDLM user's point of view, a component EPR is merely an identity assigned to a component, and the Deployment API does not define any operation sent to this endpoint from the user. Is this correct?
A Component EPR can't be just an identity. An EPR must be addressable. The Deployment API does define these operations. If the Deployment API receives a Terminate() operation from the client, it must then contact each component and coordinate sending Terminate() messages to each.
I don't clearly understand 3.4.1. (a) Does state extention mean definition of internal states? Does it allow any other extension? (b) How can I define extension using WSDM MUWS State capability? (c) For example, I want to have a system run multiple times after a single deployment (I want to go back and forth between initialized and running), how can I extend the lifecycle model?
State extension allows only extension within a defined state. 4.4.1.3 defines the state properties and how to use WSDM MUWS. The scenario you defined here in (c), however, is not supported. This would require more than just support from the lifecycle model. It would require the Deployment API to provide a means to do this, which is not currently defined. -----Original Message----- From: Jun Tatemura [mailto:tatemura@sv.nec-labs.com] Sent: Wednesday, May 04, 2005 12:58 PM To: Stuart Schaefer Cc: cddlm-wg@ggf.org Subject: Re: [cddlm] Component Model Update Stuart, Please find the attached file which is my feedback only on Section 3. I will give comments on the rest of the document later... Best Regards, Jun