You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2007/07/12 17:47:39 UTC
Re: [Axis2] Post-1.3 mustUnderstand header validation proposal
AXIS2-2853
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
Re: [Axis2] Post-1.3 mustUnderstand header validation proposal AXIS2-2853
Posted by Jeff Barrett <ba...@us.ibm.com>.
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: barrettj@us.ibm.com
Glen Daniels <gl...@thoughtcraft.com> 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: 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
Re: [Axis2] Post-1.3 mustUnderstand header validation
proposal AXIS2-2853
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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).
> (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?
> (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)
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Post-1.3 mustUnderstand header validation proposal AXIS2-2853
Posted by Jeff Barrett <ba...@us.ibm.com>.
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: barrettj@us.ibm.com
Glen Daniels <gl...@thoughtcraft.com> 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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org