Skip Headers

Oracle® Application Developer's Guide - XML 10g (9.0.4) Part Number B12099-01 |
Home | Contents | Index

# 19
Oracle Syndication Server (OSS) and XML

Oracle Syndication Server (OSS) has a content syndication solution that generates one simple catalog for various content resources and aggregates any Internet data. It automatically pushes content updates to anywhere.

This chapter describes the following sections:

- Introducing Oracle Syndication Services (OSS)

- OSS Features: e-Business Content Aggregation, Exchange, and Syndication

- Information and Content Exchange (ICE) Protocol

- OSS Architecture

- Interacting with Content Providers

- Interacting With Content Subscribers

## Introducing Oracle Syndication Services (OSS)

Content syndication can be applied to many application scenarios, including catalog exchange solutions in a B2B supply chain,and content providers syndicating to multiple portals. Oracle Syndication Server (OSS) has an extensible and scaleable content syndication solution that offers the following support:

- Generates one simple catalog for various content resources

- Aggregates any Internet data

- Automatically pushes content updates to anywhere

Hence, OSS allows content syndication in B2B, B2C, and B2E, facilitating content exchange among providers, content delivery from providers to consumers, and content sharing in organizations.

See Also: http://otn.oracle.com/products Chapter 18, "Using OracleAS Dynamic Services and XML"

## OSS Features: e-Business Content Aggregation, Exchange, and Syndication

OSS provides content aggregation, exchange, and syndication for e-Businesses. OSS ensures your data is available, anywhere, and anytime. Its primary features are:

- Aggregate content from any source: OSS uses OracleAS Dynamic Services to extract or adapt information from any source, including existing Web sites, databases, enterprise applications, e-mail repositories, and legacy systems, to syndicate to its subscribers. These information and content sources are consolidated into one point of access known as a "content catalog", for any subscriber. See Chapter 18, "Using OracleAS Dynamic Services and XML" for information about OracleAS Dynamic Services.

- Personalize subscriptions and content delivery for each subscriber: OSS allows syndicators to personalize content for delivery based on profiles of subscribers, and to deliver content updates based on the subscription delivery policies.

- Automate content delivery: OSS pushes content to subscribers when information relevant to them changes. It allows a syndicator to schedule a "push" delivery for a subscriber. OSS uses Oracle9i Dynamic Services framework to push content over multiple channels.

- Transform content to adapt to a subscriber's format: Because of the OracleAS Dynamic Services framework, OSS can transform content from any formatted source to a markup language suitable for each subscriber.

Figure 19-1 summarizes OSS features. Here you see OSS used to transport and redistribute any content, using any protocol, between syndicators and subscribers. It also offers content personalization. OSS is shown to facilitate data Push and Pull strategy. OSS includes administrative tools to manage subscriber profiles, content resources profiles, established subscriptions, and system monitoring.

#### Figure 19-1 Oracle Syndication Server (OSS) Features

Text description of the illustration oss_1.gif

### Content Syndication

There are two roles in content syndication:

- Content Subscriber: One of the two parties, that obtain information and content from a syndicator. This can be human subscribers, applications in organizations needing content feeds, or entire organizations that re-purpose the content they subscribe to.

- Content Syndicator: One of the two parties, that send information and content to a subscriber, retrieving the content from a third party content provider, or providing content in-house.

Oracle Syndication Server (OSS) can be configured to act as the content syndicator, content subscriber, or both.

## Information and Content Exchange (ICE) Protocol

Information and Content Exchange (ICE) protocol is an XML-based specification to manage and automate the establishment of syndication relationships, data transfer, and results analysis in a content syndication scenario.

When combined with an industry specific vocabulary, ICE provides a complete solution for syndicating any type of information between information providers and subscribers. As a result, ICE can facilitate the controlled exchange and management of electronic assets between networked partners and affiliates. Applications based on ICE allow companies to easily construct syndicated publishing networks, Web superstores, and online reseller channels by establishing information and content exchange networks. ICE implementation features:

- Message Definition: ICE messages are XML based, andICE 1.1 specification uses XML DTD to define the format of these messages, hence the protocol grammar is thereby established through this message definition.

- Content Transport: ICE protocol has been designed based XML document exchange. Each protocol message consists of a valid XML document, and the protocol involves sending such documents back and forth between syndicator and subscriber. The specification does not restrict ICE to any transport mechanism.

- Security: ICE implementations can achieve security using methods, such as encryption, at the transport level. Or applications can agree to send digitally signed content as items in ICE protocol. Or syndicators and subscribers can use certificates to authenticate each other.

#### ICE Operation Types

ICE protocol handles four types of operations:

- Subscription establishment and management. In ICE, a relationship between a Syndicator and a Subscriber begins with some form of subscription establishment. In ICE, the subscriber typically begins by obtaining a catalog of possible subscriptions (really, subscription offers) from the Syndicator. The structure of a Catalog defined by ICE protocol consists of subscription offer groups. Each offer group has a set of offers as the finest unit for subscribers to choose from. For every offer, ICE protocol supports and defines the structure of associated delivery policies, usage reporting, presentation constraints, and business terms.

