axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Jellinghaus <r...@unrealities.com>
Subject Re: doLocal, jws, and http in general
Date Mon, 11 Jun 2001 23:31:28 GMT
At 04:55 PM 6/11/2001 -0400, Sam Ruby wrote:
>The way do-local works now is that there is the trans-input handler
>(typically HTTPSender) is replaced with a LocalDispatchHandler.  Unlike the
>previous doLocal design, the current design has both a AxisClient and an
>AxisServer, two sets of messageContexts, and two sets of chains - the
>"transport" is merely copying the messages from one context to the other.
>In fact, the messages are even forced to Strings so that serialization to
>XML and deserialization is exercised.

This is interesting to me, partly because one of the next things on my list
(after session & cookie support, coming Real Soon Now) is an example of an
Axis gateway, i.e. a message relay.  This will be basically the inverse of
your do-local example, in some sense.  Your do-local has basically a client
which routes directly into a server (no actual network involved).  The Axis
gateway sample will have a server which routes directly into a client,
which forwards the message onwards to some subsequent destination.

>The right way (IMHO) for JWS to work is for there to be a transport
>specific handler which has the responsibility to set the service.

The confusing thing to me, here, is that there are two senses of "service"
where JWS is concerned.  There is the actual service (say,
"urn:xmltoday-delayed-quotes"), and there is the JWS provider (the
JWSProcessor) which loads & runs the JWS class.  It's not clear to me how
both of these should be treated in the Axis architecture.  Is
"urn:xmltoday-delayed-quotes" the targetService?  Or is JWSProcessor?  And
what about SOAPAction?

In some sense, I think the most correct thing would be for JWSProcessor to
be a global handler, which reads the URL, detects that it is a .jws URL,
does the service-load-and-compile, and sets the service handler.  Then the
actual end-of-the-line provider would be the plain old RPCProvider just as
for all other Java service invocations.

Or perhaps I am off in left field, because what I'm talking about doesn't
seem to have anything to do with your discussion below:

>Unfortunately, the current "http" JWS handler is in reality a "servlet" JWS
>handler - it requires a servlet so it doesn't work with the
>SimpleAxisServer which does process HTTP.  My thoughts are to modify this
>handler to have all the JWS specific dispatching decisions in it, and make
>it aware of servlets, the SimpleAxisServer, and the doLocal alternative.
>Alternatively, I could split it into three separate handlers.  What I don't
>particularly care for is the current situation where jws specific logic is
>in multiple places.

Basically, I agree that jws logic should be as centralized as possible :-)

>Oh, one other thing - I defined an init method on my
>LocalDispatchHandler...when should it have been called?

Where did you get the idea to define an init method?  There are no init
methods on the HTTPDispatchHandler or TCPDispatchHandler.  The only init
method I'm responsible for is Transport.init which is basically just for
the sake of client side setup.  (and I am amenable to changes there if
people come up with a better way to do what it is trying to do.)  But
Transport, and its subclasses, are not DispatchHandlers in any sense.

(I still want to rename DispatchHandler to Sender.  Any strong objections,
over and above the normal objections to renaming files in CVS?)

Cheers,
Rob



Mime
View raw message