The Binding Specification is a single xml document which defines model context selection and binding to Templates. The specification document incorporates the following features :
|
· Navigation expressions use XPATH syntax. · XSLT constructs are used to facilitate and communicate information between launch/binding/Template facilities.
|
This chapter describes:
|
· The Binding Specification document · XPATH concepts related to model traversal
|
Binding specifications are edited using an eclipse XML Editor.
The overall structure of the document is:
o …
o projects
<templateBinding> is the root element of the document. It may include:
Example fragment:
|
<templateBinding xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://modelDriven.org/schema/modelPro/bindingSpecification" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://modelDriven.org/schema/modelPro/bindingSpecification
platform:/plugin/org.modeldriven.component.plugin.modelPro/resource/modelPro.xsd" xmlns:Element="java:org.eclipse.uml2.uml.Element" xmlns:util="org.modeldriven.modelPro.cartridge.soauml.SoaumlTemplateUtility">
<!-- list of xsl:param for each launch parameter
-->
<xsl:param name="modelPro.dir"/> <provisioningContexts> ……….. |
Namespace declarations for a Binding Specification typically include:
· xmlns=”http://modelDriven.org/schema/modelPro/bindingSpecification” Specifies the namespace for Binding Specification.
· xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” Specifies the XSLT namespace, which is referenced by some elements within a Binding Specification.
·
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” Specifies the xsi namespace, which is required for
the xsi:schemaLocation attribute.
· Other. Other namespaces are used to define bindings to XPATH function libraries as well as bindings to specific java classes. ModelPro provides some namespaces by default, and consequently they do not require explicit declaration.
An example of a java class binding declaration:
|
<templateBinding … xmlns:Element="java:org.eclipse.uml2.uml.Element">
|
Adding this namespace declaration enables the use of function access to the UML “Element” implementation using the XPATH notation as in Element:getValue($element,$stereotype,’tag’) ,
where $element is an Element Instance, $stereotype is a Stereotype instance.
The xsi:schemaLocation attribute may be used to specify the location of schemas, in particular the location of the Binding Specification schema. The explicit declaration of the schema location enables Binding Specification document validation and enhanced Binding Specification editing capabilities as described in Binding Specification/XML Editor and Validation.
The xsl:param is an optional element corresponding to the (XSLT) construct. It may be used to communicate the value of a named parameter from the launch to XPATH expressions within the Binding Specification document as well as Templates.
This element contains the set of provisionContext definitions. The structure is:
|
< provisioningContexts > < provisioningContext …> < provisioningContext …> … </ provisioningContexts >
|
Where each provisioningContext is structured as:
|
< provisioningContext name=” provisioningContext” select=” XPATH expression”> <xsl:variable name="someName" select=" XPATH expression "/> <xsl:variable
name="someName2" select=" XPATH expression2 "/> … <projectRef folder="projectKind" /> <projectRef folder="projectKind" /> … </artifactContext>
|
Example fragment:
|
<provisioningContexts> <provisioningContext name="SetRuntime" select="//uml:packagedElement[@instance.of.Node and
mp:hasStereotype(.,'JEE Provisioning Profile::JEE Provisioning')]"> <xsl:variable name="modelProDir" select="fn:replace($modelPro.dir,'\\','/')"
/> <xsl:variable name="CartUtil" select="util:newInstance()" /> <projectRef folder="Empty"/> </provisioningContext> ……….. |
The name attribute of the <provisioningContext > element assigns a name to the Provisioning Context selection specification. It is currently unused except for documentation of intent for the provisioningContext.
The select attribute of the <provisioningContext> element is an XPATH expression which selects the collection of model elements which are to be a Provisioning Context . Each selected model element becomes the Provisioning Context in which nested <xsl:variable> and referenced <project>s are evaluated.
The xsl:variable is an optional element corresponding to the (XSLT) construct. It may be used to communicate the value of a named variable to XPATH expressions deeper in the context resolution hierarchy, as well as Templates. Evaluation of select expression is performed in context of the current Provisioning Context.
The <projectRef…/> element indicates which project kinds are associated with the named <provisioningContext>. The folder attribute of <projectRef> is a reference to the folder attribute of a <project> within the <projects> element. For each Provisioning Context, evaluation of Project Context is performed for each occurrence of a <projectRef..>.
This element contains the set of project definitions. The structure is:
|
< projects > < project …> < project …> … </ projects >
|
Where each project is structured as:
|
<project folder=”folderName” name=” XPATH expression” select=” XPATH expression”> <xsl:variable name="someName" select=" XPATH expression "/> <xsl:variable name="someName2" select=" XPATH expression2 "/> … </ project >
|
Example fragment:
|
<projects> <project folder="Build"
name="$targetProjectName" select="." /> <project folder="WebServiceContract"
name="$targetProjectName" select=".[mp:hasStereotype(.,'JEE Provisioning
Profile::JEE Web Service')]/uml:type" > </project> ……….. |
The folder attribute of the <project > element is the “project kind” for a project.
|
v The folder attribute is referenced by the <projectRef> element within a <provisioningContexts> definition. The Project Context will be evaluated for any Provisioning Context which references the project folder. v The folder is the project kind. It is the name of a folder containing Templates. v For each Project Context, the set of project Templates are examined. Each Template references an Artifact Context by name. The Artifact Context selection for the Template will be evaluated in the context of the current Project Context.
|
The select attribute of the <project> element is an XPATH expression which selects the collection of model elements which are to be a Project Context . The expression is evaluated with respect to the current Provisioning Context. Each selected model element becomes the Project Context in which nested <xsl:variable> and referenced Template/<artifactContext>s are evaluated.
The name attribute of the <project > element is an XPATH expression which is evaluated with respect to the current Project Context. The result of the expression evaluation is the name of a target folder which is to contain provisioned artifacts associated with the current Project Context.
The xsl:variable is an optional element corresponding to the (XSLT) construct. It may be used to communicate the value of a named variable to XPATH expressions deeper in the context resolution hierarchy, as well as Templates. Evaluation of select expression is performed in context of the current Project Context.
For each Project Context, all Templates in the project folder are partially processed to determine the named Artifact Context selection to be used in conjunction with the Template. The Artifact Context selection associated with the Template is then evaluated with respect to the current Project Context.
This element contains the set of Artifact Context definitions. The structure is:
|
<artifactContexts> <artifactContext…> < artifactContext …> … </ artifactContexts >
|
Where each artifactContext is structured as:
|
< artifactContext name=” artifactContext” select=” XPATH expression”> <xsl:variable name="someName" select=" XPATH expression "/> <xsl:variable
name="someName2" select=" XPATH expression2 "/> … </artifactContext>
|
The name attribute of the < artifactContext > element is the Artifact Context name referenced by a Template.
The select attribute of the < artifactContext> element is an XPATH expression which selects the collection of model elements which are to be an Artifact Evaluation Context . The expression is evaluated with respect to the current Project Context. Each selected model element becomes the Artifact Context in which an associated Template is evaluated.
In summary, the Binding Specification provides the following navigation:
Model rootèprovisioningContextsàprojectsà(via project’s Templates)àartifactContextsàTemplate evaluation
XPATH syntax is used for model traversal. XPATH is normally associated with XML document traversal, but the underlying Data Model (XQuery 1.0 and XPath 2.0 Data Model (XDM)) provides a level of abstraction which is not constrained to a surface representation of an XML Document. In particular, the (XQuery 1.0 and XPath 2.0 Data Model (XDM)) states that
“There are no constraints on how an instance of the data model may be constructed directly, save that the resulting instance must satisfy all of the constraints described in this document.”.
The use of XPATH within ModelPro conforms to the XPATH specification, not including “schema-aware” constructs.
There are seven kinds of nodes in the (XQuery 1.0 and XPath 2.0 Data Model (XDM)). For the purposes of model navigation, we use only 3, as illustrated in Figure 5 XPath Data Model Structure. The correspondence between XDM Nodes and EMF concepts is roughly:
|
DocumentèResourceSet ElementèEReference AttributeèEAttribute
|
Figure 5XPATH Data Model Structure

