Oracle9iAS Syndication Server User's and Administrator's Guide Release 2 (9.0.2) Part Number A95917-01 |
|
This appendix describes some extensible features of Oracle9iAS Syndication Server.
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:oss@oss.com
triggers the invocation of the push service associated with the mailto URL.
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.
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.
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.
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.
The output schema models the ice-code element returning either an OK message or the error encapsulated in a comprehensive structure.
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.
|
Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|