Wednesday, June 27, 2007

cURL breaths life to old system

In my previous post I hinted that I would next write about how to get several legacy systems to send data to a modern .Net based application when the legacy systems only know how to talk to each other. This problem is based once again on the aged Progress applications that company A uses.

The Problem: The native language lacks the ability to make any network based connections, unless it is to a database that is of the same flavor. So what is a person to do when they want to integrate with more modern systems, many of which are being built using WCF or plain old web services? You could pack your bags and go home or better yet, start injecting more custom C code into the old dog and teach it a few new tricks.

Possible Solution (Option 1): If you need to talk to plain old web services that operate on GET's and POST's then cURL,or more specifically libcurl, is a very logical choice. cURL is just amazing; a command line tool that can do everything that a web browser can do but without the GUI. libcurl gives you the ability to put this power into your own applications. So with option 1 a libcurl based API was introduced into the legacy language.
This initial introduction of libcurl was actually done by a previous employee a while ago but it was time to update the API and support some new features. One feature that was desperately needed was support for SSL based connections (provided by the OpenSSL libraries). The next feature which we needed was the ability to pass authentication credentials with the POST requests; specifically credentials to access Windows domain systems. (I didn't mention it, but the legacy applications all run on HPUX.)
So now we have the ability to POST data to any standard web service via http/https including optional login credentials. This works very well for situations where the communication can withstand or requires being synchronous.

Next time... Possible Solution (Option 2): A JMS based messaging infrastructure...

GPG to the rescue (lipstick on the pig)

So I have been a little side tracked from my Ruby ISO8583 work for the past couple of weeks. But never fear I have been getting familiar with a really amazing API for the GPG project known as GPGME (GPG Made Easy). So why would a person be interested in this? Glad you asked.

Problem: Company A has a very, very old POS application that was written entirely in-house. The programming language/database that the app is written in is Progress (something like a 4GL). I'm not surprised if you have never heard of it. One problem is that the version of the database/language that the app is written in is now over 10 years old. Well company A needs to capture some PCI data for a very short period of time during the transaction and this data needs to be sent off to various backend systems for settlement, etc. (so this is not entirely unrelated to the ISO8583 work). The problem is that the language/database has no way to handle this, period.

The Solution: What Progress does offer is a HLC (Host Language Call) mechanism which allows custom C routines to be written and called from the application; complete with a way to pass data back and forth through shared variables and temporary tables. This is actually very cool! So what we are going to do is let the native Progress applications call a GPG encryption routine (we will be using asymmetric encryption in this case) and bingo, we have encryption in a older-than-dirt application.

The first step was to investigate the GPG libraries and see how we might integrate them and develop a very simple API for our app developers to use. And this is where GPGME came into the picture. Someone has already done a lot of the work for us and created an "Easy" API to the GPG engine. The post compile tests which are bundled with the GPGME source came in very handy when it was time to actually write our routines (it's great to see actual tests).

A few days of hacking together some C code and I had injected an encryption routine into our antique language/database.

A basic architecture and sample use case for this project would be as follows:
  1. Create a public/private key pair somewhere super-safe. Guard the private key with a pass-phrase and with your life.
  2. Distribute the public key to the legacy application systems. These applications will then use the public key to encrypt sensitive data which can be stored locally (only if you really need to) or shipped off to another super-safe system. The original 'clear-text' data must me removed after it is encrypted or the whole process is worthless!
  3. The 'super-safe' system which has the private key will then be able to access the sensitive data when it needs to.
  4. Because the legacy application systems only have the public key they cannot even decrypt the data that they themselves encrypted.
For all those out there who spend way too much time holding a well past their prime system together, I have this to say... I put lipstick on the pig. The lipstick may be pretty but it is still a pig.

Next entry teaser: " do you get several legacy applications to send data to a modern .Net based system when they only know how to talk to each other..."