Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Message-ID: <001401c08ad9$c24741c0$575c0209@watson.ibm.com>
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: <axis-dev@xml.apache.org>
References: <OF0A7E4DDA.33FBF357-ON852569E4.004185AA@raleigh.ibm.com>
Subject: Re: Multiple RPCs
Date: Tue, 30 Jan 2001 11:28:47 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I helped write that part of the SOAP spec and I am certain that
was never the intent. I could ask the others too to be certain,
but I see no point in doing it.

IMO having code around is no justification for doing *anything*.
Sorry; I'm a strong believer in throwing away code :-).

Sanjiva.

----- Original Message ----- 
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Tuesday, January 30, 2001 7:07 AM
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-)
> -Dug
> 
> 
> 
> "Sanjiva Weerawarana" <sanjiva@watson.ibm.com> on 01/30/2001 12:37:52 AM
> 
> Please respond to soap-dev@xml.apache.org
> 
> To:   <soap-dev@xml.apache.org>
> cc:
> Subject:  Re: cvs commit:
>       xml-axis/java/src/org/apache/axis/messageSOAPEnvelope.java
> 
> 
> 
> 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.
> 
> Sanjiva.
> 
> ----- Original Message -----
> From: "Doug Davis" <dug@us.ibm.com>
> To: <soap-dev@xml.apache.org>
> Sent: Sunday, January 28, 2001 11:43 AM
> Subject: Fw: cvs commit:
> xml-axis/java/src/org/apache/axis/messageSOAPEnvelope.java
> 
> 
> > 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
> > >
> > >
> >
> 
> 
>