InterStream Media Grid Objects
Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid or Uploaded to the Media Grid via Secure Media Grid Clients. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client (Media Grid Client) with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.
From RFC 3650:
Traditional URLs (Uniform Resource Locators) allow certain Internet resources to be named as a combination of a DNS name and local name. The local name may be a local file path, or a reference to some local service (e.g., a cgi-bin script). This combination of a DNS name and a local name provides a flexible administrative model for naming and managing individual Internet resources. However, the URL practice also has some key limitations. Most URL schemes (e.g., http) are defined for resolution only. Any URL administration has to be done either at the local host, or via some other network service such as NFS. Using a URL as a name typically ties the Internet resource to its current network location. For example, a URL will be tied to its local file path when the file path is part of the URL. When the resource moves from one location to another for whatever reason, the URL breaks. It is especially difficult to work around this problem when the reason for the location change is change in ownership of an asset, as ownership is generally reflected in the domain name.
The Handle System is designed to overcome these limitations and to
add significant functionality. Specifically, the Handle System is
designed with the following objectives:
- Uniqueness: Every handle is globally unique within the Handle System.
- Persistence: Handles may be used as persistent identifiers for Internet resources. A handle does not have to be derived from the entity that it names. While an existing name, or even a mnemonic, may be included in a handle for convenience, the only operational connection between a handle and the entity it names is maintained within the Handle System. This of course does not guarantee persistence, which is a function of administrative care. But it does allow the same name to persist over changes of location, ownership, and other state conditions. For example, when a named resource moves from one location to another, the handle may be kept valid by updating its value in the Handle System to reflect the new location.
- Multiple Instances: A single handle can refer to multiple instances of a resource, at different and possibly changing locations in a network. Applications can take advantage of this to increase performance and reliability. For example, a network service may define multiple entry points for its service with a single handle so as to distribute the service load.
- Multiple Attributes: A single handle can refer to multiple attributes of a resource, including associated services, available through any method at different and possibly changing network locations. Handles can thus be used as persistent entry points into an evolving world of services associated with identified resources.
- Extensible Namespace: Existing local namespaces may join the handle namespace by acquiring a unique handle naming authority. This allows local namespaces to be introduced into a global context while avoiding conflict with existing namespaces. Use of naming authorities also allows delegation of service, both resolution and administration, to a local handle service.
- International Support: The handle namespace is based on Unicode 3.0, which includes most of the characters currently used around the world. This allows handles to be used in any native environment. The handle protocol mandates UTF-8 as the encoding used for handles.
- Distributed Service Model: The Handle System defines a hierarchical service model such that any local handle namespace may be serviced by a corresponding local handle service, by the global service, or by both. The global service, known as the Global Handle Registry, can be used to dispatch any handle service request to the responsible local handle service. The distributed service model allows replication of any given service into multiple service sites, and each service site may further distribute its service into a cluster of individual servers. (Note that local here refers only to namespace and administrative concerns. A local handle service could in fact have many service sites distributed across the Internet.)
- Secured Name Service: The Handle System allows secured name resolution and administration over the public Internet. The Handle System protocol defines standard mechanisms for both client and server authentication, as well as service authorization. It also provides security options to assure data integrity and confidentiality.
- Distributed Administration Service: Each handle may define its own administrator(s) or administrator group(s). Ownership of each handle is defined in terms of its administrator or administrator groups. This, combined with the Handle System authentication protocol, allows any handle to be managed securely over the public network by its administrator at any network location.
- Efficient Resolution Service: The handle protocol is designed to allow highly efficient name resolution performance. To avoid resolution being affected by computationally costly administration service, separate service interfaces (i.e., server processes and their associated communication ports) for handle name resolution and administration may be defined by any handle service.
Adherence to the Handle System Principles with InterStream Media Grid Objects
The Handle System supports a distributed service model by allowing local services to be distributed across the Internet. InterStream uses location resolution process to locate the 'best' location to originate the URL or Handle. After the object has been originated, the grid provides a resilient framework to ensure the end-user receives a high quality experience.