« - »

Notification Service: Overview

29 October 2008

Even though we started out this series on the Notification Service with a little chunk of code, before we get too far down that road, I wanted to step back a little bit and review the basic concept. Although I imagine that this whole process could potentially grow to accomodate many features and functions, right at the moment I am going to attempt to focus on some basic functionality, just to get the ball rolling.

The basic premise of the service is simply this: given a boilerplate template for a message, an object containing data to be used to resolve variables in the template, a collection containing recipient data, which could also be used to resolve variables in the template, and few other, minor tidbits of information such as the content type, delivery method, and name of the property containing the recipient’s address within the objects stored in the collection of recipients, the service will loop through the recipients, resolve the variables in the template for each recipient, and deliver the notice via the specified delivery method. Collectively, I call all of these items needed to carry out the work of the service the Notification Request, and I envision the entire process to look something like this:

At some point in the future, I envision the potential for several independent delivery methods such as e-mail, instant message, text paging, Tweets, fax, and maybe even hard-copy to specified printers or sent to some service that prints out the message and drops into an envelope and sends it via snail mail. There are all kinds of possibilities there, but to start with, I am just going to focus on e-mail. I am going to attempt to do it in a way, though, that allows new delivery methods to be added at will without having to do much in the way of overhauling the existing code base.

Right now, I don’t see this particularly as a REST service, although some kind of REST wrapper could cetainly be added at a later time. At this point, though, I am looking more at a simple object that could be instantiated and configured via Spring, upon which you would simply invoke a single method such as notifier.sendNotification(notificationRequest) or notificationRequest.send(). Under the hood, of course, there would be a number of layers of subordinate services (such as the SimpleVelocityService) to perform such functions as retrieving notice templates or delivering messages for a specific delivery method. From the outside, though, I hope to make it a rather simple, basic API to get the job done.

As far as the templates are concerned, I do see the need for the standard REST service to maintain the templates, incorporating all of the standard CRUD operations so that templates can be created and kept up to date. I’d like to set that up in such a way that you can drop in the maintenance widgets onto your own plain HTML pages in much the same as was done for the maintenance of the authorities in the Authorization Service. I would also like to organize the templates in some way so that you could have a central repository of templates that included both shared templates and templates specific to certain applications or departments, with of course, the option to use your own repository as well.

I think I will actually start with the templates themselves, and go ahead and start to build the Notice Template maintenance process as a separate project. The DAOs and the data managers and the associated unit tests will all be pretty much clones of things that we have done before, so that will be a nice, familiar place to get the ball rolling. Once that is in place, then we branch out to the features and functions more specific to the particular goals of this particular project.

That’s the view at 30,000 ft, anyway. Next time, I think we will create a NoticeTemplate bean, and then start tossing together all of the parts to connect that to a back-end database and some front-end data maintenance processess. These things have a way of evolving over time, so when all is said and done, the final result may not look anything like the picture above, but that’s the vision that we will set out with, anyway!


http://blog.restafarian.org/2008/10/notification-service-overview/

Leave a reply

You must be logged in to post a comment.