May 2005 - cddlm-wg - lists.ogf.org

early draft of deployment API
by Steve Loughran 19 May '05

19 May '05

This is all in CVS, but for those without access, here is the latest copy 1. moved over to MUWS (consistently) 2. purged MOWS 3. highlighted everywhere in the docs the namespace needs to be fixed. I've just noticed that my processing-of-options section names two faults to be returned in specific cases, but does not define the faults. I have them defined in a (non normative) doc, constants.xml, and will knock up a quick XSL to make an HTML doc. but it cannot be normative, as we will think up new faults as we go along. Or to be precise, they will find us. ignore errors in the visio-derived images; visio is playing up on that vmware instance, and my laptop is on loan to someone else. I'll fix them from home, or even ssh down that vmimage and use it at work. -steve

1 0

RE: Latest version of the component model
by Stuart Schaefer 19 May '05

19 May '05

Bryan, Thank you for your assistance. I fixed most of what you have commented on. I am still not comfortable with the different namespace revisions between published specs that we are relying on, but I have fixed the document to reflect the actual XSD. Really only one question below on the WSDM StateCapability. Regards, Stuart > -----Original Message----- > From: Murray, Bryan P. > Sent: Friday, May 13, 2005 6:06 PM > To: Milojicic, Dejan S > Subject: RE: Latest version of the component model > > Dejan, > > I am including my notes from reviewing the spec. I did not > look at the wsdl/schema in detail, but did look briefly at it. > > Bryan > > > > Section 1.1: > I would use standards group namespaces rather than > proprietary namespaces whenever possible. I recommend the > following namespaces: > > wsa: Use either the W3C submission namespace or the Last Call > namespace > > wsrf-*: Use the namespaces from the TC web site: > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf > > WS-Notification specs should also use the namespaces from the TC web > site: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn > > Also, don't use the prefix "wsrf-nt" for WS-BaseNotification > - it is not accurate. Instead use "wsn-baseN" or something similar. > > section 2: > 2 related specs are mentioned, but there is no reference to > the specs (even in the references section). You need to > provide a link to the specs. > > section 2.1.3, 2nd to last sentence: This sentence makes it > sound like the "Component Model Specification" is some other > document rather than this document. Change "that" to "this". This was part of stock material created for all documents. Changed. > > section 3.4: The last para discusses linking lifecycles of > related components but does not say how this is done. More > speciifc rules should be stated for when a system component > can transition between states based on the states of some of > its dependent components transition. The actual discussion is in Section 5. I put in a reference. Section 3 is designed as a non-normative overview of the component model. Not a place for rules. > > Section 4.1: The example in 4.1 is not compliant with the > schema fragment in 4.1.3 because it is not possible to have a > string as a child node of the CommandPath element unless > mixed="true" is added to the commandPathType complexType. The > end element is 'simpleType' whereas the start element is > 'complexType'. This is fixed. > > In CDL documents, sometimes the cdl prefix is used and > sometimes it is not - better to be consistent. I changed all documents to be full CDL fragments with the cdl:system elements. > > section 4.4.1.3 (and others): The type 'lifecycleStateType' > is used, but this type is not declared in the XML schema. > Should this be muws-p2-xsd:StateType? Also, near the end of > the section there is a schema fragment for ApplyingPolicy. I > think this should be defined as > follows: > <xs:element name="ApplyingPolicy" > type="muws-p2-xsd:StateType"/> I think with this definition > it is still possible to have the instance definition listed, > but the xsi:type attribute is not necessary. The schema was updated, but not copied into the document. It has been fixed. The cmp:lifecycleStateType is an extension of the muws-p2-xs:StateType. Not sure about the xsi:type. > > section 4.4.2.2: If a set of operations go together it is not > necessary to use a separate interface for each operation. The actions don't all go together, as some are declared in WS-RF and some are component model specific. > > section 4.4.2.3: I would recommend that additional operations > be decalred directly in WSDL rather than having a "do it" > operation to provide additional capabilities. This allows a > client to discover what the service is capable of through > examining the WSDL rather than not having any means of > discovering what the service is capable of if all other > operations go through RunTask. The RunTask action is not meant to replace an implementers ability to define operations in WSDL. It is meant as a well-known endpoint for simple, internal tasks to be accomplished. > > section 4.5.4: DeploymentFault is not declared in the schema. As above, copied the schema. > > Section 4.6.1.1: ComponentLifecycleEvents sound a lot like > StateCapability Events defined by MUWS part 2. See section 3.2.6. They are exactly StateCapability Events. Just using the cmp:LifecycleTransition derivative of muws-p2-xs:StateTransition. Does that mean I have to declare it as a StateCapability event?? Won't a WSDM consumer recognize it, as its types correlate correctly? > > Section 4.6.1.2: WS-BaseNotification defines an implicit > topic for every mutable property. The notification define in > baseN contains the old and new values and is placed in a MUWS > ManagementEvent in the extension location. The current draft does. Not the version I have been using. Why would WS-BaseNotification require the use of WSDM MUWS? > > section 4.6.2.1: Dangling "The". It is not clear where the > On* elements go - is it in a CDL doc? It looks like most of > the On* events are shortcuts for subscription to the generic > state transition event with a filter for a specific state. Yes. > > section 8.1.6: ImplementsMessageSet is not defined in the > schema and no reference is provided to where it might be defined. Removed. Should have been purged earlier. > > > -----Original Message----- > From: Milojicic, Dejan S > Sent: Wednesday, May 11, 2005 6:04 AM > To: Murray, Bryan P. > Subject: FW: Latest version of the component model > > Hi Bryan, > > Sorry to bug you. I was curious if there is any chance to > review the documents or you plan to do so? > > Thanks, > > Dejan. > > -----Original Message----- > From: Milojicic, Dejan S > Sent: Tuesday, April 26, 2005 7:00 AM > To: Murray, Bryan P. > Subject: FW: Latest version of the component model > > Hi Bryan, > > Is there any chance that you can one last time review this spec? > > Thanks, > > Dejan. > > PS You mention that you will forward to me the interop spec > (materials), can you please do so? > -----Original Message----- > From: Stuart Schaefer [mailto:Sschaefer@softricity.com] > Sent: Friday, April 22, 2005 4:11 AM > To: Milojicic, Dejan S > Cc: Iyer, Subu; Rafaeli, Sandro; Talwar, Vanish > Subject: RE: Latest version of the component model > > Dejan and Team, > > Attached is the latest draft of the component model document. > I am also attaching the schema and WSDL files. The complete > set will be uploaded into our SourceForge project later today. > > Regards, > > Stuart > > -----Original Message----- > From: Milojicic, Dejan S [mailto:dejan.milojicic@hp.com] > Sent: Monday, April 11, 2005 2:21 PM > To: Stuart Schaefer > Cc: Iyer, Subu; Rafaeli, Sandro; Talwar, Vanish > Subject: Latest version of the component model > > Hi Stuart, > > My team members are after me. I told them that the newest > version of the component model will be out this Sunday and > now they are asking me where is it :-)? > > Is there any update on this front. I am also using this > opportunity to introduce to you Subu Iyer, Sandro Rafaeli and > Vanish Talwar, who work with me on the Scalable Management > project and who have interest in using the CDDLM work. > > Thanks, > > Dejan. > > >