In order to enable access to all model elements directly or indirectly referenced by a model, it is necessary for the scope of the XDM data model to encompass an EMF “Resource Set”. A Resource Set is the transitive closure of all resources having model elements referenced by a given primary model. This “universe” of contained model elements corresponds to the XDM document node.
Element Navigations within an XML document is with respect to XML element names. Attribute navigations are with respect to XML attribute names and yield a value which cannot be the basis for further navigation. For a schema-based XML document, each element and attribute has a type. Corresponding to these concepts:
|
· Navigations between EObjects within an EMF model are with respect to (the name of an) EReference. This form of navigation corresponds to XDM Element Node navigation. · Navigation via (name of) an EAttribute yields an object which cannot be navigated using EMF reflection. The modeled type of an EAttribute will be a Data Type which can be rendered in some form of schema primitive type. This form of navigation corresponds to XDM Attribute Node navigation. · Every EStructuralFeature has a type, which is an EClassifier.
|
There is an anomaly at the top of the model, namely the existence of a “Resource” between the Resource Set level and the top level EObjects, as well as navigation from a Resource to the top level EObjects. As a resolution of this anomaly, the navigation (i.e., the XSD Element name) from Resource Set to Resource is asserted to be “resources” and the navigation (i.e., the XSD Element name) from Resource to EObjects is asserted to be “contents”.
(XML Path Language (XPath) 2.0) XPATH defines a path expression to be the mechanism for navigation between nodes. A path expression consists of a series of “steps” separated by “/” or “//”. There is a definition for both a formal node reference notation and an abbreviated notation.
The basic path expression interpretation for an EMF model is illustrated in Figure 6 XPath Path Expressions, based on the XDM mapping for an EMF Model:
|
ResourceSetèDocument EAttributeèAttribute EReferenceèElement
|
Note: the primary variation from the XPATH specified semantics is that the explicit reference of an Element name in ModelPro XPATH allows navigation to any EReference, not just children of the Node. Thus, explicit navigation is permitted across the entire model, not just containments.
Figure 6XPATH Path Expressions

