Cameron Laird
Spring, 2002
"Ready to join the Web Services revolution" However immune you are to such marketing-driven labels, there&'s a valuable technical core to Web Services (WS), and it's likely to lead to important changes, if not a revolution. Don't let those changes make you uneasy, though -- you'll continue to find that Perl is one of the best ways to get your work done.
The major vendors speak as though Visual Basic and Java are the natural ways to program WS. That's only part of the story, though. This article will show how freely available code makes it simple and useful to write COM-WS gateways in Perl.
SOAP and COM Basics
In fact, this is the sort of job that's easier in Perl than in better-advertised languages. Consider the Simple Object Access Protocol (SOAP), the principal underlying transport for WS applications to communicate with each other. Despite the official description of SOAP as a "lightweight" networking method, leading SOAP toolkits weigh in around 100 MB to start. With Perl, though, SOAP is built in to the compact popular ActivePerl distribution for Windows and other platforms.
SOAP passes objects -- both methods and data -- between hosts. It's a method for distributed computing, that is, for sharing calculations between separate computers. Consider this comparison: a Web server makes a document on one machine available to any user with a Web browser; SOAP uses many of the same mechanisms to make a calculation one computer can do available to other computers that need the result.
What does that have to do with Microsoft's Component Object Model (COM)? Microsoft advertises COM as "the most widely used component software model in the world." COM is the way much software is "re-used". Suppose, for example, that someone has worked up an Excel spreadsheet that calculates medical supplies that a hospital department needs to re-order periodically. There are several different functional uses of that calculation -- to adjust budget estimates, to order from suppliers, and so on. An older generation of software embedded the source form of the calculation in each of the several different applications that needed it. COM factors out that redundancy, by giving applications the ability to dynamically communicate with Excel at calculation-time. Responsibility for performing the specific calculation remains in a single place, in the spreadsheet, with results communicated back and forth between the spreadsheet and client applications.
That's how COM should work, at least. There are several difficulties with this sketch, though. COM expects all processes to reside on a single host -- a single desktop, typically. Moreover, that desktop must be Windows, or at least an operating system that emulates Windows rather closely.
SOAP's Benefits
This is where SOAP starts to look good. SOAP operates almost everywhere. Its base technology is close to that of the World Wide Web, so it's almost equally ubiquitous. In particular, it's common to access a SOAP service from anywhere --from a MacOS desktop, from a monitoring mainframe, or from embedded mobile devices. SOAP serves more than just Windows.
That's why many organizations with significant investments in information technology are looking for ways to generalize the resources they have with WS gateways or wrappers. Basic functionality continues to operate as legacy code without interruption, but WS makes the information available pervasively.
Plenty of toolkits from proprietary vendors offer gatewaying features. You'll find, though, that a simple Perl wrapper is plenty easy to program, and no more difficult to configure usefully than the commercial packages.
Assembling Ingredients
Configuration is often the biggest obstacle to progress in this sort of work. It can take more time to prepare the ingredients for a savory SOAP recipe than it does to whip them up into a working process.
For this first example, we need:
I'll use Internet Explorer (IE) as my COM server for discussion purposes. Why not Excel, which seems to be the engine for a plurality of all COM automations in production? Excel is sub-optimal for learning COM, in several small respects -- perhaps the most compelling is that it's expensive. You probably have access to IE already, and even if you don't, it's only a no-charge download away. Once you're comfortable with IE's COM facilities, it's easy to make the transition to Excel, Access, or any of the thousands of COM-enabled third-party applications.
Any common Web server will do. In my experiments, I generally use a home-brewed server that I've customized through the years to meet my own needs. Any version of Internet Information Server (IIS), Apache, Roxen, and so on, should fare just as well in this demonstration. Just be sure you understand how to configure scripts so they're properly invoked as Common Gateway Interface (CGI) processes.
As you move to production, you'll likely consider switching to mod_perl or a comparable architecture to improve performance. SOAP is mediocre in time efficiency, and it looks particularly bad when each invocation spawns a distinct Windows process, as CGI does. Even on the slow desktops I keep in my office, though, CGI is good enough for development and demonstration.
A Few Lines of Perl Code: The Heart of the Gateway
We're almost ready to see working code in action. On the same host that's running IE, you need a Perl interpreter that can:
If you install ActiveState Corporation's ActivePerl (http://www.activestate.com/Products/ActivePerl/), both of these come as part of the standard distribution. I recommend that those who do their own generations from sources exploit the CPAN module to streamline retrieval of all the modules on which SOAP::Lite depends.
In any case, make sure you're using a recent version of SOAP::Lite. Release 0.51 is a significant improvement over all previous ones. ActivePerl users can verify their version by launching the ppm Perl Package Manager facility from a DOS command-line. Once it's started, enter "query SOAP-Lite". If you're not at 0.51 or better, simply "install SOAP-Lite".
For a simple gateway, use the example SOAP::Lite file:
"soap.cgi":
# -- SOAP::Lite -- soaplite.com -- Copyright (C) 2001 Paul Kulchenko --
use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
-> dispatch_to('/TEMP/HTDOCS/cgi-bin/')
-> handle
;
In the directory \TEMP\HTDOCS\cgi-bin, put the source file "Coords.pm":
package Coords;
use Win32::OLE;
$application = Win32::OLE->
GetActiveObject("InternetExplorer.Application.1");
sub getCoords {
$left = $application->Left();
$top = $application->Top();
return ($left, $top);
}
1;
Access this from a client application such as:
use SOAP::Lite +autodispatch =>
uri => 'urn:Coords';
proxy => 'http://testhost/cgi-bin/soap.cgi', # local CGI server
on_fault => sub { my($soap, $res) = @_;
die ref $res ? $res->faultdetail : $soap->transport->status, "\n";
}
;
while (1) {
@c = getCoords();
print $c[0], ", ", $c[1], "\n";
sleep 1;
}
The client will begin to print out lines such as:
128, 80 128, 80Back on the host where our COM server -- the IE browser -- is running, iconify or minimize the browser. Note that the SOAP client begins to print:
-32000, -32000This is simply IE's way to flag that it's minimized.
Bring the browser back to the top of your execution stack. Click on the title bar, and move its main window around. Note that the SOAP client reports new coordinates for the window origin.
174, 78 180, 20 180, 20You've just wrapped a COM service for SOAP.
SOAP > DCOM
Realize what that means: as SOAP, the information can readily traverse firewalls and proxies, and most likely be filtered and managed by existing infrastructure. If you want security rules for your service, you can set them up using the same mechanisms that you already know for Web service. While COM and its distributed kin, DCOM, in principle boast strong security features, they're poorly understood in many organizations and rather haphazardly implemented. Although WS security isn't necessarily easier in the abstract, the opportunity to re-use Web-oriented experience makes it more manageable for such teams.
Moreover, there's complete language neutrality in WS. You're welcome to use GUI-building end-user development environments such as Visual Basic or Delphi, rather than Perl, on the client side. The entire server side, including the Perl-coded gateway, remains unchanged.
And you can provide these advantages to your organization or clients with just a few lines of new code. There's no "big bang" of changing all existing software over to a WS-friendly form. Instead, all COM-serving programs stay in place, and you gateway them as necessary.
Microsoft and other vendors advertise gateways that require no coding at all. This is a bit of an exaggeration, though. In principle, COM servers can supply sufficient information so that an intelligent gateway automatically exposes a complete programming interface through WS. Few real-world COM servers actually live up to this possibility. As a practical matter, COM-WS gatewaying generally requires at least a small amount of "hands-on" programming. Although I've written a prototype of such an automatic gateway, I've found it easier so far to build working gateways "by hand". Once this is done, of course, Perl is available for any customization or enhancement to the interface the legacy COM server gives.
For more information on SOAP and COM, see:
http://starbase.neosoft.com/~claird/comp.infosystems.www.misc/SOAP.htmland
URL: http://starbase.neosoft.com/~claird/comp.protocols.misc/COM.htmlNote that SOAP::Lite itself includes a SOAP-COM gateway that goes in the other direction, and makes SOAP services available to COM clients. Look for the COM/ directory in the SOAP::Lite distribution. Also, for information on the ability of Microsoft products and tools to automate SOAP-COM gatewaying, it's best to use Microsoft's own www.microsoft.com search facility for references to "SOAP toolkit" and "WSML COM".
My thanks to Paul Kulchenko for all he's done as the author of SOAP::Lite, as well as for his personal generosity helping me learn it.
Cameron Laird is a full-time developer and vice president of Phaseit, Inc. http://www.phaseit.net/, working mostly with scripting languages including Perl. He was particularly busy in 2001 with WS applications, about which he's written several articles. Cameron's best-known to Perl-oriented audiences as maintainer of the official Perl/Tk FAQ http://starbase.neosoft.com/~claird/comp.lang.perl.tk/ptkFAQ.html.