Network Observer Exercise

For this assignment, you will be extending/modifying your code from the "chain" exercise (proxy, chain, almost flyweight... let's refer to it as "chainEx"). You can also think of it as modifying one of the observer examples we looked at in class, and adding to it some of the network proxy code you wrote for the "chainEx". You will write a program that has a model (subject) and three observers (you can make more if you wish). The observers will be observing the subject across the network.

Subject:
For the subject, let's use a combination of the button panel from "chainEx", and one of the chain processors (I guess technically we will have a chain of respopnsibility of length 1, but that's not the point of this exercise). Make the GUI be an array of buttons 20x15, with labels from 1 to 300. Each time the user clicks a button, the label number will be sent to the chain (as in "chainEx"). The chain's one "processor" will handle the subject state changes. It will take the number, save it as state, and then notify it's observers that there has been a state change.

Note that this makes the processor the subject, a separate object from the button panel GUI object. If the state information was saved and handled in the GUI object we would still have the Observer pattern, but we want to make the subject a separate object for better modularity. In this way, we could have other GUIs or objects sending change-state information to the subject. We can even have observers sending change-state requests; the set state method in the subject is not required to be private, and miht be accessed by any client code.

Observers:
The observers will be three different processes that are communicating over the network with the subject (that means 4 total processes, counting the GUI/subject). So they are like the PP, OP, and EP from "chainEx". Let's make one observer display the state of the model every time there is a state change. Let's have another observer report the state of the model only when it is a prime number. Finally, let's make the 3rd observer only report the model state on every 4th state change. Each observer will provide its "view" of the model by simply printing out the state (number). System.out.println is fine... no need for any popup windows or anything like that unless you want to fancy it up.

Two-way registration:
We have an issue over how to get the observers registered with the subject. The processes are starting at different times. In the single-process example from class, the registration was done by first creating the subject. When each observer was instantiated, the subject was passed to the observer class constructor. Then in it's constructor, the observer passed a reference to itself back to the subject.

We can try to do this in the network case. One idea is to use a proxy. Do we want one proxy, representing the subject as far as the observers are concerned? This way, the proxy will contain the list of observers rather than have it in the subject proper.

Another way is to create one proxy for each observer (on the subject side), and then the subject will keep a list of observer proxies. An observer proxy will handle network communications as well as making decisions related to whether to engage the network or not. Once the proxy is created, and registered as an observer, it will then be listening on its pre-determined port for the matching observer process elsewhere to check in and establish a network connection.

Since the subject and the observer proxies are in the same process, we can create the subject first, and then send a reference when we run the constructor for each proxy. Within the proxy constructor, the subject is called and passed a reference to the observer proxy being created.

Other ideas or approaches?

Issues:
Can we build a structure that allows us to fire up a new observer over the network and have it register with the subject, and have the subject not know about it in advance? Can this happen if we use one proxy for the subject?