- Data delivery. The Subscriber then subscribes to particular subscriptions, possibly engaging in protocol parameter negotiation to arrive at mutually agreeable delivery methods and schedules.

- Event logs. The relationship then moves on to the steady state, where the primary message exchanges center on data delivery. ICE uses a package concept as a container mechanism for generic data items. ICE defines a sequenced package model allowing syndicators to support both incremental and full update models. ICE also defines push and pull data transfer models. Managing exceptional conditions and being able to diagnose problems is an important part of syndication management; accordingly, ICE defines a mechanism by which event logs can be automatically exchanged between (consenting) Subscribers and Syndicators.

#### Other Miscellaneous ICE Operations

Finally, ICE provides a number of mechanisms for supporting miscellaneous operations, such as the ability to renegotiate protocol parameters in an established relationship, the ability to send unsolicited ad-hoc notifications (i.e., textual messages) between systems (presumably ultimately targeted at administrators), the ability to query and ascertain the state of the relationship, etc.

## OSS Architecture

OSS is built on OracleAS Dynamic Services to adapt any content/information from Web sites, Internet Applications, or database, into an XML representation. It also transforms the XML into a markup language specific to the subscriber by means of XSL stylesheets.

Each content source is modeled as a set of services in OracleAS Dynamic Services. Information about the subscribers, content resources, and existing subscriptions is stored in OSS's registry. At runtime, OSS's engine processes subscriber content requests by invoking the corresponding components, and sends back content responses. On notification of content updates, OSS's engine checks its local registry to locate relevant subscribers and then pushes the updated information according to the delivery policy specified inside the subscription for each subscriber. Events from OSS are logged in an Oracle database.

Figure 19-2 illustrates Oracle Syndication Server's architecture overview and main functional components. Oracle Syndication Server (OSS) is built on OracleAS Dynamic Services framework using XML and Java. It communicates using a Java servlet, deployed in a servlet container with any industry standard Web listener, to receive and send messages. Information about subscribers and content resources as services are stored in OSS's registry on Oracle.

#### Figure 19-2 Oracle Syndication Server: Architecture Overview

Text description of the illustration oss_2.gif

OSS components are divided into two parts:

- Components that interface with content providers directly or through OracleAS Dynamic Services framework

- Syndication Server Engine that manages the interaction between content subscribers and the content providers.

## Interacting with Content Providers

OSS interacts with content providers using OracleAS Dynamic Services(DS). OSS exposes content providers as a set of Dynamic Services services. The handling of a subscriber's request is mapped to a corresponding service execution inside the specified Dynamic Services Engine. OSS serves as a digital asset hub, aggregating content from all types of providers, regardless of location, access protocol, or content format.

### Dynamic Services Content Provider Adapter (DSCPA)

DSCPA provides the interface for OSS's engine to access each registered content provider as a set of DS services. Enforced by the OSS, every published content provider service must comply with pre-defined DS interface. At runtime, OSS invokes the specified DSCPA to construct a DS service request from the subscriber's request. DSCPA then sends the service request to the specified DS engine for execution. The DS service engine's response is collected by DSCPA, marking the end of the transaction with a content provider. OSS requires each content provider to have the following minimum set of DS services:

- "Catalog" DS service. Used for content providers to provide catalog information of their available subscription offers.

- Subscription Approval DS service. Used as a way for certain content providers to approve subscriptions before they are stored in the OSSer. The service takes in a subscription request, forwarded by OSS, as input, and returns an approved subscription if the content provider agrees on all terms.

- Content Access DS service. Subscribers can initiate pulling content from OSS as well as having the content pushed to them.

- Subscription Cancellation DS service. Subscribers can cancel their subscriptions. When this occurs, OSS forwards the intent to an underlying "unsubscribe" DS service implemented by the content provider to allow the content provider to perform subscription clean ups.

## Interacting With Content Subscribers

As OSS is implemented with ICE as the underlying mechanism of communication, a Content Subscriber Development Kit (CSDK) is bundled with OSS to facilitate subscribers in implementing their applications to communicate with any content syndicator using ICE. CSDK contains a client library that abstracts to some extent the formation of ICE messages from the subscriber's perspective, so applications can be easily developed without being coupled with the underlying communication protocol with the server. Along with this client library is a set of API documentation that will further facilitate the process of content application development.

### Delivering content to subscribers

Transport Protocol Manager (TPM) handles PULL and PUSH content deliveries from OSS to subscribers. In PUSH, subscribers can speak a protocol-specific language - most of them are XML-based markup languages.

To deliver data to a specific subscriber, TPM transforms the XML-formatted content to an appropriate subscriber-specific markup language and transports the content over a specified transport layer. This is done by a DS service model, one DS delivery service for each protocol. At runtime, the TPM selects a DS delivery service corresponding to a specified protocol, and executes it through the underlying DS framework.

| Copyright © 2001, 2003 Oracle Corporation. All Rights Reserved. |
Home | Contents | Index