|
Today two major versions of ICE exist. ICE 1.1, provides
businesses with an XML-based common language and architecture
that facilitates automatic delivery, updating and managing
content assets in a trusted fashion without manual packaging
or knowledge of remote Web-site structures. ICE 1.1
uses an XML DTD to define a hierarchical structure that
addresses both messaging and a syndication model. ICE
2.0 represents a major revision to the ICE Specification.
ICE 2.0 defines robust content syndication, supported
in a Web Services environment. ICE 2.0 is defined as
a W3C XML Schema, replaces the ICE 1.1 messaging structure
with SOAP messaging protocol, and provides WSDL scripts
to facilitate syndication as a Web service.
About ICE 2.0
The ICE Authoring Group extended ICE 1.1 design goals
for ICE 2.0 through a formal and open requirements process.
Design goals for ICE 2.0 build on the goals for ICE
1.0 and 1.1. New goals for ICE 2.0 include:
- XML Namespaces: The requirement is to eliminate
element collisions by moving all ICE-defined elements
into one or more ICE namespaces.
- XML Schema: Since ICE is a protocol, it
requires features such as type definitions found in
XML Schemas but not supported by XML DTDs. This entails
ICE DTD transforming to ICE SCHEMA but more than a
straightforward translation to one that is extensible.
- Simplicity of Specification: There shall
be a requirement to break ICE into modules in a manner
that allows for simplicity of implementation and maintains
interoperability.
- ICE and SOAP: ICE 2.0 needs to define the
characteristics of the communication over SOAP Version
1.2.
- Express ICE as a Web service (WSDL): There
is a requirement to define the end points of the ICE
conversation as WSDL, either message-oriented, RPC-oriented
or both, on top of SOAP.
- Asynchronous Communication: ICE must be
able to support Asynchronous Communication for wireless
and transient systems.
- ICE Subscription Management of non-ICE delivery,
FTP and simple
HTTP:GET Mechanism:
ICE 2.0 shall be able establish a subscription that
may then be delivered outside the ICE protocol. E.G.
use ICE subscription management to control the FTP
delivery of files. ICE 2.0 is designed to handle current
and future delivery vehicles, and an apparatus needs
to be considered to allow for such delivery including
both in-band and out-of-band delivery transport with
behavior defined and in-band and out-of-band negotiation
transport with behavior defined.
ICE 2.0 has been released as a set of 6 documents.
You can download these documents individually or download
a ZIP file containig them all. The schemas and WSDLs
are also available. See above.
About ICE 1.1
ICE 1.1 was designed based on the concept of XML document
exchange: each protocol message consists of a valid
XML document, and the protocol involves sending such
documents back and forth between syndicator and subscriber.
This specification explicitly discusses the binding
of the generic ICE protocol to the HTTP transport mechanism.
This specification uses the term ICE/HTTP where necessary
to specifically refer to the concept of ICE bound to
an HTTP transport mechanism.
The ICE Authoring Group defined a number of design
goals for ICE 1.1 based on requirements analysis and
much thought and discussion. Some of the most important
design goals for ICE are included here for reference:
Note: These goals are non normative. They are included
here for historical purposes only.
- ICE shall be straightforwardly usable over the
Internet.
- ICE shall support a wide variety of applications
and not constrain data formats.
- ICE shall conform to a specific XML syntax.
- The ICE requirements shall constrain the ICE process
to practical and implementable mechanisms.
- ICE shall be open for future, unknown uses.
- Compactness of representation in ICE is of minimal
importance. Note: this is a statement about low level
encoding methodology, e.g., the use of XML in general
and the particular choice of tag and attribute names
in particular.
- ICE shall keep protocol and packaging overhead
to a minimum. Note: this is a statement about protocol
overhead in the sense of round trips, complexity,
and other high level performance effects. It is not
a contradiction of the previous point. The design
of ICE achieves its performance objectives by optimizing
the high level design of the protocol flow and state
management, not by micro optimizing the spelling of
individual packets.
|
