How do I write message queue handling in an object-oriented way?
If you've ever written code that takes messages from a message queue and updates a table in the database, how would you choose to structure it nicely. How would you structure it? Messages are XML data, one node per row in the table. Rows in a table can be updated, deleted, or inserted.
source to share
Typically, with OO message queuing implementations, you make classes yourself that represent separate message types. To the extent that the various types of messages that you expect to receive are derived from each other, this provides a class hierarchy for messages.
With configurations based on the baseline configuration, you can simply set up persistence for these classes directly.
Then there is one or more classes that listen to the message queue and just store the messages, maybe just one. It shouldn't be more difficult than this.
source to share
I don't believe you have provided enough information for a good answer. What do the messages look like? Do they differ in content / type, or are they all just "messages"? Do they interact with each other, or is it just a data format conversion? One of the keys to designing OO is to understand that the game of "find nouns-n-verbs" (which is the same as you described) rarely leads to a better solution. It certainly won't be the worst, but you end up with data aggregation and a bunch of procedural code.
The procedural code is not bad. Why should it be OO? Does the problem itself require polymorphism and data hiding? Is there any complex behavior you are trying to model? There is no shame in using a non-OO solution when the problem is simple.
source to share
The best way to generate OO code when messaging or working with any middleware is to hide the middleware APIs from your code and just deal with the business logic.
eg. see these examples
- POJO Consuming that pretty much describes your use case and
- POJO Producing if you need to send messages to the message queue.
Then you just need to define what your data transfer objects look like; how do you want to encode things on the wire in XML / JSON / whatever.
The great thing about this approach is that your code is now completely incompatible with middleware - you can swap your message queue and use database or JavaSpace, SEDA memory or files, or any other communication protocol or middleware API .
source to share