tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Venkata Krishnan" <for.svkr...@gmail.com>
Subject Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Date Wed, 23 Jan 2008 07:52:52 GMT
Hi,

I have changed this now to put the computed intents back into the
binding/implementation instance.  So the bindings and implementations can
now parse the intents and filter the mayProvided ones and take appropriate
actions.   I'm trying to see if I can get this demonstrated on our axis2
binding.

I've also made some changes to now get the bindingType and
implementationType definitions in order.  Here is how things should work
from now on : -
  - every binding and implementation type has a definitions.xml file in the
META-INF/services directory in which will be defined a bindingType or
implementationType element that contains all the intents mayProvided and
alwaysProvided by the binding / implementation type.
- ever binding / implementation instance will have reference to this
corresponding type bindingType or implementationType definition.

All this under r614447.

Thanks

- Venkat




On Jan 16, 2008 12:52 AM, Greg Dritschler <greg.dritschler@gmail.com> wrote:

> I agree that intents that are listed in mayProvide do not require a policy
> set.  The binding/implementation provides the functionality of the intent
> if
> the intent is present on the relevant composite element.  It looks to me
> that CompositeWireBuilderImpl, as part of the process of trying to find
> matching policy sets, removes intents that are found in mayProvide from
> the
> model object.  In that case, how would the binding/implementation know it
> should provide the intent functionality if the intent isn't present in the
> model anymore?
>
> Greg Dritschler
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message