CDDLM Configuration Description Language (CDL)

CDDLM Configuration Description Language (CDL)

Jun TatemuraNEC Laboratories America

GGF13, March 15 2005

CDL Core concept overview CDL FAQ from draft reviews

Essential questions regarding CDL design philosophy

User (who deploys)

Use of CDL in Deployment Example: Three-tier web applications

Component provider

Appserver

Appserver

Appserver

DBserver

DBserver

DBserver

Webserver

Webserver

WebserverComponent

object

Componentobject

ComponentobjectResource

Broker

CDLTemplate

ApplicationWrapper

Provider (developer)provides

provides

(schema, default values,…)

CDLTemplateCDL

TemplateCDL TemplateFor 3tier app

refers to

(application structure,…)

CDLFor a specificdeployment

request

refers to

discovered resourcesagreed values

discovery and agreement

Deployment APIsubmit

CDDLM XML-based CDL Configuration: Property Lists

<webserver> <hostname>example.com</hostname> <port>80</port></webserver>

CDL Notations @cdl:extends – inheritance of prototype @cdl:ref – value reference @cdl:type – data type annotation @cdl:lazy – lazy (runtime) value resolution

Prototype References

@cdl:extends=xsd:QName

<cdl:cdl targetNamespace="urn:tmp-uri1"><cdl:configuration><WebServer> <hostname /> <port>80</port></WebServer><Tomcat cdl:extends="WebServer"> <port>8080</port> <maxThreads>200</maxThreads></Tomcat></cdl:configuration></cdl:cdl>

<cdl:configuration xmlns:tmpl="urn:tmp-uri1">

<Tomcat cdl:extends="tmpl:Tomcat"> <hostname>myweb.com</hostname></Tomcat></cdl:configuration>

<Tomcat> <hostname>myweb.com</hostname> <port>8080</port> <maxThreads>200</maxThreads></Tomcat>

Value References @cdl:ref=cdl:pathType

<Web cdl:extends="WebServer"> <application cdl:ref="/application"/> <applicationPath cdl:ref="/applicationPath"/> <dbconnection cdl:extends="DBConnection"> <JNDIName cdl:ref="/dbname"/> <hostname cdl:ref="/DB/hostname"/> <port cdl:ref="/DB/port"/> <username cdl:ref="/DB/username"/> <password cdl:ref="/DB/password"/> </dbconnection> </Web></WebApp>

<WebApp> <application/> <applicationPath/> <dbname/> <data/> <dbuser/> <dbpassword/> <DB cdl:extends="DBServer"> <data cdl:ref="/data"/> <username cdl:ref="/dbuser"/> <password cdl:ref="/dbpassword"/> </DB>

Schema Annotations

@cdl:type @cdl:use

<WebServer> <hostname cdl:type="xsd:string" cdl:use="optional"/> <port cdl:type="xsd:positiveInteger" cdl:use="required">80</port></WebServer>

Laziness Annotation

@cdl:lazy=“xsd:boolean”

<server> <port cdl:lazy="true"/></server>

<app> </app>

Lazy Property(provide side annotation)

Lazy Reference(consumer side annotation)

CDL Document cdl import types configuratio

n system

<cdl:cdl targetNameSpace=xsd:AnyURI?> <cdl:documentation …/>? <cdl:import …/>* <cdl:types>? <cdl:documentation …/>? <-- schema definition -->* <-- extensibility element -->* </cdl:types> <cdl:configuration>? <cdl:documentation …/>? <-- PropertyList -->* </cdl:configuration> <cdl:system>? <cdl:documentation …/>? <-- PropertyList -->* </cdl:system> <-- extensibility element -->*</cdl:cdl>

CDL FAQ

Inheritance (prototype references) Value references Data Types

Inheritance [Q1]

Why Inheritance? Isn’t inheritance just a feature of

front-end systems? CDDLM could receive a CDL document after inheritance resolved.

Inheritance [A1] [A] Inheritance is used between component

providers and component users. Standardization is thus required.

Component description from a provider describes properties that are supported as a

prototype Names, types, default values, optionality, laziness

A component provider Inherits the prototype to give

property values, composite structures of components Note: CDL provides declarative description

through prototype-based inheritance + immutable property lists

Inheritance [Q2]

Why not inherit a deep tree? Prototype resolution only inherits

immediate children. We may want to overload data within a deep structure.

a

c

f

a

b

e

c d

f

1001030

1 20

extends a

b

e

c d

f

10030

1 20

Inheritance [A2] (1)

