I have several microservices and many of them have Integration Events. Imagine a microservice M1 that needs to subscribe to an event that lies in the microservice M2. How can I subscribe to the event without coupling the M2 and M1? Is there another way to subscribe without using the event type instead use the event name for example?
While Rebus encourages the use of type-based topics, the underlying mechanism is based on simple string-based topic names.
The "raw topics" mechanism is available via bus.Advanced.Topics, so you can
await bus.Advanced.Topics.Subscribe("whatever");
to subscribe to the whatever topic, and then you can
await bus.Advanced.Topics.Publish("whatever", yourEvent);
to publish events to that topic.
The RabbitMQ Topics sample demonstrates how it can be done, and it even shows how RabbitMQ's underlying topic wildcards can be used this way.
There are two ways ( depending on your need) which can be used to address this scenario
first it to IHandleMessages and handle for dynamic object
second is by providing implementation of ISerilizable
we used the second option.
Further read:
https://github.com/rebus-org/Rebus/issues/24
Related
For my use-case I'm going to have many topics. Because I won't be able to create all topics up-front I would like to create them dynamically. I thought a receiver of an event could create a topic first before subscribing. The sender would simply try to push all the data (the push would fail if nobody created and subscribed for it). Is this a valid pattern?
I know that I have to somehow solve the deletion of topics (the receiver can't do much as others might have subscribed in the meantime as well).
Yes, it's a valid pattern. Actually receiving and processing messages will cost money. If you use SQS recipients, you will need to beware of queue receivers that are not used, though. The costs will add up very quickly.
Depending on your use case, AmazonMQ (SaaS ActiveMQ) may work better. All kinds of Topic policies can be implemented without cost for the listeners or individual topics.
I'm implementing an Alexa search skill for a website. My question is that there is some kind of possibilities to give intents some kind of scopes, so built in Intents could be reused?
I mean, for ex. the AMAZON.YestIntent to have different functionalities on different situations.
You can handle this in your intent handler. You can save context information in the session or a database if you are using one. Then in the intent handler, test the session or DB data to determine which response to take.
For example, in the Who's On First? Baseball Skit skill, the dialog between the user and Alexa is about 85 lines long. The user can say "who?" at several different places in the dialog, and Alexa needs to respond differently depending upon which line of the dialog they are at. To handle this, I simply save the line number in the session. Then when an intent is called, the intent handler gets the line number session variable, uses it to select the appropriate response, and increments it and passes it along in the session for the next line.
It really depends on the complexity of your skill, the accepted answer is a perfectly correct implementation for a simple flow and it starts to address keeping state tied to the session.
If your skill is more complex and you're using Node.js, I would suggest using the official SDK which offers this functionality out of the box:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs
The state management allows you to define which intents should be handled in each state and the rest can be passed to a context-specific handler. More information is here:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs#making-skill-state-management-simpler
The state management takes a little getting used to, but once you have used it, you won't go back because of the control it offers you over the experience.
I am trying to make a chat application in meteorJS and i was thinking of making a seperate collection for each groups dynamically when they initiate chat, I want to publish and subscribe that collection for transmitting chat information and all the group user can subscribe it, but i am not being able to create a collection dynamically.
I tried making a function which gets call when the user subscribe the collection.
this.createDb =(name) ->
#ChatDb = new Mongo.Collection(name)
return true
everything is fine, but when i subscribe this collection from client side, ChatDb is unknown, Can any one help me with this, that would be great. :)
ps- i am writing code in angular-meteor framework
Andrew Mao's answer to a similiar question:
In most instances, you probably don't want to create multiple
collections, but instead use one collection and send views of it to
clients depending on their subscription.
You may want to check out the
https://github.com/mizzao/meteor-partitioner package I've built which
is designed especially for this purpose, and includes an example for
how to do this for multiple chat rooms. You can also see
https://github.com/mizzao/CrowdMapper for an implemented example.
I haven't done Meteor for a while now so I couldn't give you a solid answer. But I remember quite clearly that creating collections dynamically is not the recommended way for achieving what you want to do.
I am writing an Adobe AIR application using PureMVC.
Imagine that I have an page-based application view ( using ViewStack ), and user is navigating through this pages in some way ( like clicking the button or whatever ).
Now for example I have an Account Infromation page which when instantiated or showed again needs to load the data from WebService ( for example email, account balance and username ), and when the data is returned I want to show it on my Account Information page in the proper labels.
The problem is when I will execute this three Web Calls, each of them will return different resultEvent at different time. I am wondering what is the best way to get the information that ALL of the service calls returned results, so I know that I can finally show all the results at once ( and maybe before this happens play some loading screen ).
I really don't know much about PureMVC, but the as3commons-async library is great for managing async calls and should work just fine in any framework-setup
http://as3commons.org/as3-commons-async/
In your case, you could create 3 classes implementing IOperation or IAsyncCommand (depending on if you plan to execute the operations immediately or deferred) encapsulating your RPCs.
After that is done you simply create a new CompositeCommand and add the operations to its queue.
When all is done, CompositeCommand will fire an OperationEvent.COMPLETE
BTW, the library even includes some pre-implemented common Flex Operations, such as HTTPRequest, when you download the as3commons-asyc-flex package as well.
I would do it in this way:
Create a proxy for each of three information entities (EMailProxy, BalanceProxy, UsernameProxy);
Create a delegate class which handles the interaction with your WebService (something like "public class WSConnector implements IResponder{...}"), which is used by the proxies to call the end ws-methods;
Create a proxy which coordinates all the three results (CoordProxy);
Choose a mediator which will coordinate all the three calls (for example it could be done by your ApplicationMediator);
Create notification constants for all proxy results (GET_EMAIL_RESULT, GET_BALANCE_RESULT, GET_USERNAME_RESULT, COORD_RESULT);
Let the ApplicationMediator get all 4 notifications;
it is important that you should not only wait for all three results but also be ready for some errors and their interpretation. That is why a simple counter could be too weak.
The overall workflow could look like this:
The user initiates the process;
Some mediator gets an event from your GUI-component and sends a notification like DO_TRIPLECALL;
The ApplicationMediator catches this notification, drops the state of the CoordProxy and calls all 3 methods from your proxies (getEMail, getBalance, getUsername).
The responses are coming asynchronously. Each proxy gets its response from the delegate, changes its own data object and sends an appropriate notification.
The ApplicationMediator catches those notifications and changes the state of the CoordProxy. When all three responses are there (may be not all are successful) the CoordProxy sends a notification with the overall result.
I know it is not the best approach to do such an interaction through mediators. The initial idea was to use commands for all "business logic" decisions. But it can be too boring to create the bureaucracy.
I hope it can help you. I would be glad to know your solution and discuss it here.
What is the difference between MVVM messaging and RaisePropertyChanged.
I'm trying to run a function in View model A when a property in view model B changes, which approach is a better one to use - Messaging or RaisePropertyChanged broadcast?
Thanks,
Nikhil
Messaging decouples your view models. It's like a Tweet, you send out a message into the air and someone can read it or someone could register to listen for it. PropertyChanged is used by the UI to know that something changed and to redraw the values.
Messaging is definitely the best choice. MVVM light has a built in option to broadcast the message. You can use the mvvminpc code snippet.
It's surprising your post wasn't answered sooner. Maybe this answer will still be useful to someone out there.
To follow #Kevin's post:
Messages are indeed used for decoupled comunication. This means that once the message is sent one or more recipients - who have registered their interest in a particular message type - are notified.
In general I use INotifyPropertyChanged when the comunication between the view and the view-model is concerned (via databinding) and messages when I want to communicate between multiple view models or upward from the view-model to the view and databinding is not concerned.
When receiving messages in the view model make sure that you call Cleanup to unregister from the Messenger. If you handle the message in the view - where no Cleanup is available - register for the Unloaded event and call Messenger.Unregister(this) from there.
Depends on how View model A and View model B relate to each other.
If View Model A already has direct reference to B for a valid reason (e.g. A "owns" B i.e. it is parent-child relationship) then just subscribe to B.PropertyChanged event. That way B doesn't need to remember that something depends on it which is in spirit of reactive programming.
(offtopic: in case if B has longer lifetime than A then don't forget to unsubscribe from event because "long living publisher / short living subscriber" can result in memory leaks).
If A and B are unrelated / in very different parts of the app then messaging might be a better choice.
Messaging should be used when it is solving a specific problem. If you uses it everywhere your application becomes difficult to maintain and later understand the code.