Simple Object Access Protocol: Application of soap (turn)

Object | Access Simple Object Access Protocol: application of Soap

SOAP, a new communication protocol developed by the World Wide Web Consortium, is the abbreviation for the Simple Object access Protocol (Chinese: The easy Objects accessing protocol), which is currently available from IBM, Ariba, Commerce One, SAP, Compaq, The support of HP and other companies. It enables different applications to exchange data with each other through HTTP communication protocols in XML format. Because HTTP communication protocols are ubiquitous on the web and XML parsers are fairly easy to obtain, soap can be easily applied and developed. Of course these conveniences have a price: sacrificing some of the speed of running, so soap itself is not used to replace the original low-level program, but if the programmer's main consideration is to be able to easily communicate with other systems, then soap can indeed play its role. SOAP development tools have been available in many development environments, including Python,java,visual Basic,perl. Programmers with remote procedure call API programs, such as Java RMI or Microsoft COM +, will find that SOAP development tools have a sense of déjà vu.

Here I show you how to use the Perl programming language to develop a network service (WEB services) and how to build an application on a SOAP server.

First go to http://www.soaplite.com download SOAP::Lite tool program, it is a Perl program module, just install this set of modules and related function library (related data address: http://www.soaplite.com/# Prerequisites), you can start writing SOAP service programs.
Before we start designing a SOAP Listener (listener), we need to understand how SOAP handles requests from clients. First the client sends an XML file to the server called the "soap package (envelope). After the server receives this file, it analyzes the file, reads the category name (class name) and function name, and establishes a corresponding relationship between these names and the specific Perl program objects. In the example program below, we create a category called World, which contains two functions HelloWorld and Goodbyeworld:

Package world;
Sub New {
Bless {}, shift;
};
Sub HelloWorld {
My ($self) = @_;
Return "Hello world\n";
};
Sub Goodbyeworld {
My ($self, $adjective) = @_;
Return "Goodbye $adjective world\n";
}
1;


While it is not possible to actually see what a SOAP request looks like, knowing how the SOAP request content works behind the scenes is helpful for debugging the program. Here, we use this very simple example to illustrate how the SOAP client asks for the world category mentioned above and calls the HelloWorld function inside:


<?xml version= "1.0" encoding= "UTF-8"?
<soap-env:envelope
xmlns:soap-enc=http://schemas.xmlsoap.org/soap/encoding/
Soap-env:encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi=http://www.sorw.org/2001/xmlschema-instance
xmlns:soap-env= "http://schemas.xmlsoap.org/soap/envelope/"
Xmlns:xsd= "Http://www.sorw.org/2001/XMLSchema" >
<SOAP-ENV:Body>
<namesp1:helloworld xmlns:namesp1= "World"/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


You can see very clearly in this XML file where the envelope and the body begin: The HelloWorld function is called inside the bodies. In the line description, the value of the namespace (namespace) property is the name of the function we are calling, and the value of the XML namespace (XML namespace) property is the name of the object class to which the function belongs. In this example, we call the Hellowworld function of the World object class. When we want to call the Goodbyeworld function, most of the content does not need to be modified, as long as the body part of a slight modification can be:

<SOAP-ENV:Body>
<namesp2:goodbyeworld xmlns:namesp2= "World"
<c-gensym9 xsi:type= "xsd:string" >cruel </c-gensym9>
</namesp2:GoodByeWorld>
</SOAP-ENV:Body>


Since soap itself is passed through the HTTP communication protocol, we can directly take advantage of the Web server-related functionality provided by Perl itself. First, write a simple CGI program that sends incoming requests to the world class that we've written before, and sends the response information generated by SOAP back to the browser. Please do not forget to confirm that your server supports CGI programs before you begin execution, and set the permissions of the program to allow execution. The following CGI program receives the SOAP request and passes it to the world category we wrote before:

#!/usr/bin/perl
Use Soap::transport::http;
Use world;
soap::transport::http::cgi
Dispatch_to (' World ')
-> Handle;


That's all we have to do, and the rest of it is left to the SOAP module to handle. You must write a CGI program similar to the one above for each SOAP class you intend to call. Also note that the parameter used in the Dispatch_to () method above is the name of the SOAP class you want to link to. When writing a SOAP class, be aware that these categories must be the same as other categories, and that there must be a method named new $self to be the first parameter to use when calling other methods. Place the wrapper name (package name) in the first line of the program code, and then store the module in. PM as an extension (refer to the World Class sample program mentioned earlier).

