axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <gdani...@macromedia.com>
Subject Re: doLocal, jws, and http in general
Date Tue, 12 Jun 2001 12:26:38 GMT
> 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



Mime
View raw message