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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
