“Custom” Checks/Constraints/Actions A proposal for the OASIS SDD TC Rich Aquino, Macrovision Julia McCarthy, IBM March 1, 2007

Agreed to basis for the proposal Everything in the SDD that corresponds to the deployment environment may require custom logic. Custom logic should be associated with declarative data. therefore the current CustomCheck elements (in Requirements) should be removed in favor of new custom logic associated directly with a declared requirement The association between custom logic and SDD elements could be explicit in the SDD or be provided by an implementation. We prefer that it be in the SDD if we can find a timely solution – hence this proposal.

SDD elements that correspond to the deployment environment. Resource identity –type, Name and Version in Topology.Resource –Resource Name, Version, Fixname and Property in ResultingResource –Resource Name and Version in RequiredBase –Property in ResultingChange elements Resource properties –Used in ResourceProperty variables and all constraint types Actions that need to be performed –Lifecycle operations for content units We already provide the ability to provide custom logic for lifecycle operations via artifacts. Artifacts are optional because even lifecycle operations may not require custom logic in all cases. –“completion actions”

Proposal Terminology Resource Handle: a means for accessing a specific instance of a resource. Actual implementation of the handle is shared knowledge between the artifact creator and the software implementation that will use the artifact. Plan: Once the logical deployment model described by the SDD has been fully “resolved”, i.e. content elements have been selected for a particular deployment and logical resources have been associated with particular resource instances, the result could be called a fully resolved model or a plan. Pre-Plan: Before full resolution of the model. Implied Inputs : Inputs that do not have to be defined by the SDD author because they are part of the semantics of the custom artifact element in the SDD. This is true for pre-custom-proposal artifacts and will also be true for the proposed custom artifacts. *These concepts represent implications of the current SDD and may need further discussion if it turns out we don’t all have the same understanding.

ElementAssociated Custom Function Implied InputsOutputs (assume basic success/fail outputs for all) Deployment Implementation Timing Lifecycle Operation Artifacts (i.e. artifacts currently in the SDD schema) Perform lifecycle operation on resulting resources Artifact element; resource handle (except for create) Create: handle to created resource Plan Execution time (i.e. actual deployment) Resource Elements (Topology); RequiredBase Elements Discover resource instances that meet identity criteria The resource element or required base element from the SDD Handle(s) to discovered instance(s) As needed by implementation ResourceProperty Variable Elements Determine variable value The ResourceProperty element; handle to the resource instance A value for the variable Specification-defined variable evaluation time Constraint Elements (all are based on resource properties) Determine if the constraint is met. The constraint element; handle(s) to resource instance(s) True/false associated with each input handle As needed by implementation Completion Element;Perform post-lifecycle operation processing; Completion element from SDD; associated resource handle(s) NonePost-operation or post-complete deployment. (Does this need to be a choice?) (ResultingResource Elements;) (ResultingChange?) (for Resulting Resources this might be registration) Resulting element from SDD; associated resource handle(s) NoneSame as Completion

Design Decisions All custom logic is associated with a specific SDD element which in turn is associated with specific resource element(s) in topology. Custom logic is in separate SDD section. This results in no change to current schema sections (other than replacing current CustomCheck element with custom logic in the new section) One custom artifact can be associated with one, many or all of the supported elements. This allows the SDD author to choose the granularity – anything from one artifact per element that needs custom logic to one custom artifact for all elements of a particular type.

Semantics

Add “CustomStuff” to DeploymentDescriptor *We PROMISE this ridiculous name will not actually go into the schema.

<element name="ConfigurationUnit" type="sdd-dd:ConfigurationUnitType"/> <element name="LocalizationUnit" type="sdd-dd:LocalizationUnitType"/> <element name="CustomStuff" type="sdd-dd:CustomStuffType" minOccurs="0"/>

Supporting Types

Proposal: Supporting Types

How two of the artifact types relate to SDD elements and the deployment environment.

Additional Change Add id attribute to base ConstraintType so that ConstraintEvaluationArtifacts can be associated with constraints.

Implementation Implications Implementations can look in custom “stuff” section to see if there are artifacts available to help with a specific function. Implementations can choose to optimize for performance when the SDD author associates one custom [discovery | evaluation | action] artifact with multiple [discovery | evaluation | action] elements. Planning implementations may care only about custom discovery artifacts. At one end of the deployment implementation specturm, deployment implementations could be built that totally rely on custom artifacts for interaction with the deployment environment. (e.g. A simplisitic implementation built to just get in the game.) At the other end of the spectrum, deployment implementations could be built that are capable of performing all discovery, evaluation and actions on the types of resources they support and so would not support custom actions at all. (e.g. Software built by REALLY smart people or software built for restricted and simple environments.)

JRE Example Note that jre.xml doesn’t have need for all of the custom artifact types.

Choose a name for CustomStuff Possibilities: CustomArtifacts: Because CustomStuff is a list of various custom artifact elements. HelperArtifacts: Because “custom” isn’t the characteristic that distinguishes these artifacts from the lifecycle artifacts. These artifacts help an implementation discovery and evaluate the environment – as opposed to the lifecycle artifacts which help an implementation change the environment.