axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <gdani...@allaire.com>
Subject Re: SOAPAction
Date Fri, 09 Feb 2001 14:18:11 GMT
> 1) the notion of transport chains is sound.  Perhaps we should also have
> transport sender chains?  I will try to come up with scenario.

Yep, I think that's probably right.  I implemented a first cut at transport
chains (will add to it + clean it up a bit today) which doesn't include
this, but it's easy to add.

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

Yes, that was what I was thinking, and I in fact called the Handler
"Router".

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

Either. :)  As a simple case, I envision each Servlet being configured with
a single name - and those don't even have to be unique unless there's some
different configuration to the transport chain.  This key, just like
everything else, can also be determined dynamically if desired.

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

It can be either place, IMHO.  I see our goal here as defining a useful and
yet extremely flexible framework in which developers of various types
(transport developers, Handler developers, assemblers/deployers, clients)
can do just about whatever they want and still get a lot of value-add from
our system.  So since I don't see a strong need to make a restriction here,
I'd rather not.  In general, as long as SOMETHING before you in the Handler
chain sets up what you need in the MessageContext, you don't care who it
was.  If people want to write "thick" transports, I say let 'em.

That said, I think the examples and transports we provide should strive to
demonstrate our idea of "best practices".

--Glen

> 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