Michael Elhadad

Software Engineering - Fall 1999

Lecture 7: Distributed Objects (Part 3) -- Objects above Sockets

Motivation

Object Model

The Object Model determines which objects are made accessible by the server. It has the form of a navigation graph, where each object exposes methods to obtain new objects.

In the Broadcast Server example, the Object Model starts as follows: 

a Site: contains a set of Channels
a Channel: contains a set of ScheduledEvents
a ScheduledEvent: is made of a Lecture, a Scheduled Time and a Duration.
a Lecture: is composed of Assets and a composition file.
an Asset: is made of a MaterialFile and meta-data
	: belongs to one or more AssetCategories
an AssetCategory: contains Assets
	: belongs to a parent AssetCategory

Interface for a Distributed Object: Channel

To make distributed objects accessible through any distributed technology (sockets, RMI, DCOM or CORBA), one must first identify the interface of the object.

A distributed object cannot publish data directly, because all access to the distributed object must be mediated by the middleware -- that is, data is not directly accessible through pointers because it resides in separate processes and machines.

For example, the Channel object can be characterized by the following interface (using Java-like syntax): 

public Interface Channel {
  // return eagerly the whole list of scheduled events on the channel
  // whose ScheduledTime is more or equal than "from" and strictly less
  // than "to".
  // Exception thrown if: To < From
  // Returns an empty list if the channel is not formatted during the
  // requested period.
  SchedEventList getSchedEvents(DateTime from, DateTime to)
    throws EInvalidParam;
  
  // return a lazy enumerator of the sched. events on the channel
  // Same signature as above.
  SchedEventEnum getSchedEventsEnum(DateTime from, DateTime to)
    throws EInvalidParam;

  // add a scheduled event to the channel.
  // The parameter specifies the requested time and duration.
  // throws an exception if the requested slot overlaps with an existing
  // scheduled event.
  void addSchedEvent(SchedEvent se)
    throws ECannotAdd;
}

Implementing the Channel Object using Sockets

Using the framework introduced in the previous lecture, of MultiServer, ConnectionHandler and ServerProtocol, the general approach is the following:
  1. Define an interface for the distributed object
  2. Define a class ChannelImpl that implements this interface
  3. Define a subclass of ServerProtocol, ChannelProtocol that contains an instance of Channel
  4. The ChannelProtocol class defines a protocol that is responsible for:
    1. Dispatching incoming requests to each published method
    2. De-serializing the incoming parameters
    3. Invoking the embedded ChannelImpl method
    4. Catching potential exceptions and serializing them back
    5. Receiving the result and serializing it back
In this schema, we still do not handle the issues of "life cycle", that is, when and how is the distributed object constructed and destructed. In general, lifecycle can be an extremely challenging issue.

The ChannelProtocol maintains a state according to the following state-machine: 

Ready
ReceiveParameter1-1 (One set for each method)
ReceiveParameter1-2
...
According to the protocol, the client sends requests identified with "tags" and the server sends back return values or exception notification using tags. The tags used for the Channel Protocol are: 
Incoming Tags

GS1	Requests the getSchedEvents method
GS1-1	Send parameter 1 (From) of getSchedEvents
GS1-2   Send parameter 2 (To) of getSchedEvents

GS2	Requests the getSchedEventsEnum method
GS2-1	Send parameter 1 (From) of getSchedEventsEnum
GS2-2   Send parameter 2 (To) of getSchedEventsEnum

GS3	Requests the addSchedEvent method
GS3-1	Send parameter 1 (Se) of addschedevent


Outgoing Tags

GS1-V	Return value of getSchedEvents method
GS1-E	Exception from getSchedEvents method
p
GS2-V	Return value of getSchedEventsEnum method
GS2-E	Exception from getSchedEvents method

GS3-V	Return value of getSchedEventsEnum method
GS3-E	Exception from getSchedEvents method
The state-machine implements the following transitions: 
Current State		Event	Reaction	Next State
===================================================================
Ready			GS1	ok		ReceiveParameter1-1
Ready			GS2	ok		ReceiveParameter2-1
Ready			GS3	ok		ReceiveParameter3-1
Ready				ERROR		Ready

ReceiveParameter1-1	GS1-1	ok		ReceiveParameter1-2
ReceiveParameter1-1		ERROR		Ready

ReceiveParameter1-2	GS1-2	invoke-return	Ready
ReceiveParameter1-2		ERROR		Ready

ReceiveParameter2-1	GS2-1	ok		ReceiveParameter2-2
ReceiveParameter2-1		ERROR		Read

ReceiveParameter2-2	GS2-2	invoke-return	Ready
ReceiveParameter2-2		ERROR		Ready

ReceiveParameter3-1	GS3-1	invoke-return	Ready
ReceiveParameter3-1		ERROR		Ready

Serialization Protocol

To pass parameters, one must serialize them through the socket connection. Java provides support for Object Serialization for this type of application (and many others as well).

To make an object serializable, just add: 

public class Channel
  implements Serializable
...
The methods used to read and write objects are: 
writeObject(ObjectOutputStream out)
  throws IOException;
readObject(ObjectInputStream out)
  throws IOException;
Last modified May 5th, 1999 Michael Elhadad