Re: Misunderstanding of SOAP message and protocol binding

[Karl Auerbach <karl@cavebear.com>]

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/>