Hi, To update, I have split the bigbank into bigbank and bigbank-account to show the distribution of policies across contributions. I just about have trouble with the things that need to be imported / exported across these two. I'd prob. need Luciano's help to get over this.
The other thing I have started to do is the 'alwaysApplicablePolicySets' that was suggested. There weren't to many things to do for this and I am right now trying to find a way to test this in the itest-policy. - Venkat On Thu, Feb 21, 2008 at 11:35 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Hi Sebastien, > > Thanks for looking it up and providing opinions. All of them sound good > to me and I will get onto them after am done with some things am fixing with > policy annotations and an iTest for policy. > > Just the one thing about the PasswordCallBackHandler. It only meant to > domonstrate that its a gateway to your user registries. Agreed that this > might be taken very literally by some users. So, do you suggest that I > interface with some user registry in the CallBackHandlers ? If so can a > simple Hashmap based user registry do or would you like some LDAP based user > registry integration here? > > Thanks. > > > - Venkat > > > On Wed, Feb 20, 2008 at 6:38 AM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > > > Venkata Krishnan wrote: > > > Hi Sebastien, > > > > > > I have made the changes to the secure-bigbank demo. Let me know if > > there is > > > something that looks odd and not practical in a real world scenario. > > > Thanks. > > > > > > > I'm starting to like it :) I have a few more suggestions: > > > > - Merge it into the main bigbank scenario. > > - Place definitions.xml files in different contributions to show that > > policies can be configured externally. > > > > > > - Remove the CallbackHandlers as hardcoding a password in a piece of > > code in the contribution is not what I'd call practical :) > > > > Another suggestion to make policies easier to use: Support external > > attachment of a PolicySet to a composite element independent of the > > presence of intents. > > > > Here are some use cases: > > - configure confidentiality at deployment time, without having to go > > back and change the application composite to add intents or policySets. > > > > - configure the number of HTTP connections on a reference [1], over time > > when traffic increases, again with no change to the composite. > > > > External policy attachment is starting to be discussed in the OASIS > > policy spec workgroup [2], but I was thinking that we could start simple > > with just an additional attribute on PolicySet for now, like this: > > > > <policySet alwaysAppliesTo="xpath" ...> > > <!-- typical policySet configuration here --> > > /policySet> > > > > The policySet would be applied to the composite elements matching the > > xpath in alwaysAppliesTo, independent of the presence or not of any > > intents. > > > > Thoughts? > > > > [1] http://marc.info/?l=tuscany-user&m=120051348720777 > > [2] http://www.osoa.org/jira/browse/POLICY-15 > > -- > > Jean-Sebastien > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
