axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: MU use-case
Date Fri, 01 Jun 2001 14:18:52 GMT
Ah, thanks - forgot completely about that API that's already

"Glen Daniels" <> on 06/01/2001 09:46:58 AM

Please respond to

To:   <>
Subject:  Re: MU use-case

As you point out, #4 is really just an implementation pattern for #1, which
think is fine.

The basic idea we're then putting forth is "get all your header processing
BEFORE your actual service handler runs", which I like.

Incidentally, we do already have the Handler.canHandleBlock(QName) API, and
formerly had "QName [] blocksHandled", which is very similar to
I recall having some discussion in which we ended up removing that latter
method, but if we end up going more in the streaming direction we may well
it again.


----- Original Message -----
From: "Doug Davis" <>
To: <>
Sent: Friday, June 01, 2001 8:03 AM
Subject: MU use-case

> 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.
> others?
> 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.
> thoughts?
> -Dug

View raw message