RE: So what do SOAP and XML-RPC buy you?

[Stuart Naylor <indtec@eircom.net>]

RPC!!!

When I go to the library I select a couple of books and return home. It
would seem that you are intent on breaking my back with taking the whole
library back home so I can select my reading matter.
After my selection of books and probably the required traction I can then
return the library.

RPC and API technologies are essential in off loading transaction weight.
Currently 'content' as a total understatement is a tad to inefficient and
broadening that scope is a ridiculous statement. Even with Moores Law we
will have to wait for far to long before we can kill the problem with
hardware.
Simple small schemas are still the way to go for now and RPC can fill a void
until the methodology to provide multi-user, secure XML data in a
efficiently can be found.
RPCs are not the problem (Get / Post) it is the API that provides the narrow
scope.
What I would like to see is not the manufacture of new schema or RPC but a
methodology of describing a API in a general context.
As for the current thread I don't believe the 'Mine is bigger than yours'
has any worth as mine is bigger than yours, well my girlfriend always has a
smile and hopefully not a ironic one.
Leaving the envy to one side what I would like to hear is how schema or RPC
can reduce the shear quantity of bits down the wire.

TBLs Semantic web caught my eye and if you can search down to find data then
you can traverse upwards to find metadata. With the combination of schema
and RPC a semantic API could be a possibility.
I have had posts about B2B and App2APP initiatives such as :-

BPMI.org The Business Process Management Initiative
http://www.bpmi.org/index.esp

Composite Capability-Preference Profiles (CC-PP) Structure and Vocabularies
http://www.w3.org/TR/CCPP-struct-vocab/

Jini.org -- The Community Resource for Jini(tm) Technology
http://www.jini.org/

Universal Description, Discovery, and Integration
http://www.uddi.org/

Universal Plug and Play
http://www.microsoft.com/hwdev/upnp/

Open Applications Group
http://www.openapplications.org/

The amount of initiatives out only prove that RPC is required you can't say
it is wrong until you have a solution to elevate the reasoning why these
bodies have been created.

The above range from souped up EDI to WAP enabled ring tone tune down
loaders and I am not saying they are great. They are solutions to problems
but don't say they are bad until you have a better method.


-----Original Message-----
From: Ken MacLeod [mailto:ken@bitsko.slc.ut.us]
Sent: 20 April 2001 15:11
To: xml-dev@lists.xml.org
Subject: Re: So what do SOAP and XML-RPC buy you?


David Brownell <david-b@pacbell.net> writes:

> > The only unique* component here is that the data passed as the
> > content are represented in the calling language as
> > compound/complex objects conforming to [little-s] schemas rather
> > than streams of mime content.
>
> That's what I'd call a marshaling API.  In this case, it'd be a
> policy-rich layer over the "stream of MIME content" style APIs that
> already exist.
>
> The XML-over-HTTP messaging would use those stream'o'MIME calls
> directly, rather than with intervening policies for SOAP etc.

Yes, exactly.  Circling back to the point that started this thread,
the policy-rich layer is what is the "perceived buy" of XML-RPC and
SOAP, even though they are a very, very narrow scope of "XML over
HTTP" (or, "XML over any transport", in the latter case).

Broadening the scope of the what content can be "marshalled better"
(for some definition of "better" :-), and removing the implicit
messaging (or RPC) layer would be a huge win.

  -- Ken

------------------------------------------------------------------
The xml-dev list is sponsored by XML.org, an initiative of OASIS
<http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org