You are here

Now that I've ranted about what I don't want HookUp to be, maybe I should elaborate on what I do want it to be and how I intend to get it there.

Language.

I've chosed .NET, specifically C#. I come from a C++ background mostly under windows, so this seemed to be a good next step (and a good resume builder.) I have used java quite a bit in the past, but mostly just the core language stuff. In fact I've written entire client/server communication frameworks in java but I felt that there's entirely too much to learn about java technologies to build a truly useful system. I'm so far behind the curve on J2EE -- I didn't even get through the tutorial.

So, C# it is. That means a windows based system. I'm not too concerned about this for a couple of reasons:
- It's possible that .NET will be ported to Unix by the time this is ready. Shared Source CLI (a.k.a Rotor) is already targeting FreeBSD and Mac OS.
- Microsoft is a juggernaut. It's probably a safe bet that most companies have at least 1 windows box in them.

Database

I intend on being database agnostic: OleDb all the way. That should open up just about everything as long as I can deal with the different stored procedure versions. First off I will target SQL server (being the easiest to get my hands on,) followed by Oracle and maybe MySQL.

To help me with the data access portion there are a couple of nice tools I'm looking at:
- Microsofts Data Access Application Block seems to be a useful bit of code. You can pretty much search and replace Sql with OleDb and you're set (you lose a few Xml related methods specific to SqlServer but that doesn't seem to be a stopping point.)
- Microsoft ObjectSpaces is an intriguing ORM tool.

Protocols

Internally I'll use Xml all the way. I'll need to provide support for other formats for input and output like raw binary, flat file (delimeted and positional). There are also a bunch of industry specific protocols depending on where the system gets used. There's HL7, HIPAA, X12 for healthcare. FIX, FIXML and STAMP for Fincancial etc, etc.

I'll also provide support (both incoming and outgoing) for web services. That seems to be a fairly hot ticket nowadays, even in non-Microsoft camps. That provides a nice integration point with java systems for instance.

User experience

I'm targeting developers. The first few/several version will have no gui associated with it. Configuration is through Xml and tracking will be through log files.

In future I plan to provide a graphical representation of a given configuration. I played with Lego enough as a kid to be able to visualize a "building-blocks" approach when I see it. Who knows, maybe this GUI will be extended to configure the system and even trace an execution path like a debugger.

Tools

There are a number of potentially interesting tools like the Data Access Application Block at Microsoft Patterns and Practice.
I'm a big fan of NUnit
NDoc looks interesting for documentation. I'll have to check it out further.
I don't really like the built-in logging capabilities of .NET so I've been looking at log4net.

Design goals / Plan of attack

Simple simple simple. The last thing I want to do is create another heavyweight app. I want it simple to extend the basic blocks I will provide. However, I don't want to back the user into doing a bunch of coding just to get things off the ground.

Inputs: .NET Assembly API, Files, MSMQ, Web Service API, Database table
Outputs: Files, MSMQ, Database, e-mail
Configuration: Xml config files a la app.config.
Transformation: Xslt all the way baby.
Database: OleDb compatible but can be used completely without a database.
Pre/Post processing: Encryption, Digital Signatures, Certificates

I plan on having both synchronous and asynchronous execution paths depending on how a given path has been configured (e.g. even a call to an asynchronous method will end up being synchronous if you don't configure some checkpoint.)

I want to make sure the system is very trackable. If something goes wrong you have to be able to find out where.

Since I'm going for an enterprise level system it has to perform, scale and recover.

What's looming

The first releasable package is going to have the following features:
- Inputs: .NET Assembly API, Files, MSMQ
- Outputs: Files, MSMQ
- Pre/Post Processing: Encryption (Crypto API stuff)
- Database: OleDb
- Synchronous and Asynchronous processing
- Proper exception handling and checkpointing
- Not going insane.

Will keep blogging...