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 15:00:08 GMT
Glen,
  speaking of debugging - thanks for continue to use
the Debug.Print stuff - it makes it easier to see where
things so wrong w/o a debugger.
-Dug


"Glen Daniels" <gdaniels@allaire.com> on 02/09/2001 09:57:17 AM

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

To:   <axis-dev@xml.apache.org>
cc:
Subject:  Re: SOAPAction




+1

We definitely need to keep usability in mind, and I can see some clear ways
that we can do that: the system infrastructure is hugely flexible, but the
"building blocks" we expose at a higher level will hopefully be nicely
chunked (i.e. by default you can deploy a new Servlet Listener with a
canned
HTTP chain that gets configured by some kind of wizard or something so that
you don't have to deal with writing the WSDD for that yourself).  Also it
would be nice to make testing and debugging tools which integrate easily
into the system to ease problem-solving....

--Glen

----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Friday, February 09, 2001 9:39 AM
Subject: RE: SOAPAction


> 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