Hi Glen, Thanks for the comments! My thoughts 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/12/2007 10:47:39 AM: > Hi Jeff: > > Thanks for the proposal. A couple of comments: > > First and foremost - this approach seems far too heavyweight to me. It > feels a lot simpler and more natural to simply register understood > QNames with AxisOperation/AxisService, much as you were doing before. > Why is the validator technique better? A few reasons why I think the pluggable validator technicque is better: (1) Several folks asked for it to be made pluggable :-) (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. (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. > > Second, re: actors/roles. As I mentioned before, we already have a > mechanism to iterate through only the headers that are for the roles > we're playing. By default we process only those headers for the > ultimate destination and the "next" roles. All you need to do to change > that is create an org.apache.axiom.soap.RolePlayer object which returns > the supported "non-standard" roles and answers whether or not it is the > ultimate destination. What we need to do is provide an API/config > 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 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. 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. > So in short, I'd vastly prefer a simple QName registration API rather > than callouts to new components, and I think we need to finish designing > the actor/role configuration. > > Thoughts? 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. > > --Glen > > Jeff Barrett wrote: > > Goals > > ===== > > > > 1. Pluggable and extensible via configuration. Allow higher-level, > > non-engine components to participate in mustUnderstand validation. > > Examples include JAX-WS runtime and appliction handlers, WS-RM, and > > systems using Axis2 as a bus. > > > > 2. Support for actors/roles. Only mustUnderstand headers for > > actors/roles in which this node acts should be checked. Note that > > actors/roles would not be implemented immediately, but future support is > > taken into consideration in the design. > > > > OVERVIEW > > ======== > > > > A list of soapHeaderValidators can optionally be configured in axis2.xml. > > The list of validators will be stored on the AxisConfiguration. Each > > validator has a method which takes a collection of not-yet-understood > > header QNames, a collection of String roles, and a MessageContext. The > > method will return a collection of header QNames based on the input > > parameter which are still not understood; that is, it removes any that it > > understands from the list. > > > > The AxisEngine.checkMustUnderstand() method will invoke each validator, > > passing in the collection of still-not-understood headers. If, after all > > the validators are called the collection is not empty, a mustUnderstand > > fault is thrown. The logic would be something like: > > > > String[] rolesActedIn = ... // list of actors/roles > > acted in. > > QName[] notUnderstoodHeaders = ... // list of all mU headers > > not marked as processed > > SOAPHeaderValidator[] validators = > > axisConfig.getSoapHeaderValidators(); > > for (SOAPHeaderValidator validator : validators) { > > notUnderstoodHeaders = > > validator.validate(notUnderstoodHeaders, rolesActedIn, messageContext) > > } > > > > // If there are any not-understood headers after running the > > validators > > // throw an exception > > if (notUnderstoodHeader.length != 0) { > > throw notUnderstoodException > > } > > > > There is no API for the registration of understood headers; each validator > > > > is responsible for deciding what it understands and removing it from the > > collection. For example, the JAXWS validator would look for a property > > (which it set earlier) on the AxisOperation containing the QNames for any > > JAXWS SEI header parameters and any headers understood by JAXWS > > application handlers. That property would be set by JAXWS on the > > AxisOperation during application startup. > > > > Configuration in axis2.xml > > -------------------------- > > > > The <soapHeaderValidators> element is optional. If ommited then all > > mustUnderstand headers must be marked as processed by handlers, or a > > mustUnderstand fault will be thown (i.e. current > > AxisEngine.checkMustUnderstand semantics are unchanged) > > > > <soapHeaderValidators> > > > > <soapHeaderValidator>org.apache.axis2.jaxws. > JAXWSSoapHeaderValidator</soapHeaderValidator> > > > > <soapHeaderValidator>my.other.validator. > MySOAPHeaderValidator</soapHeaderValidator> > > </soapHeaderValidators> > > > > > > > > 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] > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