SOAP::Lite can also dynamically load different modules based on the required name, which allows us to write a CGI program that can load any one of the modules in a directory. This approach is less secure, and it is not easy to control which module to load, but the various SOAP modules are unified in the same directory, the file management is indeed more convenient. To dynamically load different soap modules, we must remove the relevant use narration and use the directory path that holds the SOAP module file as the first parameter of the Dispatch_to () method:

#!/usr/bin/perl
Use Soap::transport::http;
soap::transport::http::cgi
Dispatch_to ('/home/httpd/soap_modules/')
-> Handle;


SOAP client programs are as easy to write as SOAP server programs. All you need to do is load the SOAP::Lite module and know some information about the remote service (or "endpoint endpoint" "). In fact, gathering information about remote services may be the hardest part. You must know the URL of the remote server, the namespace URI of the method the server provides, and the names of these methods and the parameters that need to be passed in. Once this information has been obtained, we can begin writing a SOAP client program. In the example program below, I write a client program for the SOAP server that I just built:

Use SOAP::Lite;
My $s = soap::lite
->uri (' World ')
->proxy (' http://soapserver.mycompany.com/soap/soapserver.cgi ')
->helloworld ();
Print $s->result ();
My $s = soap::lite
->uri (' World ')
->proxy (' http://soapserver.mycompany.com/soap/soapserver.cgi ')
->goodbyeworld ("cruel");
Print $s->result ();


In this program, the URI accepts a parameter that is the name of the category on the remote server that we intend to call. But not every SOAP server follows this practice in practice, so you may have to confirm the correct value for the URI here. The parameter accepted by the proxy method is the URL of the SOAP handler (handler) above the remote server. Each time you try to go online to the server, you must provide the URI mentioned above and the proxy before you can succeed online correctly. Finally, we can call the method above the remote server, in which we call the HelloWorld () and Goodbyeworld ("cruel"), and the result () function to get the response information of the server. Please note that although all two of the methods we call are from the world category, we have two separate transactions in place to create two entities (instance). This means that two entities are not aware of each other's current state, so they cannot communicate with each other. For example, you can't set a class value on one of these entities, and then try to get that value on another entity.

The SOAP service program may also require that the client provide a specific SOAPAction field, which is routed through the HTTP header. To set the value of this parameter, you can use the On_action method to cover the preset processing. Take a look at the example program below:

My $s = soap::lite
->uri (' World ')
->on_action (Sub {return "/action#action"})
->proxy (' http://soapserver.mycompany.com/soap/soapserver.cgi ')
->goodbyeworld ("cruel");
Print $s->result ();


In practice, if you need to understand some debugging information, the SOAP::Lite module provides an option to view the details of the communication between the client and the server. This option displays the details of the entire request process and is useful when tracking program errors. Error messages are most often derived from incorrect URI or proxy settings, which appear in the contents of the SOAP envelope (packet). To use this feature, you can display the debug information on the standard error output stream (STDERR output streams) as long as you add +trace => all after the SOAP::Lite narration.

Use SOAP::Lite +trace => all;
My $s = soap::lite
->uri (' World ')
->proxy (' http://soapserver.mycompany.com/soap/soapserver.cgi ')
->goodbyeworld ("cruel");
Print $s->result ();


The SOAP::Lite module also provides a feature called AutoDispatch, which allows you to directly call the method provided by a remote server in a Perl program. Once the AutoDispatch feature is activated, when you call the program without a defined method, these calls are automatically routed to and executed on the remote server. The AutoDispatch feature allows soap to be incorporated into the Perl program without trace, as long as it is connected to a remote server and then directly to the various methods provided on the server, without having to refer to the SOAP object first.

Use SOAP::Lite +autodispatch =>
uri=> "World",
proxy=> ' http://soapserver.mycompany.com/soap/soapserver.cgi ';
Print HelloWorld ();
Print Goodbyeworld ("Sweet");


In the above program, because HelloWorld () and Goodbyeworld are not defined in our Perl program, they are routed directly to the remote server set by the proxy for execution. Using the AutoDispatch function is like inheriting other categories, so when calling the method provided by a remote server in your program, make sure that the remote server has already defined these methods for use.

Summary:

In reality, it's easy to use soap in Perl. It doesn't take much to create a server or write a client to make a request to the server. When you have a certain understanding of soap, believe that you can create new Web services, or directly using the services provided by other SOAP servers to enhance your site's functionality