RE: [sca-policy] Issue 15: Logical, Virtaul Domain Infoset for ExternalPolicy Attachment

[Mike Edwards <mike_edwards@uk.ibm.com>]

Michael,

The thing that brought me up short with
the proposal is that the logical infoset is *SO* far from the 
structure of the entities that we expect
assemblers to work with.  When an assembler looks at a
composite file there are *NO* "input"
or "output" elements in the structure at all, let alone at the
points implied by the logical infoset
that you propose.

For me, the leap from the actual infoset
to the logical one is across a great chasm which I think
is going to fox most people.

OK, you rightly lay down the gauntlet
"come up with a better alternative" - that will take time &
thought.
However, I think I am justified in pointing
out the almighty blemish in the current proposal and I urge
us to seek something better.


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

"Michael Rowley" <mrowley@bea.com>

12/02/2008 14:27

To	"Michael Rowley" <mrowley@bea.com>, Mike Edwards/UK/IBM@IBMGB, <sca-policy@lists.oasis-open.org>
cc
Subject	RE: [sca-policy] Issue 15: Logical, Virtaul Domain Infoset for External Policy Attachment

I want to reiterate something
I said near the end of yesterday’s call, that there are some key use cases
that we should concentrate on making simple.  Here are a few:
 
1) All inbound traffic on binding.ws
should use this authentication policy
 
      //input/binding.ws
 
2) Outgoing “requisition”
messages should be signed using this policy, when binding.ws is used
 
     //output[@message=”tns:RequitionMessage”]/binding.ws
 
3) This authorization policy
should be used for this specific component service (which is a web service):
 
    //binding.ws[@uri=’http://acme.com/mydomain/component/service’]
 
 
I’d certainly be interested
in seeing alternate proposals for the logical infoset used for policy attachment,
but I’ll be looking to see if these and other use cases are equally easy
in any alternate proposal.
 
Michael

---

From: Michael Rowley [mailto:mrowley@bea.com]
Sent: Friday, February 08, 2008 9:47 AM
To: Mike Edwards; sca-policy@lists.oasis-open.org
Subject: RE: [sca-policy] Issue 15: Logical, Virtaul Domain Infoset
for External Policy Attachment
 
 
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

---

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