Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [swordfish-dev] Swordfish and Sopera policy questions
Title: Re: [swordfish-dev] Swordfish and Sopera policy questions
Hi all,

some comments inline.

Regards
    Jerry


On 13.11.09 13:53, "Andrey Kopachevsky" <kopachevsky@xxxxxxxxx> wrote:

We with Sergey have found several difference in Swordfish and Sopera policy trading, that we need to discuss:


  1. Policy trading: if we use Swordfish Registry, policy trading happens during endpoint resolution on consumer side (in ServiceResolver component), but in case with ASF SR we already receive AgreedPolicy inside lookup response.

With ASF, policy trading also happens during provider lookup (== endpoint resolution?). The difference IMO is that with ASF, die policies are kept in a central location (Service Registry), while they have to be distributed to the consumers . I have to confess that I consider the ASF approach more practical from the point of view of an operator.

There is one aspect that we IMO should not adapt from ASF to Swordfish. I did not yet encounter a single case where the  indirection “logical consumer policy name” -> “policy id” via the  configuration was useful.


 2. ASF AgreedPolicy consists of set of policies (for each service operation), for example
 
 
    <Agreed ...>
 
     <Operation name="findReservation">
 
      <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy">
 
       <wsp:ExactlyOne>
 
        <wsp:All>
 
         <sopa:HttpTransport
 
          xmlns:sopa="http://types.sopware.org/qos/SOPAssertions/1.1" />
 
        </wsp:All>
 
       </wsp:ExactlyOne>
 
      </wsp:Policy>
 
     </Operation>
 
 
     <Operation name="createReservation">
 
      <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy">
 
       <wsp:ExactlyOne>
 
        <wsp:All>
 
         <sopa:HttpTransport
 
          xmlns:sopa="http://types.sopware.org/qos/SOPAssertions/1.1" />
 
        </wsp:All>
 
       </wsp:ExactlyOne>
 
      </wsp:Policy>
 
     </Operation>
 
    </Agreed>
 
 
 
 
 for Swordfish we have one policy associated with provider endpoint:
 
 
 
 
 
 
  <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
 
   xmlns:swf="http://www.eclipse.org/swordfish/schemas/policy"
 
   xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
 
   wsu:Id="Compression">
 
   <wsp:ExactlyOne>
 
    <wsp:All>
 
     <swf:Compression optional="true" />
 
    </wsp:All>
 
   </wsp:ExactlyOne>
 
  </wsp:Policy>
 
 
 

So in Swordfish case we don't have association between policy and operation name, like we have in Sopera case, what approach should we use?
 
 
In ASF, we use the participant policies (ppdx) to map policy documents to the individual operations of a policy. That is one way to do this, other ways would be
  • use WS-PolicyAttachment to attach stand-alone policies to individual operations
  • include policies into the wsdl

Each approach has pros and cons. Before I cast my vote I’d like to understand if we’re going to use the existing ASF infrastructure and refine that or try to extend the Swordfish registry.

 
 
 

 3. We don't have mention of message exchange scope (request or response) for Swordfish policy, like in Sopera
 
              <Operation name="findReservation">
                     <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy">
                         <wsp:ExactlyOne>
                             <wsp:All>
                                 <sopa:HttpTransport
                                     xmlns:sopa="http://types.sopware.org/qos/SOPAssertions/1.1" message="request"/>
                             </wsp:All>
                         </wsp:ExactlyOne>
                     </wsp:Policy>
                 </Operation>

This really depends on the semantics of the policy assertion you’re looking at. E.g., it is certainly makes more sense for something like encryption or compression and less sense for transport or message tracking.

Back to the top