Tutorials to .com

Tutorials to .com » Dotnet » Webservice » Simple Object Access Protocol: SOAP Application <zt>

Simple Object Access Protocol: SOAP Application <zt>

Print View , by: iSee ,Total views: 11 ,Word Count: 2320 ,Date: Wed, 20 May 2009 Time: 10:03 PM

SOAP, is the World Wide Web Consortium (W3C) developed a new communication protocols: Simple Object access Protocol (Chinese: Simple Object Access Protocol) in English abbreviation, the current has been IBM, Ariba, Commerce One, SAP, Compaq, Hewlett-Packard companies. It between different applications through the HTTP protocol to xml format to exchange information with each other. Since the HTTP protocol on the network ubiquitous, and xml parser would be quite easy to obtain, so SOAP can easily be applied and development. Of course, these convenience comes at a cost: the expense of some speed, so SOAP is not a substitute for the original low-level procedures, but if the program is a major consideration for designers can easily communicate with each other and other systems, then SOAP can indeed play its effectiveness. SOAP development tools in many development environment can be achieved, including Python, Java, Visual Basic, Perl. We have remote procedure call API procedures (such as Java's RMI or Microsoft's COM +) development experience will be a programmer to use SOAP development tools category has a sense of deja vu.

Here I would like to tell you how to use the Perl programming language to develop Web services (Web services), and how to establish a SOAP server application above.

First of all, to http://www.soaplite.com Download SOAP:: Lite tool, it is a Perl program modules, as long as this module is installed and the relevant libraries (the relevant information Address: http://www.soaplite . com / # Prerequisites), we can start the preparation of a SOAP service program.
At the beginning of the design of a program SOAP listen (listener), we must first know how to handle SOAP requests from the client. First of all, the client will send a xml file to the server, known as "SOAP package (envelope)". Server receives the document will analyze the documents, read the file containing the class name (class name) with the function name (function name), and in these the name of the Perl program with a particular object relationship between. In the following example program, we have established a group called the World categories, including two function HelloWorld with 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;

Although we are unlikely to actually see a SOAP request (request) what looks like, but the SOAP request for the content of these behind-the-scenes work, the debugging process would be helpful. Here, we use the following very simple example to illustrate how the SOAP client of the World category of the above-mentioned request, and call 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 in this XML document is very clear to see the packets with the main (body) of the places to start: HelloWorld function is called inside the body. Described in the bank, the namespace (namespace) attribute is the value of the function we want to call names, and XML Namespaces (XML namespace) attribute value is attached to the function by the name of the object categories. Which in this case, we call the World object HellowWorld function categories. When we GoodByeWorld function to call when the majority of content without modification, as long as the body part will be some slight modifications:

<SOAP-ENV:Body>
<namesp2:GoodByeWorld Xmlns:namesp2="World">
<c-gensym9 Xsi:type="xsd:string"> cruel </ c-gensym9>
</ Namesp2: GoodByeWorld>
</ SOAP-ENV: Body>

SOAP is adopted as a result of their own HTTP protocol to pass, so we can direct the use of Perl on their Web server-related functions. First of all, the preparation of a simple CGI program, this program will receive a transfer request to write to us before the World category, and the generated SOAP response information back to the browser. Prior to the start Do not forget to confirm your server supports the CGI process and the authority to set the program to allow implementation. The following CGI program will receive SOAP requests and passed on to our written before the World Category:

#! / usr / bin / perl
use SOAP:: Transport:: HTTP;
use World;
SOAP:: Transport:: HTTP:: CGI
dispatch_to ( 'World')
-> Handle;

We have to do only these, the remaining part of all to the SOAP module to deal with on the list. You have to call you intend for each category of SOAP are similar, respectively, to write a CGI program above. In addition, we must note that in the above dispatch_to () methods are used inside the parameters that you want to link the name of the SOAP types. SOAP category in the preparation of a time when attention should be paid to these categories and other categories must be the same, there must be a new method (method) $ self to do, when to call other methods used in the first parameter. The package name (package name) on the first line of code, and then to this module. Pm as the store extension (please refer to the World category of the above-mentioned examples of procedures).

