| ACADEMIC COMPUTING and COMMUNICATIONS CENTER | |||||||||
SOAP: XMP Under the Covers | ||||
If you think XML is just a new, improved HTML, think again. Related protocols such as SOAP, Simple Object Access Protocol, make it a whole lot more. SOAP is a new way for programs to communicate with other programs, using XML. Normal humans like us won't see this type of XML rendered in any way, but SOAP will make it much easier for programmers to write applications that we humans can use. Programmers know the value of subroutines. They're the only sensible way to deal with medium-to-large programs: chop them into pieces, with each one encapsulating a different, distinct bit of behavior. Then to perform the overall task, you call the subroutines, or have them call each other, in the right order. Wouldn't it be particularly clever if we could get our subroutines to run on different computers? This is a networked world, after all, and it makes sense to harness many computers at once. Sometimes this is done simply to increase CPU power. But in most cases, it's done because you want to obtain or change some information that resides on the remote computer. The process of using remote subroutines as if they were local is called RPC, Remote Procedure Call. Mind you, there are a lot of difficulties making RPC work well. Sending and retrieving data across a network, when the remote machine may or may not be up or responding, is tricky. But the overall concept has a lot of followers, each with their own standards -- DCE RPC, CORBA, RMI, and DCOM, just to name a few. And now, SOAP. Why SOAP, when there already are so many other standards to choose from? In a word, S is for Simple. Each of the other protocols does a lot more and carries a lot more baggage. If you just want the basic functions, independent of language and independent of operating system, with a minimum of runtime services, SOAP may be the best call. SOAP uses XML to encapsulate the data that needs to be sent to the remote subroutine. And, of course, XML is used to return data from the subroutine and to return notification of any error condition that might have occurred. Any mode of transport can be used for SOAP calls, although HTTP will probably be the most popular. That's right, the same HTTP that a Web browser uses to talk to a Web server. After all, HTTP can transmit Web pages, even through firewalls, and XML pretty much looks like a Web page, even if the tags and content have a completely different meaning. That's one sign of a well-designed protocol -- it can be used cleanly in new circumstances. This article is not a SOAP tutorial, just an example of how XML can be used to transfer data from one program to another. Suppose I manage twenty workstations and I need to monitor the status of the Web server I'm running on each of them. (Is the Web server up? Heavily loaded? Down?) Instead of logging onto each one in turn, I put a SOAP server on each (which is not much more than a standard Web server and a CGI script), then I have a central machine send a SOAP request to each one in turn and compile their answers into a report. The SOAP message might be as simple as: <SOAP:Envelope> <Getstatus> <Process>httpd</Process> </Getstatus> </SOAP:Envelope> I've left off some small details related to XML namespaces, but the basic idea is clear: I want to execute the remote subroutine named <Getstatus> and pass it a single parameter whose name is <Process> and whose value is httpd -- send me the status of the HTTPD process that's running on the machine. Once the SOAP server is ready, it's easy for anyone else to write their own SOAP clients for their own purposes. They can write their processes in perl, C++, Java, COM, JavaScript, or Python, and run them on just about any machine. This simplicity and interoperability make this a very appealing scheme. SOAP is by no means the only way to transfer data via XML. There are quite a number of protocols under development, many driven by the needs of business-to-business e-commerce. XML is used because of the ease of interoperability it provides. For more about SOAP, see: http://www.soap-wrc.com/webservices/default.asp ebXML, electronic business XML, is a more ambitious, business-oriented XML transport protocol; it's at: http://www.ebxml.com/ And there are many more.
|
||||
| The A3C Connection, July/Aug/Sept 2000 | Previous: Processing XML: XSLT | Next: RSS: Spreading the News |
| 2000-10-13 connect@uic.edu |
|