axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject MU use-case
Date Fri, 01 Jun 2001 12:03:41 GMT
One possible mustUnderstand use-case we need to make
sure we support is the case where there's an MU header
that isn't processed on the request/input chain but
rather on the response/output chain.  What this means
is that our soap-semantic checker that makes sure all
MUs are understood (before we exec the service) needs
to take into account that not all MUs have been processed
yet even though they *are* understood.

The example I'm thinking of here is the case where we
have an EMail header that is supposed make the server
send back the response in an e-mail message as well as
the normal way.  This would go on the response side of
the chain.

So, I see a couple of ways of supporting this:
1 - require 2 handlers, where the 1st is placed on the
    request side of the chains and just sets an
    "understood" flag.  The 2nd on is on the response
    side and does the real work.
2 - require a new method in handlers, "canUnderstand",
    or something like that and each handler in the chain
    is called until we get the flag set - problem with this
    is that we might not know the entire chain till later
    and the performance will suck.
3 - require all headers to register which thing they are
    interested in (in advance) - problem with this is that
    someone could register interest in "everything" and not
    one particular header - but then that could be their
    problem/user-error.  Plus, again, we might not know the
    entire chain till later.
4 - Require the handler writer to have logic in his 'invoke'
    method to check to see if he's in the request or response
    side of the chain and do the 'understood' check on the
    request, and 'real' work on the response side.  Similar
    to #1 but it's all one handler, but the same handler would
    then need to be places in the chain twice.

For 2 and 3, not knowing the entire chain might not be that
bad - we can just use whatever handlers we have so far.

I'm leaning more towards #4, but I do like 3.  If we come up
with a reason for handlers to register themselves (like if we
change our parsing model) then I'd go with 3, but if we keep
things the way they are now, #4 might be the easiest way to
solve this.


View raw message