Glue Software

As someone who inevitably becomes involved in the technical implementation of configuration management systems (CMS) I am often called upon to create what I choose to call ‘glue software’. Glue software is not a full integration between two products (often there is simply no way to fully integrate products) but rather it is a more Heath Robinson collection of scripts, triggers and hooks used to provide some connection between applications that support the CMS.

There are a multitude of technologies that can be used to create glue software, including but by means limited to; SQL, various shell scripts, C, C++, C#, Java, PHP, Python, various web technologies (XSLT, ASP etc.) and so on. Over the years I have used all of these and more but by far and away my favourite glue software development language is PERL. And here’s why…

PERL is ubiquitous. There is almost no regular platform on which PERL cannot be run; Windows, *NIX, Mac and Mainframe are all generally covered and therefore most of the platforms one is likely to be using in a modern CMS are covered.

PERL is simple. Well, more accurately, PERL is easy to teach/learn because it is accommodating, typically providing more than one way to express a programming notion. PERL is a fairly forgiving language, but it has to be said that sometimes this flexibility leads to confusing pieces of code. One soon learns to interpret the more idiomatic usage though and the confusion is lifted leaving only the choice of programming approach afforded by PERL’s flexibility.

PERL has a vast library of freely available libraries. Like many languages that are available across multiple platforms, PERL has developed a wide following from many disciplines and this has meant the development of a large library of routines to do almost anything you want. Check out CPAN and look through all the modules available there. To paraphrase Apple’s App. Store tag line, ‘there’s a PERL module for that’. This facility alone can save hours of tedious programming.

Write it once, use it anywhere. Using a native script language (such as ksh, Bourne shell, or even – shudder – BAT) means you are largely tied to one platform. PERL’s ubiquity, when combined with careful programming, means your carefully crafted and debugged script will work pretty much anywhere.

PERL has a long and illustrious career as a web programming language. Pre-dating Java, PHP, ASP and others as serious dynamic web technologies1 the Apache mod_perl module has allowed PERL code to be embedded in web pages for many years.

With PERL modules like Tk (or Tkx) you can create graphical user interfaces for your scripts that adapt to the window system on which they are displayed. (The newer Tkx provides a much more raw interface to the underlying TCL/Tk libraries. It also, to my eyes, produces a better UI that matches more closely the host platform. Basically because the TCL/Tk libraries are more up-to-date than the Perl/Tk implementations.)

So, that is in broad strokes my case for PERL. But there’s more.

Perhaps the best supported PERL package is that provided by ActiveState. Although hardcore PERL mongers may consider this limiting I suggest (especially to new PERL users) using ActiveState’s installation and limiting yourself to using the packages provided through there PERL Package Manager from their repository.

Although ActiveState provide only a subset of available packages it is a substantial subset and, more importantly, they work across all the platforms supported by the main ActiveState distribution. This in turn means that the write once, use anywhere philosophy is easier to maintain.

Added to this common support facility the ActiveState PERL Developer Kit (PDK) provides a cross platform packaging facility that means applications developed on one platform can be wrapped into executable packages suitable for multiple target environments. So, if you develop your PERL on Mac OS X you can provide packages targeted for Windows, Solaris, Linux and AIX platforms without ever leaving your OS X environment. And that has to be a good thing.

As if this were not enough, the PDK also provides the means to package your PERL as a Windows service, a dll, a System Tray utility, or a .NET library (making your PERL libraries available to your .NET developers).

As with any broad statement, claims of PERLs utility must be accompanied by a cautionary note. The path to PERL Nirvana is not an easy one. Not all PERL modules are of a high quality. Not all PERL applications will easily package using the PDK. And not all PERL code will work on all platforms. Just as with any programming language you, the programmer, must be aware of platform differences and ensure your script will handle them gracefully.

All this said, with a little forethought and care PERL provides a powerful platform for glue software and more.


1. Okay, PHP was officially announced about six months or so before mod_perl, but PERL was already established as the predominant CGI language by then and mod_perl instantly made embedded PERL a success while PHP has some time to go before being mature enough to use seriously.

Advertisement
  1. Common Interface « Principia: Power from Simplicity

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.