axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <NAKAM...@jp.ibm.com>
Subject Re: [Vote] 1 Msg or 2
Date Sat, 03 Feb 2001 14:45:37 GMT

Dug,
Are we talking about tehcnical reasons?  I think that we are talking about
a concept of MessageContext.  From techincal point of view,
what we can do with two approaches are equivalent.  In that sense,
2 message approach is NOT wrong.  Maybe I am asking what concept
we have, and how the concept is expressed as API.  The concept
here is that handlers simply consume a message and create a new
message (I do not agree, but you have claimed in this way to
justify the single API).  There is no incoming/outgoing distinction
here.  I want to know how you introduce the distinction to the
single API.  If you introduce such distinction, why don't you
consider the different API?

Regards,

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


From: "Doug Davis" <dug@us.ibm.com> on 2001/02/03 12:38

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: [Vote] 1 Msg or 2



In the single message case you're assuming that each
handler will just update the message passing through the chain,
right?  Couldn't the handlers simply create a new message
instead of modifying the current one?  Is there a technical reason
why this would be wrong?  When I read your comments I
understand everything you wrote, but what I think is missing
is the technical reason why having 2 messages  is wrong -
or is it that 2 will work but you prefer 1 message?
-Dug


"Yuhichi Nakamura" <NAKAMURY@jp.ibm.com> on 02/01/2001 09:41:53 PM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: [Vote] 1 Msg or 2




-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 Handler,
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" <dug@us.ibm.com> on 2001/02/01 23:37

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
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










Mime
View raw message