Design pattern needed

Question

Hi,

I am going to develop a tool that will do the following:

• collect the files from remote server - periodically every few minutes.
• Export the collected files into a one single file.

From the client, it sends a request to the server every 5 or 10 mins. Then server then sends a list of files. This part is called 'collection'. After 'collection', 'export' needs to be done (consolidate all files that have been collected during the 'collection' period.

My idea is that the above 'collect' and 'export' actions are like 'producer' and 'consumer'. So, can I use the 'observer' pattern to implement the above actions? If not, please propose any other design pattern.

Regards, Kannan DV

Answer 1

Since the two components are naturally loosely-coupled, you can design, implement and test them separately. I don't think that there is an inherent need for one of the known patterns here.

However, if you wish to receive notifications from the collector, you can indeed look into the Observer pattern:

Observer. Define a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

On the other hand, as I understand, exports aren't done when the Exporter requests it, but in fixed intervals, so the Exporter can get a Collection any time, so you'll probably need some cache mechanism in the Collector (rather than a notification system).

Answer 2

Sounds promising. To give a good advice here, someone might need more information about your context and your expectation of the tool. Its up to you to find the right responsibility assignments for your components.

I find this article very helpful to find the right slicing of components:

link On the Criteria To Be Used in Decomposing Systems into Modules

Answer 3

The difficult bit here is ensuring/managing the fact that the producer needs to know that the consumer successfully received the collection.

When it sends the files but doesn't receive an acknowledgement receipt, does it automatically just leave the files in-place for the next collection and let the consumer sort it all out, or does it need a UI to manage it as a human task, or what?

Answer 4

The server cannot proactively notify the collector, that's why the collector is polling the server. This means there is no observer pattern applicable between collector and server.

If you want to let the exporter start its process autonomously you could give it a BlockingQueue on which the collector places a notification (i.e. a 'Job' object indicating which files need to be exported). The exporter repeatedly calls queue.take() to obtain the next Job. Note that BlockingQueue.take() waits until an element becomes available on the queue, without hogging CPU. See: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html which includes some sample code.

Answer 5

The observer pattern could be applied here with the right design... You are currently polling your server and digesting the data, which inherently does not lend itself to the observer pattern (if I understood your post correctly). Two good options here is to have the server notify a JMS queue when changes/updates/additions are ready to be exported and then you could use the observer pattern to receive the messages and digest them. Alternatively, you could have your server publish the data to a feed (like RSS) and then have a service that polls the feed and creates a notification (when there are changes since the last feed update). Then you could have use the observer pattern to digest the data.

If the server is likely to be producing export data very frequently, then neither of these options are likely to be a good fit... however, if they are controlled intervals (in time) or push data only when a certain amount of data is available (as opposed to pushing every change in an environment that changes frequently), then this can be a good model to follow as it keeps your components loosely coupled and reusable. Direct polling of the server is probably going to create a non-reusable component (which might be ok here, i don't know).

Hope that helps.