All the Perl that's Practical to Extract and Report

web services

gav on 2003-09-10T18:19:12

Well the bandwagon has finally reached us and we're implementing web services so the pretty desktop applications our C# developers write can have something to talk to.

I've been playing with SOAP::Lite and have a few questions:

Anyway it's all rather exciting, though I did web services back in 1999 with CSV over HTTP before it was cool.

Either way...

KM on 2003-09-11T22:12:31

When I had to choose between SOAP and XML-RPC, I chose XML-RPC for what we needed. SOAP has more overhead, and we didn't really need to pass objects back, and if I had to teach people about namespaces in XML so they could understand how things worked, it would have never gotten off the ground. Last I heard, the SOAP spec may change, or was changing, or may not be backwards compatable. Someone else may know, it has been over a year since I was comparing the two in-depth.

So, I think it depends on what you need. If you need things that SOAP has, use it. If you want something pretty damn simple, and easy to work with.. use XML-RPC. We had Wintendo guys interfacing with the services I created, co-workers understood the XML-RPC payload quickly, and had a decent grasp of the modules. So, I guess it also depends on your timeline and group-size.

In my case, I was using XML-RPC but had the option to plug-in SOAP if needed. All API modules were non-transport specific so all I had to do was open a new port. I wrote a custom application server to do it, then finally convinced people we should use Apache/mod_perl... since I was reinventing Apache with mod_perl :-)

I got into many religious discussions between the two... but XML-RPC won out for what we initially needed. I also did many benchmarks (doing tasks we needed to get done) between XML-RPC and SOAP implementaions... XML-RPC won out every time.

XML-RPC v. SOAP: let's get ready to rumble

jjohn on 2003-09-12T14:41:53

I like both, although I gravitate toward XML-RPC both because I know it well and SOAP doesn't offer me additional power (strangely, this is precisely why I don't program in python much).

Both message procotols do Remote Procedure Calls. Method calls and parameters are serialized into XML and sent over HTTP. XML-RPC is simple and procedural. I have used it a lot and am actively developing a few applications that depend on this protocol. It's simple and and smaller than SOAP and does 99% of what I need. However, XML-RPC for windows C/C++ isn't all that easy to use nor are the libraries as well developed as they should be. My information maybe somewhat out of date, but you will want to research the availability of XML-RPC C# libraries before committing to this terribly useful protocol.

All that said, SOAP RPC is nearly identical to use as XML-RPC. SOAP is object-oriented (kind of, it does maintain attribute values of an "object" across serialization). SOAP is a general messaging protocol. It is meant to do more than shuttle RPC requests (although that's what it does best). There are some fascinating technologies available for public SOAP services, like UDDI and web service routing. Additionally should you need the added power of defining your own serialization types, SOAP has a provision for this. Lastly, SOAP is very well supported by Microsoft, so your C# fellows shouldn't have difficulty in finding the right libraries to use.

Randy Ray is the mad genius behind RPC::XML, which is a module that attempts to remedy some of the holes in the XML-RPC spec (including function signatures and error codes). I used Randy's library back in 2001 and thought it was heading in the right direction. However, I'm very, very familiar with Frontier::RPC (the first XML-RPC and the one covered in ORA's XML-RPC book) so I haven't seen the latest improve Randy has cooked up.

The bottom line: write servers in XML-RPC and SOAP that implement an echo function and try out both. Build clients for both. This excerise won't take long and will give you a good feel for which path you want to take.

Where the dragons be: BOTH protocols suck at sending large data. That is, sending a large (several megabytes) base64 binary block is bound to cause you XML parser headaches. Sending small XML message works best. You may run into trouble with heavily nested data structures too.

I like web services a lot. The technology makes the power of RPC far easier to debug. Allowing other developers to take advantage of one's own work in their own language is just too cool for words.

Re:XML-RPC v. SOAP: let's get ready to rumble

perrin on 2003-09-17T17:27:55

I don't think you could call SOAP "object-oriented" in any meaningful way. It has no concept of state management, so you can't instantiate an object and then call methods on it across the wire. It's just RPC with the ability to serialize complex data types.