Jun Tatemura NEC Laboratories Amercia GGF10, March 2004 CDDLM XML-CDL Jun Tatemura NEC Laboratories Amercia GGF10, March 2004

Issues Overview [1] Attribute set description model [2] Component description model [3] Lifecycle management model [4] Dependencies and assertions [1-4] Relationship with SmartFrog

CDL Top-Level Structure Divided into sections (similar to WSDL) Cf. SmartFrog has a uniform language structure and utilizes predefined names and frameworks (e.g., sfConfig, Prim) Configuration on a system can be described in multiple CDL files <import> and <include> <cdl targetNamespace=“xsd:anyURI”> <types …/>? <!-- schema definition --> <configuration …/>? <!-- configuration data --> <system …/>? <!-- system structure --> <services …/>? <!-- service endpoints --> </cdl>

Import and Include Similar to XML Schema <import namespace=“xsd:anyURI” location=“xsd:anyURI” /> Import of external namespaces <include location=“xsd:anyURI” /> Inclusion of XML Data Similar to SmartFrog’s #include but may be more restrictive due to validity as XML data

Issue 1: Attribute Set Description Model

Attribute Sets Configuration is a set of attribute-value pairs Inheritance: the “extends” operation (from SmartFrog) for extensibility of configuration Every attribute set can be referred to with a QName extends reuse override addition

Using QName for Attribute Set Name Namespace realizes a globally unique reference to specify an attribute set <cdl targetNamespace=“uri1”> <attributeSet name=“abc” .../> </cdl> <cdl xmlns:tmpl=“uri1”> <attributeSet name=“myabc” extends=“tmpl:abc” .../> </cdl> A template CDL provided by the application provider CDL specified by the application user

Two Design Alternatives of Attribute Description [Alt-1] CDL specific attribute elements (current draft) <cdl:attributeSet cdl:name=“apache” cdl:extends=“ex:httpd”> <cdl:attribute> <cdl:name>hostname </cdl:name> <cdl:value> example.com </cdl:value> </cdl:attribute> </cdl:attributeSet> [Alt-2] Configuration specific schema <tns:apache cdl:name=“apache” cdl:extends=“ex:httpd”> <tns:hostname cdl:use=“…” …> example.com </tns:hostname> </tns:apache>

[Alt-1] Attribute Sets <attributeSet> element <attributeSet @name defines QName of this set @extends specifies a prototype set <attributeSet name=“xsd:NCName” extends=“xsd:QName”?> <attribute …/>* </attributeSet>

[Alt-1] Attributes A pair of name and value Augmented by <type>, <lifetime>, <use>, etc. type: type definition (XML Schema) lifetime: deployment | runtime | dynamic use: required | optional | readonly -- discussed later as another issue <attribute> <name>xsd:string</name> <type/>? <lifetime/>? <use/>? <value/>? </attribute> <attribute> <name>host</name> <type>xns:ipAddress</type> <lifetime>deployment</lifetime> <use>required</use> <value>15.144.56.243</value> </attribute>

[Alt-1] Nested Attribute Sets An attribute can have an attribute set as its value Nesting of attribute sets is flattened and linked with references (QNames) <attribute> <name>database-server</name> <type>cdl:refToAttributeSet</type> <lifetime>deployment</lifetime> <use>required</use> <value>tns:database</value> </attribute> <attributeSet name=“database” extends=“oracle” > <attribute .../> ... </attributeSet>

[Alt-1] Reference to Attribute An attribute is identified with the QName of an attribute set + the name (string) of an attribute This is one reason why attribute sets are flattened <reference> <attributeSet>xsd:QName</attributeSet>? <attributeName>xsd:string</attributeName> </reference> (alternative expression) <reference set=“xsd:QName”?>xsd:string</reference>

[Alt-2] Fully-bound Configuration Documents After references are resolved and values are fixed, a document becomes a simple and natural XML data based on application-specific schema Similar to WS-ResourceProperties <apache cdl:name=“xsd:NCName”> <MaxClients>150</MaxClients> <HostName>example.com</HostName> … </apache> resolution <apache cdl:name=“xsd:NCName” 　　　　　　cdl:extends=“xsd:QName”> <HostName /> … </apache> Schema for a particular configuration document

[Alt-2] CDL Functionalities Functionalities same as Alt-1 are achieved with attributes (@name, @extends,…) <apache cdl:name=“apachetmpl” 　　　　　　cdl:extends=“x:httpd”> <MaxClients>150</MaxClients> <HostName cdl:lifetime=“deployment” cdl:use=“optional” /> … </apache> CDL specified by the application user extends <apache cdl:name=“myapacheconfig” 　　　　　　cdl:extends=“tmpl:apachetmpl”> <HostName>myuri.com</HostName> … </apache> A template CDL provided by the application provider

