IDEAlliance

© 2008 IDEAlliance
Incorporated. Contact
us at (703) 837-1070.

ICE Authoring Group Targets Web Services for a Major Revision of the ICE Specification

IDEAlliance and the ICE (Information and Content Exchange) Authoring Group released the Draft Requirements for ICE2 Specification  to the public on February 21, 2002  during the XML and Publishing Hot Technology Day of the Seybold Conference and Exposition in New York City.

Dr. Richard Martin, Chairman of the ICE2 Specification Development Committee stated that “for the next version of the ICE protocol, it is critical to consider a relationship and/or usage of Web Services related standards for the ICE2 definition. Given that ICE content syndication is inherently distributed and that Web Services standards are squarely focused on distributed computing space, there is enough synergy between the two sets of standards that can be exploited to make ICE2 more complete and easier to adopt." 

ICE is an application level protocol, related to reliable content delivery process and it does not have to be tied down to the lowest level of transport, repository or description standards. It is valuable for ICE to depend upon the growing Web Services standards from the implementation point of view. If we are able to layer ICE2 on top of different web services standards, then developing an ICE client or finding a listing of providers will become a familiar and trivial task. Given that ICE is inherently distributed and that Web Services standards are squarely focused on distributed computing space, there is enough synergy between the two sets of standards that can be exploited to make ICE2 more complete and easier to adopt.

There are three major web services standards that ICE2 will consider. These are WSDL, SOAP and UDDI:

WSDL:

WSDL is an XML based description language that currently describes RPC based end-points. This is currently being developed by W3C for extending it to enable messaging style program end-points. ICE currently has an XML based protocol for conversation between client and server. For ICE2, we need to define ICE end-points with WSDL (either message oriented or RPC based or both). Having done that, we will eliminate the need for ICE client packages. Any WSDL to Java or any other programming language based generator will be able to generate ICE client interfaces in that programming language. This will also enable customer applications to embed ICE capabilities within their applications as web services and their web services management infrastructure can manage their client. ICE2 will guide and perform all content related operations and transfers at the application layer.

SOAP:

Simple Object Access Protocol is widely being used as transport for web-services related RPC. Most of the current implementations of SOAP only support session-less RPC style invocations but that is changing soon. SOAP is gearing towards the messaging infrastructure. It is the belief that ICE2 should layer its communications on SOAP. This matches the previous discussion on the use of WSDL for “description”. ICE2 shall define the characteristics of the communication over SOAP (understanding the current and evolving standards). This definition will help maintain content integrity and guarantees even though SOAP does not provide this type of support. ICE2 will have to consider evolution in HTTP as well as SOAP standards that may cover security, session and other features that ICE may need today. If ICE2 can take advantage of SOAP and keep itself flexible to adopt changes that are going to happen in SOAP space, it allows ICE developers and users to take advantage of their existing communication infrastructure and management services while taking advantage of ICE for their content distribution applications or content subscription activities.

UDDI:

There are major problems that ICE content providers face today and that is related with discovery. How people find that there is a server that can deliver content to their ICE client. UDDI solves that problem for web services end-point today. UDDI is fairly open and generic. ICE2 has to recommend a practice and perhaps detail the usage pattern for finding content providers from UDDI. This may simply be a best practices white paper presented to ICE users who want to use UDDI. It should also discuss how users should interpret this information. We may want to utilize publishing-industry-specific ontology to categorize offers and contents that one can subscribe.

Fifteen Draft Requirements

The ICE Authoring Group has initially identified fifteen draft requirements that will focus on the lessons learned during the past four years of ICE implementations, coupled with continued innovations in the XML community, to review and refine ICE to meet the growing demands of business. Some examples of the ICE 2.0 DRs include:

DR1 XML Namespaces:  The requirement is to eliminate element collisions by moving all ICE-defined elements into one or more ICE namespaces.

DR2 XML Schema:Since ICE is a protocol, it requires features such as type definitions found in XML Schemas but not supported by XML DTDs.

DR6 Express ICE as a Web Services (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.

DR7 Modularity of Specification: There shall be a requirement to break ICE into modules in a manner that maintains interoperability.

You can read and comment on the Draft Requirements for ICE 2.0 by visiting www.icestandard.org.  Comments are due by March 8.