1
Introduction

As a feature of Oracle9iAS, Oracle9iAS Syndication Server is designed to deliver file system and database content to Information and Content Exchange (ICE)-compliant subscriber applications, and automatically provides content updates over networks supporting the HTTP or HTTPS protocol in a secure way. It provides extensibility at multiple levels; it supports HTTP, HTTPS, and SMTP communication mechanisms including the ICE Version 1.1 protocol. It allows access using corporate databases and conventional file systems. Oracle9iAS Syndication Server features a comprehensive system for the automated, controlled exchange, and management of digital assests among business partners.

1.1 Content Syndication Concepts

Content syndication is the aggregation, exchange, and distribution of information from content providers to subscriber applications. The content providers provide the content, the syndicators distribute the content, and the subscriber applications, who subscribe to a set of content offerings from a catalog, reuse the content.

With the advent of the Internet, syndication is rapidly evolving to:

• Automate the process of information aggregation and exchange

• Handle a wide variety of content formats

• Deliver content to a wide variety of distribution channels automatically, securely, and reliably

A content subscriber application acquires a content catalog of available offers from a content syndicator and selects the desired subscription offers. After establishing all contractural, monetary, and business agreements between the subscriber application and syndicator, the subscription process is complete. As part of this subscription, a subscriber application may wish to pull new information or have it automatically provided to them either when it is updated, or at some specified time interval.

1.1.1 Business Problems or Technical Challenge

Typically, sharing content (information) among affiliated groups of content providers through affiliated networks is an expensive, impromptu process. Each new partner requires customized, manual, time-consuming processes to update, share, and exchange content. As Figure 1-1 shows, the content syndicator struggles with each new affiliate member over content format, validation, delivery options and frequency, notification, reporting and monitoring, content integration into disparate Web servers, operating systems, databases, and other proprietary technology. Content comes from a variety of sources including dialup and ISDN connections, satellite dishes, FM broadcasts, SMTP e-mail servers, FTP servers, hard disks, and magnetic tapes.

Figure 1-1 Typical Problems Facing Content Syndicators

Text description of the illustration syndprob.gif

A comprehensive syndication framework must not only address the issues of disparate content formats and communication channels, but also the needs for reliability, scalability, and security in an enterprise environment.

1.1.2 Standardized Solution Emerges

The Information and Content Exchange (ICE) standard (Version 1.1) manages and automates the establishment of syndication relationships, content transfer, and results analysis. The purpose of ICE is to replace the impromptu efforts of content exchange with a standardized, low-cost mechanism for managed, automated content exchange and content sharing of Web site assets among partners. Through the adoption of an industry-specific vocabulary, ICE provides a complete solution for syndicating any type of information between content providers and subscriber applications. Subscriber applications include networked partners and their affiliates.

As ICE becomes universally accepted and implemented across the Web, it will enable companies and industries of all sizes to take advantage of the vast amount of content on the Web, and establish business-to-business value chains in a low-cost, automated way. Web application developers can use ICE as a standard platform to exchange multiple data types and rapidly deploy applications, while protecting data privacy and incorporating existing standards. ICE dramatically reduces the cost and difficulty of creating and operating online distribution networks, and building value chains among content providers, affiliated networks, syndicators, and subscriber applications. ICE increases the value of business alliances by facilitating the controlled exchange and management of content among affiliated networks. Businesses can form partnerships with multiple affiliates at minimal incremental cost.

ICE defines a complete server-to-server syndication protocol and processing model. Within ICE, an XML-based common language and architecture is used to describe groups of content offerings as catalogs, as well as to schedule content delivery (push and pull), and to update type (incremental versus full), business rules, intellectual property rights, and all other aspects of automated content exchange.

ICE uses XML document exchange as its fundamental protocol model. ICE messages, also known as payloads, are valid XML documents, with a single ICE-payload root element and a structured hierarchy of tags describing the ICE operations and data. A payload is a single instance of an XML document formatted according to the protocol definitions contained in the ICE specification.

Payloads are transported over HTTP and use a sequenced package model. The two basic ICE actions are push and pull. To send an ICE/HTTP payload, the sender performs an HTTP POST to a URL provided by the receiver.

