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 Wed, 13 Sep 2000 14:40:25 GMT

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
send Envelope in a fairly abstract way.  Then I feel it is "MessageSender."
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
I am afraid that it is difficult to add header processing around Message class.
(I hope
that my guess is wrong.)
3. SOAPTransport is still RPC-oriented.  We do not need serializer/deserializer
for transport class, don't we.  (This is not related to message extension.)

Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413

From: "Sanjiva Weerawarana" <> on 2000/09/01 11:34

Please respond to

To:   "Apache SOAP" <>
cc:    (bcc: Yuhichi Nakamura/Japan/IBM)
Subject:  added support for messaging

I've been working on adding message handling support and am about
to commit a first implementation. The model is as follows:

Registering a message handler:
    - handlers are identified by the namespace URI of the first
      element in the <Body> element of a SOAP envelope
    - the localpart of the element name is used as the name of
      method within the handler class to call to process the
    - the handler method must have the signature
        void xyz (Envelope, PrintWriter)
      where the first arg is the envelope that was received and
      the 2nd arg is the print writer into which any results
      should be written.
    - the deployment descriptor has been augmented with a flag
      'type="message"' which must be used to indicate to the
      runtime that the registration is for a message handler and
      not an RPC handler

Processing messages:
    - there is now another servlet (MessageRouterServlet) which
      is responsible for receving messages and routing them to the
      right message handler. The message handler uses the service
      manager to find the deployment descriptor and then does the
      actual invocation of the method.
    - I have reworked the two servlets so that much of the logic
      is shared (e.g., lifecycle management of the objects).

Client API:
    - there is a org.apache.soap.messaging.Message class which can
      be used to send (and receive, if the transport supports it)
      a message. The API is simple: send (Envelope, ..) basically.

    - There's a dumb sample that has a client for sending an envelope
      (which must be given in an input file) to some message router
      and a sample message handler which just prints "I got it" to
      the output stream.

    - the registration method is inadequate .. one needs to be able
      to register listeners without having to necessarily require
      the first element of the <Body> to be namespaced.
    - the message handler signature is inadequate .. it gives the
      incoming Envelope to the handler (which is ok), but if the
      handler wants to send a message in response, then it has to
      do all the work and write out the XML characters to the given
      stream. That's not good .. I've been contemplating adding a
      "respond (..)" method to SOAPTransport and then handing the
      handler a special SOAPTransport object that supports respond().
      Something like this is needed because the handler must be able
      to set headers too (like Content-Type) and also be able to set
      things like the status code for HTTP transports. I'm struggling
      with how to enable all that and yet not require the handler
      author to be fully aware of the transport used to get to it.
      I've been at this point for the last few days and haven't found
      a nice clean way to do it .. Any bright ideas would be greatly

In the process of doing this I made some added code to put a
stacktrace into the fault when a fault is generated. I also made
the fault come out in all cases .. I think this is a bit more

I will put some comments into each commit message too as much as I
remember .. I had to make quite a few changes to get message support
in cleanly (well, as far as I tell at this time).


View raw message