OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: SOAP/ XML-RPC


Both SOAP and XML-RPC are overkill unless you are trying to bind to existing
RPC based functions.  

We developed a simple approach invoke java member functions based only on a
defined signature of the member function, where the only argument of the
member function was a java string type representing the XML document itself.
The root tag of the XML document was name of a registered member function,
once you strip off the transport tags.  Therefore the only thing that is
required is a well-formed, valid XML document, and information where you can
find its DTD/Schema.  

My understanding with SOAP and XML-RPC that they allow the ability to call
existing RPCs using asynchronous techniques whereas the previous RPC
invocations required synchronous calls and blocking.  With that, I could
asychronously send a XML document to a system, and it could invoke an RPC on
that system (which could actually be an n-tier system using synchronous
techniques).

I don't agree with the SOAP spec's need to define arrays etc, the only
specified requirement being that the root tag is the UML operation name, and
the argument is a valid XML document.  Why try to specify every possible
type of argument????  I am sure they got paid well to develop it, but it's
overkill.  Here is where the KISS principle really applies well.

Scott

-----Original Message-----
From: Peter Kacandes [mailto:Peter.Kacandes@EBay.Sun.COM]
Sent: Wednesday, April 12, 2000 12:55 PM
To: ebXML-Architecture@lists.oasis-open.org
Subject: RE: Registry Submissions and Queries


Just wanted to clarify and make a couple of corrections to my previous
comments.

First off, what I meant to say was that there had been an IETF pre-BOF and
BOF on SOAP, not an 
OASIS TC. Sorry for the confusion. Its hard to keep all of these things
straight sometimes.

Secondy, its important to distinguish between SOAP and XML-RPC. I'm told
that there are 
certainly situations where XML-RPC might be a good thing. Apparently, there
was a presentation 
at the BOF on the requirements for XML-RPC. I'm further told that there was
a comparison 
between those requirements and what is available in SOAP. I'm told that that
is where SOAP was 
found to be lacking.

I'm further told that, when thinking about XML-RPC, the key thing to keep in
mind is the 
degree of synchronicity and coupling. In situations where syncronous
operations and tight 
coupling between systems is required, then XML-RPC could be useful.
Alternatively, if the 
systems should be able to operate asynchronously and loosely coupled, then
XML-RPC might not 
be the best way to go.

If its a "real time" system, then one might tend to think that that is a
situation where you 
would want synchronous operations and tight coupling.

Again, seeing as I'm obviously not very familiar with any of these things,
take the above with 
a large grain of salt. I think I'll keep my mouth shut on this topic from
here on in.

regards

pk

>From: "Petit, John" <jpetit@kpmg.com>
>To: "'Peter Kacandes'" <Peter.Kacandes@EBay.Sun.COM>,
ebXML-Architecture@lists.oasis-open.org
>Subject: RE: Registry Submissions and Queries
>Date: Wed, 12 Apr 2000 07:59:12 -0400
>MIME-Version: 1.0
>
>
>
>-----Original Message-----
>From: Petit, John 
>Sent: Tuesday, April 11, 2000 4:06 PM
>To: 'Peter Kacandes'; ebXML-Architecture@lists.oasis-open.org
>Subject: RE: Registry Submissions and Queries
>
>
>In retrospect, a non-real time search system is probably the only way to
put
>together searches across such immense and distributed
>databases/repositories. With ebXML as the framework to tie the worlds data
>together, real-time searches are not feasible. Therefore a central search
>system must send out a series of queries to all registered repositories
>(which could easily be in the tens of thousands). The system would have to
>wait for the query responses and organize them when they come back (also
>listing those systems it has not heard from). Such a mechanism may very
well
>be a form of XML-RPC.
>
>-----Original Message-----
>From: Peter Kacandes [mailto:Peter.Kacandes@EBay.Sun.COM]
>Sent: Monday, April 10, 2000 8:06 PM
>To: ebXML-Architecture@lists.oasis-open.org; jpetit@kpmg.com
>Subject: RE: Registry Submissions and Queries
>
>>
>><JOHN_RESPONSE>
>>I do not think that I follow you here. I assume that the above described
>>query is not what you have in mind for ebXML searches correct? XML-RPC
>would
>>be too slow for that task. In what context is this XML-RPC?
>></JOHN_RESPONSE>
>
>
>Agreed, some type of XML-RPC approach is not the way to go.
>
>
>
>Peter Kacandes
>
>Application Planning, Architecture & Strategy	phone number: 	X36529
>WWOPS IT/Supply Chain Management		email:	peter.kacandes@ebay
>
>***************************************************************************
*
>*
>The information in this email is confidential and may be legally
privileged.
>It is intended solely for the addressee. Access to this email by anyone
else
>is unauthorized. 
>
>If you are not the intended recipient, any disclosure, copying,
distribution
>or any action taken or omitted to be taken in reliance on it, is prohibited
>and may be unlawful. When addressed to our clients any opinions or advice
>contained in this email are subject to the terms and conditions expressed
in
>the governing KPMG client engagement letter.         
>***************************************************************************
*
>*
>***************************************************************************
**
>The information in this email is confidential and may be legally
privileged.
>It is intended solely for the addressee. Access to this email by anyone
else
>is unauthorized. 
>
>If you are not the intended recipient, any disclosure, copying,
distribution
>or any action taken or omitted to be taken in reliance on it, is prohibited
>and may be unlawful. When addressed to our clients any opinions or advice
>contained in this email are subject to the terms and conditions expressed
in
>the governing KPMG client engagement letter.         
>***************************************************************************
**

Peter Kacandes

Application Planning, Architecture & Strategy	phone number: 	X36529
WWOPS IT/Supply Chain Management		email:	peter.kacandes@ebay



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC