CDDLM Component Model

1
CDDLM Component Model
Stuart Schaefer Softricity, Inc. sschaefer_at_softri
city.com
2
CDDLM Foundations

• A Component Description Language (CDL) document
  describes a deployment
• It is submitted to a node implementing the
  Deployment API
• This node is then responsible for the deployment
  lifecycle of the Components described in the CDL
  document

3
Components

• Deploy and manage Resources
• May or may not contain Services
• Manage the lifecycle of the Resource
• Provide a WS Resource for interaction
• With the Deployment API
• With other Manageability Providers
• Provide a WSDM Manageability Endpoint
• Provide properties and interfaces for
• Configuration
• Lifecycle Management
• Maintenance

4
Component Model

• The Component Model provides semantics for how to
  use the CDL language to describe a deployment
• Provides a mapping between the definitions in CDL
  and Components able to deploy described Resources
• Describes the implementation requirements of a
  CDDLM compliant Component
• Describes the interaction of Components with the
  CDDLM Deployment API
• Defines the normative lifecycle of a deployment

5
CDDLM System

• A System is a group of 1n Components that each
  contain 0n Services
• Services are defined as WS-I or WS-RF compliant,
  but must have at least one valid WS-Addressing
  Endpoint Reference.

6
Defining a System

• A System is defined within a CDL document as the
  ltcdlsystemgt node.
• Within the CDL description, nodes are defined as
  children of the system node. These nodes are
  language components.
• Language Components are logical nodes defined in
  the system which may or may not map to a physical
  resource.
• If a Language Component is defined with a WSRF
  resource identifier, it is then also a deployment
  component.
• Deployment Components are software resources that
  provide a concrete implementation of a language
  component.
• In order to be deployable, a system MUST contain
  at least one deployment component.

7
Why Language Components?

• Language Components provide a means of expression
  and organization of the hierarchy of a deployment
  a deployment graph
• When a deployment is described in CDL, the
  property list resolution process and templating
  may create nodes that are simply placeholders for
  properties.
• It is undesirable to require a deployment action
  for these placeholders
• The flow of deployment may be hard to control or
  describe hierarchically. Additional nodes can
  help organize and group the deployment.
• All references within the CDL document are made
  to elements within the CDL defined hierarchy, not
  to deployed component endpoints.

8
Requirements for Deployment Components

• A valid Deployment Component
• MUST implement a WSRF resource
• MUST expose its properties as WS-ResourcePropertie
  s
• MUST support WS-BaseNotification
• MUST implement the WSDM Identity and State
  Capabilities
• MAY support WS-MetaDataExchange
• A Language Component will be mapped to a
  Deployment Component IFF it defines an
  identifiable Deployment Component property in its
  CDL property list
• ltcmpComponentReferencegt
• ltcmpCodeBasegt
• ltcmpCommandPathgt

9
Deployment Component Properties

• A CDDLM Deployment Component instance is called a
  Component Object
• Each Component Object will expose the following
  properties of its WSRF resource
• Identity REQUIRED
• Required by WSDM
• MUST have a base ResourceId element with type
  muws-p1-xsResourceId
• MUST expose this property as part of its WSRF
  Resource Properties document
• ComponentName OPTIONAL
• A name used within inter-component message
  exchanges, derived from the actual CDL path
• ComponentStatus REQUIRED
• Expose the state of the component object as a
  WSDM State Capability
• Contains the WSDM State, WSDM StateTransition,
  and implementation specific ExtendedState
  properties
• ComponentProperties REQUIRED
• WSRF Resource Properties document
• SHOULD be an extension of the CDDLM
  ComponentProperties element definition

10
Deployment Component Operations

• Each Component Object will expose the following
  operations of its WSRF resource
• WS-ResourceProperties Operations
• GetResourceProperty
• GetMultipleResourceProperties
• SetResourceProperties
• QueryResourceProperties
• State Transition Operations
• Initialize
• Run
• Terminate
• Destroy WS-ResourceLifetime
• Maintenance Operations
• RunTask

11
Deploying A System

• The Deployment API is responsible for creation of
  a WSRF resource to represent the System
• The System EPR will aggregate lifecycle
  operations and state for the components of the
  System.
• Once created, the System EPR will instantiate
  each Deployment Component
• Each Deployment Component is created as a WSRF
  resource with a Component EPR
• From this point, operations on the System EPR
  will translate to aggregated operations on
  Component EPRs
• For more detail on this process, come to
  tomorrows presentation on the Deployment API

12
Component Lifecycle Model

