axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: [Vote] 1 Msg or 2
Date Fri, 02 Feb 2001 22:02:51 GMT
Since handlers are interchangable (or maybe not) - what happens
if someone wants to use the dispatcherHandler twice in the chain?
Does this cause a problem?  I 'm thinking 'no', as long as the dispatcher
also knows how to merge the two output messages (yuck).

Steve Graham/Raleigh/IBM@IBMUS on 02/02/2001 04:08:11 PM

Please respond to

Subject:  Re: [Vote] 1 Msg or 2

I like the notion of the getActiveMessage() api on

I am not sure of the need for the additional state variable

I would prefer the message flow to act something like:
1) message received by transport layer, message is placed in the
MessageContext in the "input message" property.
2) AxisEngine.invoke() sets the value of the "active message"
property of the MessageContext to point to the value of the
"input message" property
3) pre-Handlers are invoked
4) Things may "pivot" when a dispatcher is invoked.
   - Part of dispatcher.invoke() is to send the "active message
     on to the next application (eg intermediary forwards,
     final destination invokes the actual web service, etc.)
   - The "kind" of dispatcher will know to block or not block
     and know if there is anything to expect coming back.
   - If there is a response message, the dispatcher would set
     that message as the value of the "output message" property
     and set the "active message" property to point to it.
5) post-Handlers are invoked.

I would prefer that the switching behavior be done in the
dispatcher, not the targetted chain container.  If we isolate
the switching behavior here, then a dispatcher within
a single chain will exhibit the similar correct behavior.



Steve Graham
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies

Doug Davis/Raleigh/IBM@IBMUS on 02/02/2001 02:02:16 PM

Please respond to

Subject:  Re: [Vote] 1 Msg or 2

Don't disagree with the code you're proposing for targeted chains,
but we need to also figure out a way to do it for chains that don't
have a handler labeled a "pivot point" but I guess we can decide on
that one later and take the easier case first.

Jacek Kopecky <> on 02/02/2001 08:33:13 AM

Please respond to

Subject:  Re: [Vote] 1 Msg or 2

+1 on two messages (I agree with Glen's comment).

I disagree with having getMessage() only and switching. I propose
three methods on the messageContext:

and also


Property 'incoming' controls which message is returned from
getActiveMessage(). Thus we incorporate switching as an add-on that
doesn't block the non-switching behavior.

Let's give the responsibility of switching to the TargettedChain, and
let's switch right after the pivot handler invocation.

If I don't hear any disagreement I'll commit code to do this and I'll
also simplify the LogHandler for this change on Sunday.

                            Jacek Kopecky

On Fri, 2 Feb 2001, Yuhichi Nakamura wrote:

 > -1
 > I still not sure whether the single API is adequate because this
 > excludes other patterns such as public/subscribe.  However,
 > at this moment, let me accept the single API.
 > I think the concept of the single API is that we do not
 > distinguish "forwarder" and "pivot" handlers at the API level
 > although each handler has to know which he/she is (I hope that
 > forwader/pivot are proper terms).     This point was
 > clearly mentioned by Jacek, and I suppose this hypothesis.
 > If we do not distinguish handlers, why do we need to
 > distinguish request/response messages in MessageContext.
 > A message is just updated by the handler.  I guess there is
 > some contradiction here.  In terms of the different API,
 > request/response are distinguished.
 > Another practical issue is how to get messages from MessageContext.
 > Dug's MessageContext has getIncomingMessage, etc.
 > My's MessageContext has getMessage.
 > Many forwarder handlers prefer the latter such Digital Signature
 > Logging handler, etc.  If MessageContext has two messages and provides
 > getMessage(), we need a switch (request/reseponse switch :-).
 > A reference implementation of MessageContext is found in TRL proposal
 > directory in axis-cvs.  The implementation is extremly simple.
 > Regards,
 > Yuhichi Nakamura
 > IBM Tokyo Research Laboratory
 > Tel: +81-46-215-4668
 > Fax: +81-46-215-7413
 > From: "Doug Davis" <> on 2001/02/01 23:37
 > Please respond to
 > To:
 > cc:
 > Subject:  [Vote] 1 Msg or 2
 > To help move things along, I'd like to propose that
 > we VOTE on one of the smaller open issues - one message
 > or two in the MessageContext.
 > I propose that we have two messages, an incoming and
 > an outgoing (or an request and a response - we can
 > work on the words after the vote).  From the e-mails
 > I think that's where most (not all) people are but
 > I'd like to have a formal vote to try to bring this to
 > a close.  Committers, if you vote -1 please give a
 > details list of reasons why one message would be better
 > in an effort to sway us to your side.  Likewise, if you
 > vote +1 and can think of reasons why one message just
 > won't cut it please let us know of those too.
 > -Dug

View raw message