[cddlm] Component Model Update

[Stuart Schaefer]

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 at sv.nec-labs.com] 
Sent: Wednesday, May 04, 2005 12:58 PM
To: Stuart Schaefer
Cc: cddlm-wg at 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