I'm having my first contact with Vertx's EventBus and I realized there are two ways to submit a message. Used the send or publish method. I ask: What is the practical difference between using these two methods and in what scenario do they use each one?
Both send and publish are used to send a message to an event bus address. However there are some differences between the two.
By using publish:
A message is sent to one or multiple listeners
All handlers listening against the address will be notified
No answer is expected from handlers
By using send:
A message is sent to one and only one handler registered against the event bus address.
If multiple handlers are registered, only one will be notified. The receiver will be selected by a "round-robin algorithm" as per the docs.
The receiver can answer the message, this answer can be empty or contain a response body. A response timeout can also be specified.
In practical usage, publish is quite useful to inform that an event has occured, whereas send is quite handy for asking a treatment where the response matters.
Conceptually, publish uses the publish/subscribe pattern whereas send uses the request/response pattern.
Related
I have an [Azure Storage] queue where I put e-mail messages to be sent. Then, there is a separate service which monitors that queue and send e-mails using some service. In this particular case I'm using SendGrid.
So, theoretically, if the sender crashes right after a successful call to SendGrid Mail Send API (https://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/index.html), the message will be returned to the queue and retried later. This may result in the same e-mail being delivered more than once, which could be really annoying for some type of e-mail.
The normal way to avoid this situation would be to provide some sort of idempotency key to Send API. Then the side being called can make sure the operation is performed at most once.
After careful reading of SendGrid documentation and googling, I could not find any way to achieve what I'm looking for here (at most once semantic). Any ideas?
Without support for an idempotency key in the API itself your options are limited I think.
You could modify your email sending service to dequeue and commit before calling the Send API. That way if the service fails to send the message will not be retried as it has already been removed from the queue, it will be sent at most once.
Additionally, you could implement some limited retries on particular http responses (e.g. 429 & 5xx) from SendGrid where you are certain the message was not sent and retrying might be useful - this would maintain "at most once" whilst lowering the failure rate. Probably this should include some backoff time between each attempt.
Is there a way when using the REST API to send an outgoing message that I can specify the SMS Url to use for any responses to that message? I saw mention of it in the docs where it says you can specify it for the phone number in the console or via the API. If I post a variable named SmsUrl when sending the text it still uses the url connected to the number or the twilio app.
We need responses to submit back to a url on our server that includes a parameter that lets us connect the response to a specific inspection request. In other words we need to be able to connect the response not to the from number but to the record on our end for which the outgoing message was triggered.
Thanks
If you are sending from a single number this is totally impossible, SMS simply doesn't work like that. If you send me 5 SMS and then I reply to one of them my reply contains no data which links it to the SMS I am responding to.
The only ways I can see you achieving this are:
Assign a different outgoing number to each trigger. This is foolproof
but may not be viable depending on your usecase and nuber of
triggers. It may also confuse your users if they get texts from many
different numbers, although if you buy consecutive ones you could
mitigate this.
Include instructions in your SMS like "Reply 1 to request a call, 2
to request a password reset..." or "Start your reply with XXXX" where
XXXX is a unique code you generate server side and assign to the
user, or have a code for each trigger or whatever. This would work
with only one outgoing number, but in my experience the end users
will screw it up a lot of the time and not respect your instructions.
I want to send a mail and only if this works put a message into a JMS queue.
How can I do it? I couldn't find any mail:outbound-gateway.
OBS: By now a am using publish-subscribe-channel, but this is not exactly what I need.
OBS: By now a am using publish-subscribe-channel, but this is not exactly what i need.
Why not?
There are several techniques to do this:
Publish subscribe channel with the JMS endpoint the second subscriber (mail order="1", jms order="2") (with ignore-failures="false" - the default).
Recipient List Router
Expression Evaluating Request Handler Advice
At this moment we are building a new architecture that is based on the principles of CQRS and domain-driven-design. We are now having some discussions about how we should deal with external communication. To make the question more concrete I use the example of sending a SMS notification when a customer creates a order.
The client creates a NewOrderCommand that is handled by the associated command handler. The handler creates a new Order object in the domain model, that generates a NewcustomerCreatedEvent. The object is saved in the event store and the event is published to all the listeners.
So far so good but now the question. Where should we sent out the SMS notification?
Our first instinct told us we should send it out by using a event listener that listens for the NewCustomerCreatedEvent and sends out the message. The problem with this approach is that the sending of the SMS is also part of our business logic. We are selling hosted services so our clients should be able to see all the SMS messages that are sent on their behalf. Because the sending of the message takes place outside of the domain we are not able to do that.
So we created an SMS domain and now when the event listener receives the NewCustomerCreatedEvent the event handler creates a new command SendSmsMessageCommand that will create a new SMSMessage object in our domain, sends out the SMS notification and creates a SmsSent event that we use to create the view.
At first we were sending the SMS message in the domain model, but we realized that this could give some problems. Let's say that after sending the SMS something happens (an exception is thrown) and the transaction is rolled back. Our domain supports this completely so data wise we are ok, but the SMS message is already sent, so when the command is resent the SMS notification will be sent again.
We were thinking about sending out the SMS on the SmSSent event but that would be a little bit strange, because the event says the message is already sent but is isn't.
The example above brings us to the question how to deal with external communication in the CQRS and domain-driven-design concept? We are not only talking about sending an SMS notification but also about sending an invoice to and external billing system and all other sort of communication to the outside world. Should we do this in the domain because it business logic or should we always do that based on events in our event handlers? And if we do so, is it acceptable to use events that say that the message is sent when it's not actually done yet?
Hope you guys have already dealt with this situation and can give us some advice on this subject.
I would think a domain object for the SMS message is not necessary. You just need to report the SMS's sent to the customer, correct? The SMS messages are not used in any domain logic, correct?
So I would have the handler send an SMS and then publish another event that says an SMS was sent and have an event handler listen for the SMS sent message and materialize that info in a read model so that the customer can view them.
You could use a Saga, or a Process Manager as Microsoft calls it. This basically listens to events, which change the saga's state, and issues commands based on the state logic implemented in the saga.
In your case it would be a two state saga, that waits for both CustomerCreatedEvent and OrderCreatedEvent, and, either issue a command to send an sms, if you have a specialised bounded context for communication, or call an infrastructure service, through an interface, to send the sms.
Here you can find Microsoft's article on the saga/process manager pattern:
https://msdn.microsoft.com/en-us/library/jj591569.aspx
And two articles containing implementations:
http://danielwhittaker.me/2015/03/31/how-to-send-emails-the-right-way-in-a-cqrs-system/
http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/
As the title says, I would like to send a welcome message when a user subscribes to a bot.
However, as I understand it, presence subscribe stanzas should not contain a from-JID that includes resource (and my testing with Adium indicates that is also the case). That is, welcome message could easily be sent to the bare JID but is that really the right way to do it? It feels like it should be sent to the actual instance where the subscription originated.
Perhaps I'm seeing a problem where there is none? If not, any ideas on how to solve it?
Do not fear sending a message to a bare JID. Almost all the time this is what you want. The user may already have a fantastic system in place using priority to get the answer at the right device, like a blackberry, their home jabber client, the one at work, and so on. Heck, they may have sent the request from their blackberry that has a 0 priority, and they want to get the answer back at their desk.
Just send a message stanza with a type of headline, since you don't want them to reply to the notice.
The things said about messages are all right.
If you care about whom to send presence subscribe stanzas to, I wonder whether you really know resources at that time. IIRC, resources are stripped off before forwarding presence subscribes and I assume that you are responding to them. Furthermore, the bot wants to be informed about all presences, so subscribing to the bare jid is the right thing to do.