[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Issue 15: Logical, Virtaul Domain Infoset for ExternalPolicy Attachment
Thanks for writing this down Ashok.
I put it all in a Word doc so that I could comment until I ran out of time
to work on it.
(See attached file: Issue15_DomainInfosetDescription.doc)
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
ashok malhotra
<ashok.malhotra@o
racle.com> To
OASIS Policy
02/06/2008 01:17 <sca-policy@lists.oasis-open.org>
PM cc
Subject
Please respond to [sca-policy] Issue 15: Logical,
ashok.malhotra@or Virtaul Domain Infoset for External
acle.com Policy Attachment
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Issue15_DomainInfosetDescription.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]