|
Information and Content Exchange (ICE) Reference Version
|
 |
 |  | Find |
|
Abstract
|
No abstract was provided for this paper.
|
Keywords
|
|
Contents
|
ICE-Cubes
ICE protocol for use by content Syndicators and their Subscribers.
The ICE protocol defines the roles and responsibilities of Syndicators and
subscribers, defines the format and method of content exchange, and provides
support for management and control of syndication relationships. ICE is useful
in automating content exchange and reuse, both in traditional publishing contexts
and in business-to-business relationships.
ICE is an application of the XML.
Basic concepts in ICE are represented using the element/attribute mark-up
model of XML. Note, however, that ICE is a protocol, not just a DTD, and so
in that way differs fundamentally from other pure document applications of
XML such as MathML, etc.
The ICE Specification s21-04-ice.html is authored by the
ICE Authoring Group. The ICE Specification 1.0 has been posted as a Note to
the W3C. The ICE Authoring Group is hosted by IDEAlliance. A new version of
the ICE Specification, ICE Version 1.1 can be found on the
IDEAlliance Web site. ICE 1.1 is an ICE 1.0 compatible update to the ICE 1.0
specification. This update is made in response to the implementation experience
that has been gained over the past year. It differs from the ICE 1.0 specification
in that it corrects several minor deficiencies in the original specification.
It corrects several typographic errors. It continues the clarification of
the specification to assist developers in achieving inter-operable implementations.
Finally, ICE 1.1 specifies several of the most asked for implementation features.
ICE 1.1 is fully upwards compatible with ICE 1.0 in that an ICE 1.0 implementation
can inter-operate with an ICE 1.1 implementation using any function of ICE
1.0. ICE 1.1 implementations add capabilities (most notably extensibility)
that are only accessible to other ICE 1.1 implementations. A special draft
version of ICE 1.1 is included on this Conference CD.
In addition to developing the new ICE 1.1, the ICE Aughoring Group has
developed the ICE reference version, ICE-Cubes Subscribers. IT was designed
in UML with a directed implementation target of the Java 1.1 platform using
Together/J.
The goal is to provide a well documented, highly flexible core (platform
independent) implementation of the ICE protocol that is available to everyone
at minimal cost.
There is a highly visible pictorial UML model of the ICE system design
that can be rapidly understood at a high level. This assists potential application
developers in determining how best to implement the application specific syndicators
and subscribers with the ability to delve deeply into the function of the
reference implementation without have to fight their way through the implementation
underbrush. Note that this UML model can potentially be directed at other
implementation platforms.
There is a detailed text specification of ICE from the ICE Authoring
Group, that is used to validate and compare against both the UML model and
the implementation to assure conformance.
We believe that this 3 part cross support technique will lead to many
inter-operable syndicators and clients. This should leverage the network effect
by creating a broad based public foundation infrastructure for ICE. The overall
and detailed design is complete. Component implementation is underway.
The general architecture provides a policy driven implementation of
the ICE protocol with core function abstracted into customizable components.
There are Seven major components of the ICE reference implementation:
- 1. Abstract Store - This component is designed to formalize and hide the actual storage implementation mechanism used by an implementing application. We designed it to make sure that both file oriented and database oriented storage solutions (and/or both) are well supported by the abstract store component.
- 2. Abstract Transport - This component is designed to formalize and hide the acutal network implementation protocols used by an implementing application. We are specifically designing it to support multiple disparate protocols (such as HTML, POP, FTP and SMTP) being used simulutaneously.
- 3. Application - This component is constructed by an implementor that wishes to use ICE. It contains the vertical application logic, determines the specific policies that the reference code follows when executing the ICE protocol.
- 4. Policy - This component is the "control" interface between the ICE application and the reference implementation. The ICE reference implementation is designed to use policy interfaces (i.e. specific policy methods and/or variables) that are controlled by the ICE application. It uses these policies to manage resources, set processing priorities and resolve "quality of implementation" issues pointed out by the ICE specification. Systems - These components are the major functional pieces of the reference implementation. They manage scheduling, catalogs, collections, subscriptions, negotiation, protocol, Packages, Assembly, Delivery, Event logs, Abstract Storage and Abstract Transport.
- 5. Subsystems - These components consist of the functional pieces such as calendar, delivery schedule, dispatcher, payload assembly, payload disassembly, subscription management, collection management, transport scheduling, event logging management, etc.
- 6. Component Classes - These components define the fine grained objects and class defintions of ICE. Included are such things as delivery rules, ice-dates and times, items, packages, payloads, catalogs, subscription offers, requests, responses, negotiable items, etc.
Previous
Table of Contents