ICE requests are specified using an ICE-request XML element, and ICE responses are specified using an ICE-response element. For ICE/HTTP, the ICE-request must be sent in an HTTP POST, and the ICE-response to that request must be sent in the HTTP response to that POST. Therefore, a single ICE request/response pair always maps directly to a single HTTP POST/corresponding response pair. Event logs are exchanged automatically for helping exception handling or problem diagnostics.

1.2 Syndication Server Solution

Oracle9iAS Syndication Server is designed to deliver file system and database content to ICE-compliant subscriber applications and automatically provides content updates over networks supporting the HTTP or HTTPS protocol. This radically simplifies the process of syndication. Oracle9iAS Syndication Server provides a comprehensive solution for content aggregation, syndication, and distribution by letting you make available any or all of your content, to anywhere, at anytime, and deliver it securely. Content syndicators can use Oracle9iAS Syndication Server with the following benefits:

• Aggregate content from various content repositories, including existing databases, enterprise applications, and e-mail repositories. Using Syndication Server to extract or adapt content from database and file system sources, this content is consolidated into a single point of access known as a content catalog offering, accessible to any ICE-compliant content subscriber application.

• Deliver content according to policies associated with each subscription, and conforming to the ICE protocol. Content can be delivered according to a prescribed schedule or upon a pull request from the subscriber application.

• Administer all server functions from Oracle Enterprise Manager, including subscriber application and content provider registration, subscription delivery schedule and status, and system event monitoring.

Figure 1-2 shows the key features of Oracle9iAS Syndication Server.

Figure 1-2 Key Features of Oracle9iAS Syndication Server

Text description of the illustration ossfeat.gif

1.3 Overview of Concepts

Oracle9iAS Syndication Server consists of the following components:

• Transport protocol manager

• Request manager

• Subscription manager

• Affiliates manager

• Message manager

• Content provider adaptor

Table 1-1 describes each of these components.

Table 1-1 Syndication Server Components and Their Functions  

Components	Functions
Transport protocol manager	Handles both the pull and push content deliveries from Syndication Server to subscriber applications and transports the content over a specified transport layer, such as HTTP or HTTPS.
Request manager	Coordinates the handling of request messages from content subscriber applications and response messages from content providers through the transport protocol manager. Interacts with the transport protocol and affiliates managers. Serves as a central dispatcher of messages.
Subscription manager	Manages the subscriptions of each subscriber application by maintaining mappings between subscriptions and catalog offers.
Affiliates manager	Manages all the profiles of the content providers. Each content provider profile includes its preferred content provider adaptor implementation and all necessary parameters to this adaptor, its delivery policy, its business terms, and its account and billing preferences.
Message manager	Manages protocol-specific messages, such as ICE messages, and automatic packaging of digital content.
Content provider adaptor	Provides the interface for the Syndication Server engine to access each registered content provider as a set of content provider operation modules. The content provider adaptor supports both the file and database types of content through file and database content provider operation modules.

Figure 1-3 shows the Oracle9iAS Syndication Server architecture.

Oracle9iAS Syndication Server is a fully J2EE-compliant servlet deployed in Oracle9iAS Containers for Java (OC4J) as part of the Oracle9iAS Portal and Wireless installation, and can take advantage of OC4J services for session and failover management. Syndication Server can also be deployed as needed both within OC4J and across multiple Oracle9iAS instances to accommodate varying machine load and utilization from syndication processes. To maintain subscriber application credentials for accessing specific catalog offerings from content providers, Syndication Server uses user authentication and authorization features of the Oracle9iAS repository.

All information about subscriber applications, their subscriptions, and content resources are stored in the Syndication Server registry residing in the Oracle9iAS repository.

Figure 1-3 Syndication Server Architecture

Text description of the illustration syndarch.gif

1.4 Roles in Content Exchange Scenario

Section 1.4.1 and Section 1.4.2 describe the roles of content subscriber applications and content provider adaptors.

1.4.1 Content Subscriber Applications

In the business of content syndication, a content subscriber application is one of the two parties who obtains and repackages information and content from a content syndicator. A subscriber application can be an ICE-compliant application or a non ICE-compliant application that uses the client library API (see Appendix A).

1.4.2 Content Provider Adaptor