1 0

RE: [cddlm] MUWS and MOWS
by Stuart Schaefer 18 May '05

18 May '05

Steve, I think you should check this with the WSDM guys, but this is from WSDM MUWS Part 1.0, Chapter 6. I read it to say that only the Identity capability is required. "Implementers of manageability endpoints are free to expose additional manageability capabilities beyond those defined in MUWS. An additional capability is represented by a set of manageability capability interfaces. The properties defined in a new capability must be defined as XML Schema Global Element Declarations. The operations defined in a new capability are represented as WSDL 1.1 operations. Furthermore, a manageability endpoint offering a new capability is free to ignore all standard manageability capabilities defined by MUWS except for the Identity capability. 811 The MUWS Identity capability is REQUIRED. " Chapter 5 seems to indicate that Identity, ManageabilityCharacteristics, and CorrelatableProperties are required, but again Chapter 6 seems to countermand that. For lifecycle representation, I would prefer you to use the cmp:lifecycle definitions. In regards to the MOWS stuff, you don't have to purge it. You could use it. I made it completely optional in the component model. You may choose to use it, since you are exposing web services such as the Portal EPR. Stuart -----Original Message----- From: Steve Loughran [mailto:steve_loughran@hpl.hp.com] Sent: Wednesday, May 18, 2005 12:47 PM To: 'cddlm-wg(a)ggf.org' Subject: [cddlm] MUWS and MOWS OK, I think I understand it better; the cmp XSD is helping me to get to grips with this. to be MUWS, we appear to need 0. properties as WSRF properties 1. an identity (URI) 2. some XML document declaring our capabilities (how this gets to the system is out of band) 3. an operational status attribute 4. optional: a state derived from the muws state stuff 5. events for changes in (3) and (4) that are derived from the muws events I am thinking that I must describe the state of the systems using the cmp: lifecycle, and have matching events, but declare that transition operations are queued requests -it isnt an error to send >1 state changing operation to a system EPR, when it is in a valid state for that request -it is an error to send a state changing operation to a system EPR when it isnt in a valid state for it -you can send terminate requests to terminated systems. -The OperationalState of a system is "operational" only when in the running state. I'll then purge all MOWS stuff (GetManageabilityReferences &c). is this right? -steve