[Alt-2] Drawback: Schema Definition Is Mandatory Schema is required to assure a valid CDL document is also a valid XML document Schema for vendor specific httpd Schema for generic httpd New elements added Redefinition of schema <httpd cdl:name=“template” …/> <apache cdl:name=“template” …/> <apache cdl:name=“myapache” …/> CDL for generic httpd template CDL for vendor specific httpd template CDL for user deployment

[Alt-2] Nested Attribute Sets Nested structure can be applied Better readability More powerful inheritance and reference models <webapp cdl:name=“mywebapp” 　　　　　　cdl:extends=“tmpl:webapp”> <webtier> <MaxClients>100</MaxClients> </webtier> <apptier> <MaxThreads>100</MaxThreads> </apptier> <dbtier> <MaxConnection>150</MaxConnection> </dbtier> … </webapp> Inheritance (recursive) extends includes Reference (QName+Xpath) <reference root=“xsd:QName”> xpath </reference>

Pros and Cons [Alt-1] CDL specific attribute elements Pros: Cons: Schema is optional Semantically similar to SmartFrog Cons: Bad readability Configuration data must be given in a different style from other WS-RF based resources [Alt-2] Configuration specific schema Pros: Readability Syntactically similar to SmartFrog Better match with WS-RF Xpath reference model Dependencies and assertions can use XPath Cons: Schema is required

Issue 2: Component (Wrapper) Model

Component Model A system is a tree which leafs are components A component refers to an attribute set A component is deployed through a Component Service (CDDLM wrapper) Component Service endpoint WS-Resource <system> <component> Component Service endpoint WS-Resource <configuration> Component Service endpoint WS-Resource <attributeSet> <attributeSet>

Binding to Component Service Endpoints A <services> element binds components to component service endpoints Similar definition structure to WSDL Typically given before resource assignment agreement Component Service endpoint <system> <system> WS-Resource <component> <component> Typically given after resource assignment agreement <component> <services> <service component=“xsd:QName”>wsa:EndpointReference</service> … </services>

Component Model Discussion Component Service endpoint may be either WS-RF-based or OGSI-based Nice to have a transparent description in CDL WS-Addressing’s EndPointReference may be used Do we standardize: How to identify content of application (e.g., URL, path within an archive file) How to transfer content of application -- May be component service specific

Issue 3: Lifecycle Management Model

Lifecycle Management in CDDLM CDDLM Processor must manage deployment lifecycle of multiple components deploy start stop undeploy get/set getStatus deploy start stop undeploy get/set getStatus Component Service endpoint CDDLM-Service endpoint CDDLM Processor Consistency among components should be maintained Component Service endpoint CDDLM Client (e.g., Job Manager) Component Service endpoint

Constraints on Attributes For better management of consistency Lifetime: deployment|runtime|dynamic When value should be fixed Use: required|optional|readonly Whether value should be given Read-only value is assigned only by Component services (only get operation is valid on this attribute) (e.g., a port number may be dynamically assigned) Lifetime must be specified when use is specified Type: QName of schema [Alt-1] SmartFrog has only deployment and dynamic (LAZY) lifetime. CDDLM does not know when a lazy value is resolved.

Lifecycle Dependency in a System Restriction on the order of lifecycle management operations <deployAfter> <startAfter> If lifecycle dependency is only from data dependency, we may not need these notations (order can be inferred from data dependency)

Issue 4: Dependencies and Assertions

Dependencies An attribute value is derived from other attribute values <assign> <to><reference …/></to> <from>{<reference …/>|<expression …/>|<value …/>}</from> </assign> and/or <attribute> <name>xsd:string</name> {<reference …/>|<expression …/>|<value …/>}? </attribute>

Assertions An assertion specifies a condition which must be satisfied by given attribute values An assertion has QName so that it can be overridden <assert name=“xsd:NCName” language=“xsd:anyURI”?> xsd:any </assert>

Issues on Dependencies and Assertions Expression languages? Specified with URI There should be one normative expression We may let Xpath 1.0 be the default normative expression. http://www.w3.org/TR/1999/REC-xpath-19991116 Later we may add Xpath 2.0 as an alternative URI Where to place Within an attribute set Outside of attribute sets

Example of XPath-based Expression Any attribute value can be assigned to xpath VariableReference ($QName) by using <reference> and <let> <cdl:expression> <xp:root><cdl:reference …/></xp:root>? <xp:let name=“NCName”> <cdl:reference …/> </xp:let>* <xp:return>xpath</xp:return> </cdl:expression> the context node variable bindings xpath pattern

Relationship with Attribute Description Alternatives If we take [Alt-2] for attribute description, Xpath-based dependencies and assertion would be more powerful and intuitive <apache cdl:name=“apachetmpl”> <MaxClients>150</MaxClients> <HostName/> … <cdl:assert> boolean(MaxClients > 0) </cdl:assert> </apache> The parent of <assert> (i.e., <apache>) is regarded as the context node of XPath