SOAP:: Lite can also be requested based on the name to dynamically load different modules, this feature allows us to prepare a directory to load a module in any one of the CGI program. This is the relative lack of security, but also less easy to control exactly which module to load, but the unification of the various SOAP module placed in the same directory in the file management will indeed be more convenient. Dynamic loading to a different SOAP module, we must use the relevant description removed, and the SOAP module stored the directory path as a file dispatch_to () method of the first parameter:

#! / usr / bin / perl
use SOAP:: Transport:: HTTP;
SOAP:: Transport:: HTTP:: CGI
dispatch_to ( '/ home / httpd / soap_modules /')
-> Handle;

SOAP Client SOAP server as easily as the preparation procedures. You only need to load the SOAP:: Lite module, and that some long-distance services (or "endpoint endpoint") information on the list. In fact, long-distance services to collect relevant information and it is possible that some of the most difficult. You have to know the remote server's URL, the server containing the method of the services provided by the namespace URI, as well as the names of these methods into the parameters and needs. Once this information has been made, we can begin to write a SOAP client program has been. In the following examples of procedures which, I just set up in front of a good server to write a SOAP client:

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 process there, uri parameter is acceptable to the remote server is our intention to call the top of the category name. But not every SOAP server in its operation, follow this practice, so you may have to check another URI where the correct value should be used. acceptable proxy method parameter is the distance above the SOAP server process (handler) the URL. Every line in an attempt to the server at all times to provide the above-mentioned URI and proxy, the right line to success. Finally, we will be able to call the method above, the remote server, and in this case which we call the HelloWorld () and GoodByeWorld ( "cruel") of these two methods, and through the result () function to obtain information on the response from the server. Please note although we call the two methods are from the World in this category, but here we have adopted two separate transactions to create the World category of the two entities (instance). This means that between the two entities and have no way of knowing the current state of each other, so they can not communicate with each other. For example, you can not an entity in which a class above the value set, and then trying to get in another entity above this value.

SOAP services may also require the client to provide a specific SOAPAction field, this parameter will be sent through the HTTP head table. To set this parameter, you can use the method to outweigh on_action default approach. See the following procedures for this example:

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 know some information on debugging, SOAP:: Lite module provides an option to see the client and server communication between the situation in details. This option will display the entire course of the detailed information requested in the follow-up procedure is very useful when an error. From the most common error message in the URI is incorrect or proxy settings, this information will appear in the SOAP packet (packet) inside the text. To use this feature, simply use SOAP:: Lite are described followed by the + trace => all, on the debugging information can be displayed on standard error output stream (STDERR output stream) of the above.

use SOAP:: Lite + trace => all;
my $ s = SOAP:: Lite
-> Uri ( 'World')
-> Proxy ( 'http://soapserver.mycompany.com/soap/soapserver.cgi')
-> GoodByeWorld ( "cruel");
print $ s-> result ();

SOAP:: Lite module also provides a function called Autodispatch, it can let you program in Perl which directly call methods provided by the remote server. Once activated Autodispatch function, when you call the definition of procedures for which there is no way, these calls are automatically transferred to the remote server and the implementation of the above. Autodispatch feature allows SOAP integration without leaving any traces in the Perl program which, as long as the link on the remote server, and then you can directly call the server methods provided above, without need to refer to SOAP object.

use SOAP:: Lite + autodispatch =>
uri => "World",
proxy => 'http://soapserver.mycompany.com/soap/soapserver.cgi';
print HelloWorld ();
print GoodByeWorld ( "sweet");

Inside the procedure above, as HelloWorld () method with the two GoodByeWorld in our Perl program which are not defined, they will be directly transferred to the remote proxy server set to the implementation of the above. Autodispatch features like the use of other types of succession, as in the procedures which call methods provided by the remote server time, make sure the remote server has been defined above is indeed a good use of these methods for the.

Summary:

In reality, through Perl using SOAP is a very easy thing. Regardless of the preparation of the establishment of a server or a client request to the server, what efforts are not spent. In a certain understanding of SOAP, I am sure that you will be able to create a new Web service, or direct access to other services provided by SOAP server to enhance your website functionality!


.Net WebService Articles


Can't Find What You're Looking For?


Rating: Not yet rated

Comments

No comments posted.