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 23:03:16 GMT
In the case where a unique URI for each server is absolutely impossible or
practically infeasible to achieve, then yes, we would have to fall back to
examining the message.  The question is: is going to be an often enough
occurrence to require Axis to ship with a default configuration of reading
the contents of the message in order to facilitate dispatching.  I do not
believe that it is.  I believe that the vast majority of service that will
be deployed can have the benefit of a unique URI.

- James

> -----Original Message-----
> From: Dirk Reinshagen_C [mailto:DReinshagen_C@zaplet.com]
> Sent: Wednesday, February 07, 2001 2:46 PM
> To: 'axis-dev@xml.apache.org'
> Subject: RE: SOAPAction
> 
> 
> One point to your preference for option #1.  It is 
> fairly easy to create new or virtual URLs under HTTP, but 
> under other protocols (i.e. JMS, SMTP) would you 
> really want to create a separate JMS QUEUE or SMTP 
> address for each type of SOAP service?  If not it seems
> like you would have to fall back to option #3.
> 
> Dirk
> 
> -----Original Message-----
> From: James Snell [mailto:jmsnell@intesolv.com]
> Sent: Wednesday, February 07, 2001 2:07 PM
> To: 'axis-dev@xml.apache.org'
> 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