axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Graham" <sggra...@us.ibm.com>
Subject RE: SOAPAction
Date Fri, 09 Feb 2001 11:51:05 GMT
Glen:
Some comments/questions.

1) the notion of transport chains is sound.  Perhaps we should also have
transport sender chains?  I will try to come up with scenario.

2) with regards your p.s.  Where you use the term dispatcher (at least
upstream in the chain) the term router might be preferable.  Routers are
traffic cops which choose which chain to invoke next.  Dispatchers actually
forward the message to another actor or target web service.

3) Your two scenarios involve transport keys of Servlet1 and Servlet2.  Are
these different servlets?  Or is the key formed by some sort of if
statement in a single AxisServlet?  It seems to me that the decision as to
whether to use SOAPAction header or namespace of body entry to key the
routing of the message should be in some engine component (? first handler
in a transport specific chain?) not the transport layer.

sgg
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
Web Services Architect
Emerging Internet Technologies
++++++++


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.

> -----Original Message-----
> From: Steve Graham [mailto:sggraham@us.ibm.com]
> Sent: Thursday, February 08, 2001 8:52 AM
> To: axis-dev@xml.apache.org
> Subject: RE: SOAPAction
>
>
> ok, so we agree that the WSDL tells the requestor what needs to do to
> properly express the target of the soap message.
>
> Now, think about the problem of the router in the Axis
> engine.  It receives
> the MessageContext from the transport layer, then what?
> In other words, until the router knows what the target service is, it
> cannot locate the target service-specific chains etc. that
> were configured
> (through the WSDD) based on details from the WSDL.  So the
> router must look
> for clues regarding the target service with the possibility
> of the clues
> appearing in any of the 3 mechanisms.
>
> What happens when the soap envelope uses 2 or 3 of the mechanisms
> simultaneously?  This is ok if the mechanisms agree, but what is the
> behavior when the mechanisms don't all agree?  Fault?
>
> sgg
>
> ++++++++
> Steve Graham
> sggraham@us.ibm.com
> (919)254-0615 (T/L 444)
> Web Services Architect
> Emerging Internet Technologies
> ++++++++
>
>
> "MURRAY,BRYAN (HP-FtCollins,ex1)" <bryan_murray@hp.com> on 02/07/2001
> 09:54:47 PM
>
> Please respond to axis-dev@xml.apache.org
>
> To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> cc:
> Subject:  RE: SOAPAction
>
>
>
> Right - the WSDL tells the client what to do, and the Axis
> configuration
> tells the handlers what to do and how the dispatch will be done.
>
> Bryan Murray
>
> -----Original Message-----
> From: James Snell [mailto:jsnell@lemoorenet.com]
> Sent: Wednesday, February 07, 2001 6:30 PM
> To: axis-dev@xml.apache.org
> Subject: Re: SOAPAction
>
>
> For #1, nothing needs to be done, the client has to use a
> service endpoint
> anyway...
>
> For #2, WSDL can be used since WSDL has features to specify
> the SOAPActor
> attribute for a service implementation
>
> For #3, WSDL can be used to specify the namespace of the body element.
>
> In all actuallity though, the client shouldn't have to know
> anything about
> which method we plan to use.  Through WSDL or some similar
> mechanism, we
> tell them the information that needs to be in the envelope and in the
> SOAPAction header and go from there.
>
> - James
>
>
> ----- Original Message -----
> From: "Steve Graham" <sggraham@us.ibm.com>
> To: <axis-dev@xml.apache.org>
> Sent: Wednesday, February 07, 2001 6:03 PM
> Subject: RE: SOAPAction
>
>
> > ok, how do we communicate to the requestor which method to use?
> > The point I tried to make with standards is, there needs to
> be a standard
> > way that any requestor can format the SOAP message in a way
> that will get
> > routed properly.
> >
> > ++++++++
> > Steve Graham
> > sggraham@us.ibm.com
> > (919)254-0615 (T/L 444)
> > <<Pithecanthropus Erectus>>
> > Emerging Internet Technologies
> > ++++++++
> >
> >
> > James Snell <jmsnell@intesolv.com> on 02/07/2001 05:06:31 PM
> >
> > Please respond to axis-dev@xml.apache.org
> >
> > To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> > cc:
> > Subject:  RE: SOAPAction
> >
> >
> >
> > Out options for dispatching messages to services include:
> >
> >    1. Dispatching based on URI of service listener
> >    2. Dispatching based on HTTP SOAPAction header or
> similar transport
> > layer
> > specific mechanism
> >    3. Dispatching based on the namespace of the body entry.
> >
> > First, let it be acknowledged that the SOAP specification
> doesn't care
> how
> > exactly messages are dispatched -- that is an
> implementation detail left
> > completely up to the SOAP application implementor.  We can
> use any of the
> > three above mechanisms to achieve SOAP compliance.
> >
> > So let's look at the pro's and con's of the three and compare:
> >
> > 1. Dispatching based on URI of service listener
> >
> >    The good thing about this is that dispatching to a
> particular service
> is
> > really dead simple.  We just read in the URI, lookup the appropriate
> > service
> > for that URI and go from there.  A unique ID can be created for each
> > deployed service by appending a Query String parameter to
> the end of the
> > basic listener servlet.  There is nothing about this approach that
> violates
> > the SOAP specification.  This is a highly scalable solution.
> >
> > 2. Dispatching based on HTTP SOAPAction header or similar
> transport layer
> > specific mechanism
> >
> >    The utility of the SOAPAction HTTP header as defined by the SOAP
> > specification is fuzzy at best.  There are no conventions as to how
> exactly
> > to use it, nor are there similar mechanisms defined for
> other transport
> > mechanisms.  While I'd say that this is a fairly simple way
> to dispatch,
> it
> > opens up many possibible incongruities with other SOAP
> implementations
> that
> > either choose not to fully support the SOAP Action header (leave it
> blank)
> > or to use it in some unexpected way.  There are facilities
> in the SOAP
> > Specification that allow a Service provider to define and
> enforce a use
> > convention for the SOAP Actor attribute which would be a
> requirement in
> > order to use this as an effective dispatch mechanism.  On
> the upside,
> this
> > is at the very least a scalable solution.
> >
> > 3. Dispatching based on the namespace of the body entry.
> >
> >    This is not a scalable solution as it would require the
> parsing of
> every
> > message received every time.  The equivalent to this would
> be digging
> > through the contents of an HTTP POST just to figure out which
> > script/servlet
> > to post it to.
> >
> >    Another potential problem with this case is the instance
> where a Body
> > entry doesn't exist at all, rather the message consists of
> nothing more
> > than
> > Header entries (which is also perfectly legal according to the SOAP
> > spec)...
> > in other words, something like the following:
> >
> >     <Envelope>
> >        <Header>
> >           <m:ReceiptAcknowledgement />
> >        </Header>
> >        <Body/>
> >     </Envelope>
> >
> >    In this case, we CANNOT dispatch using method #3.
> >
> > Out of the three possible mechanisms then, #1 appears to
> be:  a) the most
> > scalable, b) the most reliable, c) the most predictable, d)
> the easiest
> to
> > implement
> >
> > - James
> >
> >
> > > -----Original Message-----
> > > From: Steve Graham [mailto:sggraham@us.ibm.com]
> > > Sent: Wednesday, February 07, 2001 1:00 PM
> > > To: axis-dev@xml.apache.org
> > > Subject: RE: SOAPAction
> > >
> > >
> > > James:
> > > We should not use this "convention" as it is not required in
> > > the SOAP v1.1
> > > spec.
> > >
> > >
> > > ++++++++
> > > Steve Graham
> > > sggraham@us.ibm.com
> > > (919)254-0615 (T/L 444)
> > > <<Pithecanthropus Erectus>>
> > > Emerging Internet Technologies
> > > ++++++++
> > >
> > >
> > > James Snell <jmsnell@intesolv.com> on 02/07/2001 11:59:12 AM
> > >
> > > Please respond to axis-dev@xml.apache.org
> > >
> > > To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> > > cc:
> > > Subject:  RE: SOAPAction
> > >
> > >
> > >
> > > +1.
> > >
> > > I'd much prefer dispatching services based on some unique
> URI (email
> > > address, url+query-string, etc).  "Opening" the message
> > > envelope simply to
> > > find out which service to invoke is definitely NOT the way to go.
> > >
> > > - James
> > >
> > > > -----Original Message-----
> > > > From: Glen Daniels [mailto:gdaniels@allaire.com]
> > > > Sent: Wednesday, February 07, 2001 8:53 AM
> > > > To: 'axis-dev@xml.apache.org'
> > > > Subject: RE: SOAPAction
> > > >
> > > >
> > > > I disagree re: saying sayonara to lazy parsing.
> > > >
> > > > Figuring out which service to dispatch to can be done at ANY
> > > > stage in the
> > > > pipeline.  For isntance, the email address which receives a
> > > > SOAP message may
> > > > map to only a single service.  The same holds true for an
> > > HTTP URL, or
> > > > dispatch might be completely accomplished by a "service-id="
> > > > query-string
> > > > parameter.
> > > >
> > > > SOAPAction is simply one transport-specific way that dispatch
> > > > to the target
> > > > service MIGHT be accomplished.  Depending on the particular
> > > > endpoint, you
> > > > may or may not be able to uniquely identify a service/chain
> > > before you
> > > > parse.  So if you want lazy parsing, you make sure there's
> > > > some way to do
> > > > it.
> > > >
> > > > --Glen
> > > >
> > > > > -----Original Message-----
> > > > > From: Steve Graham [mailto:sggraham@us.ibm.com]
> > > > > Sent: Wednesday, February 07, 2001 10:24 AM
> > > > > To: axis-dev@xml.apache.org
> > > > > Subject: Re: SOAPAction
> > > > >
> > > > >
> > > > > we may have to kiss pulled parsing goodbye, as SOAPAction
> > > header is
> > > > > optional (it is required, but the content may not be
> > > > > reliable).  Further
> > > > > for requests coming in from other transports (SMTP) we cannot
> > > > > rely on this
> > > > > as a mechanism to lookup which type of service is
> being invoked.
> > > > >
> > > > > sgg
> > > > >
> > > > > ++++++++
> > > > > Steve Graham
> > > > > sggraham@us.ibm.com
> > > > > (919)254-0615 (T/L 444)
> > > > > <<Pithecanthropus Erectus>>
> > > > > Emerging Internet Technologies
> > > > > ++++++++
> > > > >
> > > > >
> > > > > Doug Davis/Raleigh/IBM@IBMUS on 02/07/2001 09:26:56 AM
> > > > >
> > > > > Please respond to axis-dev@xml.apache.org
> > > > >
> > > > > To:   axis-dev@xml.apache.org
> > > > > cc:
> > > > > Subject:  Re: SOAPAction
> > > > >
> > > > >
> > > > >
> > > > > I was looking at the spec and it talks about how the
> SOAPAction
> > > > > header can be used for HTTP to indicate intent of the message.
> > > > > Well, I was assuming that the SOAPAction should (not
> "must" but
> > > > > "should") match the requested URI of the service for
> the simple
> > > > > reason that if it doesn't match then what good is it?  If
> > > it doesn't
> > > > > match then we're basic saying the user can lie about
> their intent.
> > > > > Also, w/o having the target URI in the SOAPAction then we can
> > > > > kiss laying parsing goodbye.  But like I mentioned in the code
> > > > > I wasn't sure about it so I just wrote something to
> get us going.
> > > > > -Dug
> > > > >
> > > > > Jacek Kopecky <jacek@idoox.com> on 02/07/2001 09:05:56 AM
> > > > >
> > > > > Please respond to axis-dev@xml.apache.org
> > > > >
> > > > > To:   axis-dev@xml.apache.org
> > > > > cc:
> > > > > Subject:  SOAPAction
> > > > >
> > > > >
> > > > >
> > > > >  Hello. 8-)
> > > > >  During the cleanup I saw Dug has some IMHO wrong
> > > assumptions about

> > > > > SOAPAction.
> > > > >  Dug, please explain how you use the Action string in the
> > > code, so I
> > > > > can continue the cleanup not screwing your code badly. 8-)
> > > > >  I'm writing this to the list, so that we all can have a
> > > discussion
> > > > > about the SOAPAction header and its use - proposals,
> anyone? 8-)
> > > > >  Thanks
> > > > >
> > > > >                             Jacek Kopecky
> > > > >                                Idoox
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>



Mime
View raw message