Upgrading to version 6.0
I’m in the process of upgrading a set of ISO8583 servers for a client. One of these is the original server that caused The Server Framework to come into existence back in 2002. The other two servers are based on a 2005 cut of the code; one written in 2005 and one, heavily based on the other, written in 2008.
The upgrade is primarily to support windows performance counters on Windows Server 2008 and to allow for x64 builds. These features have been available in The Server Framework for some time but if your systems work (and have been through complex and time consuming integration testing) then there’s little reason to update the code just for the sake of it. Planning a move to Windows Server 2008 (or Windows Vista) means that the PerfMon code that originally leveraged Jeffrey Richter’s code from Programming Server Side Applications and that ran fine on all versions of Windows from NT4 through to XP doesn’t cut it anymore. Of course I should have been playing by the rules all along rather than just assuming that Richter’s code was good, but, well, times change. The new PerfMon code is documented here and is a great improvement on the old code. Upgrading from the old code to the new code is reasonably straight forward, especially if you use one of the new example servers as a guide. In fact, I found myself using the example servers as a guide for the whole upgrade. Things have changed quite considerably in the framework since 2002 but all of the concepts are still there and the resulting implementation is much cleaner and easier.
The x64 changes are easier. The Server Framework has supported x64 for some time now and upgrading a server to build for x64 is pretty painless. For my code it generally consists of selecting a more appropriate type than size_t
for some things; I was a bit of a size_t
fanboy back in the day…
It’s interesting to look at the testing that was done with each of these servers as it shows how my attitude to testing has evolved. The 2002 server has a .Net server test that can be run against the server and which validates that given a set of ISO8583 messages into the server we get the correct responses back. This .Net server test was the basis for my Code Project article on server testing. There were no unit tests for this server. The 2005 server includes a unit test suite for the message processing logic. This pushes all variations of message into the message processor and tests that we get the correct responses in the form of response message, error logs and database access. It uses interfaces to reduce coupling and mocks to allow easier testing (database access without touching the database, etc). All in all it’s pretty similar to how I test today. This server also has a black box test but it’s written using my C++ server test code (see here for an example); it’s not as easy to extend but it’s faster and allows for more concurrent connections than the managed test that the earlier server uses. This server test also starts with an empty database and runs a series of database scripts to populate the database with test data before starting. The 2008 server’s tests are slightly refined from the 2005 server. The database scripts are processed to include dates that are related to today’s date so that the server test can send messages with dates that are correct for the day we’re running the test; the 2005 server needed to be run on a specific day for the tests to work, or you needed to hack the tests and the scripts… I expect I’ll update the 2005 server’s tests to use the new style of database scripting and test message generation as it means that the server will be easier to test going forward. I’m not quite sure what I’ll do with the 2002 server; I doubt I’ll build a suite of unit tests for it as I’m not actually touching the message processing and generation code, but I expect the server test will be a pain to run, with hard-coded dates in messages and the expectation of test data that doesn’t appear to be scripted… I may end up resorting to using my TimeShifter tool to run the server as if it were some time in 2002; we’ll see.