It will be difficult to override a property with structured data

a

c

g

a

b

e

c d

f

1001030

1 20

extends

h

200

a

b c d

1 20g

100

h

200

a

b

e

c d

f

1030

1 20

g

100

h

200?

Inheritance [A2] (2)

Parameterization<ServerSet> <ashost/> <dbhost/> <AppServer> … <host cdl:ref=“/ashost”/> … </AppServer> <DbServer> … <host cdl:ref=“/dbhost”/> … </DbServer></ServerSet>

<MyServer cdl:extends=“ServerSet”> <ashost>localhost</ashost> <dbhost>localhost</dbhost></MyServer>

list2list1

Inheritance [Q3]

Why inheritance is defined on an ordered list What makes a difference between

property set inheritance and property list inheritance

a

b

c

d

c

e

a

f

a

b

c

d

e

f

extends

Inheritance [A3]

[A] The CDDLM Component Model needs an ordered tree

[A] XML is an ordered tree. A user of CDL may want to have ordered property lists (the Component Model is an example) cdl:extends corresponds to

xsd:extension of xsd:sequence

Value references [Q1]

Why do we need cdl:refroot

<a> <c …/></a><e> </e>

We may use:

<a> <c …/></a><e> </e>

We now use:

Value references [A1] [A] it will be also complicated when it is combined with

prototype resolution Most references will be within a tree (i.e., no need of

cdl:refroot)

<a> <c>100</c></a><e cdl:extends=“a”> <c>200</c></e>

<e> <c>200</c></e>

<e> <c>200</c></e>

?

<a> <c>100</c></a>

<a> <c>100</c></a>

Value references [Q2]

Why lazy references Isn’t a lazy property (provider-side

annotation) enough? Why do we need a consumer-side laziness annotation?

<server> <port cdl:lazy=“true”/></server>

<app> <p1 cdl:ref=“…” cdl:lazy=“true”/></app>



<app0> </app0>

Lazy property

Lazy reference

Value Reference [A2] [A] an example: a reference to a

system environment property (e.g., current time). The consumer side wants to control resolution timing

<deploymentTime cdl:refroot=“sys:sytemProperties”cdl:ref=“/time” cdl:lazy=“true”/>

Note: CDL itself does not define “system properties”

Data Types [Q1]

Is CDL yet another schema language? Are you trying to replace XML

Schema?

Data Types [A1] CDL is designed to leverage (not replace)

XML Schema

How to achieve schema validation in CDL CDL: Prototype-based inheritance to generate

configuration data in a flexible and dynamic manner

Challenge: how to make use of XML Schema to validate dynamically extensible data

Note: Schema validation is optional in CDL

Solution: @cdl:type Attribute for Type Annotation @cdl:type=“qname” Type specification for property values Source data can be validated with @cdl:type Resolved data can be validated with @cdl:type (type

check) and @cdl:use (optionality check)

<cdl:configuration> <WebServer> <hostname cdl:type=“xsd:string”/> <port cdl:type=“xsd:int”/> </WebServder></cdl:configuration>

Generating XML Schema for Validation A CDL processor may optionally

generate XSDs for unresolved and/or resolved configuration data

CDLCDL

XSD

CDL processor

CDLXSD

validates

refers-to

refers-to

Resolution result

XSD for unresolved data (source data)XSD

validates

XSD for resolved data (result data)

Example of Validation After reference resolution

<a> <a1 cdl:type=“t1” cdl:use=“required”>v1</a1> <a2 cdl:type=“t2” cdl:use=“optional” /> <a3 cdl:type=“t3” cdl:use=“optional” >v3</a3></a>

A CDL processor may generate Configuration data

<a><a1>v1</a1><a2/><a3>v3</a3></a> XSD for the configuration data

<xsd:complexType name=“aType”><sequence><element name=“a1” type=“t1”…> …</sequence></xsd:complexType>

Data types [Q2]

How to use cdl:types and cdl:import Should data types be defined

internally (using cdl:types) or externally (importing with cdl:import)?<cdl:cdl …>

<cdl:import …/> <cdl:types> …. </cdl:types> …</cdl:cdl>

Data Types [A2] [A] cdl:type is used when data types are

defined within the namespace of the configuration data

<cdl:cdl targetNamespace=uri1> <cdl:import …/> <cdl:type> … </cdl:type> <cdl:configuration> <a …/> … </cdl:configuration></cdl:cdl>

Referred to with the same namespace (uri1)

Documents

CDDLM Configuration Description Language (CDL)