That’s funny – I had the
opposite reaction about the move to Word. Threads of questions and their answers
are really hard to managed using comments in Word. Unfortunately, Word doesn’t
allow you to use cut & paste out of a comment, so I can’t think of an
easy way to move these questions back into the body of the email.
I’ve attempted to answer the
questions by including the answers in the body of the document, prefixed with
the number of the comment with the question.
Michael
From: Mike
Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Friday, February 08, 2008
7:22 AM
To:
sca-policy@lists.oasis-open.org
Subject: Re: [sca-policy] Issue
15: Logical, Virtaul Domain Infoset for External Policy Attachment
Folks,
Thanks
to Dave for putting this into a Word doc - Word may do many things poorly, but
its commenting and
change
tracking is the bees knees.
Here
are my comments added in - and they are not favourable to some of the ideas:
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley
Park, Mail Point 146, Winchester, SO21
2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
David Booz
<booz@us.ibm.com>
06/02/2008 20:03
|
To
|
sca-policy@lists.oasis-open.org
|
cc
|
|
Subject
|
Re: [sca-policy] Issue 15: Logical, Virtaul
Domain Infoset for External Policy 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
[attachment
"Issue15_DomainInfosetDescription.doc" deleted by Mike
Edwards/UK/IBM] ---------------------------------------------------------------------
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
Unless stated
otherwise above:
IBM United Kingdom Limited - Registered in England
and Wales
with number 741598.
Registered office: PO Box 41,
North Harbour, Portsmouth, Hampshire PO6 3AU