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

Next meeting
by Milojicic, Dejan S 30 Mar '05

30 Mar '05

Hi Team, I can not make the meeting on Wednesday. We have the option of holding it on Tuesday morning at 6am PST (etc. for other time zones) or to postpone it for next week. Does this work for everyone else? You can also hold it without me. Can you please confirm your preference by email asap? I will post the notes shortly, I am doing some last cleansing. Thanks, Dejan.

2 1

GGF13 ACS-WG sessions announcement.
by Keisuke Fukui 13 Mar '05

13 Mar '05

Folks, This is a reminder that we will have the ACS-WG#1 at Emerald 3 at 13:00. We welcome your participation. To see more detail, please enter acs in the search menu on the "GGF13 Schedule" on the GGF top page. http://www.gridforum.org/webevents/publish/webevent.cgi?cmd=listweek&ncmd=s… Thank you! -Keisuke

1 0

RE: [cddlm] XSD consistency
by Stuart Schaefer 09 Mar '05

09 Mar '05

Steve, Not sure what you mean by making major changes to the component model. It appears that you mean the deployment API. All of the component model events derive from MUWS. Second, I would like components to use a simple fault model, so I did not include all of the elements of faults that you have done. Also, reflecting Bryan's comments, I made the model a little simpler. Do you really want the deployment API to transmit its own faults as derivatives of the component model? Relaying, sure. But that does not require anything other than WS-Notification support for forwarding of the cmp types. Stuart -----Original Message----- From: Steve Loughran [mailto:steve_loughran@hpl.hp.com] Sent: Wednesday, March 09, 2005 9:03 AM To: 'cddlm-wg(a)ggf.org' Subject: [cddlm] XSD consistency Stuart, Jun I am reworking my XSD/WSDL to use your stuff; will check in it in shortly. Some major changes I'd like to suggest to component model 1. every event type extends the muws ManagementEventType . You've done this for lifecycle, but I'm doing it for all deployment events 2. We need to move the deployment fault declarations into the component model, so that your component model can extend them them. The deployment API can then relay cmp: For the xml-cdl schema, is NCName the right choice for component names? There are a lot of unicode chars in that list I propose a name type that can be used in cmp: and api: which is restricted to what we really, really want in the names of things. The system name type I (had) in the deployAPI coudl be the foundation, it said a-zA-Z_\-\. as the first char, the same plus digits everywhere else. I dont know if that is ideal (indeed, I'd drop the "-" from a name, but having a simple, restrictive name type is important. We dont want to repeat the mistake of ant where "," , " " and "" are in fact valid names in some places. <xsd:simpleType name="systemNameType"> <xsd:annotation> <xsd:documentation> This is the policy for the naming of systems </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:NCName"> <xsd:pattern value="[a-zA-Z_\-\.][a-zA-Z_\-\.\P{Nd}]*"/> </xsd:restriction> </xsd:simpleType>

2 1

XSD consistency
by Steve Loughran 09 Mar '05

09 Mar '05

Stuart, Jun I am reworking my XSD/WSDL to use your stuff; will check in it in shortly. Some major changes I'd like to suggest to component model 1. every event type extends the muws ManagementEventType . You've done this for lifecycle, but I'm doing it for all deployment events 2. We need to move the deployment fault declarations into the component model, so that your component model can extend them them. The deployment API can then relay cmp: For the xml-cdl schema, is NCName the right choice for component names? There are a lot of unicode chars in that list I propose a name type that can be used in cmp: and api: which is restricted to what we really, really want in the names of things. The system name type I (had) in the deployAPI coudl be the foundation, it said a-zA-Z_\-\. as the first char, the same plus digits everywhere else. I dont know if that is ideal (indeed, I'd drop the "-" from a name, but having a simple, restrictive name type is important. We dont want to repeat the mistake of ant where "," , " " and "" are in fact valid names in some places. <xsd:simpleType name="systemNameType"> <xsd:annotation> <xsd:documentation> This is the policy for the naming of systems </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:NCName"> <xsd:pattern value="[a-zA-Z_\-\.][a-zA-Z_\-\.\P{Nd}]*"/> </xsd:restriction> </xsd:simpleType>

1 0

Component Model Specification update
by Stuart Schaefer 07 Mar '05

07 Mar '05

Enclosed in this email is a significant update to the Component Model specification document. Also enclosed are the WSDL, Schema and XML Topic Space documents. I have attempted to respond to most of Bryan Murray's comments. My response is also attached. I would like to ask that people review this document at your earliest convenience. There are many aspects of the documents that I will need to synchronize with Steve and the Deployment API. Our decision to adopt the new WSDM specifications creates many complications. Stuart

1 0

CDL ver 1 draft with cross-references
by Jun Tatemura 05 Mar '05

05 Mar '05

The attached file is the CDL ver 1.0 draft with cross-referencing paragraphs based on the discussion in the previous meeting. Best Regards, Jun Tatemura

1 0

Paragaph on Component Model
by Stuart Schaefer 04 Mar '05

04 Mar '05

The CDDLM Component Model outlines the requirements for creating a deployment object responsible for the lifecycle of a deployed resource. Each deployment object is defined using the CDL language and mapped to its implementation The deployment object provides a WS-ResourceFramework compliant "Component Endpoint" for lifecycle operations on the managed resource. The model also defines the rules for managing the interaction of objects with the CDDLM Deployment API in order to provide an aggregate, controllable lifecycle and the operations which enable this process.

2 1

Schema Policy
by Steve Loughran 03 Mar '05

03 Mar '05

As we discussed on the project phone conference yesterday, we are having fun with schema versions. To summarise 1. component model and API use the IBM-namespaced WSRF specs (the original set), and WS-Addressing of 2003 2. if you pull down the "latest" versions of WSRF & WSN you find out they are inconsisent with each other 3. WSDM has been approved by OASIS, based on draft 0.1 of WSRF and WSN. 3. WSN draft 0.1 uses WSA 2003 for addressing 4. WSDM uses WSA 2004 for addressing, except when using WSN notifications, at which point WSA 2003 has to be used. Apart from different namespaces, the two versions are apparently identical. 5. WSA addressing is still evolving at the W3C. A version may be standardised this year, a version which is likely to be somewhat incompatible with either WSA2003 and 2004. 6. Any attempt to use the latest stuff in the CDDLM component model and deploy API is a painful and futile way to waste days of your life. Stuart, Dejan and myself had a phone discussion with some of the WSDM team yesterday, then Stuart and I discussed what our policy should be. Here it is 1. We will use draft-0.1 of the OASIS versions of WS-RF, WS-N for our WSRF schemas. 2. We will use wsa: to refer to WSA 2003/04 everywhere . Our addresses will be compatible with the draft of WS-N 3. We will declare the wsa2004: alias to the WSA 2004/08 namespace. This will only be used in returning MOWS identity references. 4. We indent to update this stuff when the underlying specifications are standardises. Specifically, once WSA becomes a W3C release, and the WSRF, WSN, WSDM specs are updated to reflect that change, then we will move too. We are not going to chase latest versions of other peoples specs when some of the core underpinnings are still unstable, as it vastly complicates the interoperability story. There will be no attempt to revisit the versions until that point, so people can work with the CDDLM specification knowing that we are not going to update it every month. Note that Apache Hermes/Muse is compatible with our versioning policy. That is, they currently use the same versions we do. I will keep an eye on them to keep them in line. Life would have been easier if WSDM had used the same version of the addressing specification as the rest. Although both Stuart's and my companies voted for WSDM as it stands, we do understand the viewpoint of the few organisations that voted against it on the grounds of unstable foundations. But It has happened; all we can do is manage the implications for us and for people who work with the CDDLM framework. -Steve

1 1

Paragraph on CDL
by Jun Tatemura 03 Mar '05

03 Mar '05

The CDDLM Configuration Desrciption Language (CDL) is an XML-based language for declarative description of system configuration that consists of components (deployment objects) defined in the CDDLM Component Model. The Deployment API uses a deployment descriptor in CDL in order to manage deployment lifecycle of systems. The language provides ways to describe properties (names, values, and types) of components including value references so that data can be assigned dynamically with preserving specified data dependencies. A system is described as a hierachical structure of components. The language also provides prototype-based template functionality (i.e., prototype references) so that the user can describe a system by refering to component descriptions given by component providers.

1 0

New deploy API release
by Steve Loughran 02 Mar '05

02 Mar '05

This is a zipfile including the deploy API, WSDL, versions of WSRF that are mostly compatible, stuarts CDL, etc,etc. Its effectively a snapshot of CVS. When stuart and jun add their docs in (stuart is working on his XSD/WSDL there), we will have a one-stop redistributable of the specs+XML doc: changes are all in red. Key changes -clarify addFile semantics -lookupApplication out. resolve() also supported by portalEPR, doing a combined lookup of app by name *and* resove below it. Good for consistency, good for reduced round trip operations (sometimes). -steve

1 0