Re: Misunderstanding of SOAP message and protocol binding

[Larry Menten <lmenten@lucent.com>]

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Body>
  <p:itinerary
    xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
     <p:departing>New York</p:departing>
     <p:arriving>Los Angeles</p:arriving>
     <p:departureDate>2001-12-14</p:departureDate>
     <p:departureTime>late afternoon</p:departureTime>
     <p:seatPreference>aisle</p:seatPreference>
   </p:departure>
   <p:return>
     <p:departing>Los Angeles</p:departing>
     <p:arriving>New York</p:arriving>
     <p:departureDate>2001-12-20</p:departureDate>
     <p:departureTime>mid-morning</p:departureTime>
     <p:seatPreference/>
   </p:return>
  </p:itinerary>
  <q:lodging
   xmlns:q="http://travelcompany.example.org/reservation/hotels">
   <q:preference>none</q:preference>
  </q:lodging>
 </env:Body>
</env:Envelope>
The above is an example from the SOAP 1.2 Recommendation, just so that
we
all know what is being described as an Airbus. 

Karl: If you would provide a comparable example or be more precise about
what you feel is redundant we can debate this more meaningfully.

Larry





Karl Auerbach wrote:
> On Fri, 9 May 2003, Chen, Weijing wrote:
>
> > Or someone wants to use BEEP binding, he can use BEEP protocol, but with the
> > same SOAP Message Construct.
> >   
>
> Why would I want to do that?  It seems to me that BEEP already provides me
> with the needed mechanisms (and existing implementations in a number of
> languages) to carry on a well structured, parallal/multi-flowed, secure,
> reliable dialog between the configuring-user and the being-configured
> device.
>
> Putting SOAP inside BEEP strikes me as like putting an Airbus into a
> Boeing, and it may be equally unable to get itself off the ground and
> deliver something that is implementable and usable to network operators.
>
> At the end of the day I want routers and switches that contain software
> mainly there for the purpose of doing routing and switching.  I want my
> memory buffers filled with quickly moving packets, not with redundant
> layers of redundant protocol constructs.
>
> As I mentioned in an earlier note, I see value in that part of SOAP that 
> expresses rules regarding the serialization of various data types.  But I 
> fail to see what is to be gained by using either the envelope or RPC 
> aspects of SOAP if BEEP is already present.
>
> I see a risk here of repeating the computer-science over engineering kind
> of non-pragmatism that led to the tower of babel of layers killed OSI.
>
> So my suggestion is either SOAP or BEEP, not both.  And on the platforms 
> that I use, BEEP is rather closer at hand.
>
>
> > So someone please tell me why SOAP Message Construct can be not reused
> > beside the reason of NIH syndrome.
> >   
>
> Using SOAP over BEEP is a lot like riding two horses at the same time.
> You don't get to the destination any faster, and the risks of a tumble
> along the way are greatly increased.
>
> 		--karl--
>
>
>
>
> --
> to unsubscribe send a message to xmlconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/xmlconf/>

-- 
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA