axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Multiple RPCs
Date Tue, 30 Jan 2001 12:51:14 GMT
This is really no different than the multiple pivot
point type of discussion we had.  If I take a single
RPC call and split it out, ie:
What do we do if getQuote-Part3 faults?  We stop,
erase any current outgoing message and replace it with
a fault.
This is the exact same semantics that's in the code now.
We loop over each RPC call and if one faults, we stop
replace any outgoing message with a fault.
Where's the confusion? complexity?
If someone has a problem with this then they should
also have a problem with the notion of multiple pivot

Steve Graham/Raleigh/IBM@IBMUS on 01/30/2001 07:38:10 AM

Please respond to

Subject:  Re: Multiple RPCs

The problem still lies with multiple faulting.  How do you convey the fault
element of 2 or more body entries that have faulted?

SOAP Spec (sect 4.4) states:
If present, the SOAP Fault element MUST appear as a body entry and MUST NOT
appear more than once within a Body element.

I interpret this as meaning a SOAP:body can contain only 1 soap:fault child
element.  Is this too narrow?

You could use some convention in the fault's detail element child, but this
is at best a hack.

The fault semantics don't seem to be resolvable, I vote remove the
functionality because it is not complete.  Sure complete for the case where
execution succeeds, but not the fault case.

Steve Graham
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies

Doug Davis/Raleigh/IBM@IBMUS on 01/30/2001 07:07:26 AM

Please respond to

Subject:  Re: Multiple RPCs

Actually I don't think you're right - they're not talking just
about messaging at that point - they do talk about RPC in that
same section.  Section 4.3:
    Typical uses of the Body element include marshalling
    RPC calls and error reporting
When I read the spec, including section 7.1 (RPC and SOAP Body),
I see plurals being used - maybe it's a mistake, maybe I'm reading
too much into it - but what I really don't understand is the
strong objects to this.  If no one sends us multiple RPCs in the
SOAPBody then the code in there will never get used and there's
no harm done.  If someone does send us a SOAPBody with multiple
RPCs we have logic in there now that does something with it - if
people don't like our semantics then they're free to not use it
or they can write their own handler.  I'm not suggesting that we
spend a lot of time on this (either in discussions or in coding),
*I'm mean let's get real* - the code is already in there!!!!
And the semantics are not exactly hard to understand - if people
don't like it then don't use it.  I can't believe we're arguing
over whether to write code that's already been written.  8-)

"Sanjiva Weerawarana" <> on 01/30/2001 12:37:52 AM

Please respond to

To:   <>
Subject:  Re: cvs commit:

The spec is talking about *messaging* at this point and NOT about
RPC. From a messaging perspective, there's nothing special about
one body entry or the first body entry .. its just some XML to be
taken from here to there. When you put in RPC semantics, its a
different world.


----- Original Message -----
From: "Doug Davis" <>
To: <>
Sent: Sunday, January 28, 2001 11:43 AM
Subject: Fw: cvs commit:

> Yes, in fact the spec says:
>   All immediate child elements of the Body element are called
>   body entries and each body entry is encoded as an independent
>   element within the SOAP Body element.
> Notice that it doesn't say "the body entry", or "the immediate
> child".  I believe they purposely used plurals here.
> -Dug
> Jacek wrote:
> > Hello Dug. 8-)
> >  Are you sure SOAP allows multiple message bodies? Or more
> > precisely: does SOAP RPC allow for multiple calls within one body? I
> > always thought that the body maps to a single RPC call. My
> > understanding might have been too narrow, that's true.
> >  But still, wouldn't passing more than one RPC call in a single SOAP
> > message be problematic in means of recognizing what is an RPC function
> > invocation and what is just an independent structure accessed via an
> > href? The SOAP spec says the RPC call is modelled as a struct, in this
> > the subsequent method calls would be indistniguishable from data.
> >  I don't know, this just looks crazy. 8-)
> >
> >                             Jacek Kopecky
> >                                Idoox
> >
> >

View raw message