Programming Web Services with XML-RPC
Pages: 1, 2, 3
Joining Meerkat and the Discussion Server
Now we have two XML-RPC applications at our disposal: Meerkat, to explore stories on web sites, and our discussion server, which can annotate arbitrary items as long as they can be given a string identifier.
PHP and XML-RPC can be used to synthesize these two applications into a new one, allowing spontaneous discussions to take place around news stories. Figures 5-2 and 5-3 show the user interface for such an application. Users can browser Meerkat's database, and whenever stories that have comments are found, the comments are displayed against them. A link gives the option to add a comment to a story.
|
|
|
|
Example 5-3 gives a complete listing of the code required to build this application.
A Closer Look at the Meerkat Discussion Server
![]() Programming Web Services with XML-RPC By Simon St.Laurent, Joe Johnston & Edd Dumbill
Foreword by Dave Winer |
|||||
After reading this chapter, there should hopefully be no surprises for you in the Meerkat discussion application. It is a purely client-based application, creating two xmlrpc_client objects: one for Meerkat and one for our discussion server. However, there are some features worth noting:
- The
dispatch( )function wraps all the common error handling required in processing XML-RPC method calls. It may prove useful in your own programs. - The application uses a naïve implementation. Within one invocation of this script, many XML-RPC method calls are generated. HTTP connections are slow to create, and thus it is advisable to make as few method calls as possible within one script. Several tactics could be used to reduce this overhead, such as:
- Redesigning the server API to return more data per method call. The discussion server might be redesigned so that
discuss.getComments( )accepts an array of IDs as its argument and returns an array of arrays holding the comments for each ID. - Caching returned results. In our application, the entire list of categories is retrieved each time, regardless of whether it has changed or not. For data that changes infrequently it may be acceptable to cache data, once retrieved, for the rest of the user session. One way to do this in the discussion application would be to use frames to separate the category, channel, and story lists, and to add some JavaScript to enable the frames to interact with each other. This would entail reorganization of the PHP script to support this new architecture.
In general, it is not wise to include many XML-RPC calls in applications that require rapid user feedback--although many factors, such as server load and network conditions, obviously affect this decision.
What PHP and XML-RPC Can Do
|
Related Links |
This chapter demonstrates the use of PHP in creating XML-RPC client and server applications. PHP is ideal for creating XML-RPC web services in an environment that already has a running web server, and thus for adding XML-RPC interfaces to existing web applications. This chapter also shows the strengths of PHP used as a web integration language, bringing together disparate applications under one user interface.
Although normally thought of as a frontend application tool, PHP can now be a viable choice for creating backend systems by using XML-RPC as a middleware language. Consider the advantages of hiding access to a database behind an XML-RPC service. You could use PHP's native database routines to tightly control access to the underlying data store. CGI applications written in any language can then retrieve information from the database without actually knowing anything about the particular Relational Database Management System (RDBMS) used.
The possibilities for web services are only now being explored. PHP makes that exploration both easy and fun.
Return to XML.com.
