next up previous
Next: Implementation of the Experimental Up: No Title Previous: The Transformation from MCS

Multimedia Object Exchange Manager

Design and Implementation of OEM

To exchange the MMOs in the distributed multimedia system, we need a uniform representation which is able to maintain all information of an MMO. This requirement leads to the formulation of an Object Exchange Format (OEF) (see Appendix II). The OEM maintains and manages the OEF and interacts with other system modules. The object oriented approach is adopted in designing the OEM.

The Object Exchange Format

The OEF consists of five parts: header part, node part, link part, knowledge part, and raw data part, as illustrated in Figure gif. A version number of the OEF and the specifications of the MDS and the MCS constitute the header part. The node part and link part contain information of the Multimedia Static Schema (MSS). Conceptually, the MSS is equivalent to the MMO hypergraph structure while the MDS and the MCS are derived from the MSS. They reflect the spatial/temporal relations in the MMOs as well as the communication and synchronization requirements.

  


Figure: Object Exchange Format.

Our design goal is to formulate a simple yet flexible OEF for our prototype system. It should adapt to the MHEG multimedia object standard [5] easily. To achieve simplicity, the OEF is defined as an ASCII text stream, with blank space as a delimiter. The beginning and ending marks for parts and fields are fixed as three-letter abbreviations. For example, the node part's begin mark is denoted as NPB and the node part's end mark is denoted as NPE. The simplicity makes it easy to implement the OEF without compromising functionality. The OEF reserves room for future extension by setting NIL fields in order to keep flexibility and extensibility.

Object identification and classification

Five classes are identified when analyzing and designing the OEM. They are mds, mcs, mss, knowledge, and rawdata. Class mss is further decomposed into two classes which are node and link. The top level class mmo contains the above five classes and is the generalization of a composite MMO. An MMO has only one static hypergraph structure, one knowledge structure, and one raw data. Only one MDS and one MCS exist at any point in time. Thus, an mmo class instance consists of only one instance of each of the five classes. The class diagram of the OEM is shown in Figure gif. In the class diagram, there is no ``A kind of" relationship among classes. Thus, no inheritance relationships exist in the class hierarchy. There is only the containment relationship in the class hierarchy. For example, class mmo contains class mms, mds, mcs, knowledge, and rawdata. Class mss contains class node and link.

  


Figure: OEM Class Hierarchy.

Class description

The instances of the five classes (mds, mcs, mss, knowledge, and rawdata) are combined into the MMO represented in Object Exchange Format (OEF). Physically, an MMO in the OEF is an ASCII stream which can be read, written , and transferred. Besides this common data, classes also have their own internal data structure.

Class mds and mcs:
The internal data of class mds and mcs are similar. They are G-Net specifications describing the spatial/temporal and synchronization relations within the whole MMO. The basic operations are ``put" and ``get" - put a G-Net specification into the Object Exchange Format and get a G-Net specification from the Object Exchange Format.
Class knowledge:
Like class mds and mcs, class knowledge has only two basic operations: ``put" and ``get". The meanings are similar to those in class mds and mcs. But the internal data are different. Now the internal data is the private knowledge of the MMO, represented as a set of rules, each of which consists of condition part and action part. The rule set can be written in a script language. Therefore, what the ``put" or ``get" here does is just to put/get the rule set to/from the Object Exchange Format.

Class rawdata:
This class manipulates directly on the raw data of objects. It either ``gets" raw data from the OEF, or ``puts" raw data into the OEF. Besides, after getting raw data from the OEF, it can present the data according to its media type. The presentation will be performed by following the specification of the MDS.

Class mss:
This class keeps all the information of the MMO hypergraph structure, or MSS. The hypergraph is made of nodes and links, so the class mss contains two lower-level classes: node and link where actual node and link information are maintained. In practice, mss maintains two linked lists, one for nodes, one for links. The basic operations are ``put" the MSS into the OEF and ``get" the MSS from the OEF, add/delete a unit to/from the node linked list, and add/delete a unit to/from the link linked list. The node and link data are stored in an internal C/C++ structure. The C/C++ structure is instantiated by the MMO editor and shared with the MMO browser in the User Interface module. When the MSS is to be ``put" into the OEF, the C/C++ structure is translated into ASCII stream and vice versa when we ``get" MSS from the OEF.

Class mmo:
This is the top-level class that contains the above five classes. It ``puts" all the data in its five component classes into the OEF and ``gets" data from the OEF and feeds them back into the five classes. Besides, the class mmo has a ``send" operation which sends the OEF through network by calling MMS network primitive and a ``receive" operation which receives the OEF by calling MMR network primitive. It also has ``retrieve" operation which fetches an OEF from a remote site and a ``present" operation which makes presentation based upon the MDS specification. It also processes the data in the header part of OEF.

Class node:
This class contains detailed information of a node in the MMO hypergraph structure. It includes information such as node id, file name, media-type, size, location, etc. Class rawdata is defined as ``friend" of the class node which means all methods of class rawdata can access private data in class node. This is necessary because when accessing the raw data of a node, one has to know such information as media type, size, and location of the raw data. This information is kept in class node. So class rawdata should have access to private data of class node. It seems that this approach breaches the wall between objects thus violating the principle of information hiding, but sometimes it is necessary and convenient to do so in the implementation.

Class link:
This class contains detailed information of a link in the MMO hypergraph structure. It includes information such as link id, type, starting and ending nodes, direction, etc. Similar to the other classes, the main operations are ``put/get" link data to/from the OEF.

