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 Thu, 08 Feb 2001 13:52:15 GMT
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