Re: RPC/Messaging API (was: Re: MIME attachment changes available)

[Wouter Cloetens <wc...@raleigh.ibm.com>]

On Sun, 26 Nov 2000 22:34:35 -0500, Sanjiva Weerawarana wrote:

>> >This is what Message provides. I would prefer to not confuse arbitrary
>> >sending with what Call does (which is, implement the SOAP RPC conventions).
>>
>> I agree, if the design is such that RPC is layered on top of messaging.
>
>No, its not because that would require an extra method call to get the
>routing to work. The saving would be that there's one servlet instead of
>two, but pretty much all the shared logic has been moved out, so there
>isn't much to gain.
>
>The message stuff is done totally differently because messages are
>delivered to handlers with specific signatures and handlers are
>registered directly. RPC handlers (methods) are chosen based on the
>signature .. the two are just different beasts.

You've lost me. Hmm, I think what's causing the confusion. By
"messaging" I was referring to a message-oriented filosophy, i.e. a
call and a response are each just messages. I think you interpreted my
statement as referring to the way messaging has been implemented in v2.

The bottom paragraph does give me a better idea of what the messaging
servlet is all about though. That servlet is by the way out of sync
with the pluggable provider support.

>> >These don't seem to belong in Call IMO. I'm not sure where they
>> >belong .. what requirement do these provide a solution for?
>>
>> Mostly to decouple the process, so client-side code can manually
>> intervene or execute random parts of the process...
>
>If they allow the client-side to do random stuff I would -1 committing
>this stuff. The SOAP stuff is very new yet and I am against making it
>any more flexible than needed. Keeping optionality minimized is vital
>for getting user acceptance of new things IMO and if there's no clear
>problem these solve then let's keep them out until a problem shows up!

I've seen patches that copy the entire process, just to be able to
intervene to do things. A very hot one, for which many different
patches are available, is picking up a session cookie, in which people
copy whole chunks of the HTTP transport mechanism and all of
Call.invoke()'s functionality. The less the users need to copy and the
more they can just invoke selected pieces of functionality, the less
tightly coupled to the implementation details they'll be and the less
pain we'll cause when we change the internals.

I'm not that emotionally involved with this part of the changes though.
:-) I'll leave the methods in question out.

>> Well, in the change I made today, through the introduction of the
>> TransportMessage class, I sort of broke Message and I'll indeed need a
>> common object to make it work again. I'll take a look at how we can fix
>> the relationship between these classes...
>
>Can you explain what you're doing please? I don't understand why you need
>to introduce a transport layer change to plug in the MIME stuff ..

Ok. Extracting the SOAP envelope from the binary message content, or
generating the message content bytes from the envelope, has become a
lot more complex in the multipart MIME world.
In the current version of the software, every SOAPTransport
implementation pretty much does all the work. Now that's become a
pretty hairy endeveour. On top of that, there is duplication of effort
since there's client-side generation of the request, very similar to
server-side generation of the response, and server-side interpretation
of the request, very similar to client-side interpretation of the
response.
So I've implemented a transport layer class that encapsulates a generic
"message" in a transport-independent manner.
For an incoming message, it can be constructed from an InputStream, in
which case it will read the content, determine (from the Content-Type,
also provided by the transport layer) if it's multipart or not,
construct the multipart info in the SOAPContext and extract the
envelope. The transport layer can also invoke the editIncoming() step
of the transport hook extension on it. Because of the way the servlet
is designed, it doesn't unmarshall the response envelope into an
Envelope object, but merely provides it as a String or a Reader.
For an outgoing message, it can be constructed from an envelope and
SOAPContext, from which the binary content (and the content-length,
content-type etc) can be generated. And of course editOutgoing() can be
invoked.
The idea is also that any transport type can override this
"TransportMessage" class and intercept generation or interpretation of
the content. For 8-bit safe transport protocols, I imagine that the
MIME envelope will pretty much look the same as the HTTP version. For
e-mail, for instance, I can imagine an "SMTPMessage" subclass that
would override the method that generates a byte array from a SOAP
envelope and SOAPContext's multipart, to make sure that all parts are
generated in a 7-bit safe manner.
Thanks to this class, I've also been able to eliminate HTTPUtils' inner
class Response. This class performs its function for all transport
types. I'm considering adding a mechanism for adding transport-specific
properties to it, which could be used to hold things like the HTTP
status code or cookie headers for HTTP, or the reply e-mail address for
an e-mail request, the response Destination for a request that came in
over a JMS transport...

>Message is strictly client-side, so I don't see how that will be broken
>by server-side additions .. Call is used on both sides, but with different
>semantics.

This impacts both sides. Specifically, my statement that the
introduction of this class requires that the message class at the
higher layer derives from RPCMessage, refers to the need to be able to
call the buildEnvelope() method of Call or Response. Hmm, upon closer
inspection, that appears to be a flaw in my design. There's no real
need for that, I can get the transport layer to do it... I'll fix it.

bfn, Wouter
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.