1 0

MUWS and MOWS
by Steve Loughran 18 May '05

18 May '05

OK, I think I understand it better; the cmp XSD is helping me to get to grips with this. to be MUWS, we appear to need 0. properties as WSRF properties 1. an identity (URI) 2. some XML document declaring our capabilities (how this gets to the system is out of band) 3. an operational status attribute 4. optional: a state derived from the muws state stuff 5. events for changes in (3) and (4) that are derived from the muws events I am thinking that I must describe the state of the systems using the cmp: lifecycle, and have matching events, but declare that transition operations are queued requests -it isnt an error to send >1 state changing operation to a system EPR, when it is in a valid state for that request -it is an error to send a state changing operation to a system EPR when it isnt in a valid state for it -you can send terminate requests to terminated systems. -The OperationalState of a system is "operational" only when in the running state. I'll then purge all MOWS stuff (GetManageabilityReferences &c). is this right? -steve

1 0

namespaces
by Steve Loughran 18 May '05

18 May '05

as a followup to the phone call, if we are to submit this week's draft to the editor, we must have consistent namespaces by the end of the week. So: 1. what is the root URL we should use 2. what is the date extension we are all going to use 3. accordingly, what will be the three consistent XSD/WSDL namespaces for the various specifications. -Steve

1 0

Questions on the component model
by Stuart Schaefer 17 May '05

17 May '05

Sandro Rafaeli has had many good questions concerning the Component Model. I will forward them to the mailing list to help others clarify questions they may have. Stuart ----- Original Message ----- From: Stuart Schaefer <mailto:Sschaefer@softricity.com> To: Sandro Rafaeli <mailto:sandro.rafaeli@hp.com> Sent: Tuesday, May 17, 2005 9:34 AM Subject: RE: Latest version of the component model Sandro, These are good questions. If you don't mind I will be posting some of them to the CDDLM mailing list, since I think that they will help a lot of other people clarify similar issues. To answer your question, the component model does NOT require you to create a delegate to do what you want, nor do you have to create a set of separate undeploy components. In your example, you have defined the <cmp:sequence> to have the deployment scope of the initialization phase. You could add a separate tag such as <cmp:reverse> to make the termination proceed in reverse order. <cdl:system> <cmp:sequence lifecycle="initialization"> <cmp:reverse lifecycle="termination"> <mysql/> <confLanguage/> <tomcat/> <jpetstore/> </cmp:reverse> </cmp:sequence> </cdl:system> If you want to have more precise control over the order of the termination sequence, as you defined it below, instead you could use a deployment event to enforce the desired order. An event such as <cmp:OnTerminated> will allow you to define exact sequences or simplify notify other components of events. <cdl:system> <cmp:sequence lifecycle="initialization"> <mysql/> <confLanguage> <cmp:OnTerminated process="terminate" target="/mysql"/> </confLanguage> <tomcat/> <jpetstore> <cmp:OnTerminated process="terminate" target="/tomcat"/> </jpetstore> </cmp:sequence> </cdl:system> This CDL will indicate to CDDLM that the initialization should occur sequentially, but the termination has dependencies. confLanguage and jpetstore can be terminated in whatever order, but the system should wait for confLanguage to notify the mysql component when it has successfully terminated, and wait for jpetstore to notify tomcat. If either jpetstore or confLanguage fail to terminate, the CDDLM system should take action to resolve the failure. HOpefully this answers your question. Stuart -----Original Message----- From: Sandro Rafaeli [mailto:sandro.rafaeli@hp.com] Sent: Tue 5/17/2005 8:17 AM To: Stuart Schaefer Cc: Subject: Re: Latest version of the component model Hi Stuart, I'm discussing some details of CDDLM with a team in Brazil, and we come about a new problem. Please, consider the following example: <cdl:system> <cmp:sequence lifecycle="initialization"> <mysql/> <confLanguage/> <tomcat/> <jpetstore/> </cmp:sequence> </cdl:system> In this example, confLanguage configures the language used in some myslq database and jpetstore is a webapp of tomcat. The "sequence" tag deploys the four components in the declared order. That's plain. Now, when I send a Terminate and Destroy to system EPR, it will execute terminate and destroy in the exact same order as the deployment (since it has to obey "sequence"), but I really need to destroy confLanguage before mysql and jpetstore before tomcat. Should I actually create a DELEGATE component to be parent of my four components and the DELEGATE componet should be aware of the reverse order when a terminate/destroy is requested? Would it be acceptable to execute the CDL above (without the DELEGATE) to run my resources and then destroy the deployment components without destroying my applications (resources) so that my apps are still running after I have destroy my System EPR and then later on when I want to really destroy the apps I execute a new CDL where my deployment components are actually not deploying a resource but rather destroying (erasing it)? This is something I would do with smartfrog. I know the state of a deployment component should reflect the current state of my resource, but it seems to be easier to implement the latter. Thanks for your time, Sandro.

