axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reitzel, Charlie" <>
Subject RE: flow naming (vote please)
Date Tue, 27 Feb 2001 23:39:06 GMT
Sorry a bit late on this thread.  To my mind, both pieces of information
seem relevant: send/recv and request/response.  This gives you 4 chain

      SOAP Client		SOAP Server
t1)	Request.send()
t2)				Request.recv()
t3)			 	Response.send()
t4)	Reponse.recv()

It seems like error handling, in particular, would be different at each

It also seems to derive well from a generalized message, which can send()
and recv().  Where Request/Response are specific sub-types of message.  The
codec applies at the generic message send()/recv() level, right?

Configuration of intermediaries should account for both facets, I'd think.
You might want to inject a logging service into the request.recv() and
response.send() chains.  A digital signer into the request.send() chain and
a digital signature verifier into the request.recv() chain.  And so on...

A handler can have accessors to verify at runtime which chains it knows how
to participate in.  isRequestReceiver(), isResponseSender(), etc.  Of
course, the chains themselves are built according to the configuration

take it easy,
Charles Reitzel

-----Original Message-----
From: Glen Daniels []
Sent: Tuesday, February 20, 2001 9:20 PM
Subject: Re: flow naming (vote please)

Although it's a bit superfluous now, +1.  I wrote my old prototype this way
(req/resp) as well.


----- Original Message -----
From: "Steve Graham" <>
To: <>
Sent: Tuesday, February 20, 2001 2:45 PM
Subject: flow naming (vote please)

> A question related to flow naming.  Currently we have the notion of input
> chain and output chain.  I believe Yuhichi observed that these names were
> ambiguous with respect to intermediaries and requestors.
> I now see where he was coming from.  I vote that we change the terms from
> input to request and output to response.  That way at the intermediary and
> requestor nodes, it is much more clear what the purpose of the chain is.
> This would apply most immediately to SimpleTargettedChain, where
> becomes requesChain, etc.  This also affects MessageContext (input message
> becomes request message).
> sgg
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> Web Services Architect
> Emerging Internet Technologies
> ++++++++

View raw message