-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone,
Let me explain bit more on the suggested model for policy processing. The central point of control in AxisDescription. This is how it works. When you call axisDescription.applyPolicy(Policy) first it will get a registry of namespaces to modules from the AxisConfiguration. One can get the modules responsible for processing an domain specific assertion based on the namespace of that assertion. For instance if you lookup the WSSecurityPolicy namespace in that registry it will return the Rampart module. As the first phase of the policy processing, any alternatives with domain specific assertions that can not be mapped to a module for processing, will be removed. As the second phase, each module will be asked to evaluate the selected alternatives. Then module is supposed to remove any alternatives which contains assertions that can be processed by the module but can not be supported due to some reason. For instance if there is an alternative which contains at least WSSecurityPolicy assertions which can not be supported by the security module, then that alternative should be removed by the security module. The end result would be few alternatives that can be supported by the system. Now we can pick an arbitrary alternative from the bunch we got and ask the modules to load their configurations by calling something like module.applyPolicy(..). Best, Sanka Brian Hulse wrote: > I understand what you're saying, but there's a processing overhead > here. In your model, each module will winnow out the alternatives it > cannot support and pass on the result to the next. The problem with > this is that each will have to do an exhaustive search throughout > the whole policy tree, including, as you say, a complete match on > what could be very complex WS-SecurityPolicy assertions. This isn't > necessary, we only want a single supported alternative, we don't > need to process everything to get this. In addition, I was being > circumspect when I stated registration of QNames ... this is a first > stage pass of the winnow process, which is high level and easy to > do. After that, a higher level processing unit (higher than the > modules) would need to examine each alternative and ask each module > about its support statement on the assertions in its domain. This > two stage approach is what our code does and in doing so, stops when > a suitable alternative is found, rather than the exhaustive approach > you suggest. I understand that in small policies, with no or simple > choice, there is very little difference, but in the larger, more > complex cases, this will matter. > > It should also be stated that there is still the possibility with > your model of a bad choice. If the model you choose is that domain A > just removes all alternatives it cannot support, and it leaves 2 > alternatives ... which does it use? It could select one that some > other domain could not support ... when in fact there is an > alternative which could pass everyone's tests. In this respect, you > have to have some central point of control, a Policy Decision Point, > and it can't be farmed out to the domains. Am I just confusing the > issue? > > Brian. > > > On 6/27/06, *Sanjiva Weerawarana* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > On Mon, 2006-06-26 at 12:11 +0100, Brian Hulse wrote: > > I'm all in favour of this "validation" phase, although I'm not > that > > convinced about the implementation. Firstly, there's the > naming ... > > what you propose is a method called "validate", but then intend to > > remove unsupported Alternatives. If we must have this model (I > propose > > a different one below), it should be called something like > > calculateSupportedPolicy(), or some such. > > +1. > > > However, there's still a problem with this model, which exists > in the > > way that Neethi is used in Axis2 too. What we are assuming > with your > > proposed model is that each domain (module) is in charge of > all the > > facts to make a decision ... they are not. Certainly, in the > examples > > of Policies I have seen in the examples used so far, the > problem is > > not revealed, but it exists nonetheless. Consider a Policy > with mixed > > domain choice: > > > > <ExactlyOne> > > <All><A1 /> <B1 /> </All> > > <All><A2 /> <B2 /> </All> > > <All><A3 /> <B3 /> </All> > > </ExactlyOne> > > > > Suppose domain A decides it can't do A1, but can do A2, so > goes for > > the second option. However, domain B can only do B3 so it goes > for the > > third choice ... so we have A2 and B3 ... not an option ... we've > > broken the Policy. The point is, the selection of a Policy > Alternative > > must be made at a higher level, and that choice communicated > to the > > modules (domains). With this in mind, it would be a much > better model > > if the modules declared which Assertions were supported and > let Neethi > > make the decision based on the information ... feeding the > correct > > Alternative to all interested parties. > > I disagree. > > If domain A decides it can't do A1 not A2 or A3, then the first > option > is the only viable path from A's perspective .. so its going to > throw > out the other two alternatives. When the new policy comes to B, > it'll > only see B2 and say "nope, can't do" and the right decision is made: > there's no policy that both domains A & B can live with. > > In general, just declaring the assertion QNames that a module > can handle > isn't enough to decide that a module can handle the actual value > of the > assertion. We do have a way for the modules to define what policy > assertions it handles, but you still must ask the modules > whether it can > handle the specific assertion because the value (e.g., the specific > signature algorithm) may not be acceptable. > > So you have to go down to each module and ask it whether there's an > acceptable alternative in the policy alternatives that are > listed in the > policy that Neethi has computed. > > Sanjiva. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEogzS/Hd0ETKdgNIRAoCZAJ9qrbmuVVJ2rdWmiuYkNEQbFmdXkwCdF1sz XQrTuR5X+Py9jdbraH75dAA= =bp1G -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
