I have objects A and B that need to send and receive messages from each other.
For example:
I click, this causes A to send a message to B. B does something with it then sends A another message as a reply.
Right now the way I have it is,
A has a B* and B has an A* and they call each other's sendMessageTo method to communicate.
Is there a better way to do this sort of thing?
Basically, the server sends a message or the local game sends a message which a polymorphic mediator takes in. The mediator either gets the message from the server or local game. The mediator passes it on to the client which does whatever with it. The idea is that the mediator should not be doing logic for the client hence message passing.
I think you need to implement Listener/Observer pattern.
from Wikipedia:
The observer pattern (a subset of the publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
For more ref:
http://en.wikipedia.org/wiki/Observer_pattern
http://www.codeproject.com/KB/cpp/CppEvents.aspx
http://www.codeproject.com/KB/architecture/observer.aspx
Related
I have three actors to handle a CQRS scenario. The ProductWorkerActor handles the command part, ProductQueryWorkerActor handles the query part and ProductStateActor handles the state part.
The way I'm handling the query is by using:
ProductQueryWorkerActor.Ask<ProductState>("give-me-product-state-for-product-1000")
The code from ProductQueryWorkerActor:
if (message == "give-me-product-state-for-product-1000")
{
var actor = Context.ActorSelection("akka://catalogSystem/user/productState/1000");
var psDTO = actor.Ask<ProductStateDTO>(message).Result;
Sender.Tell(ps);
}
Please ignore the path being used to access the product state. It is hardcoded and intentional to make the code read simpler.
Should I be using Ask as I have used in this case to retrieve the state of a product? Is Ask called Futures?
Should I be exposing the state as DTO to the outside work instead of the actor itself?
To change any state of the product, should I handle the message processing in ProductWorkerActor or in ProductStateActor itself? In the second case, the ProductWorkerActor sends a message to ProductStateWorker, the ProductStateWorker processes the message, change the state and send another message to ProductWorkerActor that it passed validation and changed the state.
In case when you're using Event Sourcing with your actors, I advice you to use Akka.Persistence. It handles read/write actors separation and will take a lot of burden from you shoulders.
If not, in my opinion basic problem with your design is that, while you have separate actors for reading/writing to state, state itself is handled in only one actor. Why? One of the points of CQRS is to have a separate models optimized for serving their role (either read or write).
In example: you can have one handler actor (eg. ProductActor) changing it's state based on incoming commands, and bunch of different readonly actors (eg. ProductHistoryActor, ProductListActor), each with it's own state optimized for their role. Readonly actors may subscribe to event stream to listen for incoming messages about handler actor's state changes and updating their own states accordingly, while handler actor after handling a command publishes message about state change using actor system's event stream.
Ad. 1: In my opinion using Ask to communicate between actors is an anti-pattern. In your example, you're using query actor to pass message through to state actor, then blocking current actor until response arrives (which is very bad for performance) just to send message back to sender. Instead of using:
var psDTO = actor.Ask<ProductStateDTO>(message).Result;
Sender.Tell(ps);
you could simply write:
actor.Forward(message);
and let actor send response directly to sender (you query actor doesn't need to participate with sending the response).
Ad. 2: It depends on your case, but remember - you should never pass mutable objects as messages, especially when you use them after sending.
Ad. 3: I think that in your example distinction between ProductWorkerActor and ProductStateWorker is artificial. From what you're showing, they should be a single entity IMO.
I have a test for particular actor. This actor depends on some other actors, so I use TestProbe() to test in isolation.
My problem is, that I receive more messages then I am interested in testing at this very particular test. For example:
val a = TestProbe()
val b = TestProbe()
val actor = TestActorRef(new MyActor(a.ref, b.ref))
actor ! Message(1, 2)
b.expectMsg(3)
The test fails, because while creating MyActor it sends some kind of "registration" message to ones passed in constructor.
The message 3 arrives eventually, but assertion fails - this is not the first message to arrive.
I would like to avoid asserting more messages than I need for a test - those can change, etc, it is not the scope of a particular test anyway.
As the TestProbe does not contain such methods - I suspect there may be something wrong with my test setup (or rather my project architecture then). I see there are many methods like fishForMessage but all those require a explicit time parameters which seems like irrelevant as my whole test is purely synchronous.
Is there any way to accomplish such test is desired message is just among all the were received? If not, how can my setup can be improved to be easy testable?
The fishForMessage actually fits. All these assertions including expectMsg are asynchronous. expectMsg just uses the preconfigured timeFactor as timeout.
TestActorRef guarantees you only that CallingThreadDispatcher will be used to send messages and execute futures (if they use dispatcher from the test actor), so they will act sequentially til they're use context.dispatcher. Nothing stops some code inside your MyActor from using another dispatcher to send a response, so all checks still should be asynchronous - you just can't get rid of that.
Question from an akka newbie: let's say that at some point one of my actors wants to issue an HTTP request against an external REST API. What is the best way to do it? (note: I would ask the same question about an actor wishing to store data in a RDBMS).
Should I create another type of actor for that, and create a pool of such agents. Should I then create a message type that has the semantics of "please make an HTTP call to this endpoint", and should my first actor send this message to the pool to delegate the work?
Is that the recommended pattern (rather than doing the work in the initial actor)? And if so, would I then create a message type to communicate the outcome of the request to the initial actor when it is available?
Thank you for your feedback!
Olivier
This question is old now, but presumably one of your goals is to write reactive code that does not block threads, as sourcedelica mentioned. The Spray folks are best known for their async HTTP server and their awesome routing DSL (which you would use to create your own API), but they also offer a Spray-client package that allows your app to access other servers. It is based on Futures and thus allows you to get things done without blocking. Filip Andersson wrote an illustrative example; here are a few lines from it that will give you the idea:
val pipeline: HttpRequest => Future[HttpResponse] = sendReceive
// create a function to send a GET request and receive a string response
def get(url: String): Future[String] = {
val futureResponse = pipeline(Get(url))
futureResponse.map(_.entity.asString)
}
If you are familiar with futures, you know how you can further operate on Futures without blocking (like that map invocation). Spray's client library uses the same underlying data structures and concepts as their server side, which is handy if you are going to do both in one app.
Yes that sounds like a good approach.
If your HTTP client is blocking you will want to run the REST API calls in a different thread pool so you don't block your actors. You can use Future in actors to avoid blocking. Using a pool of actors is also possible though it's a little more work to set up.
For example, at the top level of your application create a ExecutionContext that is passed to actors that you create:
implicit val blockingEc =
ExecutionService.fromExecutorService(Executors.newFixedThreadPool(BlockingPoolSize))
class MyActor(implicit blockingEc: ExecutionContext) extends Actor {
def receive = {
case RestCall(arg) =>
val snd = sender()
Future { restApiCall(arg) } pipeTo snd
}
}
This will run the blocking call and send the result back to the requestor. Make sure to handle Status.Failure(ex) messages in the calling actor in case the restApiCall threw an exception.
The specific type and size of thread pool really depends on your application.
In Practical Object-Oriented Design in Ruby: An Agile Primer, the author writes, "[An object] is responsible for testing its own interface and it does so by making assertions about the results that these [incoming] messages return. … These messages need tests because other application objects dpeend on their signatures and the results they return."
She explains that "the first requirement for testing an incoming message is to prove that it returns the correct value in every possible situation," giving this as an example unit test for the diameter method for a hypothetical Wheel class:
def test_calculates_diameter
wheel = Wheel.new(26, 1.5)
assert_in_delta(29, wheel.diameter, 0.01)
end
My question is, what about incoming messages that don't return a value? I have an object whose public interface only has two methods that don't return a value but merely change the state of the receiving object. Do I still need to test that object? and, if so, how?
In typing the question, I think I've realized the answer: to use the author's nomenclature, I should test the outgoing "command" messages that are sent in response to the incoming messages.
For some context, the author later writes, "Many outgoing messages do have side effects (… an action is taken by an observer) upon which your application depends. These messages are commands and it is the respondibility of sending object to prove that they are properly sent."
In my case, my object is a container that sends messages to its children when its state changes, so that object's test should ensure that those messages are sent to its children.
Trying to understand What is IConnectionPoint and how this is connected to IConnectionPointContainer,IEnumConnectionPoints,IEnumConnections and EventHandling.
Read the artcicles from MSDN and CodeProject which is explaining a about other methods like: QueryInterface() and otherthings.
I am unable to figure out how all these things(IConnectionPointContainer,IEnumConnectionPoints,IEnumConnections) are interconnected with eachother and event Handling.
I just want to create a simpleClient which Will trigger an event in COM object.
If there are any articles or code snippet that can explain how things are related to each other with simple and small chunk of code will be helpfull.
Worth mentioning that I have started development in C recently, a beginner.
Edit #sharptooth
For the Line "typically your client will receive events and the COM object will trigger those events. "
From many articles, What I understood is When we use connection points at that point,
the client exposes a set of methods that the server uses.
I am just Outlining portion of the article from TechRepublich:
Client server vs. sink source
So the main difference between normal programming with COM in a standard client-server system and using connection points is that in the standard client-server case, the server exposes a list of methods that the client employs, and in the connection point case, the client exposes a set of methods that the server uses.
Looks like you get the big picture wrong. Typically your client will receive events and the COM object will trigger those events. To achieve this the client requests (QueryInterface()) the IConnectionPointContainer interface, calls IConnectionPointContainer::FindConnectionPoint() and IConnectionPoint::Advise() and passes a pointer to itself or some subobject there.
The client will have to implement some events interface (the one GUID of which is passed into IConnectionPointContainer::FindConnectionPoint()). Once subscribed (advised) the client will receive calls from the COM server - the events.
Typically the COM server does something routinely and decides to notify clients of it (say a user moves the mouse in an ActiveX control) - it just gets an array of pointers to event receivers and calls a method it wants on that interface.
COM events are in fact an implementation of callbacks. The same way you use callback in C++ (or C or any other languages supporting function pointers or interfaces) you use events in COM. Yes, you're right that when the server triggers the event the client in fact acts as a server reacting to the event. That's a callback scenario - the other code calls your functionality. In this case the server calls your implementation of the events interface.
These two articles provide useful information:
https://devblogs.microsoft.com/oldnewthing/?p=4113
https://devblogs.microsoft.com/oldnewthing/20130612-00/?p=4103
What #sharptooth forgot to mention is, the pointer passed to IConnectionPoint::Advise must be a pointer to a COM object.
This means It must not only implement the particular events interface but also the IUnknown interface.