Distribution of Data and Remote Invocation of Programs

1
Distribution of Data and Remote Invocation of
Programs

• Tomasz Müldner, Zhonghai Luo and 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
publishers 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
Publishers 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
Subscribers 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
Machine N
Machine N1
Machine N2
Machine N3

• 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

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
• lt?xml version"1.0" encoding"ISO-8859-1"?gt
• ltApp name"CS Lab course"gt
• ltMainClassgt ca.acadiau.cs.Lab lt/MainClassgt
• ltClassPathgt client.jar lt/ClassPathgt
• lt/Appgt
• Should be located in the channel and sent to the
  subscriber along with other channels 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