chinmay.sahoo
New member
XML Remote Procedure Calling[39] (XML-RPC) is an XML standard that’s mcommonly used for exchanging data between Web servers on the Internet. It allows you to store your data on one server, while displaying it in a Web page on a completely separate server. This would allow you to make that data available to other Webmasters, for example. Think of it as a generalized variant of an RSS
feed, and you’re not far off.
XML-RPC is a complete messaging protocol, where all the requests and responses are XML documents. The standard falls under the umbrella buzzword Web services, and is the forerunner to Simple Object Access Protocol[40] (SOAP), the current “king” of Web services. Here, I’ll assume you have a grasp of what Web services are about, if not the actual syntax of XML-RPC. If you’re not sure, you’ll find recommended material in the section called “Further Reading” at the end of this chapter, including an article that focuses purely on XML-RPC.
Why would we bother with XML-RPC if SOAP’s around? The answer is a combination of preference and practicality. XML-RPC is a lightweight protocol for data exchange, which is very easy to understand and well-supported in many languages. It’s great for intranet applications and data exchange on the Internet where you’ll be collaborating with a small group of like- inded developers. SOAP has a much more complicated specification and, as a result, is much more difficult to support correctly and reliably. Today, few, if any, of the SOAP implementations, including commercial offerings from the likes of Microsoft and IBM, fully support all facets of SOAP to 100% perfection. Part of the problem is its reliance on XML Schema[41], which most XML toolkits are still struggling to catch up with. Having said that, SOAP has the advantage that it comes with supporting technologies such as Web Services Description Language[42] (WSDL). These make it possible to build SOAP Web services that can be consumed by the many, rather than the few. If you’re planning something “big,” such as the delivery of mcommercial Web services, SOAP is probably the right choice for you .
feed, and you’re not far off.
XML-RPC is a complete messaging protocol, where all the requests and responses are XML documents. The standard falls under the umbrella buzzword Web services, and is the forerunner to Simple Object Access Protocol[40] (SOAP), the current “king” of Web services. Here, I’ll assume you have a grasp of what Web services are about, if not the actual syntax of XML-RPC. If you’re not sure, you’ll find recommended material in the section called “Further Reading” at the end of this chapter, including an article that focuses purely on XML-RPC.
Why would we bother with XML-RPC if SOAP’s around? The answer is a combination of preference and practicality. XML-RPC is a lightweight protocol for data exchange, which is very easy to understand and well-supported in many languages. It’s great for intranet applications and data exchange on the Internet where you’ll be collaborating with a small group of like- inded developers. SOAP has a much more complicated specification and, as a result, is much more difficult to support correctly and reliably. Today, few, if any, of the SOAP implementations, including commercial offerings from the likes of Microsoft and IBM, fully support all facets of SOAP to 100% perfection. Part of the problem is its reliance on XML Schema[41], which most XML toolkits are still struggling to catch up with. Having said that, SOAP has the advantage that it comes with supporting technologies such as Web Services Description Language[42] (WSDL). These make it possible to build SOAP Web services that can be consumed by the many, rather than the few. If you’re planning something “big,” such as the delivery of mcommercial Web services, SOAP is probably the right choice for you .