Hi Glen. I don't think the mustUnderstand checkers have the same semantics as an engine handler, so they shouldn't be implemented as one. A handler processes the message. A mustUnderstand checker doesn't process the message and so it shouldn't modify the message state; another component outside the handler chain (e.g. MessageReceiver, Application Handler, etc) will process those parts message.
We need to get this resolved ASAP because this affects compliants tests. Could we please chat about this on Yahoo IM or on IRC today if you still have concerns? Detailed comments inline below. Thanks, Jeff IBM Software Group - WebSphere Web Services Development Phone: 512-838-4587 or Tie Line 678-4587 Internet e-mail and Sametime ID: [EMAIL PROTECTED] Glen Daniels <[EMAIL PROTECTED]> wrote on 07/16/2007 07:31:22 PM: > Hi Jeff: > > > (1) Several folks asked for it to be made pluggable :-) > > Pluggable for pluggable's sake, or for some architectural reason? We > already *have* a plugin architecture for components that process the > message, they're called Handlers. :) If you want to refactor the > "processed" flag and change it to "understood" I'd be OK with that (so > it doesn't seem weird for Handlers to set it without doing anything else > - although I also think that's fine with "processed"), but I don't > really want Yet Another Component Plugin API (YACPA). Architectural reasons. Handlers process messages; the new checker plugin has a different semantic than that. The checkers do not process the message, they indicate something later on (like a Message Receiver) will. I think marking a header as processed should only be done when the header is processed, and I think the "processed" flag should remain as-is. I think the new checkers should not change the state of the message since they are not affecting a change on the message. > > > (2) It encapsulates the semantics of mustUnderstand validation outside the > > engine. For example, the JAXWS header param validation is odd in that a > > header is considered understood if any SEI method has it as a parameter, > > not just the SEI method corresponding to the incoming operation. Other > > validators may only want to consider the current operation. While those > > two semantics could be accomplished via a registration API on both > > AxisService and AxisOperation, that seems somewhat convoluted and > > confusing. > > Really? I didn't think so, and I like the declarative approach which > avoids a lot of callouts for the simple case where a given operation > always understands particular headers. I understand the desire for a > more dynamic solution, but again, I don't think this particular issue > warrants YACPA. > > If you want a dynamic solution, just use Handlers. I think adding a > more declarative solution would also be a good thing for the simple > static "this service handles this QName" case. Once you've got both of > those, you're set, no? I don't think the handler approach is appropriate here. In this case, the header isn't actually processed, so it shouldn't be marked as such (as noted above). The checker's are just removing elements from a list of headers that will be verfied against mustUnderstand requirements; they are not affecting the state of the message; they leave that to the component (MessageReceiver, ApplicationHandler, etc) which actually processes the message. BTW, The simple case here is where there are no checkers configured and handlers have already processed all the headers which will be validated. There would be no callouts in that case and mustUnderstand validation occurs in the engine exactly as is done today. The problem with a delcarative approach is that it doesn't address all the scenarios because the list of QNames may not be known in advance (as noted below). > > > (3) It supports a scenario where the full list of understood headers isn't > > known in advance. For example, if Axis2 is being used as a bus for a > > higher level engine (I think David Illsley suggested an ESB in an eariler > > mail), it allows that bus-engine to plug in a validator that says it > > understand all the remaining headers, and then actually check them later > > within its own context. > > I'll just say here that this can also be done just fine with a Handler. > (If I was being verbose, I'd discuss what a bad idea just claiming to > understand everything is... a SOAP engine's purpose in life, IMO, is > precisely to implement the SOAP processing model, not ignore it) I disagree. Again, the handlers would have to mark the header as processed (which it wasn't), and I don't think it is right for the checker semantic to change the state of the header. > > On to roles... > > >> mechanism for setting up roles. I'd propose something like an > >> addRole(String) API on AxisConfiguration and AxisService, and also > >> perhaps a setUltimateDestination(boolean) in those same places to enable > > > >> intermediary services that do NOT process ultimate destination > >> headers. AxisModule would want addRole() as well, and the code that > >> constructs the RolePlayer would need to take into account the roles for > >> any engaged Modules. The equivalent config in either axis2.xml or > >> services.xml would be something like: > >> > >> <isUltimateDestination>false</isUltimateDestination> > >> <roles> > >> <role>http://my-funky-role</role> > >> </roles> > >> > > > > Thanks for pointing out the RolePlayer object. I now understand better > > Sanjiva's comment on not passing roles to the validators. Perhaps if a > > higher level component is going to claim to act in a role, that should be > > registered with the engine. However, if that's true, the roles can't be > > configured soley by an XML file. They need to be dynamically > > Sure - I was simply noting that there is a use case for XML configurable > role management, not saying that it should be the only way to do it. > > Basically the really important thing is that the MessageContext knows > which are the "active" roles at any given time. Then when the > AxisService and AxisOperation are dispatched, that list can be modified. > That list could also be modified by Handlers. Something like > > public class RoleManager implements RolePlayer { > public void addRole(String uri) { ... } > } > > MessageContext { > public RoleManager getRoleManager() > } > > Then anyone could msgContext.getRoleManager().addRole(myRole). > > The engine would then simply use that RoleManager when getting the > headers from Axiom. > > > configurable. One example why is that a JAXWS application handler > > specified in an endpoint's @HandlerChain annotation, which isn't known > > until the app is deployed, can specify roles it acts in. Additionally, a > > client-side JAXWS application handler chain can be dynamically configured > > at runtime via setHandlerRegistry (or something like that), which again > > can affect the roles being acted in. > > Yup, I think a MessageContext API with some support for "statically" > configured stuff in AxisService/AxisOperation would work fine here. > > > Initially, only support for NEXT and ULTIMATE RECEVIER is needed, and you > > say that's already in RolePlayer. That's good news because it fixes one > > of the problebms we saw in compliance tests. > > Hm, this should already have been working for a while... do you have a > test that's failing with the current HEAD? > > > Even though I originally wrote the code with a QName registration API, it > > didn't solve all the problems we encounterd such as (2) and (3) above. As > > I thought about it more, I came to agree that the pluggable model is a > > better approach since, without any plugins, the semantics of the engine > > remain unchanged, and with plugins I think we can solve all the scenarios > > brought up on the list. > > In summary: > > * Please don't make YACPA unless we *really* need it. I don't think we > do for these cases. Are handlers really not good enough? > > * A combination of configured stuff in AxisService/AxisOperation and > simple APIs on MessageContext can solve both the understood headers and > the roles problems with our current components. I'm more than happy to > help flesh this out. > > Comments/thoughts very much appreciated. > > Thanks, > --Glen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
