Observer Pattern – Implementing Over HTTP and TCP/IP

You can use a technique often referred to long-polling or comet, which allows to implement a "push"-based event/update system.

Principle

The principle is rather simple:

1. client sends a request to server and keeps connections alive;
2. server keeps a handle on the connection and waits;
3. when updates are available, server sends back data to client;
4. (depending on client-side tech) client may need to send a new request.

This way the clients don't poll regularly. However, that implies that a significant number of connections might be kept alive at any single given time, so make sure you understand the implications of this approach for your server.

How to Implement It?

So, the underlying principle remains the same no matter what your platform is: as long as you can send an HTTP request and wait for the response synchronously or asynchronously, you have a way to implement long-polling.

Heavy Clients

With most programming languages aimed at developing desktop solutions (or "heavy" clients), you'd usually resort to your usual network tools: sockets.

Lightweight/Rich Clients

If we're talking about a rich web-client to build in a browser-based solution, you have the option to:

• use your usual XMLHttpRequest object (the server will only reply once it's got something to send back, at which point the client will either re-initiate another connection or use a spare one if it opened multiple ones to ensure there's always multiple channels opened at hand),
• or to use <script> tags that query a URL sending back a payload wrapped in a call to function defined in the client's context (see JSONP),
• or to use WebSocket API introduced with HTML5,
• or a variation of the above or using an external tool (Java Applet, Flash, etc...) to achieve the same effect.

Beware that, as is often the case with web techs, cross-browser support is going to require extensive testing, and you may be forced to use a combination of the above techniques if you target hostile browser market shares...

Yes, you are right. Both objects know each other if that is what your are referring to. The important thing is what they know about each other. While the BinaryObserver knows the Subject in detail the Subject knows only Observers. To be more precise the Subject doesn't know the details about your BinaryObserver it can only send messages to it that are defined in the Observer class. In that way Subject is decoupled from the details of your BinaryObserverclass.

To sum up, while the coupling of the BinaryObserver to the Subject is very high the coupling in the opposite direction is weak.