1) 1) Store them in a database and create a new service to access these
2) 2) Use SonicMQ and persist the messages.
One of the worries or considerations around the SonicMQ side of things is the way that the broker falls over is the queue fills up.
It depends... as always :-)
A messaging system is not designed to be used as a long term storage.
It provides "buffers" for messages until the client can process it.
"Long term" is the part where people have different opinions.
I personally would store the messags in a database.
Using a "scheduler" serviece or an activation daemon the mesages can then be pulled out of hte database and forwarded to the target system.
Storing it in queues might look like the easiest approach on short term.
What if the project requirements change in the near future?
What if the message volume increases a lot?
When you store them in a DB then you are on teh safe side and can adjust easily.
Could provide a little more insight into system: for example, the volume of messaging to this third party system, i.e. typical message size and rate (though as Stefan warns this has a habit of increasing over time as systems become more heavily used); how often the third party system goes into the read-only mode and for how long (is it a regular pattern that the third party has committed to, or do you need to handle unexpected longer-term outages); the total volume of messages you anticipate needing to buffer during the read-only periods?
Is it the case that the third party system supports updates the majority of the time and only goes into read-only mode for relatively short periods (e.g. for internal maintenance)?
As an aside, if you're finding the broker falls over as a queue fills then that points to a (mis)configuration issue.
Design pattern wise, queuing is for store-and-forward. As Paul noted, a CAA broker should not fail over as a queue fills up - messagea are either pushed to the db or the sender would be blocked. Also, with CAA, messages are replicated and hence persisted on both machines. Using the other approach, you will reply on the db replication.
my 2 cents.
The use case that you describe (limited down time, relatively small message rates and sizes) sounds appropriate for using SonicMQ queues or durable subscriptions. Where we tend to guide people away from using the broker persistent store is in the case of long term storage of large amounts of data, both for performance reasons and due to the fact that there is no mechanism for doing online backups of the broker store.
Now thats an interesting point that you make re backups. Excuse my ignorance but if the queue is persisted to a DB as its store then would the backup of the DB not be sufficient to mitigate this problem?
You would have to take the broker offline to do the backup, and you would need to back up both the message store and recovery log files.