Embed Size (px)
Citation preview
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> <p cdl:ref="…" cdl:lazy="true"/></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> <b …/> <c …/></a><e> <b cdl:ref=“/a/b”/></e>
We may use:
<a> <b …/> <c …/></a><e> <b cdl:refroot=“a” cdl:ref=“/b”/></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> <b cdl:ref=“/a/c”/> <c>100</c></a><e cdl:extends=“a”> <c>200</c></e>
<e> <b cdl:ref=“/a/c”/> <c>200</c></e>
<e> <b cdl:ref=“/e/c”/> <c>200</c></e>
?
<a> <b cdl:refroot=“a” cdl:ref=“/c”/> <c>100</c></a>
<a> <b cdl:ref=“/c”/> <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>
<p cdl:ref=“…”/>
<app0> <p …/></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)
