http://www.extreme.indiana.edu/~gannon/MyContext.html

MyContext Explorer (xCavate?)

Architecture

MyContext provides a uniform interface to view metadata about and generated by applications.

Structure

Sample Nodes

Registration Port

This port is intended to allow external services to send metadata to the context which can be stored as nodes in the context without the user having to do it manually. Example: An event source sends the following metadata to the registration port:
<myContextMetadata>
  <sourceid>FooEventPublisher</sourceid>
  <type>xmessage-source</type>
  <metadata>
    <sourceLocation>http://rainier.extreme.indiana.edu:2020</sourceLocation>
    <publishedEventTypes>
      <i id='0'>FileEvent</i>
      <i id='1'>ExceptionEvent</i>
    </publishedEventTypes>                                                    
    <query null='1'>
  </metadata>
</myContextMetadata>
A new node of type xmessage-source is created. If any existing node has requested for nodes from source sourceid, then the newly created xmessage-source node is added as its child. Else, it is stored under a default node.
Question: Should 'sourceid' be stored as part of the node information?

Incorporating XBooks

  1. An node with metadata type xbook-directory can be used to store metadata about an xbook repository and display the list of XBooks available in it as nodes of type xbook-file.
  2. The user can then select an XBook to launch and the plugin associated with the xbook-file can launch it for the user. A unique id for the XBook instance is returned.
  3. A new node with type xbook-run is created as a child to the xbook-file node and passed the 'id' of the running instance.
  4. The xbook-run node requests the registration port to add all incoming metadata with sourceid='id' to be attached as its child.
  5. The script in the xbook instance that actually launches the application has the static and dynamic running parameters of the application as part of its 'invoice'.
  6. The script then registers the metadata retrieved from the invoice (like the location where the events are going to be published, the files that are going to be generated etc.) with the registration port using its 'id' as source.

Storing

The graph can be stored as an xml tree corresponding to the primary visual representation with 'symlink' edges being recorded as xml idrefs to the node element. Each node is 'serialized' into its xml representation based on its type and similarly 'deserialized'. If you think of nodes as implementing a java interface, the interface has a serialize and deserialize method. The serialized nodes can be stored in a local xml database.
Question: Is MyContext local or remote?
Local: Allows user to work even when not connected to the MyContext server.
Remote: Allows easier sharing of nodes between users but nodes are not shared frequently. This also means that metadata that is cached is present at the server and if one user of the node updates it, all users get the latest copy.

Searching

All metadata that has been retrieved will be cached and indexed. The user can perform a text search on the cached metadata. The search can be by node type (i.e.) search only event-publisher nodes. Each node has to ability to search within its own subtree and the whole search is performed recursively.

Implementation - Interfaces

Node {
  String name;
  String metadataType;
  String sourceid;
  Annotation annotation; // String, metadata, file
  MetadataObject metadata;
  Node[] children;
  NodeLocation location;

  SearchResult search(String query);
  String serialize();
  void deserialize();
}

/**
 * Stores reference to the metadata service from which the metadata can be
 * retrieved and other parameters that are needed to retrieve the metadata
 */
MetadataObject {
  Object serviceReference;
  Object metadataParameters;
  Object metadataCache;
}

/**
 * Maps the node type to the plugins that can handle that particular node
 * type. The default plugin is used to open nodes but user can choose to
 * open the node with another plugin type
 */
PluginRegistry {
  Vector nodeTypeMapping; // each node type has an entry with a vector of 
                          // plugins that can handle the node type
  void registerPlugin(Node node, Plugin plugin);
  Plugin getDefaultPlugin(Node node);
  Plugin getAllPlugins(Node node);
}

/**
 * Handles the node and interacts with the user through the output window
 * can create new nodes (children) using reference to context tree
 */
Plugin {
  handleNode(Node node, OutputWindow window, ContextTree tree);
}

/**
 *  Handles the tree structure, adding, removing nodes,
 *  expanding and collapsing of tree
 */
ContextTree {
  Node head;

  NodeLocation addChild(NodeLocation parent, Node child);
  void removeChild(NodeLocation child);

  void expandLevel(NodeLocation node);
  void collapseLevel(NodeLocation node);
}

/**
 * listens of the registration port for newly arriving metadata.
 * Plugins can register their interest in newly arriving metadata
 * meeting a particular spec (say sourceid). The plugins are notified
 * when the metadata arrives by invoking the handleNode method in them
 */
RegistryPort {
  Vector nodeSourceMapping; // maps each node source to list of plugins
                            // interested in its arrival
  registerInterest(String nodeSourceid, Plugin callbackPlugin);
  deregisterInterest(String nodeSourceid, Plugin callbackPlugin);
  nodeArrived(String nodeSourceid, Node node);
}

Yogesh L. Simmhan [ysimmhan@cs.indiana.edu]
[Last modified on Tue Dec 17 14:23:01 EST 2002]