1 0

RE: [cddlm] Component Model Update
by Stuart Schaefer 17 May '05

17 May '05

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(a)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

1 0

RE: [cddlm] Automated build/test of sourceforge schemas.
by Milojicic, Dejan S 13 May '05

13 May '05

Great job, Thanks Steve, Dejan. > -----Original Message----- > From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] > On Behalf Of Steve Loughran > Sent: Friday, May 13, 2005 12:50 PM > To: CDDLM working group > Subject: [cddlm] Automated build/test of sourceforge schemas. > > > We now have a nightly build of the default target of the > build file: XML validation, XSLT generation of java constants > & compilation into a JAR:- > > http://brutus.apache.org/gump/jdk15/ggf-cddlm/cddlm/index.html > > From tonight it will also validate all the valid/ files > against the version of the CDL schema that is on the > sourceforge site. This will make sure that things are > internally consistent. > > The gump server sends complaint mail out whenever the build > does, which is every time the Java1.4 run takes place. I'm > the only person getting that mail, but I can add others if > they care. Alternatively, subscribe to the RSS feed. > > -steve > >

1 0

Automated build/test of sourceforge schemas.
by Steve Loughran 13 May '05

13 May '05

We now have a nightly build of the default target of the build file: XML validation, XSLT generation of java constants & compilation into a JAR:- http://brutus.apache.org/gump/jdk15/ggf-cddlm/cddlm/index.html From tonight it will also validate all the valid/ files against the version of the CDL schema that is on the sourceforge site. This will make sure that things are internally consistent. The gump server sends complaint mail out whenever the build does, which is every time the Java1.4 run takes place. I'm the only person getting that mail, but I can add others if they care. Alternatively, subscribe to the RSS feed. -steve

1 0

RE: [cddlm] proposed change to deploy API state info
by Stuart Schaefer 13 May '05

13 May '05

Steve, The stateInfo string comes from an early revision of the Component Model. The CM now uses WSDM. You should follow the example in the CM to reflect the use of WSDM. Stuart -----Original Message----- From: Steve Loughran [mailto:steve_loughran@hpl.hp.com] Sent: Friday, May 13, 2005 1:32 PM To: CDDLM Subject: [cddlm] proposed change to deploy API state info looking at the deployment API, it has three components: state enum, stateInfo (a string) and extended state <xsd:element name="state" type="cmp:lifecycleStateType"/> <xsd:element name="stateInfo" type="xsd:string"/> <xsd:element name="extendedState" type="cmp:unboundedXMLAnyNamespace" minOccurs="0"/> We dont really need that stateInfo string do we? the cmp: state identifies every state; if you want to map that enum to a string in the language/locale of preference, you are free to do so. And the extended state can be anything you like. I propose, therefore, dropping that element, leaving a sequence of <xsd:element name="state" type="cmp:lifecycleStateType"/> <xsd:element name="extendedState" type="cmp:unboundedXMLAnyNamespace" minOccurs="0"/> Comments?

2 1