I have 2 programs A, B. If A finishes, I want B to know that and start to run, using data from result of A.
A is a .NET web application. I think that’s not kept alive in memory all the time, right? Only alive if requested from browsers, right?
Before, A and B are the 2 functions of the same program. But B program fails sometimes due to business reasons. And even if B doesn’t fail, it’s time-consuming and makes the clients wait for too long and be unhappy. So I separated B out. Clients using A smoothly and are happy. B do staff in background.
My current design is: when A finishes, A saves the data into database. B is a windows service. It checks the database every 5 minutes and start to run if finds new jobs. A, B doesn’t know each other.
The boss asked why idle for 5 minutes? I answered because that’s the simplest way of implement some of our business. I didn’t design much.
So I went to read materials, and found that the Observer Pattern seemed like what I want. After several readings, I think the Observer Pattern can only be applied to classes in the same program, and the classes and objects are in memories.
I’m not sure if my question is: Can the GOF Design Patterns be applied to different programs?
or: How does something like RabbitMQ implements this real-time-processing kind of requirements?
I cannot imagine to set check interval of 5 minutes to a really small time period. That’s a lot of burden to cpu.
EDIT: I have come into this explanation about Observer and Publish/Subscribe, which I think is useful to those seeing this thread from search.
http://addyosmani.com/resources/essentialjsdesignpatterns/book/#observerpatternjavascript
Differences Between The Observer And Publish/Subscribe Pattern
The Observer pattern requires that the observer (or object) wishing to receive topic notifications must subscribe this interest to the object firing the event (the subject).
The Publish/Subscribe pattern however uses a topic/event channel which sits between the objects wishing to receive notifications (subscribers) and the object firing the event (the publisher). This event system allows code to define application specific events which can pass custom arguments containing values needed by the subscriber. The idea here is to avoid dependencies between the subscriber and publisher.
This differs from the Observer pattern as it allows any subscriber implementing an appropriate event handler to register for and receive topic notifications broadcast by the publisher.`
You’re right that the Observer Pattern is more for designing OO classes. One pattern that can work between programs is the publish-subscribe model, and I think that would be a good fit for what you describe. Process B subscribes to certain events that are triggered by A. This is typically mediated by a service architecture; eg, process A and B are web applications (or WCF/MVC/Web API), and there’s a third application that mediates the publish-subscribe pattern. So when A completes, it sends an event to the pub-sub service; and the pub-sub service sends out a notification to all subscribers to that event (in your case, application B).
You can implement this pattern yourself; there are also .NET frameworks such as NServiceBus that implement it.