Finding Distributed Objects

 

A collaborative application can require two kinds of searches: finding processes and finding process types. The secretary trying to set up a BOF meeting may have to find (the actual addresses of) a member's calendar processes so that they can be composed into a session. Also, a new member may want to find a calendar process type to set up a process to manage her or his calendar.

To find a specific process, we use standard Web technology: the process is found by looking up the appropriate home page. For instance, the address of Adam's calendar process address is found at Adam's home page.

Finding an appropriate process type is a more interesting problem for several reasons: (a) the specification of the type must be clear so that a potential user can determine if that process type can be composed with the process types of other people with whom that person collaborates, and (b) if the interfaces of two types do not match, some scheme should be employed to refine interfaces to achieve a match. We use the notion of inheritance from object technology to solve this problem.

Inheritance.

The specification and implementation of a process type is placed in a Universal Resource Locator (URL). Inheritance of process types is implemented on top of URLs, as illustrated in Figure 9. First, we discuss location of process specifications and implementations.

 
Figure 9: Inheritance types are compatible only if the interfaces are inherited from the same URL (Universal Resource Locator). In this sense, we exploit existing Web technology. 

The URL that contains a process specification and implementation includes the following parts, defined bottom up, starting from objects and going to sessions:

1. Specifications and implementations of objects that can be sent as messages.
2. Marshaling methods, i.e., methods for packing these objects into byte streams for transportation across a network, and then unpacking the byte streams back into the objects.
3. Specifications of the messages themselves. This includes methods for appending a message of the specified type to an output queue.
4. Specifications of the types of input and output queues, including the skeleton of the program segment that retrieves a message from an input queue and then deciphers the message, i.e., retrieves its component objects.
5. Specification of the process, in terms of a state transition system. This specification includes the specification of the state changes and messages sent in response to each message received, and details about the implementation of the process itself (so that the process can be installed anywhere). The process specification also defines the binding of the files (i.e., persistent store) to the program.
6. Specification of the sessions in which the processes can be used.

A process type can be tailored to a specific group of users by refining its type; in object-oriented terms, we create a subtype that inherits from the parent type, as illustrated in Figure 9. The subtype must, of course, support the objects, messages, and sessions of the parent type; it may also support additional objects, messages and session-interactions.

Our initial design for implementing inheritance is by brute force: a process type can be stated as inheriting from another type, but no tools are provided to check that one type is a subtype of another -- instead, it is merely an assertion provided by the programmer. The URL that contains the subtype's specification and implementation contains pointers to its parent types. Processes of types and can be composed in a session C if both types are the same or one is a subtype of the other, and both support sessions of type C. Thus, determining whether two interfaces (objects, messages, message-queues, or processes) ``match'' is done by following the pointers in their URLs. A more sophisticated mechanism could be used, but this is not the focus of our research.

Composing Distributed Objects.

The composition of distributed objects requires checking if their interfaces match; once that checking is complete, a session connection can be set up, and a series of transactions can occur. For example, as shown in Figure 10, independently running distributed processes can collaborate on-the-fly over the Internet safely, because their interfaces have been verified to be appropriate.

 
Figure 10: Sessions can be set up on-the-fly once interface matches have been checked. Here, a boss can have her meeting process request a 1pm get-together with her workers, and the workers' processes can receive that request and (automatically or interactively) reply, also requesting to their secretaries to change their 1pm appointments, if needed. 

Mobility and Resource Discovery.

We are investigating enhancements in our system design to support communication between mobile objects through the use of directory registries [CS96]. As described at the end of Section 2.1, each process can have an immutable home address URL (that is available to Web search engines); this home address includes the unchanging address of an input queue to which requests to participate in sessions are sent. As shown in Figure 11, processes can use these home URLs to set up sessions, as the input queue for a mobile process can be on a different processor than its home address.

 
Figure 11: The Web can be used to locate the interfaces and specifications of distributed (and possibly mobile) processes. The Web can also be used to locate the running programs themselves.