axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Graham" <>
Subject Re: [Vote] 1 Msg or 2
Date Sun, 04 Feb 2001 01:24:12 GMT
When I wrote up the (long) scenario, I realized that input message and
output message were relative to the final destination soap application.

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

"Yuhichi Nakamura" <> on 02/03/2001 10:02:39 AM

Please respond to

Subject:  Re: [Vote] 1 Msg or 2

You said that there is no difference between pivot and forwarder
handlers.  When I follow your claim, I do not know when you
introduce the incoming/outgoing distinction.  If you distinguish
pivot and forwarder handlers, then incoming/outgoing
are properly distinguished.

Re: Who is reponsible for switching?
I agree with Steve.  Pivot should do.

If we could not reach agreement, your API is acceptable to me.
As I mentioned in another mail, which is incoming message in


Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413

From: Jacek Kopecky <> on 2001/02/02 22:33

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