Solution B only works if you request the data from System A every time it is required by System B. Otherwise you cannot guarantee the information is up to date. This is not as bad as it sounds and is in fact the basis of all SOA architectures.
The decision of whether to push (Solution A) or pull (Solution B) depends on the ratio of updates in system A to the number of queries in System B.
Where you have lots of updates in system A versus a few queries in System B then "pull" is the obvious choice.
Where you have relatively few updates in system A and lots of queries in System B then "push" is the way to go.
Where you have lots of updates and lots of queries either choice is equally good (or bad!).
in the case where almost everyone needs to know about a certain data structure, why is Dependency Injection any better than a global object?
Dependency injection is the best thing since sliced bread, while global objects have been known for decades to be the source of all evil, so this is a rather interesting question.
The point of dependency injection is not simply to ensure that every actor who needs some resource can have it, because obviously, if you make all resources global, then every actor will have access to every resource, problem solved, right?
The point of dependency injection is:
- To allow actors to access resources on a need basis, and
- To have control over which instance of a resource is accessed by any given actor.
The fact that in your particular configuration all actors happen to need access to the same resource instance is irrelevant. Trust me, you will one day have the need to reconfigure things so that actors will have access to different instances of the resource, and then you will realize that you have painted yourself in a corner. Some answers have already pointed such a configuration: testing.
Another example: suppose you split your application into client-server. All actors on the client use the same set of central resources on the client, and all actors on the server use the same set of central resources on the server. Now suppose, one day, that you decide to create a "standalone" version of your client-server application, where both the client and the server are packaged in a single executable and running in the same virtual machine. (Or runtime environment, depending on your language of choice.)
If you use dependency injection, you can easily make sure that all the client actors are given the client resource instances to work with, while all the server actors receive the server resource instances.
If you do not use dependency injection, you are completely out of luck, as only one global instance of each resource can exist in one virtual machine.
Then, you have to consider: do all actors really need access to that resource? really?
It is possible that you have made the mistake of turning that resource into a god object, (so, of course everyone needs access to it,) or perhaps you are grossly overestimating the number of actors in your project that actually need access to that resource.
With globals, every single line of source code in your entire application has access to every single global resource. With dependency injection, each resource instance is only visible to those actors that actually need it. If the two are the same, (the actors that need a particular resource comprise 100% of the lines of source code in your project,) then you must have made a mistake in your design. So, either
Refactor that great big huge god resource into smaller sub-resources, so different actors need access to different pieces of it, but rarely an actor needs all of its pieces, or
Refactor your actors to in turn accept as parameters only the subsets of the problem that they need to work on, so they do not have to be consulting some great big huge central resource all the time.
Best Answer
Hope you are not looking for a platform specific solution
If Yes, your requirement highlights a pub/sub pattern. I handled the same using RabbitMQ which has specific support for Pub/Sub scenario.
Without going in to granular details, to give you an idea on RabbitMQ's pub/sub model
It has something called "exchange" in addition to "producer","queue", & "consumer"
The core idea on this messaging model is that the producer never sends any messages directly to a queue. A quite often the producer doesn't even know if a message will be delivered to any queue at all. The producer can only send messages to an exchange. An exchange receives messages from producers and the other side it pushes them to queues.
It supports different exchange types to satisfy your various needs - direct, topic, headers and fanout.
This means greater flexibility to de-couple core MQ functionality from the business logic, which you may want to impose on message formats/delivery/retry logic
I used "topic" exchange type which supports message routing/filtering just by looking at message name/title.
To give you a best use of this logic - I had a weird requirement (on pub/sub model) to maintain the list of active subscribers , which I managed to get it done by introducing a heartbeat (topic based) message on the same queue
For the said reasons, and high accuracy on message delivery, and good performance results of supported AMQP protocol, I felt quite happy about my choice
Disclaimer : I am not advocating here that RabbitMQ is the only choice, but sharing this as my nice experience with a smart solution. There are quite few pub/sub solutions out there in the market.
I also found WAMP interesting while exploring various options,but didn't use it for any commercial implementation