2006-09-25

Bit Plumber

It seems that most of my life is spent either waiting for, calling new, or building data transfers. I spend my Monday morning reviewing logs from the previous weekend's data transfers, I start a refresh of my development environment's database, and I work through last week's progress on the web services I created. This weeks project is to design a custom export of data from one database to an XML format and back into a different database. So much of this is repetitive and so much of it is the same from week to week I have to wonder if there isn't a group of tools to automate these tasks.

Let me introduce you to the wonderful world of ETL tools. These are tools that Extract, Transform, and Load data. In short they have the potential to replace an entire stack of SOA tools that currently are written painstakingly entity by entity by your talented Web Service programmers. They do all their by work by pragmatically by-passing the entire ORM process (that then demands you to Serialize the Objects to get XML) and skip directly to the XML.

I expect to see more applications built around these ideas as SOA catches on more. Why can't an ETL be used to generate Ajax messages or SOAP calls? After all aren't many SOAP calls and Ajax calls just loading up data from a database and transforming it into the right message format?

2006-09-06

Velocity versus JSP

I've spent the last few weeks in a new larval stage again. This time I've the been studying the alphabet soup that surrounds web portlets and the JSR168 spec. I'm not talking about learning to make portlets... that's easy... I'm talking about the best way to make portlets.

The fastest way to get working with portlets is to start by creating JSP pages and balling them up into portlets. You end up with function fast. But, if you plan on doing that, why not just go with a PHP based site? About all that JSP will get you in this case would be some props at cocktail parties where you can get an easy 'wow' by tossing around the word Java a few times.

We want MVC and we want to enforce it. So I've decided on velocity for page design. With velocity I can give page designers the ability to work with active page content and remove the possibility that some slack-jaw might muck up my code-base by slapping in some ill concieved SQL. It also means that view policy is utterly divorced from controller mechanisms.