ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <>
Subject Re: added support for messaging
Date Thu, 14 Sep 2000 14:38:20 GMT

Maybe I understand your points, but I just want to make sure.

1. Call class has invoke method.  So in the same manner, Message has "send"
doesn't it?
2. I thought that RPC/MessageRouters are "core" classes that we do (should) not
modify.  You indicate that we would modify these classes to add support for
processing.  Let me try to define HeaderProcessor class/interface, and come
3.  In an IRC chat, someone said that RPC should be developed on top of
We would provide a base platform to exchange "vanilla Envelope," then  develop
mechanism on top of that.  I thought that some members including some committes
agreed on such messaging approach.

I think the completely new architecture should be discussed, but we need a
fairly long
time.  At this moment, it might be a good idea to extend the current system
new features such as header processing.  Is it OK?



From: "Sanjiva Weerawarana" <> on 2000/09/14 20:00

Please respond to

cc:    (bcc: Yuhichi Nakamura/Japan/IBM)
Subject:  Re: added support for messaging

Sorry, I didn't see this post (I'm behind in my email).

> Does anyone look at the update?  I have not seen feedbacks on this.
> I have a few comments:
> 1. The new class "Message" is a misleading name.  It seems to wrap
> to
> send Envelope in a fairly abstract way.  Then I feel it is "MessageSender."

Its not - its an abstraction of something that is to be sent. Yes, the
only state it has is the soaptransport - hence your reasoning that its
a wrapper for a transport I presume.

> 2. Currently header processing has not been considered yet both at client
> server sides.
> I remenber current Envelope class implementation was RPC-oriented in V1.0.
As a
> result,
> I am afraid that it is difficult to add header processing around Message
> (I hope
> that my guess is wrong.)

Adding header processing is easy - the Envelope has a property called
Header which has a vector of elements. On the server side, we could
easily call some "header processor" after extracting the envelope
from the message and before processing it (for RPC or message). I
don't see what's hard about it - maybe I'm missing something.

Here are the lines from RPCRouterServlet:

  Envelope callEnv = ServerHTTPUtils.readEnvelopeFromRequest (req, res);
  call = RPCRouter.extractCallFromEnvelope (serviceManager, callEnv);

Header processing would go in between these. Here is the line from

  Envelope msgEnv = ServerHTTPUtils.readEnvelopeFromRequest (req, res);

Header processing would go after this.

That's it .. I don't see any difficulty adding it on the server side.
The client side is equally straightforward - it would go in the send()
method for Message and invoke() method for Call.

If you define a "HeaderProcessor" interface we can easily add a call
to it here. You would obviously have to add to the deployment part
to register the header processors.

> 3. SOAPTransport is still RPC-oriented.  We do not need
> components
> for transport class, don't we.  (This is not related to message extension.)

You're referring to the SOAPMappingRegistry argument right? That's
passed as a null from Message. This way we can use the same
SOAPTransport object for the two cases. I don't see anything wrong
with that - do you disagree?


View raw message