User Interface

In the DMS, the OEM does not interact with application users directly. The system user interface provides an interface to edit or browse an MMO hypergraph structure. The OEM is just a call back function of the system user interface. Nevertheless, the OEM is a key module in the DMS which interacts with all other modules. To give advanced users direct control over the OEM, a user interface is developed. Through this user interface, users can create an MMO hypergraph structure, or MSS, by entering node and link information, convert the MSS into OEF, send the OEF over network, receive incoming OEF, etc.

Interactions between Object Exchange Manager and other modules

In Figure 2, we see that all other modules will interact with the Object Exchange Manager. As the name ``Object Exchange" implies, these interactions are for the purpose of exchanging object information. In this section, we will discuss what and how interactions are performed involving the Object Exchange Manager and other modules.

Interaction with User Interface module

Basically, all information about a multimedia object MMO in a specific application domain comes from the application itself. But some information items arrive at the OEM directly from applications, while some are indirectly fed into the OEM. The information of the hypergraph structure is obtained from the User Interface module. In other words, the node and link information in the MMO hypergraph structure are passed to the OEM from the User Interface module. There are two important User Interface submodules: MMO editor and MMO browser. The MMO editor provides an editing environment for creating, modifying, saving, and loading multimedia object hypergraph structure. The MMO browser lets a user navigate through the MMO hypergraph structure, selecting, viewing, and annotating nodes of interest.

Once a user finishes editing or modifying an MMO, the User Interface module may pass the information of the MMO hypergraph structure (contained in an internal C/C++ structure) to the OEM. Then OEM converts this internal hypergraph structure into an external OEF which is stored in a temporary file in local disk. In practice, the internal C/ C++ structure can be shared by the User Interface module and the OEM. The procedures in the OEM could become the callback functions in the User Interface module which is implemented as an X-window application. When an MMO browser in the receiver end is to browse the MMO hypergraph structure, the OEM in the receiver end will have to first extract the hypergraph structure or MSS from the OEF, then convert it to the internal C/C++ structure in the browser. Finally, the browser can browse the hypergraph by accessing the internal C/C++ structure. The interaction is shown in Figure 2. Note that if a user invokes a browser to view the MMO hypergraph structure created locally, the browser will get the hypergraph directly from the MMO editor instead of retrieving it from the OEM.

Interaction with Integration and Synchronization module

The Integration and Synchronization module derives an MDS from the MSS and generates an MCS as the result of the negotiation with the underlying network layer. Once the MDS and the MCS are available, it calls OEM to store the MDS and MCS data into the OEF. On the other hand, the OEM module can retrieve MDS and MCS data from the OEF and pass them to the Integration and Synchronization module or the Presentation module. So the involved interaction is just passing data back and forth. As we know, MDS and MCS are G-Net specifications in ASCII text form [4]. So the storing and retrieval of MDS and MCS data are trivial.

Interaction with Presentation module

When the OEF arrives at the other end of network, the presentation module needs the information contained in it to present the MMO to users. However, it does not access the OEF directly, it only accesses the internal C/C++ structure converted from the hypergraph structure, or MSS, and MDS embedded in OEF. With MSS and MDS, the presentation module is able to present the MMO in a way intended by the MMO sender.

Interaction with Network Management module

  


Figure: Interaction with Network Management Module.

The interaction with the Network Management module is more complicated. The OEM supports three operations: Send, Receive, and Retrieve which perform the MMO transmission. The Send and Receive operations call primitives MMS (Multimedia Send) and MMR (Multimedia Receive) [13, 14] in the Network Management module to perform their functionality. Before sending and receiving, some side jobs are necessary. The network primitives need the MCS specification from the Integration and Synchronization module. The sending of the MMO is done intelligently in that it is guided by the MCS specification. An open place and a close place [13, 14] are constructed beforehand and the object raw data are embedded between them. After finishing all these side jobs, primitive MMS is called to send the OEF to the receiver's end. On the receiver's end, the receiver is notified of the arrival of any new MMO message. The receiver then performs the Receive operation of the OEM, which in turn, calls primitive MMR in the Network Management module to extract new MMO messages from the receiver's system mailbox or a specified directory. The Retrieve operation enables a user to retrieve an MMO from a remote site actively, not just waiting passively for any new MMO's arrival. It calls a network primitive ``retrieve" to achieve the goal. Basically, the ``retrieve" primitive makes use of FTP mechanism to get the remote MMO. It is an operation in the OEM and is written as a C shell script. There is also a similar ``retrieve" primitive in the Network Management module.

Before sending a non-text object, such as an image or an audio stream, OEM might compress the raw data using for example JPEG compression algorithm [27]. This greatly reduces the size of the MMO and thus saves the precious network bandwidth and reduces the transmission delay. On receiving such a compressed raw data, the OEM at the receiver's end decompresses the raw data and restores it into original form.

The raw data of a multimedia object might be in binary form. To reduce the overhead of the network layer, the OEM encodes the non-text raw data into ASCII text form. The encoding algorithm used is called ``binary encoding" which is used in Columbia University's Imail [22]. This encoding scheme uses only 64 ASCII characters in encoded form. Figure gif shows the process of constructing, transferring, and retrieving an MMO in OEF.


next up previous
Next: Implementation of the Experimental Up: No Title Previous: The Transformation from MCS

Latex2html
Thu Mar 27 17:33:45 EST 1997