Maybe it's just my organization's policy of giving its developers relatively free access to db's while, at the same time, putting lots of administrative hurdles and hurdle-like administrators between them and the app-server. But it's really amazing how little there is that you can't get done nicely with a sturdy db and a decent servlet-container (at most).
Example: For some time I thought a nice event-driven architecture I was planning would require some serious investment (of money and effort) into some sort of enterprisy message-bus, and, of course, then you'd have at least 2 transactional resources to keep synchronised, crying for some "serious" app-server... When I suddenly asked myself, why the hell one ta-resource, the database wasn't enough. And it is, I think. For small-scale integration tasks, where we can control the deployment of all involved systems, business components shared across applications and working on the same database will do just fine. For more difficult tasks requiring some more decoupling there's stuff like Oracle Advanced Queuing - which can be used as a JMS implementation backed, ultimately, by db-tables. Similar things should be easy to implement on any db.
And the best thing: only one ta-resource, only jdbc, no need for two-phase-commit, old Tomcat will do.
No comments:
Post a Comment