Further elaboration of the ModelPro implementation for selected XPATH path step constructs follow. In most cases, the focus is on the abbreviated syntax for the step. However, the corresponding full syntax for each step is also available. In each case, a description of the model navigation is made with respect to the underlying EObject for a given context. XPATH path step constructs not explicitly elaborated below can be assumed to be supported in a manner analogous to the selected constructs.




|
@name Selects the name attribute of the context node Corresponds to contextèeGet[contextèeClassègetEstructuralFeature(name)] In addition to above, the following pseudo-attributes may be accessed: @xmi:type provides XMI-compatible representation of type, e.g.: “uml:Model” @xmi:id provides XMI-compatible representation of id, e.g.: “_wK98VYA_Ed2xsvzRuEHZYg” @mpurl provides fully qualified URI representation of context, e.g.: “platform:/resource/org.modeldriven.application.fUML.example/model/fUML.uml#_wK98VYA_Ed2xsvzRuEHZYg” Note: this construct also allows access to ModelPro instance.of.* pseudo-attributes, which are described in the section on schema-aware processing.
|

![Text Box: .//para
selects the para element descendants of the context node.
Corresponds to contextèeAllContents[@name=’para’]](Binding%20Specificatio2_files/image014.gif)
ModelPro XPATH does NOT currently implement schema-aware processing. This restriction is primarily due to the underlying (Saxon) XPATH non-commercial implementation. From the (XML Path Language (XPath) 2.0) specification, many features derived from the following definitions are not enabled:
![Text Box: • [Definition: In-scope schema definitions. This is a generic term for all the element declarations, attribute declarations, and schema type definitions that are in scope during processing of an expression.] It includes the following three parts:
o [Definition: In-scope schema types. Each schema type definition is identified either by an expanded QName (for a named type) or by an implementation-dependent type identifier (for an anonymous type). The in-scope schema types include the predefined schema types described in 2.5.1 Predefined Schema Types. ]
o [Definition: In-scope element declarations. Each element declaration is identified either by an expanded QName (for a top-level element declaration) or by an implementation-dependent element identifier (for a local element declaration). ] An element declaration includes information about the element's substitution group affiliation.
[Definition: Substitution groups are defined in [XML Schema] Part 1, Section 2.2.2.2. Informally, the substitution group headed by a given element (called the head element) consists of the set of elements that can be substituted for the head element without affecting the outcome of schema validation.]
o [Definition: In-scope attribute declarations. Each attribute declaration is identified either by an expanded QName (for a top-level attribute declaration) or by an implementation-dependent attribute identifier (for a local attribute declaration). ]](Binding%20Specificatio2_files/image015.gif)
The XPATH constructs which are impacted by the above restrictions are described in the following section.
![Text Box: InstanceofExpr
::= TreatExpr ( "instance" "of" SequenceType )?
The boolean operator instance of returns true if the value of its first operand matches the SequenceType in its second operand, according to the rules for SequenceType matching; otherwise it returns false. For example:
• 5 instance of xs:integer
This example returns true because the given value is an instance of the given type.
• 5 instance of xs:decimal
This example returns true because the given value is an integer literal, and xs:integer is derived by restriction from xs:decimal.
• (5, 6) instance of xs:integer+
This example returns true because the given sequence contains two integers, and is a valid instance of the specified type.
• . instance of element()
This example returns true if the context item is an element node or false if the context item is defined but is not an element node. If the context item is undefined, a dynamic error is raised [err:XPDY0002].](Binding%20Specificatio2_files/image016.gif)
The above examples work with ModelPro, but attempting to use the following syntax will fail:

As a work-around, there are Boolean pseudo-attributes of the form @instance.of.class. For example, the above expression could be written as:

Within XPATH expressions, QNames are used to identify functions and node names. The following prefixes and namespaces are implicitly available from a ModelPro Binding Specification:
Figure 7Implicit prefix/namespace mapping
|
Prefix |
Namespace |
description |
|
fn |
http://www.w3.org/2005/xpath-functions |
Provides access to the complete XPATH 2.0 function library |
|
xs,xsd |
http://www.w3.org/2001/XMLSchema |
Access to constructors and other references to schema types |
|
saxon |
http://saxon.sf.net/ |
Provides access to saxon extension functions |
|
xmi |
http://schema.omg.org/spec/XMI/2.1 |
For reference to supported XMI attributes |
|
mp |
java:org.modeldriven.modelPro.xdm.ModelUtility |
Access to ModelPro helper functions |
In addition, all EMF meta-model s are ECORE models which have defined prefixes and namespaces. The prefix/namespace of all referenced ECORE models are implicitly provided to the context for XPATH expression evaluation. Any EReference-based Element Node has a QName which includes the prefix associated with the meta model for the underlying EObject. EAttribute-based Attribute Nodes do not have a prefix in their QName.
Any number of explicit prefix/namespace bindings may be specified in the <templateBinding> element of the Binding Specification. For namespace names of the form “java:package….class”, this extends the function library to include any accessible java class, as per Saxon extension mechanisms. These mechanisms enable access to model functionality beyond that available via EStructuralFeature and/or parameter-less method invocations.
Direct access to the underlying model API requires the use of mp:* functions to unwrap EObjects from their XPATH node façade. More specifically, the function “mp:Object(Node node)” exposes the underlying EObject for any given Element Node used in a path expression. Other mp:* functions are documented in the ModelPro javadoc reference.
The Binding Specification may optionally be used in conjunction with its schema for purposes of validating structural integrity. The schema is defined as:
|
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" targetNamespace="http://modelDriven.org/schema/modelPro/bindingSpecification"
xmlns:tns="http://modelDriven.org/schema/modelPro/bindingSpecification" elementFormDefault="qualified" id="templateBinding"> <xs:import namespace="http://www.w3.org/1999/XSL/Transform"
schemaLocation="http://www.w3.org/2007/schema-for-xslt20.xsd"/> <xs:element name="templateBinding"> <xs:annotation><xs:documentation>A ModelPro Binding Specification</xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded"
minOccurs="0" ref="xsl:param"/> <xs:element name="provisioningContexts"
minOccurs="1"> <xs:annotation><xs:documentation>A Set Of uniquely
named Provisioning Contexts</xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded"
minOccurs="1" name="provisioningContext"> <xs:annotation><xs:documentation>A uniquely named Provisioning
Context based on
selection of source model elements.
Each Provisioning Context instance is passed
to all referenced projects for disposition. </xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" minOccurs="0" ref="xsl:variable"/> <xs:element maxOccurs="unbounded" minOccurs="1" name="projectRef"> <xs:annotation><xs:documentation>A reference to a
Binding Specification project definition. The
name is also the name of a project kind folder containing templates
associated with
the project. </xs:documentation></xs:annotation> <xs:complexType> <xs:attribute name="folder" type="xs:IDREF"
use="required"/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:NCName" use="required"/> <xs:attribute name="select" type="xsl:expression"
use="required"> <xs:annotation><xs:documentation>An XPATH expression
used to navigate the source model, with
current context of Resource Set. </xs:documentation></xs:annotation> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="projects"
minOccurs="1"> <xs:annotation><xs:documentation>A set of project
definitions. </xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded"
minOccurs="1" name="project"> <xs:annotation><xs:documentation>A project definition
specifies the project kind folder of templates, a selection of model elements
based on the current provisioning context instance, and the name of the target project which
will contain generated target artifacts. </xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" minOccurs="0" ref="xsl:variable"/> </xs:sequence> <xs:attribute name="folder" type="xs:ID"
use="required"> <xs:annotation><xs:documentation>Specifies the project
kind folder for templates associated with the
project. This is also the ID
referenced by a <projectRef> within
a <provisioningContext> definition. </xs:documentation></xs:annotation> </xs:attribute> <xs:attribute name="name" type="xsl:expression"
use="required"> <xs:annotation><xs:documentation>An XPATH expression specifying the name of the target
project. The context for
expression evaluation is the current project context instance, as specified in
the @select attribute. </xs:documentation></xs:annotation> </xs:attribute> <xs:attribute name="select" type="xsl:expression"
use="required"> <xs:annotation><xs:documentation>An XPATH expression specifying the set of model elements which are
project context instances. The
expression is evaluated in the context of the current
provisioning context instance. Each
project context instance becomes the context for evaluation
of an artifact context instance selection. </xs:documentation></xs:annotation> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="artifactContexts"
minOccurs="1">
<xs:annotation><xs:documentation>The set of named
artifact context definitions. </xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded"
minOccurs="1" name="artifactContext"> <xs:annotation><xs:documentation>A uniquely named artifact context definition, which defines a
selection of artifact context instances. </xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" minOccurs="0" ref="xsl:variable"/> </xs:sequence> <xs:attribute name="name" type="xs:NCName"
use="required"> <xs:annotation><xs:documentation>The unique name for the artifact context definition.
This name is
referenced by Templates. The template
will be evaluated for each artifact context
instance selected by the @select expression. </xs:documentation></xs:annotation> </xs:attribute> <xs:attribute name="select"
type="xsl:expression" use="required"> <xs:annotation><xs:documentation>An XPATH expression which specifies the selection of artifact context
instances. The expression is evaluated
in the context of the current project context
instance. Each artifact context
instance is used as the context for one template evaluation. </xs:documentation></xs:annotation> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:key name="provisioningContextName"> <xs:selector xpath=".//tns:provisioningContext"/> <xs:field xpath="@name"/> </xs:key> <xs:key name="artifactContextName"> <xs:selector xpath=".//tns:artifactContext"/> <xs:field xpath="@name"/> </xs:key> </xs:element> </xs:schema> |
Highlights of the schema definition:
|
· targetNamespace=http://modelDriven.org/schema/modelPro/bindingSpecification The namespace to be used for Binding Specifications in conjunction with schema validation. · <xs:import : definitions for optional <xsl:?> elements is based on xsl schema. · There is exactly one occurrence each for the elements <provisioningContexts>, <projects>, <artifactContexts>, and they must appear in that order. · A <provisioningContexts> element must contain at least one <provisioningContext> and the @name value must be unique across all <provisioningContext>s. o Within a <provisioningContext>, there must be at least one <projectRef> and the @folder attribute must refer to a defined <project folder=”?”> with the same @folder value. · A <projects> element must contain at least one <project> and the @folder value must be unique across all <project>s. · An <artifactContexts> element must contain at least one <artifactContext> and the @name value must be unique across all <artifactContext>s. · Attributes which must be XPATH expressions are defined with a type of “xsl:expression”.
|
To augment a Binding Specification document to include schema validation, the root element must be extended as indicated below:

