|Oracle9i Application Developer's Guide - XML
Release 1 (9.0.1)
Part Number A88894-01
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:
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:
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.
OSS provides content aggregation, exchange, and syndication for e-Businesses. OSS ensures your data is available, anywhere, and anytime. Its primary features are:
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.
There are two roles in content syndication:
Oracle Syndication Server (OSS) can be configured to act as the content syndicator, content subscriber, or both.
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:
ICE protocol handles four types of 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 is built on Oracle9iAS 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 Oracle9iAS 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 9i database.
Figure 19-2 illustrates Oracle Syndication Server's architecture overview and main functional components.
Oracle Syndication Server (OSS) is built on Oracle9iAS 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 Oracle9i.
OSS components are divided into two parts:
OSS interacts with content providers using Oracle9iAS 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.
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:
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.
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.