| | -
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.
-
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.
-
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.
-
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.
-
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.
-
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.
|