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 Wed, 07 Feb 2001 17:02:51 GMT

But you're not averse to supporting it if needed, right?  I think it's key
to allow both any sort of transport-specific dispatch AND dispatch based on
the XML.

--Glen

> -----Original Message-----
> From: James Snell [mailto:jmsnell@intesolv.com]
> Sent: Wednesday, February 07, 2001 11:59 AM
> To: 'axis-dev@xml.apache.org'
> 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