Package com.sapportals.wcm.service.ice

Represents a service based on the W3C ICE protocol to distribute content to subscribers.

See: Description

Interface Summary

Interface	Description
IICEHttpConnection	A helper class representing a HTTP connection to an ICE server.
IICEService	This is the entry point to the ICE service (Content Exchange Service) and provides methods to access the configuration of the syndicator and subscriber parts as well as their corresponding background tasks (scheduler jobs).

Class Summary

Class	Description
EventLog	Represent a log of ICE events that are associated with certain actions like requesting a catalog of offers or establishing subscriptions.

Package com.sapportals.wcm.service.ice Description

Represents a service based on the W3C ICE protocol to distribute content to subscribers.

Package Specification

Purpose
Detailed Concept
Interfaces and Classes
Code Samples
Configuration
Implementation Notes

Purpose

The content exchange service manages the distribution of content to subscribers via an HTTP connection. The distribution process is essentially a transaction between a syndicator and a subscriber. The syndicator bundles content which is available in a repository into offers for target groups. The subscriber chooses an offer and subscribes to its contents. The content exchange service controls all aspects of the distribution process. It supports the tasks of the syndicator, the tasks of the subscriber and the exchange of information and content between them.

The features of the service can be useful for businesses like news providers. Typically, a news provider collects the latest news items and distributes them to customers. With the help of the service, many aspects of this process can be easily organised and automated. The news provider can compile a catalog of offers which is automatically available to all registered customers that connect to the provider. The customers can subscribe to the offers and automatically receive updates of offers at predefined intervals.

A further area where the content exchange service may be useful is in the replication of content. If the same content is distributed to different locations and repositories, the service can be used for updates and replication. For example, if a KM repository in Germany must also be available with the same content in the USA, then the service can be used to transfer the content from one repository to the other and to subsequently update the contents at regular intervals.

The content exchange service is based on the W3C ICE protocol and can therefore interact with both subscribers and syndicators external to KM. A client that wants to subscribe an offer set up in a KM repository may use any software which observes the conventions laid down by the ICE protocol.

Detailed Concept

This section gives you an introductory overview of the components of the content exchange service and their interrelationships. When you are working with the API, it is useful to have an elementary understanding of the structure of the service.

The content exchange service has two core components: A syndicator and a subscriber. Basically it is the task of the syndicator to compile, distribute and manage offers. It is the task of the subscriber to choose offers and to stipulate the conditions under which it wants to receive offers and updates. The communication between the syndicator and subscriber take place according to the rules of the W3C ICE protocol. For the service to be able to work, both the syndicator and subscriber need to possess information about each other. The subscriber needs to know about the syndicator and its offers. The syndicator needs to know about subscribers and their subscriptions. The following graphic illustrates the basic structure of the content exchange service and the interrelationships between its components.

Offers

As illustrated in the graphic, the main task of the syndicator is to compile offers of content and to transfer these to subscribers that have set up subscriptions. An offer is comprised of an ID, description, components and a delivery policy:

• The ID is the unique identifier for the offer.
• The component represents the content of the offer. It is basically the RID of a collection which, together with its subfolders, contains the resources that are included in the offer. With the help of content filters, the offer can be restricted to a subset of the resources in the collection and its subfolders. Depending on the filter that is used, it can be limited to items that adhere to certain naming conventions, that were created before or after a certain date or do not exceed a predefined size.
• The delivery policy controls the transfer of the content to the subscriber. A default delivery policy defines the standard manner in which the offer is passed to subscribers. So-called delivery rules specify details like when content is initially transferred, how often it is updated, when the transfer is to end. It also determines whether content is sent via an http connection or zipped and attached to an email. The delivery rules distinguish between two different ways in which transfer of content is initiated: push and pull. When the transfer of content is initiated by the syndicator at a predefined time, transfer takes place in push mode. If, on the other hand, the subscriber initiates the transfer by setting up a http connection then the transfer takes place in pull mode.

Subscriptions

As illustrated in the graphic, the main task of the subscriber is to set up a subscription for a content offer. To be able to do this successfully, the subscriber needs to have information about the syndicator and its offers. Therefore, in preparation for setting up a subscription, the subscriber must register the syndicator and provide a target directory for content.

A subscription is comprised of a number of elements:

• Name, description and ID of the syndicator
• Unique ID and name of the subscription (within a syndicator subscriber relationship)
• The ID of the offer
• The delivery policy that controls the transfer of content

Subscription Procedure

The subscriber and syndicator communicate via the ICE protocol. Communication always takes place according to a request and reply schema. So, for example, the subscriber requests a catalog of offers from the syndicator. The syndicator replies by supplying a list of offers. The subscriber can then choose an offer and delivery policy and send this as a subscription request to the syndicator. The syndicator then replies by accepting or rejecting the subscription request. Using the request response schema, the ICE protocol allows negotiations about the delivery policy and contents of an offer.

In the ICE environment, the term payload is used to refer to a unit of communication. Whenever information is transferred in a request or reply it represents a payload.

ICE Repository

The content exchange service can be used in combination with a KM ICE repository. The purpose of the repository is to enable an alternative channel for content distribution. When sensitive data is distributed an http connection may not be secure enough. In this case the transport of the data on a CD or other data medium is preferable. Also, if a large amount of data has to be transferred, for example, the initial content of an offer, then the transport on a CD may be necessary. The ICE repository is used to prepare the content for this type of distribution. It serves as a container where all the data for an offer is collected before it is transferred to a CD or other data medium for transport.

Note that the ICE repository is implemented in a separate framework package that does not have a public interface.

Packages of the Service

The components of the content exchange service and their interrelationships, as described above, are reflected in the packages and API of the service. The packages are grouped by syndicator, subscriber and the ICE protocol as shown in the table:

Component	Package
Syndicator	com.sapportals.wcm.service.ice.syndicator
Subscriber	com.sapportals.wcm.service.ice.subscriber
ICE Protocol	com.sapportals.wcm.protocol.ice.protocol

Interfaces and Classes

The graphic shows the central interfaces of the ICE Service.

Code Samples

Implementation Notes

The scheduler and task queue service must be active when ICE is used.

Configuration

The content exchange service can be configured with the parameters shown in the table.
The parameters are set with the help of the user interface of the Content Management configuration framework.
For more information, see the documentation Administering Content Management.

The parameters that are not required have default values that are used if no value is specified.

Parameter	Required	Description
ice_service	yes	Name of the user that executes the ICE background tasks
root	yes	The root directory for the logging of events
active	yes	Activates or deactivates the service