ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George I Matkovits <>
Subject Re: added support for messaging
Date Thu, 14 Sep 2000 16:17:09 GMT
IMHO simple extensions (like adding Sanjiva's header processor) are a much better
approach then a 'from  scratch' rewrite. BUT again I am just a biased Web
Services retrograde :-)
Regards - George

Sanjiva Weerawarana wrote:

> > 1. Call class has invoke method.  So in the same manner, Message has "send"
> > method
> > doesn't it?
> Yes, it does. I thought about having "setEnvelope (Envelope env)" and
> then have send only take the action URI etc. like Call.invoke. That
> seemed a bit "design religion" to me and I chose the current approach..
> I have no problem with going back to the other way.
> > 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.
> Well, isn't header processing a "core" feature?? If we put it in then
> its a core feature and hence will impact these classes as well as all
> the stuff around the deployment code.
> > 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.
> We can in fact right now get rid of RPCRouterServlet and implement
> RPC over messaging the MessageRouterServlet. It would cost one extra
> method call. Here's the process:
>     - consider service "urn:s1" with methods m1 and m2.
>     - register an RPC message handler as the recepient for all RPC
>       "messages" (envelopes): x:m1 and x:m2, where xmlns:x="urn:s1"
>     - when invoked, the message handler would do the logic in
>       rpcrouter: find the target object for the given URI, invoke the
>       method, get the return value
>     - marshall the return value into an envelope and write it out to
>       the wire
> I conjecture that its not worth building RPC over messaging this way..
> the current model works more directly and I'm not sure we're saving
> that much by building RPC over the messaging code.
> > 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?
> It is by me .. others?
> Sanjiva.

View raw message