On Monday, February 18, 2002, at 11:30 PM, OrbMagic wrote:
Can anybody actually give me a business need for SOAP and XML-RPC key word here is "need".
What we're building is a procedure call API, as such it is a natural fit for something like XML-RPC. You are absolutely correct that technically we could just build directly on top of HTTP, however we would have to do more work, and in the end would probably emerge with something that still looked an awful lot like XML-RPC anyway.
XML-RPC defines the semantics and syntax for remote procedure calls, the fact it uses XML is secondary. It's appealing because it's simple and works well enough most of the time. Implementations already exist for most languages and since it's so simple it interoperates pretty well. If we were to build a raw HTTP solution then we push a lot of burden for constructing client libraries onto to the people who want to use it. With XML-RPC those libraries will probably already exist.
If this still bothers you just think about XML-RPC messages as text rather then XML. The format it uses is really simple enough that you could build a simple custom parser that only understands its messages. This is exactly the same thing you'd have to do with post messages anyway, the XML-RPC library just does a lot of the work for you.
Seems to me (I've been developing app-server centric application for about 6
years now) and
I still haven't come across anything that I couldn't do via HTTP and
http-formcas submitted values either from a form or through somekind of an
automated HTTP Post application. As far as Server sided components
And you probably won't come across anything either. After all XML-RPC and SOAP are just HTTP posts anyway. They simply provide a predefined format for those posts instead of each application inventing their own.
The same question can be applied to HTTP it self, for instance I could say I really don't see anything that I couldn't do with raw TCP/IP. The point is that HTTP has benefits that are not purely technical, XML-RPC and to a lesser extent SOAP do too.
If I say to you I expose an XML-RPC API, and assuming you know what XML-RPC is, you'll instantly know that all you'll need to call the API is an XML-RPC library and the list of methods and parameters that are exposed.
Your focus is on the information being exchanged not on how you go about exchanging that information.
However, if I say I expose an HTTP POST API, you don't have that instant understanding because the next question is going to be what's the format of the messages that I need to send and what's the format of the response I should expect. Your focus is on the mechanism of exchanging data rather then on just the data.
It's just abstraction. The fact XML is used for the messages, is basically just history at this point. There are numerous "better" or more "efficient"
or more "powerful" ways to do all of this. We already have a CORBA solution which is about the most powerful way to solve this problem, the problem is nobody uses it because to get that power the complexity quotient is through the roof. We've had the CORBA API available for a year and a half, in that time nobody used it from another language. I made a simple XML-RPC API available and in less then a week people were using it from PHP, Cold Fusion, Perl, Python and Applescript. This is a difficult to communicate aspect of technology decisions. Engineers want to focus in on finding the best pure technical solution and many times ignore what it is that will actually get used. We made this mistake by choosing CORBA in the first place. By using a pure HTTP solution you're just removing an abstraction that people are comfortable with. I see this as just introducing another barrier to building applications.
communicating via some kind of protocol, XML-RPC and SOAP seem to me to be completly overlapped of the hundreds of other protocols available.
Why is everybody pushing and pushing XML-x (x is some XML API (not
technology)) down our throats. I must say my career is only 6 years old, I
wasn't around before everything thing on earth was supplied by apache (which
I support and use allot of the tools) and Sun.
I have implemented an XML-RPC implementation via a servlet and found it neat
for a second or 2 but haven't seen any real use for XML-RPC, SOAP, or for
that matter, these stupid, ridiculas "Web Services", that do nothing more
that add another layer on-top of CGI. Could somebody set me straight, before
you do please give me a "real-life" NEED for WebServices, SOAP, XML-RPC.
Web services are a completely different issue and definitely not a discussion that belongs on this list. We're not necessarily building web services, we simply need a lightweight remote API with clearly defined calling semantics. I'll leave the web services hype BS to the big commercial vendors, I'm with you that a lot of it is really stupid.
If you want to debate web services and HTTP as a mechanism I suggest you join the XML-DEV mailing list. There's been a couple heated threads running on there for several weeks now debating the merits of REST vs messaging and RPC among other things.
I use allot of these and others at work all day but I also know that there
are alternatives that outperform parsing XML documents. I see this
technology being used to pass information from a middle-tier to a front-tier
in the same application in the same dept where all the data-types are known.
Whats the POINT!!!!!!!. It seems like this industry (specifically the Java
areana) just uses any piece of crap that come out just because it say XML or
'X' or 'I' or 'E' in its name.
I am sorry I am complaining and don't intend to upset anybody, but the way I
see it is; XML has a place in technology, but why do we have to base every
new technology around XML. It kinda makes things bland and boring. From what
I can see nobody looks at alternatives to XML and J2EE they just assume
thats what they have to use, it sucks!
Fred
Fred
-----Original Message----- From: Kimbro Staken [mailto:[EMAIL PROTECTED] Sent: Monday, February 18, 2002 1:58 PM To: [EMAIL PROTECTED] Subject: Re: Switch to XML-RPC / SOAP
On Monday, February 18, 2002, at 10:56 AM, Kurt Ward wrote:
Unless I'm overlooking something, I think SOAP is a little overkill for
Xindice
since the data returned will most likely always be XML and not a datatyped
response.
What do you guys think?
The one thing that is appealing about SOAP is that it supports multiple encodings so it would enable something like our XML:DB API impl to negotiate with the server to use a binary encoding while less intelligent clients use regular encodings. Right now one of the benefits of the CORBA API is that it doesn't parse the document if it doesn't have too, with SOAP you could achieve the same thing. We could actually achieve the same effect with XML-RPC through a method on a parameter, but that alters the interface.
That being said, I really prefer to take as simple of an approach as possible to start with and that is really XML-RPC. So I'm +1 for XML-RPC.
Apache XML-RPC does have a web server class that could probably handle some of the other concerns about using HTTP as the transport:
1. ability to deny requests based on remote IP 2. SSL support
SSL is going to be required when security is implemented , otherwise db usernames and passwords would be sent in plain text.
For the next release I think we should just keep the existing HTTP server. The current XML-RPC interface is really simple in that scenario. We can look at moving to something else once we start to convert over to Avalon.
The two server "plugins" both use the HTTP server. (HTTP Doc retrieval and the XML-RPC plugin).
Speaking of the XML-RPC plugin, I apologize for not having a download available. I will have some CVS updates and hopefully a download later today:
Do you want to continue to own this piece? I'm thinking we use the existing interface as a starting point and roll it into the server for the next release. Thoughts?
We should reexamine the details of the API but it's a really simple place to start. I'm comfortable with proposing you for commit based on your existing work if you want to continue improving on it?
http://sourceforge.net/projects/xindice-xmlrpc/
Kurt
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
