Issue 15: Logical, Virtaul Domain Infoset for External Policy Attachment

[ashok malhotra <ashok.malhotra@oracle.com>]

When we discussed External Policy Attachment at the f2f we came up with 
the idea of a virtual, logical infoset for the domain. The External 
Policy Attachment mechanism would specify the elements with which 
policies and policySets were to be associated by navigating down this 
infoset.

This note is based on a conversation between Michael Rowley and myself. 
The final words are mine
and may not capture faithfully what Michael intended for which I apologize.

The following is a description of how the virtual, logical infoset would 
be constructed for a domain. If we can agree on this, then we can 
specify how External Policy Attachment works over this infoset.

1. The root of the infoset is a composite element that stands in for the 
domain. This composite can have all the attributes of a normal 
composite. The values of the attributes are domain-specific and 
implementation dependent.

(Detail: The constraintingType attribute should not be set)

2. The children of this domain-composite are all the domain-level 
components within the domain. Note that this loses the contribution 
where the components come from. To remedy this we add a new attribute: 
installedFrom="contribution_uri/of/the/deployment/composite"

The infoset will also contain the result of deployment time processing. 
Some detail below:

- The results of autowire processing and explicit <wire> elements will 
both be represented in the infoset as explicit values for the 
appropriate reference/@target attributes.

- Inherited required intents and policySets will be explicitly 
represented on any element that inherits them.

- PolicySets that that are chosen by the policySet selection algorithm 
will be represented as values of @policySet attributes.

- All components will have @uri attributes (not just domain-level 
components), which contain the URI of the component. The URI will 
contain path elements from all of the composites that the component is 
embedded under. This makes it possible to write XPath expressions that 
target a single buried component.

* The following binding processing happens _/after/_ the bindings have 
been moved, as described in (4), (5) and (6) below.

- Explicit binding.sca elements will be present rather than just implied.

- Bindings will all have @uri attributes, whose value is the absolute 
URI that the runtime is using (or possibly multiple URI in the case of 
references).

3. For each <implementation.composite> include all of the contents of 
the named composite as child elements of <implementation.composite>. 
This is done recursively.

This gets us all SCDL elements within the domain. There is, however, a 
requirement to attach policies to interface elements such as "operation" 
and "message". Since the interface is identified in the SCDL by a URI, 
we can use the Document function in XPath to open the file and then 
navigate down it starting from the root element. This is certainly 
possible, but some find it awkward. It also doesn’t allow us to do 
post-processing on the port-type, for things such as inserting policySet 
attributes.

So, we propose an alternate method by which the interface elements are 
included directly within the virtual, logical infoset. This requires a 
bit of work.

4. Remove the <binding> elements from the infoset.

5. Include the contents of the interface file below the appropriate 
<service> or <reference> elements. Note that the WSDL port type that is 
included may need to be generated, based on whatever interface language 
is actually used for the service or reference.

6. Reinstate the <binding> elements that were removed as child elements 
of each <input>, <output> or <error> element of the interface.

The result of the above 3 steps may look like:

<service> or <reference>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput">
<binding ... />
</input>
<output message="tns:GetLastTradePriceOutput">
<binding ... />
</output>
</operation>
</portType>
</service> or </reference>

We will also have to change the @name attribute of the port type to be a 
QName. In WSDL, it is assumed to be a local name for the targetNamespace 
of the WSDL.

-- 
All the best, Ashok & Michael