axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
Subject Re: [Axis2] Post-1.3 mustUnderstand header validation proposal AXIS2-2853
Date Thu, 12 Jul 2007 15:47:39 GMT
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?

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>

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?

--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: barrettj@us.ibm.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message