1 /**
2  * Created on May 28, 2003
3  *
4  * To demo the client side of the interfaces in which a 
5  * simple Client event results in the full exchange of files
6  * amoung various systems that need to exchange file-based data.
7  */
8 package com.borneo.client;
9 
10import com.borneo.po.event.FileTopicHandler;
11import com.borneo.po.event.FileTopicType;
12import com.borneo.po.event.FileTopicEvent;
13import com.borneo.po.event.FileTopicEventFactory;
14
15import com.borneo.util.FileSelector;
16
17/** CLIENT-SIDE DATA-EVENT WRAPPER - Data inside wrapper was just
18 *  created and will be published. Create an event that wraps the 
19 *  data and then fire the event. 
20 * <p>Event handlers will take care of
21 *  subsequent process that will post the data to a daemon running
22 *  on some "distribution service". The dist service functions like
23 *  a standard "publisher" and will be responsible for all activities
24 *  that distribute the data to all subscribers.</p>
25 * @author r
26 *
27 * @args are delegated to another class
28 *   for description of command-line arguments see below:
29 *      class=com.borneo.po.event.FileTopicType
30 *      method=init 
31 * 
32 * The Listener Implementation is independent of the Event. 
33 * This allows for variety of behavior on the Client in response to
34 * the "FileCreated" events. For example, the demo's listener uses a 
35 * "push" of the Topic, FileName, and the DataHandle to the server.
36 * Alternate listen implementation might push an event with only the FileName(s)
37 * in which case the Server's implementation would have to respond with a
38 * "pull" request to actually get the files up there. This "pull" idea allows
39 * extra processing where the response to the file creation event is a server
40 * notify , followed by DB lookups. The lookups might, for 
41 * example, determine that the server is to use an "SSH" pull to acquire the 
42 * just created files from the client machine. Alternatively, the lookups could
43 * result in a third-party transfer being started somewhere else using Globus 
44 * protocol to direct a peer-to-peer transfer direct between source and target
45 * servers.
46 * TODO Note that the 
47 *  design permits a scenario where the trigger for the event is
48 * the insertion of an XML Root Node into a table containing "publishable" 
49 * chunks of XML. In this case the event signal's that the client has XML
50 * Node that needs to go remote machine(s) for consumption.
51 *      To accomplish this you abstract the FileTopic interface to a 
52 *      "ClientPublish" interface where the handle for what your 
53 *      about to publish is an abstraction that wraps either a resultSet
54 *      or a File...
55 */
56/* TODO
57 * Scalability ?? The event creation should be isolated ( separate thread )
58 *           from the handler responsible for processing the connection 
59 *          and for moving the files.
60 * fixme the code below is not quite correct behavior
61 * why? the code below constructs a new instance that 
62 * almost immediately afterward, becomes the source of the event.
63 * What you want is a more durable object in the VM on
64 * or very near the client machine that
65 * receives a message from this client. Message attrs. 
66 * include the topic and the Filname that i want to publish.
67 * The durable object already has a reference to the event
68 * source. The event source has already been told of 
69 * registered listeners to notify on the event.
70 * All it has to do is respond to the request to publish...
71 * endOF TODO
72*/
73public class FileEventClient {
74
75    public static void main(String[] args) {
76
77        FileTopicType ftype = new FileTopicType(args);      
78        FileTopicEvent ftevent = new FileTopicEventFactory().create(ftype);
79        ftevent.addActionListener( new FileTopicHandler() );
80        ftevent.fireActionEvent();  
81    }
82
83}
84