This is a text description of icrqrntm.gif.
This illustration is exactly the same as syndarch.gif (Fig. 1-3); however, in addition it shows the ICE request runtime flow and describes the steps as follows:
1. A subscriber application issues an ICE request (for example, get catalog, subscribe, get content). The appropriate delivery operation module (for example, HTTP, SMTP) listens for the request and forwards it to the request manager.
2. The request manager receives the request and verifies the subscriber application credentials with subscriber manager. All subscriber application profiles, including preferred communication channels and contact information, are managed by the subscriber manager. Once credentials are verified, the request is dispatched to the subscription manager, affiliates manager, and message manager.
3a. The message manager parses the ICE request payload, converting the request to an internal format used by subscription manager and affiliates manager.
3b. Upon receiving a subscribe request, the subscription manager works in combination with the affiliates manager to approve the request. A negotiation process might be started if there is any disagreement with the service terms in that subscriber application's request, such as delivery update frequencies, and so forth. The subscription manager generates the subscription once both the subscriber application and Syndication Server reach a mutual agreement. Also, at this time a unique subscription ID is assigned for future reference. After establishing the subscription, the subscription manager also stores the subscription application ID persistently in the Syndication Server's repository.
If the subscription contains any time-based push delivery rules, an instance of the scheduler is instantiated based on the time interval value. Upon establishing the subscription, an instance of the scheduler is created to carry out the time-based push delivery. During this instantiation phase, the time interval and runtime parameters (target notification URL and the associated subscription ID) are set. The container notifies the scheduler instance periodically based on the preset interval.
Upon a get-content request, the content offer, delivery policies, and business terms for the subscription are retrieved by the subscription manager. The content offer details are used by the affiliates manager to find the appropriate content provider adaptor to transform the subscriber application's request into a format suitable for the specific content provider.
3c. Based on the type of request (for example, get catalog, subscribe, or get content) that is made by the content subscriber application, the affiliates manager invokes the specified content provider adaptor.
4. The transformed request is sent to the content provider, and the corresponding response is transformed to a well-defined XML schema format. The response is then packaged as an ICE payload and delivered to the subscriber application for reuse.