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: [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]