Explanation of the added items:
|
· xmlns=http://modelDriven.org/schema/modelPro/bindingSpecification ·
The
namespace for the Binding Specification documents. · xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance · The xsi namespace, required for the following xsi:schemaLocation: · xsi:schemaLocation=http://modelDriven.org/schema/modelPro/bindingSpecification platform:/plugin/org.modeldriven.component.plugin.modelPro/resource/modelPro.xsd” ·
Declaration
of the schema location (which is within a ModelPro plug-in).
|
This is an SOA provisioning example. The entire Binding Specification follows. Selected elements of the specification will be further elaborated in the following sections.
![Text Box: <TemplateBinding xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:param name="GlassFishESBDirectory"/>
<provisioningContexts>
<provisioningContext name="jbi" select="//uml:packagedElement[@instance.of.Node and mp:tag(.,'ProvisioningProfile::Provision','TechnicalArchitecture')='jbi']/uml:ownedAttribute">
<xsl:variable name="targetProjectName" select="fn:replace(uml:type/@name,' ','')"/>
<xsl:variable name="dependentProjectName" select="fn:replace(uml:clientDependency/uml:supplier/uml:type/@name,' ','')"/>
<xsl:variable name="clientParticipant" select="uml:targetDirectedRelationships/uml:source/uml:type"/>
<projectRef folder="DistributedWebService"/>
<projectRef folder="XSLTImplementation"/>
</provisioningContext>
</provisioningContexts>
<projects>
<project folder="DistributedWebService" name="fn:replace(@name,' ','')" select=".[mp:hasStereotype(.,'ProvisioningProfile::DistributedWebService')]/uml:type"/>
<project folder="XSLTImplementation" name="$targetProjectName" select=".[mp:hasStereotype(.,'ProvisioningProfile::XSLT Implementation')]/uml:type"/>
</projects>
<artifactContexts>
<artifactContext name="singleton" select="."/>
<artifactContext name="operation" select="$clientParticipant/uml:allAttributes[@instance.of.Port]/uml:type/uml:allImplementedInterfaces/uml:allOperations"/>
<artifactContext name="implport" select="$clientParticipant/uml:allAttributes[@instance.of.Port]"/>
<artifactContext name="port" select="uml:allAttributes[@instance.of.Port]"/>
<artifactContext name="schema" select="(uml:allAttributes[@instance.of.Port]/uml:type/uml:allImplementedInterfaces/uml:allOperations/uml:returnResult/uml:type/uml:owner)[1]"/>
<artifactContext name="implschema" select="($clientParticipant/uml:allAttributes[@instance.of.Port]/uml:type/uml:allImplementedInterfaces/uml:allOperations/uml:returnResult/uml:type/uml:owner)[1]"/>
</artifactContexts>
</TemplateBinding>](Binding%20Specificatio2_files/image021.gif)
![]()
The xsl:param is a named parameter whose value is set by the launching ant script. The parameter may be referenced by any of the XPATH expressions within the Binding Specification (which is not the case in this example) or by any evaluated Template.
A fragment of the ant launch script which initializes the parameter:

