doLocal, jws, and http in general

[Sam Ruby <ru...@us.ibm.com>]

I got do-local working again with deploy and non-JWS stock quote.  I'll add
an echo functional test shortly to ensure that this continues to work.

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.

The HTTP and TCP transports are still being passed the value of doLocal -
even though it no longer makes any sense.  I'd like to remove it, but I
noticed some code tucked away in the HTTPTransport class that attempts to
make JWS work.

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.
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.

Thoughts?

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

- Sam Ruby

Re: doLocal, jws, and http in general

[Glen Daniels <gd...@macromedia.com>]

> 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.

What about dealing with transports which don't have a URL?  I.e. what if you
want to tie an email address to a particular JWS file, say?  And there's
also the issue of mapping the name to a particular file - for servlets, this
should use the servlet path, but there's perhaps a different root location
for other transports....

I think the way it works now is exactly right.  A (usually
transport-specific) Handler notices the fact that the desired thing is a JWS
file, and sets the JWSFileName property appropriately.  Then it sets the
target service to the JWSProcessor.

> >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 :-)

-1.  Finding/mapping the filename is a different job than running the
service.

And on the larger "servlet vs. 'generic' HTTP" question, I pretty firmly
believe we should just go with the servlet APIs for HTTP.  Servlets are the
standard Java way to do HTTP server stuff, and if someone really wants to
build another HTTP server (like the SimpleAxisServer), I think the way to go
is build very lightweight implementations of ServletRequest/ServletContext
and use those, so that everyone has a single paradigm/API for dealing with
HTTP-specific things.  The other option I see is defining our own set of
APIs for getting at the HTTP context/headers, and mapping all the servlet
classes into that.  Using the "optimize the common case" logic, I think that
easily 90% of our users (or more) are going to have a servlet engine if they
want to use HTTP, and requiring servlet.jar (35K) and a little shim code for
the other cases doesn't seem like that big a deal.

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

Sender is better, IMHO.  Go for it.

--G

Re: doLocal, jws, and http in general

[Rob Jellinghaus <ro...@unrealities.com>]

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