Notification Service: Now what?
22 November 2008Now that we have finished the first functional version of the Notification Service, the question becomes, “What to do now?” When we first introduced the concept for this service, we included this illustration:
Those of you who have been playing along at home will notice that we never did do anything about that little item on the bottom called Audit Log Database. The basic idea there was that it might be useful to capture the fully resolved message sent out to every recipient, along with all of the relevant details concerning who, what, where, how, and when. I still think that’s not a bad feature to have, although it should probably be set up such that you can turn it on or off, either globally, or based on some other criteria such as template context or name or maybe recipient or recipient domain.
To do that, of course, would involve another database table(s) and associated POJO(s), along with the accompanying DAO and manager and so forth. That might be a worthwhile project, and would be an excellent opportunity to try out Ray Krueger’s suggestion to refactor the DAO approach that we have been using based on a superior model. I’d still like to try that out, so this may be a good time to work that in.
On the other hand, we have only built the one MessageCourier, and I have visions of all kinds of alternative delivery methods for notifications, including HTTP PUT to REST services where the content type would be XML. In that case, the “to” address would be a URL, which I think would all be workable with the structure that we have created thus far. There are a number of others, of course, such as the tweet idea, which I also thought would be interesting to try, although I’m not quite sure how you would unit test that — maybe by making (or finding?) a Dumbster-type destination for that service just for that purpose.
But then, I also wanted to replace the HTML textarea in the notice template edit page with a Rich Text Editor like RTE, TinyMCE, or Xinha. That’s another interesting project that I pushed off to the side and said that I would pick up at a later date, so maybe now is the time for that. In fact, that page has some other hanging issues such as setting up the contentType and defaultDeliveryMethod fields to each be fed from a Smart Pick List. Same page, but an entirely different project.
And then there is the way in which I set up the MessageCourierFactory to be configurable via Spring. That doesn’t really pass my “while it is running” test — you have to update the Spring configuration and rebuild the application to install new delivery methods. If I create a Look-up Table of delivery methods to support the pick-list on the notice template editor, surely that same Look-up Table could contain the class name of the appropriate MessageCourier for each method, and accessing that table could replace the MessageCourier map in the current factory implemenation.
So … even though were are technically “done”, given the fact that we now have a working model that can actually be put to use, there is still plenty of work left to. The only question now, really, is where do we start?
Leave a reply
You must be logged in to post a comment.
