Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Importance: Normal
Subject: Merging Messages (Was: [Vote] 1 Msg or 2)
To: axis-dev@xml.apache.org
Message-ID: <OF4484EFAB.1213E531-ON852569E7.00799845@raleigh.ibm.com>
From: "Steve Graham" <sggraham@us.ibm.com>
Date: Fri, 2 Feb 2001 17:16:57 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

I think any merge behavior would have to happen by explicit action, not
default behavior.
Dispatchers should by default overwrite the properties.

So we have a chain with D1 and D2 on it.

D1 does its thing, and puts an output message into context.

D2 is invoked with output message property already set in the message
context.
Then the result of the dispatcher's invocation of the, say target web
service, replaces
the previous message.

The semantics of how to merge the two messages is well beyond anything we
should
do in Axis.

If for some strange semantic, a deployment engineer needs to do this, then
he should
set up a couple of additional handlers in his chain

D1 CH D2 MH

Where CH (cache handler) is real simple and simply caches the current
output message
in some application-specific property.  Note also that there is a good
chance that CH may
also need to reset the input message to be the output message of D1, if the
deployment
expects D2 to essentially act on the output of D1.

MH (merge handler) is responsible for doing some really application
specific merge
of the current output message (the one produced by D2) and the output
message
from D1 that was cached by CH.

sgg
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies
++++++++


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

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

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


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).
-Dug

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

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

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


Jacek:
I like the notion of the getActiveMessage() api on
MessageContext.

I am not sure of the need for the additional state variable
isIncoming().

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.

thoughts?

sgg

++++++++
Steve Graham
sggraham@us.ibm.com
(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 axis-dev@xml.apache.org

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

Jacek Kopecky <jacek@idoox.com> on 02/02/2001 08:33:13 AM

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

To:   axis-dev@xml.apache.org
cc:
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:
getIncomingMessage()
getOutgoingMessage()
getActiveMessage()

and also

isIncoming()
setIncoming(boolean)

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
                               Idoox


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
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
 >
 >
 >
 >