This combination results in the string “C:\\GlassFishESB\\” assigned as the value of the variable named “GlassFishESBDirectory”.
A fragment from a Template which references this property:
|
enterprise.module.install.dir=${GlassFishESBDirectory}netbeans\\enterprise5\\modules ide.module.install.dir=${GlassFishESBDirectory}netbeans\\ide9\\modules j2ee.server.instance=[ ${GlassFishESBDirectory}\\glassfish]deployer:Sun:AppServer::localhost:4848 java.module.install.dir=${GlassFishESBDirectory}netbeans\\java2\\modules netbeans.user= ${GlassFishESBDirectory}.netbeans\\glassfishesb soa.module.install.dir=${GlassFishESBDirectory}netbeans\\soa2\\modules xml.module.install.dir=${GlassFishESBDirectory}netbeans\\xml2\\modules
|
A provisioned artifact from this Template:
![Text Box: <provisioningContext name="jbi" select="//uml:packagedElement[@instance.of.Node and mp:tag(.,'ProvisioningProfile::Provision','TechnicalArchitecture')='jbi']/uml:ownedAttribute">](Binding%20Specificatio2_files/image025.gif)
This example has a single named Provisioning Context, “jbi”. Instances of the Provisioning Context are selected by the XPATH expression in the “select” attribute. An explanation of this particular expression follows:
|
· //uml:packagedElement for each packaged element in the model · [ which: o @instance.of.Node is a node o and and o mp:tag(.,'ProvisioningProfile::Provision','TechnicalArchitecture')='jbi'] have an applied stereotype of “Provision” with a value of “jbi” for the “TechnicalArchitecture” tag · ] · / select the · uml:ownedAttribute owned attributes
|
For this example, the following uml diagram indicates the selected items:
Figure 8Provisioning Context Selection:Uml Diagram Rendering

