Inventing the wheel

This might appear as complete non-sense even to a developer, but anyway, I decided to write down what I made in 2003 program-wise - or at least what I was trying to do. I was working more or less alone in a project and saw some patterns that always returned when I was trying to make services, application, processes and machines communicate with each other.
Basically, the first problem was quite simple. SNMP is a simple protocol (hence the S) and surveying equipment with an SNMP-IO is simple. At least it should be, but some limitations makes it complicated. Turns out that an SNMP-IO is a piece of hardware that one can connect wires to. If the SNMP-IO signals a 1 on a specific port it could correspond to an alarm of some sort (fire in the server-park, an open door, it’s raining again). Of course the technician installing the alarm knows exactly what it’s for so it’s easy for him/her to just configure the port’s description to be for example “TA cab B5”. The operator however that intensely stares at the alarm list 24/7 would like to have something else. For example a longer text (no can do in the SNMP-IO), or even better a unique description number that refers automatically to a database of texts describing the cause of the problem, the location (coordinates), appropriate measures, phone numbers etc.
So, this text needs to be edited or translated or transformed into something different. Wouldn’t it be nice to do something generic, re-usable and idiot-proof? The SNMP-IO and it’s ports can form keys that would create a unique identity. These keys could be mapped to different kind of configurable values. So the incoming SNMP must be read, processed and transformed and sent into an application (for example HP OpenView NNM) for presentation. HP OpenView NNM listens on a specific port and one has to use a library and call a specific method. And of course it could run on a different computer.
So, we also need some network protocol in order to translate the simple text to something more useful. XML might do just fine - something generic at least. Hmm, what might be needed?

from, to, subject, content

“From” and “to” might need an IP-address plus a port number. Subject seems to be needed and the content should be dynamic. A DTD might be useful? Ouch.
So we need an XML-parser and an SNMP-adapter of some sort. The adapter should be of any protocol in order to be enough generic.
What to do with the processing of the message coming in from the SNMP-IO? We have to map this to something different. An SQL-database would certainly solve the problem but it might be over-kill in this example. We could store a simple Hashtable-object as an editable text-file instead. Plainly, mapping keys to values. How difficult could that be?
Format:

key_1;…;key_n; = value_1;…;value_n

A find-method would return the correct value(s) for a specific key. For the setup of the light database we need a GUI. Configurable table-headers, number of keys and values and configurable delimiters. We also need to use wild-cards when searching. When creating the simple database we need to read large configuration files that hold the configurations (description texts), these files of course contains errors, null fields and fields with illegal characters so we need some generic exception handling. And we need to be able to present the errors and allow the operator to fix them. It must be possible to define the out-format.
<…snipped, 4 pages later…>
And there we go… bingo, it works just fine! All services in the OSGi framework acts together, huge amount of code producing the single task of translating the “TA cab B5” to something more informative and editable! And we have code that we can re-use, we only need to do the adapters, some more GUI’s and sell it on the market! Right before the deployment and real use of the code, the customer changed direction and said: “Nice work, we need to be doing something else instead. The surveillance of this equipment will in 3 years be obsolete so thank you for your time and effort.”

Back to the future
Now, in 2007 the market is ready finally to take the leap to SOA and mainly Web services architectures (wow). Customers ask for .NET (that seems to be working) and something else that also seems to be good - business processing! One service handling an on-line order for some stuff, sending it to server that processes it: checking if it is a valid order, checking shipment and sending a message to another machine placing the order. This is the typical scenario. But the scenario keeps coming back in all sorts of situations. An alarm system needs to be connected to a video system. When an alarm goes of a camera shall be activated and the operator should get a wake-up call.
A person enters a door and uses his id-card a message should be sent to a machine.
Eight databases shall be analyzed and be given a generic interface in order for 10-12 applications to work together. And so on. What are the customers asking for and what is the most popular recommendation? Hmm, BizTalk, BizTalk and BizTalk.
I’ve now seen quite a few demonstration movies both from Oracle and Microsoft and they all have understood the pattern. I just wish I had known what I really was doing back then – I wish OSGi had invented the BizTalk concept back in 2001. I’ve noticed I’ve become quite happy with working with configuring (which however, is not like laying on a bed of roses) instead of doing the actual programming.
After all, that was what it was all about in the first place - producing re-usable code!
© 2007 Christer Hellberg