tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Date Wed, 06 Feb 2008 00:24:36 GMT
 >> Jean-Sebastien Delfino wrote:
>> Reading the composite file / building its model / re-writing it to
>> finally apply the xpath sounds very complicated.
>>
>> As an application developer I'll write the appliesTo xpath to match what
>> I see in a composite XML file. Why can't we simply run the xpath on that
>> original XML file before doing all the other steps?
>>
> Venkata Krishnan wrote:
> 
> We will not be writing the entire composite, but only a fragment that is the
> parent of the intentAttachPoint.  Here is what the spec says : -
> 
> 283 ..................................................Note that the XPath
> expression will always be evaluated
> 284 within the context of an attachment considering elements where binding
> instances or
> 285 implementations are allowed to be present. The expression is evaluated
> against the parent element
> 286 of any binding or implementation element.
> ..........................................................
> 
> But then, it seems like we may have to look beyond the immediate parent or
> maybe the entire composite if your proposal is to be taken. 

Yes, but it's not incompatible. Here are some examples:
appliesTo="binding.ws"
appliesTo="service[@name='AccountService']"
appliesTo="../component[@name='AccountServiceComponent']"
appliesTo="/composite[@name='bigbank']/component[@name='AccountServiceComponent']"

By default you are in the parent of a binding or implementation, but can 
use .. or / to go up.

>  I'd like to hear some perspectives from the specs folks on this.
 >
> Now, getting to your question more specifically on why this must be done
> post-build phase, here it is....
> -  Firstly we need the PolicySet definitions to get hold of the
> 'appliesTo'.
> -  For PolicySets that are specified in the composite, they are resolved
> during the resolution phase.
> -  For those that have to be calculated based on the Intents specified,
> there needs to be a complete assembly model that is wired, since we also
> need to take into account the target's intents.  This wiring is being done
> on the 'wireComposite' method of the CompositeWireBuilder.
> -  So the calculation of PolicySets is pushed to this point i.e. its being
> done as part of the 'wireComposite' method, the moment the model has all its
> connections resolved.
> -  Only after the PolicySets are calculated, do we have a handle on the
> 'appliesTo' attribute of the PolicySets.
> 

How about this:
load the definitions.xml files declaring policySets.
for each policyset
   prepend /*/*/ to its appliesTo xpath
   for each composite XML file
     run the xpath expression against the file
     for each matching element
       add the policySet to an imaginary "applicablePolicySets" attribute
     end
   end
end

Then later when you run the composite processors, builders etc, use the 
intents + policySets + applicablePolicySets attributes to figure the 
effective policySets.

This should provide the best of both worlds:
- xpath expressions evaluated against the real authored XML artifacts
- support for the intent/policySet matching algorithm from the spec

Makes sense?
-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message