Content Syndication Using ICE
RSS is a simple mechanism for enabling the syndication of lightweight
content. RSS was designed to be simple to use and inexpensive to implement.
Although RSS has proven quite useful for the syndication of free content, RSS
remains limited in its ability to enforce business rules in the content
syndication environment. To fill this role, a second, more robust syndication
protocol, Information and Content Exchange (ICE), was devel-oped by industry
content providers and software vendors. ICE was developed to auto-mate the
negotiation of subscription characteristics and to address the need to automate
scheduled, reliable, secure redistribution of any content for publishers and
for non-com-mercial content providers.
The History of ICE
On October 27, 1998, a press summit held in San Francisco announced the
completion of a new XML-based Web protocol called ICE. On October 28, W3C
acknowledged the submission of a Note on ICE. Today, the ICE protocol stands at
version 1.1, and work on a Web services version of ICE—ICE 2.0—has begun. ICE
was initially designed to meet the syndication requirements of Web content
providers of all kinds. Today, ICE is impor-tant to anyone who wants to
distribute information on the Web according to controlled business rules. ICE
has been incorporated into many products, including Vignette, Kinecta, Oracle,
Interwoven, 3Path, HP Bluestone, and Active Data Exchange.
ICE provides support for the syndication process. The theory behind ICE
is that all online businesses have a syndication problem. Here, syndication is
defined in a much broader sense than just the distribution of published
content. Certainly publishers want a standard way to establish a reliable
syndication business process. However, the truth is that all business partners
need a reliable and accountable mechanism to exchange infor-mation on a routine
basis. What publishers as well as those involved in e-business must do is
establish online, networked information-based partnerships. Today, this process
is often ad hoc, fragile, error prone, and expensive. This cannot prevail as
the predominant Web model for syndication.
ICE provides us with a standard model that can be automated to support
syndication for all. The importance of adopting a standard interchange
mechanism is that it will lower costs of entry by eliminating the requirement
to write customized scripts for each busi-ness partner that is added to the
value chain. This, in turn, will increase opportunity by enabling a quick,
inexpensive, and standard way to add new trading partners. The exis-tence of a
standard format for interoperating between business partners is critical.
ICE is not a file format but rather a bidirectional protocol designed
specifically to sup-port content dissemination on the Web. New opportunities
created by ICE include the following:
The ability for publishers to
generate new revenue streams from existing content
The ability to lower cost of
content exchange among networked trading partners
The ability to expand distribution
of information (increased market share and increased revenue)
The ability to create Internet
Value Networks, not islands of information
ICE Authoring Group
The initial members of the ICE Authoring Group were Web pioneers who
recognized that they needed a standard protocol for interoperating. These
pioneers included Con O’Connell, Neil Webber, and Brad Husick from Vignette,
Laird Popkin from News America Digital Publishing, Rick Levine from Sun
Microsystems, Doug Bayer from Microsoft Corporation, Jay Brodsky from Chicago
Tribune Media Services, Bruce Hunt of Adobe Systems, Andy Werth from CNET, John
Petrone from Preview Travel, Gord Larose from ChannelWare, and Phil Gibson from
National Semi-Conductor. The compa-nies that developed ICE were evenly split
between software vendors and users of tech-nology, ensuring that it was a
standard that met real user requirements. ICE is therefore known as a user-driven technology standard. The ICE
Authoring Group and all ICE activities are hosted by IDEAlliance, the
International Digital Enterprise Alliance. IDEAlliance provides administrative
support for the group and plays a major role in helping to promote the adoption
of the standard at conferences and summits.
You can learn more about ICE at its Web site, http://www.icestandard.org.
The ICE Syndication Model
The ICE syndication model differs from the RSS syndication model because
RSS enables content providers to make their content free for use across the Web
by anyone. However, ICE is specifically designed to enable the managed,
reliable, scheduled deliv-ery of content in a business environment. RSS assumes
that those using the content may be unknown to the content provider. ICE, on
the other hand, assumes that a business rela-tionship has been established
before ICE transactions begin. The business agreement can involve personal
discussions, legal review, and contracts, just as any business agreement does.
ICE transactions begin only after the business agreement has been established.
ICE Terminology
Before we begin to consider a step-by-step example to illustrate the ICE
syndication model, it will be helpful to review a few definitions:
Syndicator. A content provider or
aggregator. A content distributor.
Subscriber. A content consumer or receiver.
Subscription. An agreement between a
subscriber and a syndicator for the delivery
of content according to the delivery policy and other parameters in the
agreement.
Catalog. A listing of ICE offerings.
This is the listing of all content being offered for subscriptions and the delivery terms for the content.
ICE offer. A particular subscription
offering found within the ICE catalog.
Delivery policy. The terms of delivery for ICE
content. The delivery policy can include
start date, stop date, mode (push or pull), delivery days, delivery times,
update mode, and delivery URL.
Collection. The current content of a
subscription.
ICE package. A delivery instance of commands
to update a collection such as the addition
of content items.
ICE payload. The XML document used by ICE to
carry protocol information. Examples
include requests for packages, catalogs of subscription offers, usage logs, and
other management information.
ICE Usage Example
ICE is an XML protocol that defines the business rules and processes
needed for reliable content syndication among Web servers. Currently ICE uses
HTTP as a transport layer. ICE messages, coded in XML, always come in
request/response pairs.
Two parties (Web servers) are involved in ICE transactions. The first is
the syndicator. The syndicator is the
party that provides content—either its own or content it has aggre-gated from
other sources. The second party in ICE transactions is the subscriber. The subscriber is the one who wants data from the
syndicator. In ICE, certain messages are reserved for the syndicator. Other
messages are reserved for the subscriber—and some messages can be used by
either party.
Let’s look at a typical ICE scenario so you can follow the steps in the
ICE syndication process. In this scenario, a business relationship is
established between the syndicator and the subscriber. This process is done in
person or by telephone. The subscriber provides the syndicator with an
identifier that will be used as the basis for automated ICE transactions.
The next step is for the subscriber to select subscription content. The
subscriber sends a message to request a catalog that lists all content offers
using the ice-get-catalog request. Listing 13.8 shows the ice-get-catalog request message in XML.
LISTING 13.8 An ice-get-catalog Request
<?xml version=”1.0”?>
<!DOCTYPE ice-payload SYSTEM
“http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-payload
payload-id=”PL-2000-08-24T22:10:33.901-DKennedy-423”
timestamp=”22:10:33,741” ice.version=”1.1”>
<ice-header>
<ice-sender
sender-id=”4af37b30-2c35-11d2-be4a-204c4f4f5020” name=”D Kennedy “
role=”subscriber”/>
<ice-user-agent>
IceBlock Systems ICE Processor,
V7.0 </ice-user-agent>
</ice-header>
<ice-request
request-id=”2000-08-24T22:10:33_RQ_DKennedyl_1888”>
<ice-get-catalog/>
</ice-request> </ice-payload>
At this point, the syndicator responds by delivering a catalog to the
subscriber. Listing 13.9 shows the ice-response message in XML.
LISTING 13.9 ICE Catalog Response
<?xml version=”1.0” ?>
<!DOCTYPE ice-payload SYSTEM
“http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-payload
payload-id=”PL-2000-08-24T22:10:45-XMLFiles-2761”
timestamp=”22:10:45,321”
location=”xmlfiles.idealliance.org”
ice.version=”1.1”>
<ice-header >
<ice-sender
sender-id=”4a2180c9-9435-d00f-9317-204d974e3410” name=”IDEAlliance”
role=”syndicator”/>
<ice-user-agent>
Northstar Protocols ICE
Processor, V17 </ice-user-agent>
</ice-header>
<ice-response
response-id=”RSP-2000-07-21T02:03:45-XMLFiles-9876”> <ice-code
numeric=”200”
phrase=”OK”
message-id=”REQ-2000-07-21T02:02:23-DKennedy-345”/>
</ice-response>
<ice-catalog
name=”XML Files 2001
Newsletters“
url=”http://xmlfiles.idealliance.org/offers/xmlfiles.html”>
<ice-contact
name=”XML Files“>
For information
please contact
Catalog Offers: Dianne Kennedy,
650-555-1212
Technical Support:
David Steinhardt, 650-555-1313
</ice-contact>
<ice-offer
product-name=”XMLFiles 2001 Newsletter”
offer-id=”XMLFiles-2001-V1-R1”
subscription-id=”ICE-NEW-SUBSCRIPTION”
expiration-date=”2001-12-30”
quantity=”12”>
<ice-delivery-policy
stopdate=”2002-01-01”> <ice-delivery-rule mode=”pull”
max-num-updates=”24” min-num-updates=”12”
max-update-interval=”P2678400S” min-update-interval=”P43200S”/>
<!-- max-num-updates is two
per month, min-num-updates is 12 per year, max-update-interval is 31 days,
min-update-interval is 12 hours -->
</ice-delivery-policy>
</ice-offer>
</ice-catalog> </ice-payload>
ICE has functions that will enable the automated negotiations of any ICE
offer. Suppose, for example, an offer in the catalog is the content that the
subscriber wants, but the deliv-ery policy is not acceptable. The subscriber
could use ICE messages to negotiate accept-able delivery parameters.
When the subscriber is satisfied with the offer, acceptance for the
offer is sent to the syn-dicator. The syndicator will then verify that it
accepts the subscription and provides the subscriber with a subscription ID.
The next step is for the subscriber to request initial subscription
content. The subscriber uses ice-get-package with the current-state=”ICE-INITIAL” message (see Listing 13.10). The syndicator will provide the initial
content for the subscription according to the delivery policy for the
subscription in response to this request.
LISTING 13.10 Example of an ice-get-package Message
<?xml version=”1.0”?>
<!DOCTYPE ice-payload SYSTEM
“http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-payload
payload-id=”PL-2000-08-24T22:10:33.901-DKennedy-423”
timestamp=”22:10:33,741”
ice.version=”1.1”> <ice-header>
<ice-sender
sender-id=”4af37b30-2c35-11d2-be4a-204c4f4f5020” name=”D Kennedy “
role=”subscriber”/>
<ice-user-agent>
IceBlock Systems ICE Processor,
V7.0 </ice-user-agent>
</ice-header>
<ice-request
request-id=”2000-08-24T22:10:33_RQ_DKennedyl_1888”>
<ice-get-package
current-state=”ICE-INITIAL” subscription-id=”1”/>
</ice-request> </ice-payload>
Following the initial delivery of subscription content, new content will
be delivered from the syndicator to the subscriber according to the delivery
policy of the subscription. The content is contained within the ice-payload as an ice-package made up of one or more ice-items. The ICE message may include
any kind of content directly in the message (that is, HTML, database records, XML, graphics, PDF, and so on).
Typically, though, the ICE item just sends a URL where the content is made
available. The ICE message itself can be thought of as an envelope for content
and data about the content delivery. When the ice message delivers content, it
is always as an ice-response. You can see this message flow in Figure 13.6.
ICE Error Messages
One of the features of ICE that provides a great business advantage is
the reliability of content delivery. The ICE protocol is designed so that every
request must have a match-ing response. It is these request/response message
pairs that enable us to verify and log the receipt of content. The ICE
specification has built in a number of ICE error message codes that
specifically support automation of syndication. These codes are used within the
ice-code element.
Listing 13.11 shows how ice-code is used to indicate an error.
LISTING 13.11 Example of ice-code
with Error Indication
<ice-response
response-id=”REQ-2000-07-21T02:03:00-DKennedy-1873”> <ice-code
numeric=”331”
phrase=”Failure fetching external data”
message-id=”REQ-2000-07-21T02:02:23-XMLFiles-2397”>
Unable to obtain content from URL:
http://xmlfiles.idealliance.org/xmlfiles/xmlfiles2001.htm
</ice-code> </ice-response>
The following list shows some examples of ICE messages. The protocol has
been devel-oped based on use-case scenarios. Error messages are designed from
these scenarios. Here’s the list:
200 – OK. The operation successfully completed.
201 – Confirmed. The subscriber has successfully processed the package.
331 – Failure Fetching External Data.
401 – Incomplete/Cannot Parse. You couldn’t even get the parser started!
402 – Not Well Formed XML. Your XML tags didn’t balance.
404 – Broken Link. Content is not available at the specified link.
405 – Unrecognized Sender. Who are you?
406 – Unrecognized Subscription. You have to have a valid subscription
ID.
407 – Unrecognized Operation. An operation in the package was not one
that you recognized.
408 – Unrecognized Operation Arguments. The attributes on the element
were unknown.
430 – Not Confirmed. A generic error indicating that the subscriber
didn’t complete processing.
501 – Temporary Responder Error. An “I’m too busy right now to do it”
message.
603 – No More Confirmations To Send. When you’ve confirmed everything, respond with this.
ICE clearly contains many more features and imposes many disciplines on
the process of content syndication. Therefore, one may make the false
assumption that using ICE is a complex and expensive undertaking. It turns out
that there are different levels of ICE implementation and ICE conformance.
However, actually setting up minimal ICE imple-mentation is easy for anyone.
Simple ICE Syndication
Very simple ICE implementations can provide a basic ability to syndicate
content, just as RSS can. You would make syndicated material available in this
way by following these steps:
Create content that you wish to
syndicate. Place it on your Web site so that it will be available. Suppose you
put the new issue of XML Files at the following URL:
http://www.idealliance.org/xmlfiles/issue30/default.htm
Construct the following ICE
message that describes the location of the content to be syndicated:
<?xml
version=”1.0”?>
<!DOCTYPE ice-package SYSTEM
“http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-package>
<ice-item-ref
url=”http://www.idealliance.org/xmlfiles/issue30/default.htm”
item-id=”xmlfilesissue30”/>
</ice-package>
3. Now place the ICE package on your Web site,
such as http://www.idealliance. org/ice/xmlfiles.ice.
That’s all that is required of the syndicator. If you are the subscriber
to content that is posted using this simple ICE mechanism, you have two steps
you must follow:
Obtain the URL for the ICE
package on the Web site. You might receive this via e-mail. Alternatively, it
might be posted on the home page of the site.
Parse the ice-item-ref URLs out of the ICE package and
either download the content or reference it using the URL.
Full ICE Compliance
If you intend to take advantage of the power of ICE to manage content
according to busi-ness rules, you will most likely need the full power of ICE
and the full range of ICE messaging at your disposal. This means that you will
need to purchase a tool that pro-vides ICE capabilities. Because ICE is a
server-to-server messaging protocol, you can’t really “see” ICE. However, you
can look for it as a standard protocol supported by Web content-management
systems.
The ice-payload is the XML document used by ICE to carry protocol information, or ice messages. The ice-payload is homogenous. This means that an ice-payload can only carry one kind of message. The DTD for ICE, shown in Listing
13.12, shows that the payload may carry one or more responses, one or more
requests, but may never mix requests with responses.
LISTING 13.12 The DTD for an ice-payload
<!ELEMENT ice-payload
( ice-header, ( ice-request+ | ice-response+ | ice-unsolicited-now |
ice-unsolicited-request+ | ice-unsolicited-response+) ) >
<!ATTLIST ice-payload
payload-id CDATA #REQUIRED
timestamp CDATA #REQUIRED
ice.version CDATA #REQUIRED
>
There are many different kinds of ICE requests and ICE responses. The
syndicator some-times makes requests and sometimes gives responses. Likewise,
the subscriber some-times makes requests and other times makes responses. Do
not just assume that the subscriber is the requestor. That is not at all the
case!
Here’s a list of the standard ICE requests that are supported within
full ICE compliance (as you can see, an automated tool to handle all messaging
and track states of syndicated content is a must for full ICE syndication
support):
ice-cancel. Cancels the subscription.
ice-change-subscription. Changes the subscription.
ice-code. Passes an ICE message code.
ice-get-catalog. Requests for the syndicator to request an ICE catalog.
ice-get-events. Returns an ICE events log.
ice-get-package. Requests for the syndicator to return an ICE package.
ice-get-sequence. Returns the current ICE subscription state.
ice-get-status. Returns the status of the subscription.
ice-nop. Sends a no operation message. Used for debugging.
ice-notify. Mechanism for sending a text message.
ice-offer. The ICE subscription offer sent by Syndicator
ice-package. The ICE package sent from syndicator to subscriber.
ice-send-confirmations. Returns confirmation from the subscriber that a pack-
age has been received.
• ice-repair-item. Repairs a subscription
collection by replacing missing items.
Enabling Content Management with ICE
ICE is designed to give both syndicators and subscribers the ability to
manage their con-tent. In the following simple example, the ice-access element specifies the span of
time that the URL will be available. This means the subscriber knows how long the
link will last. Also, the syndicator has made a commitment to provide it for a
specific length of time. Therefore, the duration of the content is now made
explicit, meaning each party can avoid the “404” broken link problem.
In Listing 13.13, you can see how we used ice-access-control to limit who may access the content via login and password. A security
notice is printed to indicate that even though we are granting access for
syndication, the copyright remains with IDEAlliance.
LISTING 13.13 Using ice-access
to Manage Content
<?xml version=”1.0”?>
<!DOCTYPE ice-package SYSTEM
“http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-package>
<ice-item-ref
url=”http://www.idealliance.org/xmlfiles/issue30/default.htm”
item-id=”xmlfilesissue30” />
<ice-access>
<ice-access-window
starttime=”2001-10-01T08:00:00”
➥
stoptime=”2001-10-31T017:00:00”/>
➥ <ice-access-control control-type=”password” ➥ user=”XMLFiles Subscriber” password=”xmlgo”>
2001 IDEAlliance, Inc. All Rights Reserved. Use of
the content in this item reference implies acceptance of the use license at
http://www.idealliance.com/licenses/subscriber.html
including honoring all copyrights and trademarks. You agree not to provide
others with the
access
control password above.</ice-access-control>
</ice-access>
</ice-package>
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.