E
Extensibile Features

This appendix describes some extensible features of Oracle9iAS Syndication Server.

E.1 Adding Push Delivery Mechanisms

The mechanism used to extend the scope of push delivery is built into Syndication Server as an extensible framework for plugging in new push delivery channels. The push mechanism that is prescribed by ICE is through an HTTP POST request to an HTTP listener that is hosted by the subscriber application. You can extend the scope of push delivery by allowing Syndication Server to push content through other protocols, this time to handle the delivery path, thus allowing for easy extensibility.

Whenever the scheduler informs Syndication Server of an update to be pushed to the subscriber application, a content provider operation module is invoked with the content package as the service request. Currently, Syndication Server extensibility maps one delivery protocol to one content provider operation module. In the case of HTTP delivery, the content provider operation module is an HTTP content provider operation module that takes the content package and makes a POST request to the HTTP listener on the subscriber application's side.

Being extensible to allow different channel protocols for push delivery has an implication on the selection of the content provider operation module at runtime. The mechanism is one in which the subscriber application URL is used to determine the channel protocol and therefore the content provider operation module that is needed. For example, the subscriber application URL http://www.oracle.com/syndication/Client triggers the invocation of the push service associated with HTTP, and the subscriber application URL mailto:[e-mail] triggers the invocation of the push service associated with the mailto URL.

E.1.1 Writing New Push Content Provider Operation Modules

The best way to start writing new push content provider operation modules is to copy the HTTP push operation module package (SyndicationPushPackage, located in the /etc/services directory on UNIX systems or \etc\services directory on Windows systems) to a new name, and then unzip them into some directory so you can modify them. Before modifying these files, read Section E.1.2 and Section E.1.3 for instructions on rules to follow during modifications.

E.1.2 Using Syndication Server Naming Conventions for Naming the Content Provider Operation Module

There is a heuristic that Syndication Server follows in retrieving push content provider operation modules. The identifier for the service must have the following format:

"urn:com.push:<push-protocol>.oss"

Where <push-protocol> is the channel protocol with which to push the content. The heuristic followed maps HTTP for http and SMTP to mailto and so forth.

E.1.3 Push Content Provider Operation Module Interface: SyndicationPushPackage

Each of these content provider operation modules must conform to some interface, so that it allows Syndication Server to always be able to pass in the content package as a request and receive an acknowledgment back as a response.

E.1.3.1 Input Schema

The input schema envelopes the ice-package element with an ice-push-package element containing an attribute specifying the push URL. The service can forward this URL to the protocol handler to perform the protocol-specific actions for this URL.

E.1.3.2 Output Schema

The output schema models the ice-code element returning either an OK message or the error encapsulated in a comprehensive structure.

E.1.4 Registering the Service

After you have developed and registered your new push service, it is ready for use. The next subscription that contains a subscriber application URL with a protocol matching the registered service will be able to start using your new service during push delivery.