1 / 34

CDDLM XML-CDL

CDDLM XML-CDL. Jun Tatemura NEC Laboratories Amercia GGF10, March 2004. J2EE app. Component Service. Application server. Service Requester. application. Component Service. Service Requester. Background: Components and Component Services.

jewell
Télécharger la présentation

CDDLM XML-CDL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. J2EE app Component Service Application server Service Requester application Component Service Service Requester Background: Components and Component Services • How applications are deployed on top of infrastructure Linux

  3. Application Wrapper Provider (developer) CDL Template Resource provider CDL Template For 3tier app CDL Template CDL Template Web server Component service Web server Web server CDL For a specific deployment request CDDLM processor App server Basic Service + Component service App server App server DB server DB server Component service DB server Resource Broker CDL’s Role in Deployment • Example: Three-tier web applications User (who deploys) Info from agreement

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

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

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

  7. Issue 1: Attribute Set Description Model

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

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

  10. [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> Two Design Alternativesof Attribute Description

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

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

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

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

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

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

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

  18. extends includes [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) Reference (QName+Xpath) <reference root=“xsd:QName”> xpath </reference>

  19. [Alt-1] CDL specific attribute elements Pros: 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 Pros and Cons

  20. Issue 2: Component (Wrapper) Model

  21. <system> <system> <component> <component> <component> Component Service endpoint Component Service endpoint Component Service endpoint WS-Resource WS-Resource WS-Resource 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) <configuration> <attributeSet> <attributeSet>

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

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

  24. Issue 3: Lifecycle Management Model

  25. 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 Consistency among components should be maintained CDDLM Processor Component Service endpoint CDDLM Client (e.g., Job Manager) Component Service endpoint

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

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

  28. Issue 4: Dependencies and Assertions

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

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

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

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

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

  34. Action Items • Completion of the first draft by GGF11 • More discussion on Issues • Evaluation on design alternatives based on examples (from our use cases) • CDDLM-Services • “basic” services and component services • LM requirements • Partial (re) deployment, etc.

More Related