Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 [uddi.org] and web service routing [microsoft.com]. 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 [oreilly.com] 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.

    • 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.