Distribution of Data and Remote Invocation of Programs

1. Distribution of Data and Remote Invocation of Programs Tomasz Müldner, Zhonghai Luoand Elhadi Shakshuki* Jodrey School of Computer Science, Acadia University, Wolfville, NS, Canada * presenting

2. Contents of the Talk • General goals for systems that implement data distribution and remote program invocation • Distributed Installer, DI • Related products • Conclusions • Future Work

3. General Goals • Platform Independence • Security • Scalability • Pull and Push • Efficiency • Synchronization • Fault Tolerance • Flexibility • Selective Choice • Remote Invocation

4. DI: Data Distribution • Two kinds of applications: • subscriber expresses interest in some data that can be provided by a publisher • publisher selects subscribers and specifies data to be sent to these subscribers. • A single application may be at the same time both, a publisher and a subscriber • SSL is used to support secure transmission

5. DI: Channel • An abstract concept that represents a virtual, unidirectional connection between two nodes (similar to a pipe used in P2P systems). • Two kinds of channels: • P-channel, created by a publisher. • S-channel, created by a subscriber. • Each channel has • name • optional description

6. DI: P-channel Each channel specifies the source of its data, i.e. the directory in the file system on the publisher’s computer.

7. DI: P-channel • the publisher can push, or distribute some or all of P-channels to one or more selected subscribers • when the subscriber receives the incoming P-channel, it will automatically create the corresponding S-channel based on • publisher's IP and port number • the name of the P-channel. • any data in the P-channel will be pushed into the newly created S-channel.

8. Publisher’s Configuration Files • publisher.properties (static) • port number on which the publisher will send data; • a root directory for storing all channels’ description; • the filename and password for the keystore used to establish secure SSL communication path; • target.properties (static) • lists all potential subscribers.

9. Subscriber’s Configuration Files • subscriber.properties • port number for receiving data; • a root directory for storing all incoming channels’ data; • a channel creation type • the filename and password for the keystore used to establish secure SSL communication path; • a security flag indicating whether or not the data transmission is secure (true by default); • a channel update type • a channel update option

10. Relative Virtual Mapping Example: • A publisher P creates a channel "quote", and specifies the corresponding directory "c:\program\quote". • A publisher distributes the "quote" channel to a subscriber S with all channel data (it will include all files and sub-directories under "c:\program\quote"). • In S, a channel named "quote" is automatically created, and all received data (files and sub-directories) are stored with the original hierarchy under the root channel directory(specified in the configuration file subscriber.properties)

11. S-channel • the S-channel is the reference to the corresponding P-channel • typically created automatically by subscriber software when receiving incoming P-channels pushed by publishers • the subscriber can also manually create an S-channel: • the subscriber must know in advance the available channel names in publisher side • if the channel name specified in S-channel does not exist in publisher side, this S-channel is invalid, just like that you set wrong frequency for a TV station channel.

12. S-channel GUI with buttons to create, modify, delete S-channels, and update the selected S-channel, i.e. pull data for this channel from specified publisher side.

13. New S-channel • An address of the publisher node • channel name • description, • update type and option (they can also be used for an existing S-channel, this way, the subscriber can control the way data are received)

14. Remote Invocation Components: C1 C2 C3 To distribute and to invoke components C1, C2, C3: • A publisher (on N) creates three channels; one for each of N1, N2 and N3. • The publisher specifies the Main class in the descriptor file app.xml file (explained in the next slide) for each channel. • The publisher adds addresses of N1, N2 and N3 to the file target.properties. • The publisher distributes all channels to three subscribers • The publisher uses the "remote start" button Machine N Machine N1 Machine N2 Machine N3

15. XML-based Descriptor Defines the startup class for the distributed program and the necessary path information to load dependent classes for this program, for example: <?xml version="1.0" encoding="ISO-8859-1"?> <App name="CS Lab course"> <MainClass> ca.acadiau.cs.Lab </MainClass> <ClassPath> client.jar </ClassPath> </App> Should be located in the channel and sent to the subscriber along with other channel’s content.

16. Related Work • UNISON, a file-synchronization tool • Idem, a File Synchronization and Folder Replication utility • SFTP Plugin for Eclipse, provides file and directory synchronization • DI, a platform independent system that: • uses SSL to support security • supports both; push and pull model, • one to one and one to many synchronization, with selective choice of files and directories. • provides a limited form of remote program invocation.

17. Conclusion DI satisfies goals for applications that implement remote file synchronization and remote program invocation