axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject RE: SOAPAction
Date Fri, 09 Feb 2001 14:39:45 GMT
I like the idea of this change - that said, we need to make sure that as
we make this system more and more flexible we don't make it
unusable.  One good thing about having the stock-quote sample
already there is that we can see what it takes to deploy services.  I'm
worried that building up of these chains might get unmanageable.
I'm not suggesting that we need to do anything, yet, I just wanted
to mention it so we keep it in mind.  We're building this thing so it's
easy for us to do - newbies/non-techies might not find it so easy.
-Dug


Glen Daniels <gdaniels@allaire.com> on 02/08/2001 11:34:13 AM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: SOAPAction




I've been meaning to comment on the way dispatch happens in the current
code
anyway, so this is a good discussion.

The WSDD completely controls how dispatch occurs for a given service.
Depending on which Handlers you deploy in what order, the dispatch will
happen in a particular way.  One fairly common (IMHO) pattern might look
like this:

The transport listener picks up the message in transport-specific form, and
does the MINIMUM amount of work necessary to get things in the
MessageContext.  For an HTTP servlet, this might be just putting the
ServletRequest in the MessageContext and handing it off.  The key is that
the Listener itself gives the Axis Dispatcher a key to dispatch on - each
Listener you deploy gets a key (doesn't have to be unique, necessarily).

The Dispatcher looks up a Handler for that key, and dispatches the
MessageContext.

The key points to a transport-specific chain which wants to do all the
transport-specific stuff.  This is where any Handlers which dispatch based
on URI, SOAPAction, etc. would live.  These guys, as well as setting up any
other Context info, are responsible for figuring out another key to hand to
the end of their chain, which might be a Dispatcher who finds the "real"
service, which implements the SOAP semantics.

An example:

(HTTP) -> Servlet -> Dispatcher
                      |
                      --> TH1 -> TH2 -> Dispatcher   (transport chain)
                                           |
                                           --> SOAP Service

1. Servlet gets request, packages ServletRequest up, and hands off Context
to Dispatcher, setting "DispatchKey" (or whatever we call it) to
"Servlet1".

2. Engine finds Handler in registry for "Servlet1", which is a chain that
handles HTTP servlet related stuff for that servlet.

3. TH1 pulls SOAPAction header from ServletRequest, and sets the
"DispatchKey" context property to its value.

4. TH2 looks for "ObjectID=" on the query string, and if found, sets
"TargetObject" property to its value (assumedly this will be used to find a
particular Java object or EJB to call).

5. The Dispatcher looks up the new DispatchKey (whatever the SOAPAction
was)
in the registry and goes from there.

This is a system where SOAPAction is required for dispatch to the correct
service.

A note about transport-specific processing: in this model you take most of
the transport specific pieces and make them Handlers as well.  That way
when
you deploy your Listeners, you can select what kind of functionality they
have by picking and choosing.  Instead of having a bulky Servlet with code
for authentication, SOAPAction checking, URI parsing, etc., you take all
those pieces and split them out, and gain declarative customization via
WSDD.  Note that this does NOT preclude someone from writing a
"heavyweight"
Listener which does this stuff inline.

Now, we can imagine another configuration:

(HTTP) -> Servlet -> Dispatcher
                         |
                         --> SOAPBodyDispatcher
                                  |
                                  --> SOAP Service

1. Servlet gets request, packages it into MessageContext (like we do now),
and dispatches with the key "Servlet2"

2. The Handler in the registry for "Servlet2" is a SOAPBodyDispatcher,
which
unpacks the Envelope and does a further dispatch based on the QName of the
first Body element.


It's all just configuration, and supplying the right tools (Handlers).
Dispatch happens at any number of places.  If at any point along a
particular configured set of Handlers you can't figure out what to do next,
you Fault.  So for instance if there was no SOAPAction header in the first
example, you'd Fault because that service requires it to get past the 2nd
Dispatcher.

I hope this was at least somewhat clear, I wrote it in a bit of a rush.
The
basic point is that I don't think this is really a hard problem, and
there's
no reason not to support a hugely flexible set of dispatching methods.  We
just provide good tools and defaults for the common cases.

--Glen

P.S.  Oh, I just realized that "dispatch" as I'm using it above is
potentially confusing based on the way we've been defining things.


Mime
View raw message