by July 9, 2003 0 comments



The task of creating and deploying Web services is not very different from doing the same for the more traditional Web applications. The SOAP tool kit is all that a programmer needs to implement a Web service. It acts as an abstraction layer over XML, hiding all the gory details from the programmer as well as issues like XML parsing. A Web service typically has three components–a listener to receive the XML message, a proxy component that takes the XML message and translates it into an action to be carried out, and the application code that implements such an action. 

Perl’s SOAP::lite module can be used to create all three components seamlessly, using very few lines of code. If you have the latest active Perl, then this module should be included with the distribution. Otherwise, you can install it using the following on any operating system:

perl — MCPAN —e shell 
cpan>install

You’ll have to be connected to the Internet for this command to work, as the module is downloaded directly from CPAN (Comprehensive Perl Archive Network). 

Now let’s see how a simple Web service can be written. This Web service essentially looks up a database of a phone book takes the name as input and returns the corresponding address. Typically the proxy component needs to be mounted over a Web server. This tool kit also has support for a HTTP daemon, which can act as a lightweight http server.

Use soap::Transport::HTTP::Daemon;
Use example; 
My $serv=SOAP:Transport::HTTP::Daemon
->new (LocalPort =>80) 
->dispatch_to(‘./’) ; 
$serv->handle;

Writing the Web service
We’ll first write the proxy component and listener below. This one makes use of a built in http daemon. However, this should be hosted on a Web server in a production environment.

Save this file as server.pl. This forms the wrapper around the Web service application code for serializing the output and input to/from the Web service as XML. Now, we’ll write the application code. 

The following application code is saved as example.pm in the same directory as the above. Here as you can realize the application code does not need to know nor does it realize that it has been invoked as a Web service. This is possible because of the modular structure of creating a Web service in Perl. The application code is completely separate from the mechanism that forms the wrapper for creating the Web service. So, you can use the same application code with any other program because it’s nothing but a simple Perl script. This structure can help in putting existing code from any other application into a Web service without any modification. 

Package example 
use DBI ;
sub address { 
my $name=@_ ; 
# connecting to the user database
$db = DBI->connect(“dbi:ODBC:address”, “user”, “password” ,
{ RaiseError => 1, AutoCommit => 0 });
# the currently the dbi connect string connects to a Msaccess database .. you can change it #it connect to a msql database so on and so forth .
$query = “select address from userdata where name=’$name’” ;
$statement = $dbh->prepare($query);
$statement->execute();
$add = $statement->fetchrow_array ;
return $add ;
}

Accessing the Web Service
In order to access the Web service we just wrote and posted on a Web server the following client code 

Save this file as client.pl Here, we’ve put the client on the same machine as the server and are using the localhost IP
(127.0.0.1) to access it. 

Use SOAP::Lite ; 
My $example =SOAP::Lite 
->uri (‘examples’)
->proxy(‘http://127.0.0.1’) ; 
# 127.0.0.1 may be replaced accordingly with the ip address of the machine on which the 
# server is being run
print $example ->address(“vinod”)->result ; 

Testing the Web service
To test this Web service, open the command prompt or terminal and execute server.pl using the following command:

perl server.pl 

Now on a second terminal or command prompt execute client.pl similarly.

If all is well, the output of the client should be address corresponding to the name (Vinod in this case) in the database (address). 

That’s it. We’ve written a simple Web service in Perl. This is however, not even the tip of the iceberg. Interested souls can refer to the documentation accompanying the Perl distribution and create their own Web services and clients. However a word of caution–out of the box interoperability between various SOAP toolkits, more specifically between .NET‘s soap implementation and SOAP::Lite is not there. The reasons for this include the fact that Perl is a type less language, that is, the type of a variable is not defined explicitly, but rather it can be interchanged depending on the context. For example, the same variable can act as an integer when used in a mathematical expression and as a string when concatenating. However this is not the case with the other ‘compiled languages’. Automatic WSDL generation like in .NET implementation is something that is not there, and it also has limited WSDL parsing capabilities. 

Ankit Khare

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

Your data will be safe!Your e-mail address will not be published. Also other data will not be shared with third person.