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

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

3. 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>

4. 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

5. Issue 1: Attribute Set Description Model

6. 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

7. 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

8. 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>

9. [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>

10. [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> </value>
</attribute>

11. [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>

12. [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>

13. [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

14. [Alt-2] CDL Functionalities
Functionalities same as Alt-1 are achieved with
<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

15. [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

16. [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>

17. 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

18. Issue 2: Component (Wrapper) Model

19. 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>

20. 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>

21. 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

22. Issue 3: Lifecycle Management Model

23. 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

24. 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.

25. 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)

26. Issue 4: Dependencies and Assertions

27. 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>

28. 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>

29. 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.
Later we may add Xpath 2.0 as an alternative URI
Where to place
Within an attribute set
Outside of attribute sets

30. 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

31. 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