Content providers provide the content. Syndication Server provides two types of content providers: file and database. Each type of content provider has the following minimum set of content provider operation modules:

• Catalog module

  The Catalog module is used for content providers to provide catalog information of their available subscription offers. This module is used to enforce the uniform input and output formats for all individually developed catalog modules. However, each content provider defines its own semantics of a subscription offer and offer group.

• Content Access module

  The Content Access module takes the unique subscription ID as input in order to collect all the related information, and constructs a response ICE payload according to the given module interface. Subscriber applications can initiate the process of pulling content from Syndication Server, or have content pushed to them. Either path of content access executes a Content Access module.

Figure 1-4 shows the architecture of Oracle9iAS Syndication Server and how the content provider adaptors relate to specific content provider operation modules designed for Syndication Server.

1.4.3 Syndicator

Syndicators automate the process of syndication. The role of the syndicator is to:

• Deploy the Oracle9iAS Syndication Server runtime system

• Distribute content from content providers to subscriber applications

• Monitor Syndication Server performance and log activity

Figure 1-4 Oracle9iAS Syndication Server Architecture

Text description of the illustration ossdss.gif

1.5 Syndication Server Operations Overview

Section 1.5.1through Section 1.5.5 describe and explain how the major operations of Syndication Server work, beginning with processing a request from a subscriber application who wants to access a specific content resource using Syndication Server. The operations involve:

• Setting up a subscriber application account on Syndication Server

• Aggregating subscription offerings and generating the catalog

• Process subscription requests

• Accessing content for that subscription

1.5.1 Setting Up a Subscriber Application Account

Once the subscriber application and syndicator have worked out all contractual, monetary, and business implications, then a subscriber application account can be created to allow the subscriber application to access Syndication Server. The Syndication Server administrator creates a user account for the subscriber application and sends back a confirmation message. This confirmation message contains information about the subscriber application's account, such as his subscriber application ID, contact information, access control information, and how to obtain that catalog.

1.5.2 Aggregating Subscription Offerings and Generating the Catalog

With his new subscriber account ID, the subscriber application may make a get-catalog request to view all the subscription offerings. Syndication Server contacts all authorized content providers for available offerings. After receiving all responses from the content providers, Syndication Server constructs a single catalog response and returns it to the subscriber application. Each content catalog is considered a single offer group in the generated catalog response, which is marked by that content provider's unique ID. Syndication Server can aggregate content catalogs from a variety of content providers.

1.5.3 Process Subscription Requests

The subscriber application reviews the catalog and chooses one single content offer group. The subscriber application then supplies additional information as to a preference for negotiable parameters such as delivery policy and business terms, and then makes a request to get approval for a subscription. Syndication Server (the syndicator) invokes the subscription manager to process the request, and possibly involves the corresponding content provider as needed. Following a possible negotiation process with the content provider, a subscription agreement is made, and having agreed to a set of terms, the subscriber application receives a message indicating that the subscription is set and active.

1.5.4 Accessing Content for a Subscription

If the subscription is enabled for pulling content delivery, the subscriber application initiates a content access request and provides the subscription ID. Syndication Server pulls content from the corresponding content provider and returns it to the subscriber application.

If the subscription is enabled for automatically pushing content to the subscriber application, then the subscriber application has two choices:

• Having content pushed to him based on an event, such as whenever content is updated

• Having content pushed to him based on a content update time interval, in which content is periodically updated, for example every hour based on how the scheduler is set

1.5.5 ICE Request Runtime Flow

The ICE request runtime flow is shown in Figure 1-5 and described in more detail in the steps that follow.

Figure 1-5 ICE Request Runtime Flow

Text description of the illustration icrqrntm.gif

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 the subscriber manager (not shown in figure). 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.

3. Message manager, subscription manager, and affiliates manager operations include the following:
   1. The message manager parses the ICE request payload, converting the request to an internal format used by the subscription manager and the affiliates manager.

   2. Upon receiving a subscribe request, the subscription manager works in combination with the affiliates manager to approve the request. A negotiation process defined by ICE standards 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 (the syndicator) 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 ID persistently in the Syndication Server 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.

   3. Based on the type of request (for example, get catalog, subscribe, or get content) that is made by the 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.