• Each deployment component must implement the
  CDDLM lifecycle state machine
• Each state represents the state of the underlying
  managed resource, not the component itself
• A component SHOULD NOT report its state as a new
  state until the transition is complete.

• Each Component EPR and the System EPR expose WSDM
  State Capabilities
• These require state and state transition
  properties
• WSDM also allows sub-states to augment the core
  state model

13
CDDLM System Lifecycle

• The System EPR will present the aggregated
  lifecycle of a deployment
• The System EPR is free to return any state,
  independent of the states of individual
  components
• If all components are in a specific state, the
  system state SHOULD be the same state
• If the system is transitioning to a new state,
  the system state SHOULD be the prior state until
  the new state has been achieved
• State actions MUST be coordinated. If the System
  is asked to terminate, then all components MUST
  be terminated.
• However, if something fails, the system MAY
  attempt to internally handle the failure before
  reporting a failed state.

14
Component Delegates

• Often, you would like to segment a deployment or
  defer the lifecycle management of a group of
  components to some sub element of the System EPR
• A Delegate allows the responsibility for the
  lifecycle of a group of components to be managed
  by the Component EPR of one specific component

15
Deployment Control

• In order to declaratively control the
  organization and process of a deployment, the
  Component Model defines several CDL language
  elements
• Events and Notifications
• Control Flow
• These elements are declared as properties of some
  language component node
• Event and Notification elements declare
  subscriptions for events by the component node
  and associated nodes
• Control Flow elements can
• Declare properties for nodes which are children
  of the current node. This creates a control flow
  scope.
• Declare operational attributes for a language
  component to affect the processing of other nodes
  in the hierarchy.

16
Events and Notifications

• When state transitions occur, component objects
  can send events of type ComponentLifecycleEvent
• This event is derived from the WSDM
  ManagementEventType
• A deployment component is decorated
• ltcmpOnEvent notifycdlrefgt where OnEvent is
  the type of event OnInitialized, OnRunning,
  OnFailed, OnTerminated
• The component object at ltcdlrefgt must subscribe
  to the decorated component object for to receive
  notification of that event
• When properties of a component object change that
  are declared within the CDL document, component
  objects can send events of type
  PropertyChangeEvent
• This event is also derived from the WSDM
  ManagementEventType and sends a WSRF
  ResourcePropertyValueChangedNotification wrapped
  inside
• A deployment component is decorated
• ltcmpOnChange refcdlref/propertygt
• The component object which is decorated must
  subscribe to the component object at ltcdlrefgt
  for notification of the property change event

17
Control Flow

• Control flow elements are a subset (not proper)
  of the WS-BPEL specification
• All control flow elements specify which portion
  of the lifecycle they apply to ltcmpX
  lifecyclecmpLifecycleProcessEnumgt
• Sequence
• A node decorated with ltcmpSequencegt declares all
  child nodes to be executed in lexical order
  within the file, in a depth-first fashion.
• The ltcdlsystemgt node can be decorated with this
  element
• A language only component can be decorated as
  well
• Flow
• A node decorated with ltcmpFlowgt declares all
  child nodes to be executed concurrently, in a
  breadth-first fashion.
• The ltcdlsystemgt node can be decorated with this
  element
• A language only component can be decorated as well

18
Control Flow (2)

• Wait
• A node can be instructed to wait an absolute
  amount of time, or until a specified time, before
  continuing its current deployment action
• Within the scope of a sequence, it will delay all
  pending elements of the sequence.
• Within a flow, it will pause the execution of all
  elements lexically declared after the wait
  element and children of the current node.
• Switch
• A node can contain a branching instruction to
  alter the depth-first, or breadth-first behavior
  of deployment graph traversal
• The switch statement will make a boolean test
  represented by an XPath 1.0 Query over properties
  declared in the CDL document
• The switch statement will transfer flow of
  control to the appropriate node and create a
  synchronization point at the statement
• This synchronization point serves to rebind the
  deployment graph out of lexical order, but still
  obey the scopes of flow and sequence processing

19
The Deployment Graph

• The purpose of deployment control is to provide
  structure to the deployment
• When structure does not exist, the System is free
  to implement state transitions in any way it sees
  fit.

20
Current State of Component Model

• 01-03-2005 Draft available in GridForge and
  SourceForge
• XSD, WSDL and example CDL documents are also
  available
• To be addressed
• Concerns over complexity
• Are the semantics restrictive/definitive enough
  to be useful
• WS- specifications are in flux and difficult to
  rely on
• To use WSDM 1.0, we are relying on draft specs of
  WSRF and WSA