I remember last year I designed a asp.net application where I had couple of Webforms to collect data and I was storing in the database.
Ie. Webform facilitates insert, Update and Delete of Person and allow to set reminders for the person, which is later on send to him via Email, SMS and other ways...
This year the client wanted one of their legacy application to pickup the reminders and display on is own calendar.... but the catch is the the legacy app will use its own database structure and its own programming language etc...
So client wants to have data distributed to the legacy app when Person is created or Reminders are added. Now onCreate of a Person or Reminder if I go and write codes to put data on the legacy app my application will become bulky and will become slower (its a asp.net application), Also in near future someone else might come and tell to distribute data to their system as well.....
What I did is I created couple of Queue s in MSMQ and started passing Messages.
I wrote another Windows Service which now reads Messages from Queues and distributes data to the Legacy System.
Queuing Message in MSMQ is pretty easy in .Net...
public void QueueJob(Job job, string destinationQueue, string messageLabel)
{
try
{
// open the queue
MessageQueue mq = new MessageQueue(destinationQueue);
// set the message to durable.
mq.DefaultPropertiesToSend.Recoverable = true;
// set the formatter to Binary, default is XML
//mq.Formatter = new BinaryMessageFormatter();
// send the job object
mq.Send(job, messageLabel);
mq.Close();
}
catch (Exception e)
{
throw e;
}
}
In my web application I Queued jobs like this:
//Passing the person object in the ADDPERSON_QUEUE
QueueJob(person,ConfigurationManager.AppSettings.Get(ADDPERSON_QUEUE), messageLabel);
Also in the appconfig I added this:
<appSettings>
<!--EnableQueueing values: true, false-->
<add key="EnableQueueing" value="true"/>...
I check before Queuing whether the Queuing is enabled....
So this gives me enough flexibility to keep my system independent and not to worry about
any legacy systems or any other systems that will use data from this application.
It simply Queues the task/job and do not worry about what will be done with the messages.
I also did not write any codes related to the Legacy application or its datastructure in my
webapplication and kept it independent.
Web performance is reduced a bit.. because of Queuing but its better than pumping data on legacy
systems directly.
The app config also gives flexibility to stop queuing any time.
For QueueJob Method Provider pattern is also be used for flexibility on deciding storage of messages. Who knows
in the future something great can come up... and we can simply plug in a provider.... or probably someone
would not like to use MSMQ instead use SQL Server 2005 Messaging or something else...