ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <NAKAM...@jp.ibm.com>
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"
method
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
header
processing.  Let me try to define HeaderProcessor class/interface, and come
back.
3.  In an IRC chat, someone said that RPC should be developed on top of
messaging.
We would provide a base platform to exchange "vanilla Envelope," then  develop
RPC
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
experimenting
new features such as header processing.  Is it OK?

Regards,

Yuhichi


From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com> on 2000/09/14 20:00

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

To:   soap-dev@xml.apache.org
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
SOAPTransport
> 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
and
> 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
class.
> (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
MessageRouterServlet:

  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
serializer/deserializer
> 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?

Sanjiva.






Mime
View raw message