[June 30, 2000] XML-RPC supporting 'simple cross-platform distributed computing, based on the standards of the Internet' is "a specification and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet. It's remote procedure calling using HTTP as the transport and XML as the encoding. It's designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned."
References:
XML-RPC Home Page. See here also the list of compatible implementations, news on demonstrated interoperability, etc.
"What is XML-RPC? It's a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet. It's remote procedure calling using HTTP as the transport and XML as the encoding. It's designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned." See the XML-RPC Specification" (documents the XML-RPC protocol implemented in Frontier 5.1.).
Specification "XML-RPC is a Remote Procedure Calling protocol that works over the Internet. An XML-RPC message is an HTTP-POST request. The body of the request is in XML. A procedure executes on the server and the value it returns is also formatted in XML. Procedure parameters can be scalars, numbers, strings, dates, etc.; and can also be complex record and list structures."
[May 01, 2003] "Tip: Make Your CGI Scripts Available via XML-RPC. Providing a Programmatic Interface to Web Services." By David Mertz, Ph.D. (Interfacer, Gnosis Software, Inc). From IBM developerWorks, XML zone. ['For a large class of CGI scripts, it is both easy and useful to provide an alternate XML-RPC interface to the same calculation or lookup. If you do this, other developers can quickly utilize the information you provide within their own larger applications. This tip shows you how.'] "Many CGI scripts are, at their heart, just a form of remote procedure call. A user specifies some information, perhaps in an HTML form, and your Web server returns a formatted page that contains an answer to their inquiry. The data on this return page is surrounded by some HTML markup, but basically it is the data that is of interest. Examples of data-oriented CGI interfaces are search engines, stock price checks, weather reports, personal information lookup, catalog inventory, and so on. A Web browser is a fine interface for human eyes, but a returned HTML page is not an optimal format for integration within custom applications. What programmers often do to utilize the data that comes from CGI queries is screen-scraping of returned pages -- that is, they look for identifiable markup and contents, and pull data elements from the text. But screen-scraping is error-prone; page layout might change over time or might be dependent on the specific results. A more formal API is better for programmatic access to your CGI functionality. XML-RPC is specifically designed to enable an application access to queryable results over an HTTP channel. Its sibling, SOAP, can do a similar job, but the XML format of the SOAP is more complicated than is needed for most purposes. An ideal system is one where people can make queries in a Web browser, while custom applications can make the same queries using XML-RPC. The underlying server can do almost exactly the same thing in either case... There is a difference in the way a CGI script runs and the way this XML-RPC server runs. The XML-RPC server is its own process (and uses its own port). CGI scripts, on the other hand, are automatically generated by a general HTTP server. But both still travel over HTTP (or HTTPS) layers, so any issues with firewalls, statefulness, and the like remain identical. Moreover, some general-purpose HTTP servers support XML-RPC internally. But if, like me, you do not control the configuration of your Web host, it is easier to write a stand-alone XML-RPC server..."
[April 30, 2003] "Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)." By Ward K. Harold (IBM, Austin, Texas). IETF Network Working Group, RFC. Reference: Request for Comments #3529. Category: Experimental. April 2003. 15 pages. "XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers... The BEEP profile for XML-RPC is identified as http://iana.org/beep/transient/xmlrpc in the BEEP 'profile' element during channel creation. In BEEP, when the first channel is successfully created, the 'serverName' attribute in the 'start' element identifies the 'virtual host' associated with the peer acting in the server role... In XML-RPC Message Exchange, a request/response exchange involves sending a request, which results in a response being returned. The BEEP profile for XML-RPC achieves this using a one-to-one exchange, in which the client sends a 'MSG' message containing an request, and the server sends back a 'RPY' message containing an response. The BEEP profile for XML-RPC does not use the 'ERR' message for XML- RPC faults when performing one-to-one exchanges. Whatever response is generated by the server is always returned in the 'RPY' message. This memo defines two URL schemes, xmlrpc.beep and xmlrpc.beeps, which identify the use of XML-RPC over BEEP over TCP. Note that, at present, a 'generic' URL scheme for XML-RPC is not defined... The IANA has registered the profile specified in Section 6.1, and has selected an IANA-specific URI http://iana.org/beep/xmlrpc..." See "Blocks eXtensible eXchange Protocol Framework (BEEP)." [cache]
[December 26, 2002] "From XML-RPC to SOAP: A Migration Guide." By Rich Salz. From XML.com. December 18, 2002. ['This month's installment from Rich Salz, our resident Web Services commentator, tells users of XML-RPC it's about time they started using SOAP, and provides a migration path to move between the two Web services protocols. As usual, Rich provides plenty of code and examples.'] "As you might expect from the name, XML-RPC is a way of using XML to send classic Remote Procedure Calls (RPC) over the net. XML-RPC's use of XML is very simple. It doesn't use namespaces. It doesn't even use attributes. Poking at the reasons behind technology standards can lead to interesting results. The really good ones, like the first ANSI C specification, include a detailed rationale for key decisions. Most internet standards don't spend the effort but prefer, instead, to allow an archived mailing list to act as a primary source. And, even then, it can be fun to play standards archaeologist. The primary motivator behind XML-RPC is Dave Winer, owner of a small ISV company, and one of the first webloggers. Winer was part of the initial, self-selected group that created SOAP. According to Don Box's Brief History of SOAP, Winer grew impatient with corporate delays. In July, 1998, Winer posted the specification for XML-RPC. At that point, the Namespaces in XML group had published two drafts; final recommendation publication wouldn't happen until January, 1999. Given the state of flux, and all the churn caused by following XML Schema drafts which Don describes in his article, it isn't surprising that XML-RPC avoids namespaces altogether. It is surprising, however, that XML-RPC doesn't use XML attributes. One might surmise that doing without attributes makes parsing much simpler. XML-RPC is well-suited to simple lexical handling: divide the input stream into 'tags', which are simple words surrounded by angle brackets, and values. In hindsight, however, it makes for strange XML... With a few simple changes, XML-RPC applications should be able to send and receive SOAP messages to and from well-behaved SOAP applications. Perhaps surprisingly, most of the work is in constraining the SOAP applications to be well-behaved. In the standards world, when a specification has many options and possibilities, and you define yourself to a conformant subset, that's called a profile. So what we've started work on is a SOAP profile, defined in WSDL, that should make it easy for 'legacy' XML-RPC applications to interoperate..."
[December 20, 2001] "XML Matters: XML-RPC as Object Model. A data bundle for the hoi polloi?" By David Mertz, Ph.D. (Sometime Attributor, Gnosis Software, Inc.). From IBM developerWorksm XML Zone. December 2001. ['XML-RPC for serialization? Columnist David Mertz examines XML-RPC as a way of modeling object data, and compares XML-RPC as a means of serializing objects with the xml_pickle module discussed in his earlier columns. Code samples illustrate this comparison in detail.'] "XML-RPC is a remote function invocation protocol with a great virtue: It is worse than all of its competitors. Compared to Java RMI or CORBA or COM, XML-RPC is impoverished in the type of data it can transmit and obese in its message size. XML-RPC abuses the HTTP protocol to circumvent firewalls that exist for good reasons, and as a consequence transmits messages lacking statefulness and incurs channel bottlenecks. Compared to SOAP, XML-RPC lacks both important security mechanisms and a robust object model. As a data representation, XML-RPC is slow, cumbersome, and incomplete compared to native programming language mechanisms like Java's serialize, Python's pickle, Perl's Data::Dumper, or similar modules for Ruby, Lisp, PHP, and many other languages. In other words, XML-RPC is the perfect embodiment of Richard Gabriel's 'worse-is-better' philosophy of software design. I can hardly write more glowingly on XML-RPC than I did in the previous paragraph, and I think the protocol is a perfect match for a huge variety of tasks. To understand why, it's worth quoting the tenets of Gabriel's 'worse-is-better' philosophy... By design, xml_pickle is more naturally extensible for representing new data types than is XML-RPC. Moreover, extensions to xml_pickle maintain good backward compatibility across versions. As its designer, I am happy with the flexibility I have included for xml_pickle. However, the fact is that XML-RPC is far more widely used and implemented. Fortunately, with only slight extra layering -- and without breaking the underlying DTD -- XML-RPC can also be adapted to represent arbitrary data types. The mechanism is somewhat less elegant, but XML-RPC is well thought out enough to allow compatibility with existing implementations after these adaptations..."
[December 20, 2001] "XML-RPC vs. SOAP. A simple guide to choosing the best protocol for your XML Remote Procedure Call needs." By Kate Rhodes. November 14, 2001. [Cited by David Mertz, above: "Kate Rhodes has written a nice comparison called 'XML-RPC vs. SOAP';in it, she points to a number of details that [give the lie to]SOAP's description as a 'lightweight" protocol'..."] "Within the world of XML there are two main ways to implement a Remote Procedure Call (RPC). XML-RPC and SOAP. This document will explore the differences between these two methods in order to help you decide which is best suited to your needs. ... When you get right down to it XML-RPC is about simple, easy to understand, requests and responses. It is a lowest common denominator form of communication that allows you to get almost any job done with a minimum amount of complexity. SOAP, on the other hand, is designed for transferring far more complex sets of information. It requires profuse attribute specification tags, namespaces, and other complexities, to describe exactly what is being sent. This has its advantages and disadvantages. SOAP involves significantly more overhead but adds much more information about what is being sent. If you require complex user defined data types and the ability to have each message define how it should be processed then SOAP is a better solution than XML-RPC (be sure to check out language specific solutions to this problem like Java's RMI). But, if standard data types and simple method calls are all you need then XML-RPC will give you a faster app with far fewer headaches..."
[November 01, 2001] "Building XML-RPC Clients in C." By Joe Johnston. From XML.com. October 31, 2001. ['Much XML development has traditionally used the Java programming language. However there are scenarious where, for reasons of speed, portability or history, C is the language of choice. Joe Johnston shows how to take advantage of web services from C programs. Special care is taken to bring programmers with rusty C-hacking skills up to speed.'] "XML-RPC is a useful protocol for building cross-platform, client-server applications. Often XML-RPC is demonstrated with high-level interpreted languages like Perl and Python. In this article, Eric Kidd's XML-RPC C library is used to build a simple, yet powerful debugging client. Special care is taken to bring programmers with rusty C-hacking skills up to speed. XML-RPC is a wire protocol that describes an XML serialization format that clients and servers use to pass remote procedure calls to each other. There are two features that make this protocol worth knowing. The first is that the details of parsing the XML are hidden from the user. The second is that clients and servers don't need to be written in the same language... Many articles written about XML-RPC use Java, Perl, Python, or PHP to demonstrate building Web Services. However, real life programming requirements often mitigate against the programmer's first choice of implementation language, perhaps because access to a resource whose only API is a C library is required. In this case, building an XML-RPC server to this resource opens it up to any client that supports XML-RPC..." See: (1) Programming Web Services with XML-RPC, by Simon St.Laurent, Joe Johnston, and Edd Dumbill; with Foreword by Dave Winer (O'Reilly); (2) Joe Johnston's article "Binary Data to Go: Using XML-RPC to Serve Up Charts on the Fly," which shows how XML-RPC and Web services can create simple charts for client programs.
[September 10, 2001] "Rampant Confusion." By Chad Dickerson [InfoWorld CTO]. In InfoWorld (September 7, 2001). "I'm going to start this week's column by making a couple of hype-challenged statements: XML is inherently useless; and Web services, although it's the next big thing to nontechnical folks, has been chugging along quietly for a few years without much fanfare. In my role as CTO, I sit in a lot of meetings where I act as translator between the business folks and the engineers. XML, which works quite well in helping machines talk to each other, creates quite a lot of confusion when people talk about it. Many of the discussions go as follows: Business person: 'We need to integrate data from Company X into our Web site.' Me: 'What format will the data be in?' Business person (smiling broadly): 'XML; it's all XML.' Me: 'OK, I'll need to have an engineer look at how they structure their data so we can process it properly and integrate it into the site.' Business person (smile weakening): 'But it's in XML. ... ' Me: 'Great, I'm glad it's in XML format. We need some time to port the data into our database, do QA, and make sure we process the data feed properly as it comes in.' Business person (frown developing): 'But it's in XML. ... ' At this point I start explaining that receiving an XML feed is the beginning of an integration process, not the end. To paraphrase from the XML FAQ: XML is a markup specification language and XML files are data: They just sit there until you run a program which displays them (like a browser), or does some work with them (like a converter which writes the data in another format, or a database which reads the data), or modifies them (like an editor). In other words, as much as we all love it, XML alone is more or less useless. Although XML can be wonderful for trading data among applications, applications do not magically appear around XML documents. XML does, however, function as a great point of leverage for applications, which leads us to Web services... The term Web services confuses many people, and what was supposed to make things easier is making things more difficult. But this is mainly due to lack of clarity in marketing, not shortcomings in what is essentially an extraordinarily simple and powerful concept... the XML-RPC specification provides an easily grasped window into the technical promise of Web services, while also serving as a spirited manifesto for the then-new Web services world order. When I grow confused about what Web services means, I read the XML-RPC spec and it makes sense again..."
[September 10, 2001] "XML-RPC for PHP, Version 1.0." By Edd Dumbill. Documentation. Version 1.0 is available for download. "The 1.0 release is the final release to be managed by Useful Information Company... We've developed classes which encapsulate XML-RPC values, clients, messages and responses. Using these classes it's possible to query XML-RPC servers. XML-RPC is a format devised by Userland Software for achieving remote procedure call via XML. XML-RPC has its own web site, www.XmlRpc.com. The most common implementations of XML-RPC available at the moment use HTTP as the transport. A list of implementations for other languages such as Perl and Python can be found on the www.xmlrpc.com web site. This collection of PHP classes provides a framework for writing XML-RPC clients and servers in PHP..." [Edd's XML-DEV post: "So, it took me two years to get brave enough to call it '1.0', but here it is. I finally reckon my all-PHP classes for doing XML-RPC are 'stable.' Available under the BSD license. More detail at http://xmlrpc.usefulinc.com/php.html. A good time to note too that I've moved the project to SourceForge as well (which turns out to surpass my expectations in niftiness), and have already gained two more developers on the project. It is my intent to step down as maintainer as soon as a suitable replacement emerges..." Note also the book Programming Web Services with XML-RPC, by Simon St.Laurent, Joe Johnston, and Edd Dumbill [foreword by Dave Winer]. O'Reilly, June 2001. "XML-RPC, a simple yet powerful system built on XML and HTTP, lets developers connect programs running on different computers with a minimum of fuss. Java programs can talk to Perl scripts, which can talk to ASP applications, and so on. With XML-RPC, developers can provide access to functionality without having to worry about the system on the other end, so it's easy to create web services... Programming Web Services with XML-RPC introduces the simple but powerful capabilities of XML-RPC, which lets you connect programs running on different computers with a minimum of fuss, by wrapping procedure calls in XML and establishing simple pathways for calling functions. With XML-RPC, Java programs can talk to Perl scripts, which can talk to Python programs, ASP applications, and so on..."
[July 21, 2001] "Programming Web Services with XML-RPC." By Simon St. Laurent, Joe Johnston, Edd Dumbill. From XML.com. July 18, 2001. ['An excerpt from the recently published O'Reilly book Programming Web Services with XML-RPC, written by Simon St.Laurent, Joe Johnston and Edd Dumbill. The excerpt shows how XML-RPC, a simple XML web services technology, and PHP, the popular web page scripting language, can be put to use to integrate two web applications, neither of which need to be under the control of the programmer.'] "The following sections explore using PHP to integrate two web applications into one interface. The first section demonstrates how to create a complete PHP XML-RPC server application, in this case a discussion server. The web application to which this server will be connected is a database called Meerkat, the brainchild of Rael Dornfest and O'Reilly & Associates, Inc. (who also happen to be the publishers of this book). Meerkat is a storehouse of news about technological developments. After a subsequent section that gives an overview of Meerkat, the chapter demonstrates how to integrate the database with the custom XML-RPC discussion server..."
[July 13, 2001] "Binary Data to Go: Using XML-RPC to Serve Up Charts on the Fly." By Joe Johnston [co-author of Programming Web Services with XML-RPC] From Oreilly.com. July 9, 2001. ['O'Reilly software engineer Joe Johnston demonstrates how to use XML-RPC to transport binary data as base64-encoded messages and how to set up a simple Web service that creates charts with this data.'] "Although less famous than its younger sibling SOAP, XML-RPC is a simple and easy tool that can help you integrate even the most uncommunicative of systems. Where SOAP is a generalized, object-oriented, messaging protocol that is designed to carry arbitrary XML payloads across any network protocol, XML-RPC is a simple procedural protocol designed only to make remote function calls. Lest you get the impression that XML-RPC is inferior to SOAP, there are a good number of everyday problems that XML-RPC can solve adroitly. XML-RPC can transport binary data as base64-encoded messages, much the way email clients send attachments. Because this feature is somewhat rarely used in XML-RPC applications, it's worth taking a look at a Web service that creates simple charts for client programs using this technique... As of this article's publication date, three Perl implementations of XML-RPC exist, all available at your local CPAN Web site. The oldest and best known of these is Frontier::RPC2, written by Ken MacLeod. Unfortunately, the current stable release, 0.06, has a bug that hampers transmission of base64 objects. The newest module, RPC::XML was written by Randy Ray, and it provides the really useful feature of introspection, which is a method that lets remote clients ask the server for the remote procedures it provides. It also provides type checking to ensure that clients are providing the kinds and numbers of arguments that the implementing Perl procedure expects. The module used in this article is SOAP::Lite. Recently, Paul Kulchenko added XML-RPC support to his existing SOAP package. The result is a very solid and surprisingly flexible XML-RPC library. One of the advantages of using the XMLRPC::Lite classes that come bundled with SOAP::Lite is that you can create XML-RPC servers that look like CGI scripts. This means that the XMLRPC::Transport::HTTP::CGI class lets your system's Web server worry about mundane HTTP issues (like authentication and logging) and lets you concentrate on implementing your Web service API..."
[March 15, 2001] "Getting Started with XML-RPC in Perl, Part 1. Using XML-RPC for Web services." By Joe Johnston (Senior Software Engineer, O'Reilly and Associates). From IBM developerWorks, Web services. March 2001 ['Creating an XML-RPC Web service with Perl is almost as easy as CGI scripting. This article will bring you up to speed on what XML-RPC is and how to use Perl's Frontier::RPC library to create simple clients and servers.'] "Remember the thrill of watching your first HTML form work? Perhaps you simply e-mailed the contents of the form to yourself or displayed another HTML page with whatever information the user entered. Whatever you did, you created what an information architect would call a two tiered or client/server system. With just a little additional work, the input gathered from a Web form can be stored in a database. In this way, multiple clients can interact with a single database using only their browser. The information stored in the database can be formatted into an appropriate HTML display on demand by CGI scripts. A typical Web application that uses this sort of architecture is a Weblog like SlashDot. The code that generates the HTML page is called the front end and the part that contains the database and business logic is called the back end. This system works very well until either your database or your Web server can no longer handle the traffic. If the bottleneck lies with your Web server, you may decide to simply add more Web machines to your network. If you connect to your database with native Application Programming Interface (API) calls in your front end, it becomes difficult to change the back end implementation. Switching database vendors or trying to cluster the database servers would mean changing all your front end code. The solution is to separate the presentation logic of the front end from the business logic of the back end, but they still need to be connected. The software that provides the conduit between the front end and the back end is called middleware. And one very simple, open architecture middleware protocol that works well in Web applications is XML-RPC. XML and RPCs: Remote Procedure Calls (RPC) are not a new concept. A client/server system, RPCs have traditionally been procedures called in a program on one machine that go over the network to some RPC server that actually implements the called procedure. The RPC server bundles up the results of the procedure and sends those results back to the caller. The calling program then continues executing. While this system requires a lot of overhead and latency, it also allows less powerful machines to access high powered resources. It also allows applications to harness the computational muscle of a network of machines. A familiar example of this type of distributed computing is the SETI@Home project. Dave Winer, of Frontier and Userland fame, helped extend the concept of RPC with XML and HTTP. XML-RPC works by encoding the RPC requests into XML and sending them over a standard HTTP connection to a server or listener piece. The listener decodes the XML, executes the requested procedure, and then packages up the results in XML and sends them back over the wire to the client. The client decodes the XML, converts the results into standard language datatypes, and continues executing..." Available also in PDF format. [cache]
[February 07, 2001] Sun Microsystems Proposes Java APIs for XML RPC. Sun Microsystems published a Java Specification Request for design activity that would provide consistent Java APIs for using emerging XML RPC standards. Reference: JSR-000101, Java APIs for XML RPC. JSR Review Closes 2001.02.12. Endorsers and initial Expert Group Members: Allaire, Apple, ATG, BEA, Bowstreet, Commerce One, HP/Bluestone, iPlanet, SilverStream, Sun Microsystems, webGain, webMethods. According to the text of the proposal, "There is considerable interest in using XML for 'Remote Procedure Calls', where a procedure call (or method call) on one computer is transmitted over a network as XML and is then delivered as procedure call (or method call) on another computer. In particular, there is now a W3C Protocol Working Group developing a standard XML protocol, 'XP', which supports XML RPC. The goal of this JSR is to develop APIs and conventions for supporting XML RPC protocols in the Java platform. There are three main needs to be addressed: (1) APIs for marshaling and unmarshaling arguments and for transmitting and receiving calls. These APIs should permit the development of portable 'stubs' and 'skeletons'. (A stub is a piece of code that runs on a client computer and maps a language level call into a network call. A skeleton is an analogous piece of code that runs on a server and maps an incoming network call to a language level call on the server.) (2) APIs and conventions for mapping XML RPC call definitions into Java interfaces, classes, and methods. The purpose of this 'forward mapping' is to allow XML RPC interfaces that have been defined in other languages to be mapped into Java. It is highly desirable to be able to map all XML RPC call definitions into Java. (3) APIs and conventions for mapping Java classes, interfaces, and methods into XML RPC call definitions. The purpose of this 'reverse mapping' is to allow programmers to define APIs in Java and then map them into XML RPC. There may be some constraints on which Java methods can be mapped into XML RPC. As part of mapping between XML RPC data types and Java types, this JSR will attempt to include support for existing Java language to XML mappings, such as those defined in JSR-031 'XML Data Binding' (and possibly also those defined in JSR-057 'JavaBeans Persistence'). The expert group will evaluate to what extent the XML RPC mappings and APIs should be aligned with the existing CORBA and RMI APIs and mappings. The JSR will make reasonable efforts to define APIs and conventions that are independent of specific protocols and data formats, and to define APIs that are 'pluggable' and can allow different protocols to be substituted. However, the initial primary focus will be on the emerging W3C XP standard. Where possible, the JSR will attempt to use or learn from existing work on Java XML RPC systems, especially work such as the Apache SOAP project. [Rationale:] There are already two major RPC systems in the Java platform, the OMG CORBA Object Request Broker, and the Java Remote Method Invocation (RMI) APIs. However, neither of these systems have been designed to work with XML RPC. Where practicable, this JSR should attempt to align with this existing RPC work. There are several existing JSRs that define XML APIs. These include JSR-031 'XML Data Binding', JSR-057 'JavaBeans Persistence', JSR-063 'Java APIs for XML Processing 1.1', JSR-067 'Java APIs for XML Messaging', and JSR-093 'Java APIs for XML Registries'. None of these APIs address XML RPC. However, the Java APIs for XML RPC should attempt to align with and exploit these existing APIs. In particular, it is expected there will be close liaison between this XML RPC JSR and the existing XML Messaging JSR, as it appears that it will be beneficial for these two JSRs to be closely aligned. Both styles of communication (asynchronous messaging and synchronous RPCs) are likely to be important, for different use cases." Please direct comments on the JSR to jsr-101-comments@sun.com. Contact: Graham Hamilton. See also Dave Winer's comment on the Sun JSR-000101. [cache]
[January 19, 2001] "XML-RPC: It Works Both Ways." By Dave Warner (Federal Data Corporation). From the O'Reilly Network Python DevCenter (January 17, 2001). "In my previous XML-RPC article, I showed how to access the Meerkat XML-RPC server (written in PHP) from Python. This time around, we will go behind the scenes to view the structure of an XML-RPC method call and response. Then we will develop an XML-RPC server using Fredrick Lundh's xmlrpclib. Lastly, we'll touch on some real-world concerns about XML-RPC, SOAP, and look at the W3C's working group that is driving development of XML-based distributed application standardization. A peek under the hood So how does xmlrpclib work? Its approach to the construction of method calls and responses is quite simple. A method called dumps (dump string) turns native Python objects into XML. The process is called 'marshalling'. The reverse process, called 'unmarshalling', is performed by loads (load string). Although transparent to the casual user, we can access these methods to peek under the hood. The dumps method takes three arguments: a tuple containing the parameters, the method name, and a method response. The last two are optional. Following good object-oriented design, xmlrpclib's dumps insists that the parameters are passed in the form of a tuple. This prevents modification of the parameters past this point. Let's examine the structure of a method call used with Meerkat. At this point, no connection is needed. We are simply examining what will be sent, not actually communicating with a server... For ease of use, xmlrpclib wins hands down for communicating with Meerkat. But does XML-RPC have a future? Yes! Athough the lure of wide-spread corporate backing is pushing many toward the Simple Object Access Protocol (SOAP), XML-RPC is in use today in some surprising places. Red Hat uses xmlrpclib.py in its new subscription service, and also internally. Their implementation of xmlrpclib ships with Red Hat 7 and includes enhancements by Cristian Gafton that include https support. Additionally, Userland's Frontier is fully XML-RPC aware, as is the Apache Java Project's Turbine framework and, by extension, Jetspeed. So, where does that leave SOAP? Recently, the W3C established a working group on XML protocols. They have published a draft requirements document. Although they are using SOAP as their starting point, it is unlikely that SOAP will remain unchanged by this standardization process. I don't expect SOAP to go away any time soon, but I do expect it to be in flux for the next year or so. Hopefully, the example above has shown that XML-RPC is not just a step on the way to SOAP and beyond, but a useful, simple tool in its own right. When XML-RPC was first introduced, Jon Udell asked the question: 'Does distributed computing have to be any harder than this?' Much of the time, no." See also "XML-RPC."
[February 05, 2001] "Bootstrapping. Using Python and XML-RPC to create a practical, real-world XML application: writing scripts that create a new story on the server. [COLLABORATION.]" By Dave Winer (UserLand Software). In XML Magazine Volume 2, Number 1 (February/March 2001). ['To get the benefits of using XML, developers have to work together, supporting implementors working in different environments, even supporting competitors. Why bother? Columnist Dave Winer says, because it's fun.'] "When engineers build a suspension bridge, first they draw a thin cable across a body of water. Then they use that cable to hoist a larger one. Then they use both cables to pull a third, and eventually create a thick cable of intertwined wires that can support a road that hundreds of cars and trucks can drive over at the same time. That's a bootstrap. First you take a step you know is on the path, learn from it, and use it to lift up the next level. And unlike the designer of a suspension bridge, software developers must be more flexible, because the pace of innovation in our art is so rapid. We don't know exactly what next year's trucks will look like, how much they weigh, or how many wheels they have. I'm interested in a community of developers working together to create desktop tools and server apps that work together. That's why I got involved with XML-RPC and its successor, SOAP. As I've said in previous columns, XML is the common format, but to get the benefits of using XML we have to work with each other. This means supporting implementors working in different environments, even competitors. That's how markets grow, and developer to developer, that's why it's fun -- not only do I get to impress you with my software, but I also get to enjoy other people's creations. I've created a Web application called Manila, that runs on Windows 2000 on servers that my company runs at Exodus in Santa Clara, CA. You can create a free Manila Web site and use it to publish your thoughts and links to articles you find interesting. That's great, but there's a hidden feature in every Manila site: It's scriptable over the Internet via SOAP and XML-RPC. If you've wondered when someone would put up a practical real-world XML application, the wait is over. In the rest of this column, I'll show you how to write Python scripts that use XML-RPC to create a new story on the server, and copy the content of a message to a file on my local hard drive. I chose XML-RPC because it's more mature, and offers more choices today than SOAP does. You can see a list of XML-RPC implementations here: http://www.xmlrpc.com. So if your preference is Unix, or Mac, or Windows; Python, Java, Tcl, Perl, or even my own Frontier, you can find compatible implementations and start building your own distributed applications with XML. By this time next year, surely SOAP will be as mature and as broadly supported. We needed a thin cable, XML-RPC to pull up SOAP, and then to pull up new applications, and then build systems. We're going to learn a lot in the next few years, and if XML achieves its promise, we'll share much of what we learn, and that'll be a bootstrap, and that'll be fun."