There are only 2 “Nodes” in the UML model. Only one of the nodes is a TechnicalArchitecture of “jbi”. The Node owns 2 attributes, as highlighted. There are 2 instances of Provisioning Context, one for each attribute.
Associated with the Provisioning Context instance are multiple variables. These variables may be used in subsequent XPATH expressions within the Binding Specification or by Templates. The following variable will be used for explanation:

The “name” attribute specifies the name assigned to the variable for subsequent reference. The “select” attribute is an XPATH expression evaluated in the context of current Provisioning Context instance. It may be interpreted as:
|
· uml:targetDirectedRelationships for all directed relationships which target the current Provisioning Context instance, · / for all · uml:source sources (which in this case is an attribute) · / select · uml:type the type
|
For the example model, this navigation is successful only for the “:Solution Service Implementation” (UML) attribute. Navigation will occur in the reverse direction along the Dependency to arrive at the “:Solicitation Manager Composite Application” (UML) attribute, and from there to the type of the UML attribute (namely the “Solicitation Manager Composite Application” Component).
Associated with the Provisioning Context are multiple project references. These specify which Project Contexts are to be evaluated for each Provisioning Context instance. The following projectRef will be used for explanation:
![Text Box: <project folder="DistributedWebService" name=" fn:replace(@name,' ','')" select=".[mp:hasStereotype(.,'ProvisioningProfile::DistributedWebService')]/uml:type"/>](Binding%20Specificatio2_files/image029.gif)
This element specifies that the <project> which has a @folder attribute value of “DistributedWebService” is to be evaluated for each Provisioning Context instance.
The example has multiple Project Context definitions. Each Project Context definition identifies a project kind folder for obtaining Templates, the name of the provisioned target project folder, and the selection criteria for Project Context instances. The following project will be used for explanation:
![Text Box: <project folder=”DistributedWebService” name=”fn:replace(@name,’ ’,’’)” select=”.[mp:hasStereotype(.,’ProvisioningProfile::DistributedWebService’)]/uml:type”/>](Binding%20Specificatio2_files/image005.gif)
The @folder attribute names the project kind, in this example it is “DistributedWebService”. The @folder name may be referenced by one or more <projectRef> elements within an <artifactContext> definition. The @folder name is also the name of a project kind Template folder. For this example, there is a Template folder structure as follows:
|
· velocity o DistributedWebService § *.Template § … o XSLTImplementation § *.Template § …
|
The folder “DistributedWebService” contains the Templates used for provisioning target artifacts for this kind of project.
The @select attribute defines Project Context instances. It is an XPATH expression evaluated in the context of the current Provisioning Context instance. An explanation for the example @select expression:
|
· . for the current Provisioning Context instance (which is a UML attribute) · [mp:hasStereotype(.,'ProvisioningProfile::DistributedWebService')] which has a stereotype of “DistributedWebService” · /uml:type select the UML type (which in this case is a UML Component)
|
From a UML diagram of the example model, this selects the type of the indicated attribute:
Figure 9Project Context Selection:UML Diagram Rendering

