Notes from CDDLM-WG Working Session 2 @ GGF11: Component Model

Date: June 8^th, 2004

Author: Peter Toft

 

Introduction (Dejan):

 

Presentation/discussion of the Component Model (Steve):

 

Short demo: using SmartFrog to deploy a CDDLM Soap endpoint, which can then itself accept and execute deployments.

 

Slide presentation:

 

• Definition of “component model”: the rules which must be followed to build CDDLM deployable components. We may consider renaming this to avoid this confusion.
• Proposed component model: every component has a SOAP endpoint, every component is a WSDM-compliant entity (and therefore WS-RF?). Comment: WSDM has not committed to providing all of WSRF.
• Implications
• Component integration
• Resource management
• Attributes
  • Using Get/Set attributes using WS-RF?
  • Do not like this (getter/setter) pattern generally because it prevents the dynamic addition/removal of attributes c.f. Ant. Makes things brittle
  • SmartFrog approach: component requests its attributes from the runtime (basic services)
  • Schemas are a better way than introspection
  • Contrast between properties that are part of the deployment configuration data and other properties that may be part of the function of the system (for which we could use WSDM, etc.)
  • The philosophical difference here is between push (getter/setter) and pull (“sfResolve”) methods for setting attributes
• Mediated attribute setting is more flexible
• Component state diagram – note that to terminate can only be reached via “running”
  • How to deal with the changing attributes; do we ignore this?
  • How do we know when a deployment is over; so we can start managing using
• How do we deal with the case where a state transition fails – what does the system do in this situation
• Is the state model sufficient for, e.g., a situation where a deployment has to happen over 10,000 nodes – do we need intermediate states, or can we deal with this by having specialised deployer behaviour
• SmartFrog simple liveness model; could we improve on this using WSDM?
• Do we need our healthcheck data to be other than binary?
• Faults are good – better than an extended error query?
• Maintenance task action; is this the right way of doing it
• Faults: use SOAP fault or WS-BaseFault? What information do we need to convey.
• Conclusions

 

Discussion:

 

Q. How far do we go in terms of the complexity we need to support?

A. Simple is good for the initial specifications

 

This needs to be reconciled with the evolution of Stuart’s document – will need to follow up with Stuart in a conference call.

 

Q. Do we need deployment time and runtime attributes – or are we getting into the space covered by management?

 

Q. Should we stick to just deploy/undeploy for the first version, fix the attribute set at deployment time?

 

Questions for the WSDM session tomorrow:

 

• State diagram
• WSDM interfaces versus
• Runtime versus deployment time attributes
• Components: how they request their deployment information
• Component monitoring requirements
• Configuration information relationship to XML schema representations
• Scheduling – how do we interact with these functions

 

Other comments:

• Do we expect component vendors to provide both SF and XML CDL representations? Recommendation that we go with one language – what is the motivation for having both? What is the interoperability story?