Implementing an XML API for an n-tier eCommerce application   Table of contents   Indexes   Building solutions

 

Information and Content Exchange (ICE) Reference Version

Hunt, V. Bruce
 
 V. Bruce  Hunt
 Manager Internet Technology, Advanced Technology Group
  Adobe Systems, Inc. 
 California 
 San Jose 
 USA 
Adobe Systems, Inc.,  San Jose  California USA email: bhunt@adobe.com; vbhunt@silverfox.com
 Biography
 Bruce Hunt is Manager of Internet Technology for Adobe's Advanced Technology Group. He has responsibility for Adobe's Internet Standards activities. He initiated Adobe's thrust into the electronic Book Market. His team did the initial development of Adobe Web Merchant and Adobe Web Capture. He drove Adobe's submission and partnering for Scalable Vector Graphics Standard, currently a working group of the W3C. He is vice-chairman and a founding member of the Information Content Exchange (ICE) authoring group and co-Authored the ICE specification in a joint company (Vignette, Adobe, Sun, Microsoft, News Internet, Sotheby's, CNET, National Semiconductor, Tribune Media Services, et. al.) standards effort. ICE won the Seybold Technology Trailblazer award. Bruce led the IBM/Adobe technology development effort for Adobe and created the Trinity SVG based Web viewer in 100% Java which was demonstrated at ShowCase99 and Internet World.
 Before Joining Adobe, he was Director of Director and Network Players at Macromedia Inc.; Founder and Vice President of Engineering for SilverFox Technology, Inc.; an Engineering Manager for Apple's Integrated System's group where he worked on a number of interesting custom development projects; Vice President of Product Development at Syscan Corporation; Vice President of Engineering at ForthRight System's Inc.; and Founder, Chairman and CEO of MetaPath, a local area network company.
 Bruce has a Master's Degree in Computer Engineering from Stanford University and a Bachelor's Degree in Mathematics from Harvey Mudd College. He has several patents and numerous publications. He is especially proud of his family, even though he keeps being asked by his wife who has had the same job for 28 years, why he can't keep a job.
Information and Content Exchange
Subscribers
Syndicators
 

ICE-Cubes

 ICE, Information and Content Exchange 
 
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.
 XML 
 
ICE is an application of theXML . 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 asMathML , etc.
 MathML 
 
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 http://www.idealliance.org 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.

Implementing an XML API for an n-tier eCommerce application   Table of contents   Indexes   Building solutions