The net effect of the @select, in this example, is to constrain the selected components for the DistributedWebService project to those which have been referenced by UML attributes stereotyped as “DistributedWebService”. The result is a single UML Component named “Solicitation Manager Composite Application”, which becomes the Project Context instance for subsequent evaluation of all Artifact Contexts for the project.
The @name attribute is an XPATH expression for specifying the name of the target project folder. It is evaluated in the context of a Project Context instance. An explanation for the example @name expression:
|
· fn:replace( for o @name, the name of the current Project Context instance o ' ', replace all occurrences of a space o '') with an empty string
|
The name of the provisioned project folder is thus “SolicitationManagerCompositeApplication”, which is the name of the Project Context instance (UML Component) with blanks removed.
Each Template within the folder associated with the current Project Context is examined to determine a named Artifact Context which is to be applied to the Template. In this example, the folder is named “DistributedWebService”. The folder contains many Templates. The Template used for further explanation is named “wsdl.Template”. The content of that Template follows:
![Text Box: <artifactContext name="port" select="uml:allAttributes[@instance.of.Port]"/>](Binding%20Specificatio2_files/image032.gif)
Within the VTL comment block, there is a declaration that the @artifactContext value is “port”. This identifies a named <artifactContext> within the Binding Specification:
![Text Box: <artifactContext name=”port” select=”uml:allAttributes[@instance.of.Port]”/>](Binding%20Specificatio2_files/image001.gif)
In addition to the @name of the <artifactContext>, there is an XPATH select expression which identifies all Artifact Context instances which are to be applied to the Template. An explanation for the example expression:
|
· uml:allAttributes select all UML attributes (including inherited) of the current Project Context instance (which is the UML Component “Solicitation Manager Composite Application”) · [@instance.of.Port] which are UML Ports
|
The result will be an Artifact Context instance for each port of the component, as highlighted on the following UML diagram:
Figure 10Artifact Context Selection:UML Model Rendering
In this case, there is a single Artifact Context instance, the port named “solicitationPort”. The Template “wsdl.Template” will be evaluated for each selected Artifact Context instance (in this case one).
[i]
[i]This
material is covered under copyright law.
Copyright © 2009, Data Access Technologies, Inc. for ModelDriven.org as
an unpublished work, all rights reserved worldwide.
This material is licensed for your use for free under the
terms of the GNU public license version 2 which is located at this web address:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.
This material is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software foundation; either version 2 of the License, or (at your option) any
later version. This material is
distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General
Public License at http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt for more details. By downloading, copying or using this material you agree to
this license unless this license has been superseded by a specific agreement
with ModelDriven.org or Data Access Technologies, Inc. If the above license does not meet your needs
you may contact http://www.modeldriven.org for further options.