Messaging Integration
Grails needs to provide a universal messaging system not just something specific to e-mail, although this is clearly important. Rather than introducing two concepts that are essentially the same (email and messaging) they need to be unified into a single concept to avoid duplication of effort.
Asynchronous messaging essentially defines the concept of a topic and subscribers and publishers to a topic.
Publishers
A publisher is simple a groovy class that follows the convention *Publisher. By default the first part of the name defines the topic it is publishing to:
class ExamplePublisher {
def sendX() {
return [modelObject:"blah"]
}
}
Here we're publishing to an "example" topic and the sendX() method creates a model that will be used in the sending. In the case of e-mail the sendX method will delegate the model to a views/email/x.gsp view to create the e-mail content itself. Alternatively in JMS this model will be passed in the messaging context to the subscriber.
If a publisher needs to send a message to another topic it can do:
def sendXToTopicName() {
return [mnodelObject:"blah"]
}
The topic that a publisher publishes to be default can also be changed using the "topic" property:
def topic = "another"
Subscribers
A subscriber is an object the receives messaging notifications. They listen to a "topic" in the same way publishers publish to a topic. For example:
class ExampleSubscriber {
def onMessage(ctx) {
}
}
It gets passed a context object which in the case of JMS may be the model or in the case of a POP3 or IMAP e-mail listener it could be the email itself.
Topics
Topics can vary in what they do and achieve. A topic could define an email server to send and listen for new e-mails to and from. Thus allowing the publish and subscribe of email. Alternatively it could be configured as a JMS topic for messaging. Topics will be configured in the ApplicationConfig.groovy file as follows:
class ApplicationConfig {
def topics = {
example(type:EMAIL) {
server = "localhost"
port = 3434
// etc
}
}
}
Comments (2)
Jul 25, 2007
sdevijver says:
How will a subscriber be attached to a queue or topic? It should be possible fo...How will a subscriber be attached to a queue or topic?
It should be possible for one subscriber to listen to multiple queues/topics. Multiple queues/topics is typical in cases of integration with multiple partners, where each partner has it own incoming and outgoing queues.
Obviously, a subscriber class would be common but configuration would be specific for each partner. Per partner there can be different channels, like high/mid/low priority, ordered, unordered, ...
Jul 25, 2007
Graeme Rocher says:
The examples above are using sensible defaults, there is no reason why we can't ...The examples above are using sensible defaults, there is no reason why we can't add the special case configuration options like
static topic = "sometopic"