I'm looking for a reference to a good implementation of event driven architecture based on Zend Framework. Could you share your experience in this topic?
I've found two solutions, but haven't used them yet:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Event+-+Alvar+Vilu
http://components.symfony-project.org/event-dispatcher/
Edit:
Example:
http://www.slideshare.net/beberlei/towards-the-cloud-eventdriven-architectures-in-php
I don't have much practical experience in this topic, but since no one else seems to be replying, I suppose I'll share what I think of this...
This is perhaps a bit tricky thing in PHP apps, since they typically only run for the duration of a request, so the benefit of being able to subscribe and listen to generic events during that short phase may not be very large.
However, I think there can be some benefits in allowing you to decouple your code more.
From what I can tell, the Symfony dispatcher looks better - mainly because it looks simpler.
I've used a sort of dojo pubsub type system myself: Basically you have an event publisher, to which classes can publish events. This is a sort of global event handling, where you don't specifically subscribe to the class itself - instead you subscribe to a specific event, and it doesn't matter what class publishes the event.
The benefits of this vs. subscribing to a specific class is that the code is decoupled more: In my case, it's a ZF app, and classes which subscribe to events can simply do it in the bootstrap, vs. having to do subscriptions in controllers (or where ever the publishers are created)
The downside of this approach is that it can make dependencies between things harder to track. For example you only see an event publish call, but you have no idea what sort of things listen for it without digging further into the code.
In my case I don't really know if the application has got any benefits from using this architecture - in fact I've several times considered removing it entirely and just using the objects which listen to the events directly.
Related
I have recently watched several videos about ES and CQRS models as well as I have watched few talks about AKKA persistence. I know what they are about but I have issues writing actual code that will execute.
I have few questions though.
How should i make view and event stack communicate?
Will events be passed between view and persistent actor of same persistence id passed?
What are persistent actor and view responsible for according to the model?
Edit: Where should i place my business logic? According to model i should do that in write, but what if i need to check something in read to validate cmd?
You shouldn't need to check something in your read mode to validate a command - your command would execute against your write model.
Your business logic would go in your write side, if using Akka then inside an Actor.
You haven't said what your view is so there could be multiple ways of communicating - for example, if a web page you could do req/res, or use something like SignalR
I am developing a GWT app using GWTP (Model-View-Presenter) that is deployed to GAE. Persistence will be done using Google Cloud SQL.
I am not sure what to use to send data to the database (persistence) and request data: GWT RequestFactory or GWTP Actions. Are they equivalent? What are benefits of each one for this scenario?
Thanks
I wouldn't use Request factory as it stands right now. Even for CRUD it's much more complicated to us than GWTP Actions.
RF is a great and powerful tool, but it's a little bit over engineered and working with complex data can be really difficult with all the "frozen" states problems that you will end up having. The real problems comes while using the editors with nested structures. You'll have problems saving the second level of proxies and even more the third level. Using editors with nested structures is a lot more easier with the SimpleBeanEditorDriver since you don't have to deal with the nasty frozen state for each level of nested objects.
For a simple object graph with simple CRUD support, RF is perfect, but as soon as you go to more complicated structures, brace yourself, it won't be easy to handle. Once you become a RF expert, it become a really powerful tool, but it still require more work than GWTP Actions to accomplish the same thing.
For server side security using RF, I've used AoP. On the other side, you could use action handlers, but even by using action handlers, there's some case where AoP on a service call is more appropriate.
For client side batching and caching... that's something that is really hard to achieve with RF. The documentation is unclear and dealing with frozen state within the cache is a nightmare. With GWTP-Action, there's already a simple cache implementation that you can use.
For a data-oriented app (CRUD), you should definitely use RF because it has been designed for that purpose. Now if your app is more action-oriented and these actions does not involve much data, it’s better to use the Command pattern. But nothing prevents you from using both in your app.
RequestFactory only.
Everything you need is there. If you just want to send a basic message you just call a method with whatever parameters you want.
Problem with Actions is that they're a lot more verbose than RF semantics...
Only thing you don't get with RF is the ability to use ClientHandlers...
Most examples (if not all) that I see are the sort of a function that does some sort of computation and finishes. In that aspect, FP shines. However, I have trouble seeing how to apply it in the context of an enterprise application environment where there's not much of algorithms going on and a lot of data transfer and services.
So I'd like to ask how to implement the following problem in FP style.
I want to implement an events bus service. The service has a register method for registering listeners and publish for publishing events.
In an OO setting this is done by creating an EventBus interface with both methods. Then an implementation can use a list to hold listeners that is updated by register and used in publish. Of course this means register has a side effect. Spring can be used to create the class and pass its instance to publishers or subscribers of events.
How to model this in FP, given that clients of the event bus service are independent (e.g., not all are created in a "test" method)? As far as I can see this negates making register return a new instance of EventBus, since other clients already hold a reference to the old instance (and e.g., publishing to it will only publish to the listeners it knows of)
I prefer a solution to be in Scala.
I think you should have a closer look at functional reactive programming techniques. Since you want something in Scala, I suggest reading Deprecating The observer pattern paper by Ingo Maier, Tiark Rompf and Martin Odersky.
The sketch of the solution is that publish should return IO[Unit]. Listeners should be iteratees. Registration also returns IO[Unit].
Given the following scenario:
ViewModelA launches ViewModelB (via a common Controller, of course, that uses Ioc and DI to resolve the types needed).
ViewModelB needs to set a property value in ViewModelA.
Is it bad to simply inject ViewModelA into ViewModelB via constructor injection and just set the property directly?
Or…
Should a messaging system like the EventAggregator from Prism be used to handle all communication between ViewModels?
I like the injection approach because it’s easy, but my instincts are telling me I’m missing something. I call on your collective wisdom to help fill in my blind spot.
I consider it a code smell if you need two-way references. Often you can replace one of the references with an event.
Let ViewModelB raise an event that ViewModelA subscribes to. A complete messaging system like the one found in Prism is certainly an option, but in your scenario it sounds like a 'normal' event will do just fine.
I suggest you read this question (and my answer) since it's similar, but not exactly your problem. It does deal with communication of properties between parent/child ViewModel objects.
Let's look at a basic example:
ViewModelA is the parent and has to present the Sum of some property on B
ViewModelB is the child and has a property that needs summing
So the user makes a request to edit the property on B and the request succeeds, so B presumably changes the value of its property and fires a PropertyChanged event.
ViewModelA could subscribe to the events on all children, but having gone down that path, I don't like it. When children are added and removed, you have a lot of bookkeeping to do.
Injecting A into B is cleaner, but you still have a lot of bookkeeping to do. What if you have a "Clear Children" action on A? You have to remember to properly get rid of the parent relationship from B to A in all cases. Still it's better than events in my opinion because it's more explicit.
Personally I like the messaging idea. I'm more familiar with MVVM Light's messenger than Prism, but it's the same idea... a global message bus. At any time, any B can say "I changed my property!" and then A listens for the notification and does the computation itself. I think this is your cleanest solution with much less bookkeeping.
I suggest using a much lighter dedicated Messaging solution called "Light Message Bus". It is not part of any yet another ;-) MVVM framework, but independent component. And I got it working in no time in less than 3 minutes.
You might find the sample applications of the WPF Application Framework (WAF) useful. The ViewModels don't know about each other. The mediation between them is done by Controllers. This way you can prevent cyclic dependencies between ViewModel objects.
I am working on a web application which needs to get data from some local and some non local resources and then display it. As it could take arbitrary amount of time to get the data from these resources I am thinking of using the actors concept so that each actor is responsible for getting data from the respective resource. The request thread will wait for each actor to finish its task and then use ajax to update only the portion of the web page that is dependent on that data. This way user will start seeing the data as soon as it is received rather than wait for all of them to finish and then get a first look at the data.
I am planning to look into scala/lift framework for this. I have read some articles on the web for scala/lift and want to explore if this is the correct way to approach this problem and also if scala/lift is good platform of choice. I have worked in Java and C# previously. Any opinions, comments, suggestions are welcome.
Thanks,
gary
Take a look a message queue technology like Java's JMS. Message queues allow you to handle long running background tasks asynchronously and reliably. This is the technique sites like Flickr and YouTube use to do media transcoding asynchronously. You can use a Java EE server, or a JMS technology like Apache's ActiveMQ, and then layer your Scala/Lift code on top of it.
Richard Monson-Haefel's book on JMS covers it well.
For more general help with web site scaling and construction, take a look at Todd Hoff's excellent blog, highscalability.com/. There are some good pointers to using message queues to offload long-running tasks this way.
BTW, Twitter uses Scala for something much like what you're considering. Here's an interview with some of their developers; they describe one way they use Scala:
Robey Pointer: A lot of our architecture is based on letting Rails do what it does best, which is the AJAX, the web front ends, the website—what the user sees. Anything we can offload out of the request/response cycle, we do. So we queue those tasks into a messaging system and have back-end daemons handle them.
If the non-local resources originate at some other service or system, Event Driven Architecture might work for you. Instead of pulling from the non-local resources you could set up this web-application as a subscriber to the events published by these services. Upon receiving a message regarding part of its functionality it would cache locally the data it's interested in. This should let you escape the issue of asynchronous update of parts of the page (all data would be accessible locally).
Udi Dahan blogs about this approach a lot and is also an author of a .NET message bus (NServiceBus) that can be used in such scenarios. See for example http://msdn.microsoft.com/en-us/architecture/aa699424.aspx
Actors would be a way to go. You're essentially setting up a light weight version of JMS. And Lift does the comet stuff very well.
In addition to the Scala actors, and the Lift Actors, you also have akka actors. When Scala Swarm becomes production ready you'll be ready for that too.
If the delayed information is distinct from the information that needs to display immediately, with Lift you can use a LazyLoad snippet that has the longer-running computation (calling the web service) as part of its logic. Lift will take care of inserting it into the page when its ready.