axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Snell <jmsn...@intesolv.com>
Subject RE: SOAPAction
Date Wed, 07 Feb 2001 22:06:31 GMT
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