U.S. patent application number 12/533131 was filed with the patent office on 2009-11-26 for http publish/subscribe communication protocol.
Invention is credited to Robert P. Morris.
Application Number | 20090292766 12/533131 |
Document ID | / |
Family ID | 38369968 |
Filed Date | 2009-11-26 |
United States Patent
Application |
20090292766 |
Kind Code |
A1 |
Morris; Robert P. |
November 26, 2009 |
HTTP Publish/Subscribe Communication Protocol
Abstract
A communication protocol for distributing information related to
a resource in substantially real-time to a subscriber includes a
first HTTP request message for allowing the subscriber to request a
subscription to the information related to the resource, where the
first HTTP request message includes subscription data in a header
and/or in a Uniform Resource Identifier (URI) reference associated
with the first HTTP request message, and the subscription data
identifies the first HTTP request message as a subscription
request. The communication protocol also includes a second HTTP
request message for allowing a publisher to update the information
related to the resource, and an HTTP response message for allowing
a publish/subscribe service to notify the subscriber of the updated
information related to the resource each time the publish/subscribe
service receives the second HTTP request message from the
publisher.
Inventors: |
Morris; Robert P.; (Raleigh,
NC) |
Correspondence
Address: |
SCENERA RESEARCH, LLC
111 CORNING RD., SUITE 220
CARY
NC
27518
US
|
Family ID: |
38369968 |
Appl. No.: |
12/533131 |
Filed: |
July 31, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11344696 |
Feb 1, 2006 |
7587450 |
|
|
12533131 |
|
|
|
|
Current U.S.
Class: |
709/203 ;
707/999.01; 709/217; 709/219; 709/223; 709/224; 709/229 |
Current CPC
Class: |
H04L 67/02 20130101;
H04L 67/24 20130101; H04L 51/24 20130101 |
Class at
Publication: |
709/203 ;
709/217; 709/219; 709/223; 709/224; 709/229; 707/10 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method of subscribing to information related to a resource,
the method comprising: generating a first HTTP request message for
requesting a subscription to information related to a resource,
wherein the first HTTP request message includes subscription data
in at least one of a header and a Uniform Resource Identifier (URI)
reference associated with the first HTTP request message, wherein
the subscription data identifies a tuple associated with the
resource; sending the HTTP request message to a publish/subscribe
service to subscribe to the tuple associated with the resource; and
receiving an HTTP response message to the first HTTP request
message including updated information related to the resource in
response to the publish/subscribe service receiving a second HTTP
request message updating the information related to the resource,
wherein at least one of the preceding actions is performed on at
least one electronic hardware component.
2. The method of claim 1 wherein the subscription data includes an
indication of a duration of the subscription that comprises at
least one of a specified time period and a specified number of HTTP
response messages.
3. The method of claim 1 further comprising receiving from the
publish/subscribe service an HTTP message including a notification
of an update to the information related to the resource, wherein
the HTTP message is sent each time the publish/subscribe service
receives another HTTP message that updates the information related
to the resource.
4. The method of claim 3 wherein the subscription data includes a
subscription identifier that is associated with the HTTP request
message.
5. The method of claim 4 wherein each HTTP message is an HTTP
response message that includes the subscription identifier
associated with the HTTP request message such that each HTTP
response message can be correlated to the HTTP request message.
6. The method of claim 3 wherein the received HTTP message is an
HTTP request message that includes either an HTTP PUT method or an
HTTP POST method, the method further comprising: providing an HTTP
request handler component; using the HTTP request handler component
to generate an HTTP response message based on the subscription data
associated with the received HTTP request message; and passing the
generated HTTP response message from the HTTP request message
handler component to the subscriber.
7. The method of claim 1 further comprising: prior to sending the
HTTP request message to the publish/subscribe service, establishing
a persistent connection to the publish/subscribe service; utilizing
the persistent connection to send the HTTP request message to the
publish/subscribe service; and receiving from the publish/subscribe
service via the persistent connection an HTTP message that notifies
the subscriber of an update to the information related to the
resource, wherein the HTTP message is sent each time the
publish/subscribe service receives another HTTP message that
updates the information related to the resource.
8. The method of claim 7 further comprising: providing a session
layer on top of the persistent connection; and creating a first
session and a second session sharing the persistent connection,
wherein at least one of the first session and the second session
can be terminated without affecting the other session and the
persistent connection.
9. The method of claim 1 wherein the HTTP request message includes
either an HTTP GET method or an HTTP HEAD method.
10. A method of publishing information related to a resource to at
least one subscriber via a publish/subscribe service, the method
comprising: receiving information related to a resource; generating
an HTTP request message including the information related to the
resource and tuple information identifying a tuple associated with
the resource; and sending the HTTP request message to the
publish/subscribe service, wherein the tuple associated resource is
updated with the information related to the resource and in
response to the tuple update an HTTP response message including the
information is sent to a subscriber, wherein at least one of the
preceding actions is performed on at least one electronic hardware
component.
11. The method of claim 10 wherein the HTTP request message
includes either an HTTP PUT method or an HTTP POST method.
12. The method of claim 10 wherein generating the HTTP request
message further comprises: providing other data that identifies a
non-subscribing recipient in at least one of a header and a Uniform
Resource Identifier (URI) reference associated with the HTTP
request message thereby allowing the publisher to distribute the
updated information to the non-subscribing recipient.
13. The method of claim 10 further comprising: managing a roster
and members of the roster via another HTTP request message.
14. The method of claim 13 wherein managing the roster and members
of the roster further comprises: utilizing an HTTP request message
including an HTTP PUT method to either add, update, or delete a
roster or member; and utilizing an HTTP request message including
an HTTP GET method to retrieve a roster or member.
15. A computer readable medium including a computer program for
distributing information related to a resource between a publisher
and a subscriber, the computer program comprising instructions
executable in a publish/subscribe service for: receiving
information related to a resource; generating an HTTP request
message including the information related to the resource and tuple
information identifying a tuple associated with the resource; and
sending the HTTP request message to the publish/subscribe service,
wherein the tuple associated resource is updated with the
information related to the resource and in response to the tuple
update an HTTP response message including the information is sent
to a subscriber.
16. A computer readable medium including a computer program for
subscribing to information related to a resource, the computer
program comprising instructions executable in a subscriber for:
generating a first HTTP request message for requesting a
subscription to information related to a resource, wherein the
first HTTP request message includes subscription data in at least
one of a header and a Uniform Resource Identifier (URI) reference
associated with the first HTTP request message, wherein the
subscription data identifies the first HTTP request message as a
subscription request and identifies a tuple associated with the
resource; sending the HTTP request message to a publish/subscribe
service to subscribe to the tuple associated with the resource; and
receiving an HTTP response message to the first HTTP request
message including updated information related to the resource in
response to the publish/subscribe service receiving a second HTTP
request message updating the information related to the resource.
Description
RELATED APPLICATIONS
[0001] The present application is a continuation of co-pending U.S.
patent application Ser. No. 11/344,696, entitled "HTTP
PUBLISH/SUBSCRIBE COMMUNICATION PROTOCOL," filed on Feb. 1, 2006,
and assigned to the assignee of the present application. The
present application is related to co-pending U.S. patent
application Ser. No. 11/160,612, entitled "METHOD AND APPARATUS FOR
BROWSING NETWORK RESOURCES USING AN ASYNCHRONOUS COMMUNICATIONS
PROTOCOL," filed on Jun. 30, 2005, and assigned to the assignee of
the present application. The present application is also related to
co-pending U.S. patent application Ser. No. 11/160,157, entitled
"METHOD, SYSTEM, AND DATA STRUCTURE FOR PROVIDING A GENERAL
REQUEST/RESPONSE MESSAGING PROTOCOL USING A PRESENCE PROTOCOL,"
filed on Jun. 10, 2005, and assigned to the assignee of the present
application. The present application is also related to co-pending
U.S. patent application Ser. No. 11/096,764, entitled "SYSTEM AND
METHOD FOR UTILIZING A PRESENCE SERVICE TO FACILITATE ACCESS TO A
SERVICE OR APPLICATION OVER A NETWORK," filed on Mar. 31, 2005, and
assigned to the assignee of the present application. Each of the
above-cited related applications is incorporated here by reference
in its entirety.
BACKGROUND
[0002] Today's more popular browsers, such as MICROSOFT'S INTERNET
EXPLORER and MOZILLA FOUNDATION'S FIREFOX, use the HyperText
Transport Protocol (HTTP) to exchange information over the
Internet. HTTP is a request/response, synchronous, communication
protocol, where one entity in a network (e.g., the browser) makes a
connection to another network entity (e.g., a web server), sends a
request to the other entity, and then waits for a reply from the
other entity. Notably, the reply is sent only in response to the
request. If a request is not made, a reply is not sent.
Accordingly, information received in a reply can become stale.
[0003] Another mode of exchanging information over the Internet
uses a publish/subscribe (pub/sub), asynchronous, communication
protocol. Unlike HTTP, the pub/sub communications protocol allows
an entity (subscriber) to subscribe to information provided by
another entity (publisher). The publisher posts (or publishes) the
information, e.g., data tuples, to a pub/sub service, which then
selectively transmits the posted messages (through what are
referred to as notify messages) to all interested parties, i.e.,
subscribers. The published information can be read simultaneously
by any number of subscribers. Notably, in the pub/sub
communications protocol, the pub/sub service transmits the
information to the subscriber when the information is posted, and
does not queue previously published data for retrieval when a
subscriber is online such as with email and traditional topic-based
message queues.
[0004] The pub/sub communication protocol is an example of an
asynchronous communication protocol. The commands of an
asynchronous protocol are structured such that there need not be a
one-to-one correspondence between requests and responses exchanged
between communication entities. In some cases a sender of
information (e.g., a Publisher) via the protocol need not wait, nor
expect a response from, a receiver (e.g., a Subscriber). Moreover,
a receiver need not send a request for each response. That is, a
receiver may receive multiple responses (e.g., Notifications) to a
request (e.g., a Subscription) and/or may receive an unsolicited
message (e.g., a Directed Notify). Thus, unlike HTTP where the
reply is sent directly (synchronously) in response to the entity's
request, the information can instead be sent in response to the
publisher's posting of the information (i.e., asynchronous to the
request of information). Accordingly, information received by the
subscriber can be substantially up-to-date and timely.
[0005] Well known pub/sub communication protocols include presence
protocols, which are used by presence services and Jabber Software
Foundation's pub/sub protocol as specified in Jabber Enhancement
Proposal (JEP) JEP0060: Publish-Subscribe. A presence protocol
allows a presence client, e.g., a user, to subscribe to the
presence information of another entity, e.g., a friend. The
presence information of the friend can include the friend's status,
e.g., "on-line," "out-to-lunch," and the friend's preferred
communication mode. For example, a presence service typically
conveys a user's presence on a network to other network users
(subscribers) based on the user's connectivity to the network via a
computing and/or communication device. The presence information
describing a user's presence on the network can be used by
applications and/or other services to provide what are referred to
here as "presence applications". Presence protocol data elements,
known as tuples, must have a status element. General pub/sub
protocols may support features equivalent to presence protocols,
but pub/sub tuples, in general, have no content restrictions.
[0006] A popular presence application is instant messaging (IM). IM
applications include Yahoo's YAHOO MESSENGER, Microsoft's MSN
MESSENGER, and America Online's AOL INSTANT MESSENGER. IM
applications use presence services to allow users to determine
whether other users are present on (e.g., connected to) a network.
Presence services can also be used to determine a user's status
(e.g., available, not available, and the like) and a communication
address for communicating with a user. The communication address
can include both a means of communicating with the user (e.g., via
a telephone or email) and a corresponding contact address (e.g., a
telephone number or email address).
[0007] As the popularity of presence services has grown, the number
of presence applications using different presence protocols has
also increased. Some presence applications use proprietary
architectures and protocols to implement their presence service
components, while others use architectures and protocols based on
standards. Among those are the architectures and protocols
described in "Request for Comments" (or RFC) documents RFC 2778 to
Day et al., titled "A Model for Presence and Instant Messaging"
(February 2000), RFC 2779 to Day et al., titled "Instant
Messaging/Presence Protocol" (February 2000), and RFC 3921 to
Saint-Andre et. al, titled "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", each of which are
incorporated here in their entirety by reference. Each different
presence protocol exhibits varying levels of complexity and
interoperability. As a result, a user typically cannot use a
generic client, such as a web browser, to support different
presence services. Instead, the user must install
application-specific clients for each different presence service.
This can be burdensome, particular for those devices that have
limited resources. This situation exists for pub/sub protocols in
general.
SUMMARY
[0008] Accordingly, a pub/sub communication protocol and methods
for implementing pub/sub commands using the pub/sub communication
protocol are described. According to an exemplary embodiment, a
communication protocol for distributing information related to a
resource in substantially real-time to a subscriber includes a
first HTTP request message for allowing the subscriber to request a
subscription to the information related to the resource, where the
first HTTP request message includes subscription data in a header
and/or in a Uniform Resource Identifier (URI) reference associated
with the first HTTP request message, and the subscription data
identifies the first HTTP request message as a subscription
request. The communication protocol also includes a second HTTP
request message for allowing a publisher to update the information
related to the resource, and an HTTP response message for allowing
a publish/subscribe service to notify the subscriber of the updated
information related to the resource each time the publish/subscribe
service receives the second HTTP request message from the
publisher.
[0009] According to another exemplary embodiment, a communication
protocol message that allows a subscriber to request a subscription
to information related to a resource includes an HTTP request
message that includes subscription data in at least one of a header
and a Uniform Resource Identifier (URI) reference associated with
the request message. The subscription data identifies the request
message as a subscription request.
[0010] According to another exemplary embodiment, a communication
protocol message that notifies a subscriber when information
related to a resource is updated comprises an HTTP response message
sent to the subscriber each time an HTTP request message that
updates the information related to the resource is received. The
HTTP response message is based on subscription data associated with
another HTTP request message that creates a subscription to the
information related to the resource.
[0011] According to yet another exemplary embodiment, a method for
subscribing to information related to a resource includes
generating by a subscriber an HTTP request message and including
subscription data a header and/or a Uniform Resource Identifier
(URI) reference associated with the HTTP request message. The
subscription data identifies the HTTP request message as a
subscription request. The HTTP request message is then sent to a
publish/subscribe service.
[0012] According to yet another exemplary embodiment, a method for
publishing information related to a resource to at least one
subscriber via a publish/subscribe service comprises generating by
a publisher an HTTP request message including information related
to the resource, and sending the HTTP request message to the
publish/subscribe service. Data associated with the HTTP request
message is updated with the information related to the
resource.
[0013] According to another exemplary embodiment, a method of
distributing information related to a resource between a publisher
and a subscriber via a publish/subscribe service includes receiving
from the subscriber a first HTTP request message for requesting a
subscription to the information related to the resource. The first
HTTP request message includes subscription data in a header and/or
a Uniform Resource Identifier (URI) reference associated with the
first HTTP request message, and identifies the first HTTP request
message as a subscription request. The method further includes
receiving from the publisher a second HTTP request message that
includes updated information related to the resource. In response
to receiving the second HTTP request message, an HTTP message is
generated and sent from the publish/subscribe service to the
subscriber to notify the subscriber of the updated information
related to the resource.
[0014] According to another exemplary embodiment, a method of
implementing publish/subscribe commands includes generating an HTTP
request message including an existing HTTP method for each of a
SUBSCRIBE command and a PUBLISH command. Subscription data is
included in a header and/or a Uniform Resource Identifier (URI)
reference associated with the HTTP request message generated for
the SUBSCRIBE command, and identifies the HTTP message as a
subscription request. The method further includes generating either
an HTTP response message based on a correlated HTTP request
message, or an HTTP request message including an existing HTTP
method for a NOTIFY command.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The accompanying drawings provide visual representations
which will be used to more fully describe the representative
embodiments disclosed here and can be used by those skilled in the
art to better understand them and their inherent advantages. In
these drawings, like reference numerals identify corresponding
elements, and:
[0016] FIG. 1 illustrates an exemplary system for distributing
information from an application server/service to a pub/sub client
via a pub/sub server according to an exemplary embodiment;
[0017] FIG. 2 illustrates an exemplary pub/sub service/server
according to an exemplary embodiment;
[0018] FIG. 3 illustrates an exemplary application server according
to an exemplary embodiment;
[0019] FIG. 4 illustrates an exemplary subscriber client in a
client device according to an exemplary embodiment; and
[0020] FIG. 5 is a flowchart illustrating a method for exchanging
information according to an exemplary embodiment.
DETAILED DESCRIPTION
[0021] Various aspects will now be described in connection with
exemplary embodiments, including certain aspects described in terms
of sequences of actions that can be performed by elements of a
computing device or system. For example, it will be recognized that
in each of the embodiments, at least some of the various actions
can be performed by specialized circuits or circuitry (e.g.,
discrete and/or integrated logic gates interconnected to perform a
specialized function), by program instructions being executed by
one or more processors, or by a combination of both. Thus, the
various aspects can be embodied in many different forms, and all
such forms are contemplated to be within the scope of what is
described.
[0022] FIG. 1 is an exemplary system for supporting pub/sub
services according to an exemplary embodiment. The system 100
includes a plurality of client devices 400, a pub/sub
service/server 200, and an application server 300. Throughout the
description, the terms "pub/sub service" and "pub/sub server" are
used interchangeably to mean a component that supports the
publish/subscribe functionality between publishers and subscribers.
In addition, with reference to network communication protocols, the
terms "pub/sub" and "presence" are used interchangeably to describe
communication protocols supporting the asynchronous network
interactions.
[0023] Each client device 400 includes at least one pub/sub client
401, such as a subscriber client or browser Each pub/sub client 401
and the application server 300 are collectively referred to as
pub/sub entities because they are configured to interact with the
pub/sub server 200 using a pub/sub protocol. The client devices
400, pub/sub server 200 and application server 300 are
communicatively coupled by a network 120, such as the internet. As
is shown, the client devices 400 can be a desktop or laptop
computer, a mobile telephone, and the like, such as a
network-enabled camera. FIG. 1 depicts the pub/sub server 200, the
application server 300, and pub/sub clients 401 communicating with
one another using a pub/sub protocol, and the principles discussed
herein can be applied equally to all pub/sub protocols, such as
presence protocols.
[0024] According to an exemplary embodiment, each pub/sub client
401 is configured to use a pub/sub protocol to send to the pub/sub
server 200 a subscription request for a tuple associated with a
resource. The pub/sub server 200 receives the subscription request
and registers the client's subscription to the tuple. According to
an exemplary embodiment, the application server 300 can host an
application configured to provide the subscription information
associated with the resource to the subscribing client 401 using a
pub/sub protocol via the pub/sub service 200. Note that other
arrangements are contemplated. For example, all messages between
the application server 300 and the pub/sub server 200 can be
exchanged using a request/response (e.g., HTTP) or other
synchronous communication protocol. Alternatively, messages sent
from the pub/sub server 200 to the application server 300 can be
carried using one type of protocol (e.g., request/response or HTTP)
while messages sent from the application server 300 to the pub/sub
server 200 can be carried using a different protocol (e.g.,
presence), and vice versa.
[0025] According to an exemplary embodiment, the pub/sub protocol
used by the subscribing client 401, pub/sub server 200 and
application server 300 is an HTTP pub/sub protocol that uses
existing HTTP methods (or commands) and is consistent with the
presence model and protocol described in RFC 2778, RFC 2779, and
RFC 3921 in terms of features and function. According to the RFCs,
a presence (pub/sub) protocol should support a common set of
commands from a functional standpoint. These functional commands
include: [0026] Publish: Allowing a pub/sub entity, e.g., publisher
server 300 or client 401, to update/provide tuple information to a
pub/sub service 200; [0027] Subscribe (Unsubscribe): Allowing a
pub/sub entity 300, 401 to subscribe or unsubscribe to
notifications related to specific tuple or subtuple data, and
allowing a pub/sub entity 300, 401 to know who is subscribed to the
presence entity's tuple data; and [0028] Notify: Allowing a pub/sub
server 200 to provide information from or about a tuple to a
pub/sub entity 300, 401. Notifications may be targeted to specific
clients by a publisher (e.g., via a directed publish/notify command
as described below) or they may be sent to all subscribers. The
phrase "presence protocol" and "pub/sub protocol", as used here,
includes at least those commands to allow entities to publish
information, notify entities of other entities' information, and
allow entities to subscribe (unsubscribe) to other entities'
information.
[0029] Several optional, functionally equivalent pub/sub commands
also exist. These optional commands include: [0030] Probe: Allowing
a pub/sub service 200 to get information associated with a pub/sub
entity 300, 401. This is equivalent to a Publish command except
that the pub/sub service 200 requests information rather than
having the pub/sub entity send the information unsolicited; [0031]
Directed Publish/Notify: Allowing a pub/sub entity to issue a
publish command that results in a notify command being sent to a
specific pub/sub client, thus bypassing and/or targeting the
subscription function; and [0032] Fetch or Poll: Allowing a pub/sub
entity to request tuple data without registering a
subscription.
[0033] There is also a functional equivalent set of commands for
managing a "friends list" (or "roster") related to pub/sub services
as described in Section 7 of RFC 3921. This set of commands
includes: [0034] Request Roster: Allowing a pub/sub client to
request a specific or default roster; [0035] Add: Allowing a client
to add an item or a pub/sub entity to a roster; [0036] Update:
Allowing a client to update a roster item; and [0037] Delete:
Allowing a client to delete an item from a roster.
[0038] According to an exemplary embodiment, the HTTP pub/sub
protocol described here supports the functional commands described
above by mapping existing HTTP methods (or commands), particularly
those described in RFC 2616 to Fielding et al., titled "Hypertext
Transport Protocol--HTTP/1.1" (June 1999), to pub/sub commands
where the semantics of the pub/sub and existing HTTP methods are
substantially similar. Where a pub/sub command does not have an
HTTP semantic counterpart, the HTTP pub/sub protocol utilizes an
existing HTTP command that is functionally similar and allows the
inclusion of data in an HTTP message in order to support the
pub/sub functionality without introducing a new HTTP method. In one
embodiment, the data identifies a presence command and one or more
associated attributes. The data can be in a header and/or in a
Universal Resource Identifier (URI) reference associated with the
HTTP message.
[0039] Other communications protocols, such as the General Event
Notification Architecture (GENA) and the Rendez Vous Protocol
(RVP), use or are based on HTTP. Nevertheless, both protocols
introduce new HTTP methods/commands not described in RFC 2616 to
handle presence commands that do not have a semantic equivalent in
HTTP. Unlike these communication protocols, which add new commands
and are thus extensions of HTTP, the HTTP pub/sub protocol
according to an exemplary embodiment uses existing HTTP
methods/commands and does not introduce or utilize new HTTP
methods/commands to implement pub/sub capability. By using existing
HTTP methods/commands, an existing web browser on a client device
400 or an existing web server can process the HTTP pub/sub protocol
commands without generating errors because the data that enables
the pub/sub command is included in a header or the URI reference.
According to the HTTP 1.1 specification, if such data is not
identifiable, it can be ignored and the command can be processed as
if unidentifiable data does not exist. With a small modification,
however, HTTP clients and web servers can support traditional
synchronous (e.g., request/response) information exchanges, as well
as asynchronous (pub/sub or presence) information exchanges using
the HTTP pub/sub protocol described here.
[0040] According to an exemplary embodiment, the HTTP pub/sub
protocol supports the fundamental pub/sub commands, PUBLISH,
SUBSCRIBE and NOTIFY, described above in the following manner:
[0041] PUBLISH: To support the PUBLISH command, the HTTP pub/sub
protocol utilizes an HTTP publish request message that includes a
URI to identify a tuple of interest and either an HTTP PUT or POST
method/command. According to RFC 2616, which specifies HTTP version
1.1: [0042] The PUT method requests that the enclosed entity be
stored under the supplied Request-URI. If the Request-URI refers to
an already existing resource, the enclosed entity SHOULD be
considered as a modified version of the one residing on the origin
server. If the Request-URI does not point to an existing resource,
and that URI is capable of being defined as a new resource by the
requesting user agent, the origin server can create the resource
with that URI. [0043] The POST method is used to request that the
origin server accept the entity enclosed in the request as a new
subordinate of the resource identified by the Request-URI in the
Request-Line. POST is designed to allow a uniform method to cover
the following functions: [0044] Annotation of existing resources;
[0045] Posting a message to a bulletin board, newsgroup, mailing
list, or similar group of articles; [0046] Providing a block of
data, such as the result of submitting a form, to a data-handling
process; [0047] Extending a database through an append operation.
Note that the existing HTTP PUT and POST methods are semantically
equivalent to the PUBLISH command. Accordingly, the HTTP pub/sub
protocol can implement the PUBLISH command via a publish request
message that includes either the PUT or POST method. An exemplary
HTTP publish request message according to the HTTP pub/sub protocol
that implements the PUBLISH command follows:
Example 1
TABLE-US-00001 [0048] PUT /TFPS/Catalog/Shoes HTTP/1.1 Host:
some.ps.server User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/plain;q=0.8,video/*,image/png,image/jpeg,\
image/gif;q=0.2,*/*;q=0.1,application/pdif+xml Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7 Content-Type: application/pdif+xml
<?xml version="1.0" encoding="UTF-8"?> <presence
xmlns="urn:ietf:params:xml:ns:pidf"> <status>
<basic>open</basic> </status> <contact
priority="0.8">tel:+09012345678</contact> </tuple>
</presence>
[0049] SUBSCRIBE: Unlike the PUBLISH command, a SUBSCRIBE (and
UNSUBSCRIBE) command does not have an equivalent existing HTTP
method that allows a client to subscribe to notifications related
to specified tuple or subtuple data. The HTTP GET method, however,
performs a similar function but on a one time basis. According to
RFC 2616: [0050] The GET method means retrieve whatever information
(in the form of an entity) is identified by the Request-URI. The
HTTP HEAD method is identical to GET method except that the server
returns metadata about the entity implied by the request without
transferring the entity-body itself.
[0051] According to an exemplary embodiment, to support the
SUBSCRIBE command, the HTTP pub/sub protocol utilizes an HTTP
subscription request message that includes a URI to identify the
tuple of interest, either an HTTP GET or HEAD method/command, and
subscription data that identifies the request message as a
SUBSCRIBE command and identifies one or more attributes associated
with the SUBSCRIBE command.
[0052] In one embodiment, the attributes can include a duration
indicator that defines when the subscription expires. For example,
the duration indicator can be a time period, or a value that
signifies that the subscription lasts so long as the connection or
session is active, or the like. Alternatively, or in addition, the
duration indicator can be a count parameter that indicates that the
subscription expires after the number of notifications equals or
exceeds the count parameter.
[0053] In another embodiment, the attributes associated with the
SUBSCRIBE command can include a subscription identifier. The
subscription identifier allows the subscriber client 401 to specify
an identifier so that responses can be correlated with the original
subscription request associated with the HTTP GET or HEAD
method/command. In one embodiment, the pub/sub server 200 may
override the subscription identifier chosen by the client 401 by
indicating a different subscription identifier in a first response.
Similarly, the pub/sub server 200 may override the duration
attribute and/or provide the duration left in each response.
[0054] In one embodiment, the subscription data identifying the
SUBSCRIBE command is placed in a header in the HTTP request
message. In another embodiment, the subscription data is a
parameter in the URI reference in the HTTP request message.
Exemplary HTTP subscription request messages according to the HTTP
pub/sub protocol that implement the SUBSCRIBE command follow.
Example 2 illustrates an exemplary HTTP subscription request
message with a "subscription" header, and Example 3 illustrates an
exemplary HTTP subscription request message with a "subscription"
parameter URI:
Example 2
TABLE-US-00002 [0055] GET /TFPS/Catalog/Shoes HTTP/1.1 Host:
some.ps.server User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/plain;q=0.8,video/*,image/
png,image/jpeg,image/gif;\ q=0.2,*/*;q=0.1 Accept-Language:
en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Subscription: duration=600s,id=5
Example 3
TABLE-US-00003 [0056] GET
/TFPS/Catalog/Shoes?subscription=true&duration=600s&id=5
HTTP/1.1 Host: some.ps.server User-Agent: Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/ plain;q=0.8,video/*,image/
png,image/jpeg,image/gif;\ q=0.2,*/*;q=0.1 Accept-Language:
en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[0057] In one embodiment, the subscribing client 401 can use
request headers to indicate in which format the tuple data should
be returned to the subscribing client 401. For instance, in the
examples shown above, the client 401 indicates that the tuple data
should be returned as an HTML formatted web page, which may contain
images of various types. Various existing protocols have defined a
number of formats for tuple data, and additional formats can be
created by those familiar with pub/sub (presence) tuples. In
another embodiment, the tuple data can comply by default with the
format described in RFC 3863 to Sugano et al., titled "Presence
Information Data Format" (August 2004), which is incorporated here
in its entirety by reference. Because the PIDF is assigned a MIME
type, `application/pidf+xml`, it is similar to current HTTP content
data and therefore suitable for use with HTTP.
[0058] NOTIFY: Like the SUBSCRIBE command, a NOTIFY command does
not have an equivalent existing HTTP method that allows a pub/sub
server 200 to provide updated information from the tuple to the
client 401. According to an exemplary embodiment of the HTTP
pub/sub protocol, the pub/sub server 200 is configured to generate
HTTP subscription response messages based on the subscription data
associated with the HTTP subscription request message (described
above).
[0059] In one embodiment, each HTTP subscription response message
from the pub/sub server 200 includes the tuple data identified by
the URI in the HTTP subscription request message. The tuple data
can be placed in a payload of the HTTP subscription response
message, and can be formatted in the manner specified by the client
401. Exemplary HTTP response messages to the HTTP subscription
request illustrated in Example 4 follow:
Example 4
TABLE-US-00004 [0060] HTTP/1.1 200 OK Date: Wed, 08 Sep 2004
17:32:31 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/4.1.2
Last-Modified: Wed, 08 Sep 2004 17:02:40 GMT Content-Length: 9119
Subscription: duration=593s,id=5 Content-Type: text/html . . .
HTTP/1.1 200 OK Date: Wed, 08 Sep 2004 17:33:31 GMT Server:
Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/4.1.2 Last-Modified: Wed,
08 Sep 2004 17:02:40 GMT Content-Length: 8942 Subscription:
duration=533s,id=5 Content-Type: text/html
[0061] In another embodiment, the pub/sub server 200 can be
configured to generate an HTTP notify request message that includes
either a PUT or POST method, a URI identifying a tuple in the
client 401 and the updated tuple data. The notify request message
can be sent to the client 401, where the contents of the tuple are
replaced by the updated tuple data according to the PUT or POST
method. In one embodiment, the client 401 is coupled to an HTTP
request handler that is configured to receive and process the HTTP
request message that includes the PUT or POST method, and to
generate an HTTP response message that notifies the client/browser
401 of the updated tuple data. Moreover, the HTTP request handler
can be configured to send a reply to the pub/sub server 200
indicating that it successfully received the HTTP request
message.
[0062] According to RFC 2616, HTTP 1.1 supports a persistent
connection between the client device 400 and the pub/sub server
200. That is, the TCP/IP connection between the client device 400
and the pub/sub server 200 remains open until either the
subscribing client 401 or the server 200 indicates otherwise, e.g.,
via a connection header in the HTTP request message or in the HTTP
response message. In one embodiment, the persistent connection
allows the pub/sub server 200 to traverse one or more firewalls
protecting the client device 400 to transmit HTTP subscription
response messages to the subscribing client 401.
[0063] In one embodiment, a persistent connection is created
between the client device 400 and the pub/sub server 200 each time
the subscribing client 401 sends an HTTP subscription request
message to the server 200. In this embodiment, the persistent
connection is associated with the HTTP subscription request, and
all HTTP subscription response messages correlated to the HTTP
subscription request are sent via the associated persistent
connection. Here, because the persistent connection is associated
with the subscription, a subscription identifier need not be
used.
[0064] In another embodiment, a single persistent connection can be
shared by two or more HTTP subscription requests sent by the
subscribing client 401. According to RFC 2616, persistent
connections allow a client 401 to "pipeline" request messages. That
is, the client 401 can send multiple requests without waiting for
each response. Responses must be received in the order that
requests are sent. This allows responses to be correlated with
requests. For asynchronous communication protocols, notifications
need not be received in a given order. Because notifications in a
pub/sub protocol may be received in an order different than the
order of the subscription requests, a process for correlating
subscription requests and notifications must be provided. In this
embodiment, the subscription identifier associated with a
subscription request is used to correlate an HTTP subscription
response (or notification) with the subscription request. In one
embodiment, the HTTP subscription response includes the
subscription identifier in a header, as shown above.
[0065] In another embodiment, a client device 400 can include two
or more subscribing clients 401 (not shown). For example, a client
device 400 can include an IM client 401, as well as other presence
clients 401 that utilize pub/sub (presence) services. Here, a
single persistent connection can support two or more subscribing
clients 401 by creating a session layer on top of the persistent
connection. Creating the session layer on a persistent connection
allows a subscribing client 401 to create and destroy a session
independent of the connection setup and takedown. The session may
be used to correlate notifications with responses if each session
supports one subscription otherwise the correlation technique
described in the previous paragraph may be used to allow a session
to support multiple subscriptions simultaneously. Without the
session layer, the connection is associated with only one
subscribing client 401, and the start and end of the connection
indicates the start and end of the session. Thus, providing a
session layer allows a single connection between a device and a
pub/sub server to support multiple clients operating on the
device.
[0066] In one embodiment, each subscribing client 401 can create a
session on the persistent connection by adding a session header to
its subscription request message(s). The session header can contain
a suggested session identifier, which the pub/sub server 200 can
accept or replace. Accordingly, each subscription request message
can be associated with a session identifier and a subscription
identifier, which are then used to correlate subscription responses
from the pub/sub server 200.
[0067] According to an exemplary embodiment, the HTTP pub/sub
protocol also supports the optional pub/sub commands, FETCH/POLL,
DIRECTED PUBLISH/NOTIFY, and PROBE, in the following manner:
[0068] FETCH and POLL: To support the FETCH command, the HTTP
pub/sub protocol utilizes an HTTP request message that includes a
URI identifying the tuple of interest and an HTTP GET
method/command. Because the GET method is by definition a one-time
retrieval of the tuple data, a subscription identifier is not
required. In one embodiment, the HTTP request message for the FETCH
command can include subscription data in a header. The duration
attribute can be either a count value of 1 or a time value that is
very short, e.g., a time value of 1 second.
[0069] While existing web pages can use scripts to support polling,
this type of support is unreliable for several reasons: (1) some
clients can disable scripting for security reasons; (2) script
errors can halt script operation, and (3) often times support for a
particular script language in a specific browser is lacking.
According to an exemplary embodiment, clients can natively support
polling by providing support for a FETCH command that takes a time
interval to indicate time between fetch request messages and a
count or time duration to indicate when to stop polling. Examples 5
and 6 illustrate exemplary HTTP fetch request messages with a
"subscription" header and a "subscription" parameter URI set to 1
millisecond resulting in a single response:
Example 5
TABLE-US-00005 [0070] GET /TFPS/Catalog/Shoes HTTP/1.1 Host:
some.ps.server User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/plain;q=0.8,video/*,image/
png,image/jpeg,image/gif;\ q=0.2,*/*;q=0.1 Accept-Language:
en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Subscription: duration=1,id=0X00a1c3
Example 6
TABLE-US-00006 [0071] GET
/TFPS/Catalog/Shoes?subscription=true&duration=1ms&id=10055
HTTP/1.1 Host: some.ps.server User-Agent: Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/ plain;q=0.8,video/*,image/
png,image/jpeg,image/gif;\ q=0.2,*/*;q=0.1 Accept-Language:
en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[0072] DIRECTED PUBLISH: A DIRECTED PUBLISH command does not have
an equivalent existing HTTP method that allows a publishing client
to issue a PUBLISH command which results in a notification to one
or more specific subscriber clients. According to an exemplary
embodiment, to support the DIRECTED PUBLISH command, the HTTP
pub/sub protocol utilizes an HTTP request message that includes a
URI to identify the tuple of interest, a PUT or POST
method/command, and data that identifies the request message as a
DIRECTED PUBLISH command and that identifies the specific clients
to whom the tuple data should be directed.
[0073] In one embodiment, the data identifying the DIRECTED PUBLISH
command can include the URIs of subscriber clients and/or the URIs
of a roster of clients who are to be sent notifications. The
clients may or may not have active subscriptions. In another
embodiment, the data identifying the DIRECTED PUBLISH command is
placed in a header in the HTTP request message. In another
embodiment, the data is in the URI reference associated with the
request message. Example 7 illustrates an exemplary HTTP directed
publish request message with a "directed" header for specifying a
non-subscriber recipient and a "directed-roster" header for
specifying subscriber recipients by roster ID:
Example 7
TABLE-US-00007 [0074] PUT /TFPS/Catalog/Shoes HTTP/1.1 Host:
some.ps.server User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/plain;q=0.8,video/*,image/png,image/jpeg,\
image/gif;q=0.2,*/*;q=0.1,application/pdif+xml Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7 Content-Type: application/pdif+xml
Directed-Roster=15, 2057,6 Directed: special.client.net/sysAdmin
<?xml version="1.0" encoding="UTF-8"?> <presence
xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com"> <tuple id="sg89ae">
<status> <basic>open</basic> </status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple> </presence>
[0075] DIRECTED NOTIFY: A DIRECTED NOTIFY command does not have an
equivalent existing HTTP method that allows a pub/sub server 200 to
issue a NOTIFY command to one or more specific clients. According
to an exemplary embodiment, to support the DIRECTED NOTIFY command,
the HTTP pub/sub protocol utilizes the HTTP subscription response
message described above where the specific client has an existing
subscription to the tuple data of interest. In one embodiment, a
Notify-Direct header can be added to the subscription response
message so that clients can be aware of other clients who were
notified. Exemplary HTTP response messages used as directed
notifies using a "directed" tuple which in a response identifies
the tuple and optionally may identify the publisher (not shown) are
illustrated in Example 8 follow:
Example 8
TABLE-US-00008 [0076] HTTP/1.1 200 OK Date: Wed, 08 Sep 2004
17:32:31 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/4.1.2
Last-Modified: Wed, 08 Sep 2004 17:02:40 GMT Content-Length: 9119
Directed: tuple=/TFPS/Catalog/Shoes Content-Type: text/html . . .
HTTP/1.1 200 OK Date: Wed, 08 Sep 2004 17:33:31 GMT Server:
Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/4.1.2 Last-Modified: Wed,
08 Sep 2004 17:02:40 GMT Content-Length: 8942 Directed:
tuple=/TFPS/Catalog/Shoes Content-Type: text/html
[0077] In another embodiment, where the specific client does not
have an existing subscription for the tuple data of interest, but
does have a subscription for a different tuple, the persistent
connection for the different tuple may be used to send a directed
notify response message to the specific client. In this embodiment,
the directed notify response message includes the Notify-Direct
header to indicate to the specific client the nature of the
response message.
[0078] In another embodiment, where the specific client does not
have an existing subscription for any tuple, the pub/sub server 200
is configured to generate a directed notify request message, which
comprises an HTTP request message that includes an HTTP PUT or POST
method and the tuple contents as its payload. The URI of the
directed notify request message identifies tuple data on the
specific client that is associated with the message. In this
embodiment, the client is coupled to the HTTP request handler,
which is configured to process an HTTP request message and to
generate an HTTP response message for the client/browser 401 as
well as a response to the sender of the HTTP request. based on the
request message including the HTTP PUT or POST method. Where the
specific client is behind one or more firewalls, an existing
connection between the specific client and the pub/sub server 200
is required in order to send the request message. An exemplary HTTP
PUT message used as directed notify using a "directed" tuple which
when received as a notify identifies the tuple and optionally may
identify the publisher (not shown) is illustrated in Example 9.
Example 9
TABLE-US-00009 [0079] PUT /sysAdmin HTTP/1.1 Host:
special.client.net User-Agent: Apache /1.3.27 (Unix)
(Red-Hat/Linux) PHP/4.1.2 Accept: application/pdif+xml
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Directed:
tuple=/TFPS/Catalog/Shoes Content-Type: text/html .
[0080] PROBE: A PROBE command does not have an equivalent existing
HTTP method that allows a pub/sub server 200 to retrieve
information from a publisher client 401 or 300. According to an
exemplary embodiment, the pub/sub server 200 is configured to
generate a probe request message comprising an HTTP GET command. In
this embodiment, the client is configured to handle HTTP request
messages. Where the specific client is behind one or more
firewalls, an existing connection between the specific client and
the pub/sub server 200 is required in order to send the request
message. If the client 401 has an existing connection with the
pub/sub server 200, a probe header may be added to an HTTP response
method associated with an HTTP request method received from the
client 401. Example 10 illustrates an exemplary HTTP GET message
used as PROBE with an optional "probe" header specifying the last
publish received by the server. Example 11 illustrates an exemplary
response to an HTTP request from a publisher in which the server
has added a "probe" header identifying the tuple being probed and
indicating the last update received by the server:
Example 10
TABLE-US-00010 [0081] GET /TFPS/Catalog/Shoes HTTP/1.1 Host:
some.publisher.net Apache /1.3.27 (Unix) (Red-Hat/Linux) PHP/4.1.2
Accept: application/pdif+xml Probe:
last-publish=2006:01:25:03:24:13
Example 11
TABLE-US-00011 [0082] HTTP/1.1 200 OK Date: Wed, 08 Sep 2004
17:33:31 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/4.1.2
Probe: tuple=/TFPS/Catalog/Shoes,last-publish=2006:01:25:03:24:13
Accept:application/pdif+xml
[0083] According to an exemplary embodiment, the HTTP pub/sub
protocol also supports the set of commands for managing a roster
related to pub/sub services, as described in Section 7 of RFC 3921,
by treating rosters and members of rosters as one or more tuples.
As such, the roster data can be managed using the pub/sub commands
supported by the HTTP pub/sub protocol in the following manner:
[0084] REQUEST ROSTER: In one embodiment, the HTTP pub/sub protocol
utilizes a FETCH or SUBSCRIBE command to request a specific or
default roster. That is, the REQUEST ROSTER command is supported by
an HTTP request message that includes an HTTP GET method. Example
12 illustrates an exemplary HTTP subscribe message requesting a
subscription to the roster for tuple /TFPS/Catalog/Shoes:
Example 12
TABLE-US-00012 [0085] GET /TFPS/Catalog/Shoes/Roster HTTP/1.1 Host:
some.ps.server User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/plain;q=0.8,video/*,image/
png,image/jpeg,image/gif;\ q=0.2,*/*;q=0.1 Accept-Language:
en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Subscription: duration=600s,id=5
[0086] ADD: In one embodiment, the HTTP pub/sub protocol utilizes a
PUBLISH command to add a roster or an item to a roster. That is,
the ADD command is supported by an HTTP request message that
includes an HTTP PUT or POST method and the URI of a new roster or
roster member.
[0087] UPDATE: In one embodiment, the HTTP pub/sub protocol
utilizes a PUBLISH command to modify a roster item. That is, the
UPDATE command is supported by an HTTP request message that
includes an HTTP PUT or POST method and the URI of an existing
roster or roster member, carrying the updated data in its payload.
Example 13 illustrates an exemplary HTTP publish message which may
embody both the ADD and UPDATA roster commands. The payload or body
of the HTTP request (not shown) contains the roster item(s) to be
added and/or updated:
Example 13
TABLE-US-00013 [0088] PUT /TFPS/Catalog/Shoes/Roster HTTP/1.1 Host:
some.ps.server User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/plain;q=0.8,video/*,image/png,image/jpeg,\
image/gif;q=0.2,*/*;q=0.1,application/pdif+xml Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7 Content-Type:
application/pdif+xml
[0089] DELETE: The HTTP pub/sub protocol uses an existing HTTP
DELETE method to remove a roster or a member of a roster by using
the URI of the roster tuple or the tuple of the member of the
roster. In another embodiment, the HTTP pub/sub protocol uses a
PUBLISH command with an empty payload and a URI identifying the
roster or roster member. Example 14 illustrates an exemplary HTTP
delete message requesting a deletion of roster item "14" for tuple
/TFPS/Catalog/Shoes. The roster item(s) may be specified as URI
parameters in an alternate embodiment.
Example 14
TABLE-US-00014 [0090] DELETE /TFPS/Catalog/Shoes/Roster/14 HTTP/1.1
Host: some.ps.server User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.4.1) Gecko/20031114 Accept:
text/html;q=0.9,text/plain;q=0.8,video/*,image/png,image/jpeg,\
image/gif;q=0.2,*/*;q=0.1,application/pdif+xml Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7
[0091] As described above, the HTTP pub/sub protocol according to
an exemplary embodiment utilizes existing HTTP methods/commands. By
using existing HTTP methods, the HTTP pub/sub protocol can be used
to support synchronous (e.g., request/response) and asynchronous
(e.g., pub/sub) interactions, thereby replacing a plurality of
incompatible pub/sub protocols and HTTP with a single HTTP
communication protocol.
[0092] Moreover, because the HTTP pub/sub protocol does not
introduce new HTTP methods/commands, existing web browsers and web
servers can, for the most part, process the request and response
messages without interruption. For example, if a header (comprising
the subscription data) is not recognized by the web server or
browser, HTTP 1.1 directs the server or browser to ignore the
header and to continue processing the method/command in the request
message according to normal HTTP rules. That is, a subscription
request message with a GET method and subscription data in a header
is processed by an existing web server as a standard one-time
retrieval of the identified resource. The pub/sub client can still
operate with the web server, but in a more inefficient manner and
with some loss of optional functionality. The pub/sub server can be
operable without using the new header, and indicates it does not
support a header by not returning a corresponding header in
response to a request.
[0093] FIG. 2 is an exemplary block diagram of a pub/sub server 200
according to an exemplary embodiment. The pub/sub server 200
includes an HTTP pub/sub protocol handler component 212 and
protocol stack component 211 coupled to a network connection 210.
The protocol stack component 211 is used to exchange information
received or transmitted at the physical layer (e.g., the wire, air
interface, or fiber optic cable) of the network 120, through the
data link (e.g., ETHERNET, 802.11 WIFI), transport/network (e.g.,
TCP/IP) and application (e.g., XMPP) layers of the stack. The HTTP
pub/sub protocol handler component 212 processes pub/sub commands
received from the network 120.
[0094] The pub/sub server 200 includes a command router 222 that
receives and processes pub/sub commands from the HTTP pub/sub
protocol handler component 212. For example, the command router 222
directs subscribe commands to a subscription manager 224, directs
publish commands to a publication manager 226, and sends notify
commands on behalf of a notifier 223. The command router 222 can
also process other pub/sub commands, such as PROBE and
FETCH/POLL.
[0095] The subscription manager 224 processes subscription requests
and other tasks associated with subscriptions. In one embodiment,
the subscription manager 224 processes a subscription request by
placing the subscribing client 400 on a subscription list
associated with the tuple. In addition, the subscription manager
224 authorizes the client 400, manages rosters and subscription
lists, and uses the notifier 223 to construct notification response
messages informing the application server 300 of subscriptions and
notification response messages informing clients 401 when new
information is available. The publication manager 226 processes
publish commands and coordinates with the subscription manager 244
the publication of tuple data to ensure that subscribing clients
401, if any, are notified via the notifier 223.
[0096] The pub/sub server 200 further includes a tuple manager 228
that is coupled to a tuple store 229. The tuple manager 228 manages
tuples and tuple information. It also manages rosters for security,
if provided, and stores and retrieves tuple data from the tuple
store 229. If the pub/sub server 200 stores published information,
the tuple manager 228 also stores and retrieves the published
information.
[0097] FIG. 3 illustrates an exemplary application server 300
according to one embodiment. In an exemplary embodiment, the
application server 300 is a publisher. That is, the application
server 300 hosts applications 330, 340 that provide information
related to a resource. In one embodiment, the application server
300 can be a web server that supports pub/sub applications 330, as
well as web applications 340. Communications between the
application server 300 and the pub/sub server 200 are conducted via
the HTTP pub/sub protocol. Accordingly, like the pub/sub server
200, the application server 300 includes a network connection 310
coupled to an HTTP pub/sub protocol handler 312 and a protocol
stack component 311.
[0098] In an exemplary embodiment, the application server 300
includes a resource agent component 320 between the HTTP pub/sub
protocol handler 312 and one or more pub/sub applications 330. The
resource agent component 320 is configured to receive notifications
from and to send tuple data to the pub/sub server 200 so that it
can be delivered to one or more subscriber clients 401. In one
embodiment, the resource agent component 320 is configured to
generate the HTTP publish request message associated with updated
tuple data, and to send it to the pub/sub server 200.
[0099] In one embodiment, the resource agent component 320 can
include a watcher component 322 and an associated watcher user
agent (WUA) 323 configured to receive and process notifications
from the pub/sub server 200. The resource agent component 320 can
also include a presentity component 324 and an associated
presentity user agent (PUA) 325 configured to publish tuple data to
the pub/sub server 200. According to an exemplary embodiment, the
resource agent component 320 can also include a service user agent
(SUA) component 326 that interacts with the pub/sub applications
330 as its principal, although the SUA component 326 can also
interact with an owner of the application 330 as well as other
principals.
[0100] In another embodiment, the application server 300 can also
host HTTP web applications 340. In this embodiment, the HTTP
pub/sub protocol handler and protocol stack component 312 is
coupled to one or more of the web applications 340. It should be
understood that while the applications 330 and 340 shown in FIG. 3
are depicted as separate applications, the application server 300
can also host hybrid applications (not shown).
[0101] According to an exemplary embodiment, the application server
300 can exchange information with conventional HTTP web servers
(not shown) and conventional HTTP clients (not shown), and can also
exchange information with a pub/sub client 401 using the HTTP
pub/sub protocol. Thus, the application server 300 can serve
traditional web content that includes tuple information stored on
servers supporting a pub/sub protocol communication model. In this
manner, information on a web page can be updated in real time
without embedding (in the web page) scripts that poll a web site
for updated information. By eliminating scripts, a more robust and
secure mechanism for presenting real-time data in a web page is
provided.
[0102] FIG. 4 illustrates an exemplary subscriber client 401 in a
client device 400 according to an exemplary embodiment.
Communications between the client 401 and the pub/sub server 200
are conducted via the HTTP pub/sub protocol. In one embodiment, the
client 401 is a web browser that includes an HTTP pub/sub protocol
handler 412 and protocol stack component 411. The HTTP presence
protocol handler 412 and protocol stack component 411 are coupled
to a network connection component 410 so that the subscriber client
401 can receive and send messages from and to the pub/sub server
200.
[0103] In one embodiment, the HTTP presence protocol handler 412 is
configured to generate and send HTTP subscription request messages
and to receive HTTP subscription response messages to and from the
pub/sub server 200. As stated above, the HTTP pub/sub protocol
allows the client 401 to indicate in which format the pub/sub
server 200 should return tuple data to the client 401.
[0104] Accordingly, in an exemplary embodiment, the client 401
includes a plurality of content handler components 430 for
processing information in the HTTP response messages. In one
embodiment, each content handler component 430 is similar to
content handlers included in conventional web browsers in that the
content handler component 430 is configured to process information
based on the type of the information routed to the handler
component 430. The type can be any of the number of available
presence Multi-purpose Internet Mail Extensions (or MIME) types,
such as "txt/xmpp-im", "txt/sip-simple" and "application/pidf+xml",
as well as other MIME types, such as the "image/jpeg", "video/wmv",
"audio/midi", and "txt/html".
[0105] In a related embodiment, the client 401 can also include a
content manager component 425 coupled between the HTTP pub/sub
protocol handler 412 and each of the content handler components
430. The content manager component 425 can be configured to route
the information in the payload of the HTTP response message and
other content received via the network connection 410 to at least
one of the content handler components 430 based on the type (e.g.,
the MIME type) of the information and other content received.
[0106] With such an arrangement, the client 401 can exchange
information with conventional HTTP servers, such as a web server
(not shown), using HTTP, and can also exchange information with the
application server 300 using the HTTP pub/sub protocol.
Consequently, portions of the content can be presented/updated
using a single communication protocol that supports both
conventional HTTP signaling, and asynchronous pub/sub signaling. In
this manner, application designers and client users are provided
with maximum flexibility in designing/utilizing their network
services.
[0107] As stated above, the client/browser 401 is configured to
generate and send HTTP subscription request messages and to receive
HTTP subscription response messages to and from the pub/sub server
200. The browser 401, however, is not typically configured to
receive and process HTTP request messages. For example, the HTTP
request messages can correspond to a DIRECTED NOTIFY command
including an HTTP PUT or POST method, a PROBE command, or the like,
as described above.
[0108] To accommodate this function, an HTTP request handler
component 420 is coupled to the HTTP Pub/Sub Protocol Handler 412
and is configured to process HTTP request messages from the pub/sub
server 200. In one embodiment, the HTTP request handler component
420 operates as a pseudo pub/sub server in that it receives the
HTTP request message, generates an HTTP response message
corresponding to the request message, and sends the HTTP response
message to the subscriber client/browser 401. In this manner, the
HTTP request message from the pub/sub server 200 is converted into
an HTTP response message, which the browser 401 is configured to
process. The request handler component 420 can also be configured
to automatically generate an HTTP response message and return the
generated response to the pub/sub server 200 to acknowledge receipt
of the HTTP request (e.g., NOTIFY) message. In some cases, the
automatically generated response may include information associated
with the HTTP request message displayable as a web page for
presentation to the user. Based on the user's activity with respect
to the web page, a response to the HTTP request message can be
generated and processed by the HTTP request handler component 420
for return to the pub/sub sever 200.
[0109] FIG. 5 depicts a flowchart illustrating an exemplary method
for processing a subscription using the HTTP pub/sub protocol
according to an exemplary embodiment. The method can be carried out
using the arrangement described in conjunction with FIGS. 1-4,
portions of which are referenced in the description that follows.
It will be understood that other arrangements can be used to carry
out the described method without departing from the scope of the
described techniques. Descriptions of certain terms, the meanings
of which are described in detail above in conjunction with FIGS.
1-4, are not repeated here.
[0110] Referring to FIGS. 1-5, the exemplary method begins when the
subscriber client 401 generates an HTTP subscription request
message that includes the GET or HEAD method, the URI of a tuple
related to a resource, and the subscription data that identifies
the request message as a SUBSCRIBE command (block 500). Exemplary
HTTP subscription request messages are described and shown above,
e.g., in EXAMPLES 2 and 3. The subscriber client 401 then sends the
HTTP subscription request message to the pub/sub server 200 (block
502).
[0111] In one embodiment, where the client device 400 is protected
by a firewall (not shown), a persistent connection between the
client device 400 and the pub/sub server 200 is created to traverse
the firewall. In one embodiment, the persistent connection can be
associated with the HTTP subscription request message, such that
any HTTP response message returned by the pub/sub server 200 is
sent over the persistent connection. In another embodiment, the
persistent connection is associated with the client 401 and can be
shared by two or more HTTP subscription request messages. In this
embodiment, each HTTP subscription request message can include a
subscription identifier so that HTTP response messages from the
pub/sub server 200 can be correlated to their respective
subscriptions. In yet another embodiment where the client device
400 includes two or more subscriber clients 401, a session layer
can be created on top of the persistent connection so that the
persistent connection can be shared by the clients 401. In this
embodiment, each subscribing client 401 can create a session and
each HTTP subscription request message can include a session
identifier as well as a subscription identifier.
[0112] The pub/sub server 200 receives the subscription request for
the tuple via the HTTP pub/sub protocol handler 212 and protocol
stack component 211 and registers the subscription (block 504). In
one embodiment, the pub/sub server 200 can send a notification of
the subscription to the application server 300 that hosts a pub/sub
application 330 that is configured to provide the tuple data
associated with the resource. Note that If the pub/sub server 200
is not configured to handle the HTTP pub/sub protocol, i.e., it
lacks the HTTP pub/sub protocol handler 212, and does not
understand the subscription data in the subscription request
message, the pub/sub server can ignore the subscription data and
treat the HTTP subscription request message as a conventional HTTP
request message that includes a GET or HEAD method. That is, the
pub/sub server can simply return the tuple data associated with the
URI in response to receiving the subscription request message.
Accordingly, because the HTTP pub/sub protocol utilizes existing
HTTP methods/commands, a conventional HTTP server can handle the
HTTP subscription request message, albeit in a more limited manner,
without issuing an error message.
[0113] Once the subscription to the tuple is registered, the
pub/sub server 200 and the client 401 wait for changes/updates to
the tuple data related to the resource. When the application server
300 detects an event related to the resource associated with the
tuple (block 506) and the event is one that triggers a PUBLISH
command, the application server 300 generates an HTTP publish
request message that includes a PUT method (as shown in Example 1)
or POST method and the updated tuple data in the payload of the
request message (block 508).
[0114] The pub/sub server 200 receives the HTTP publish request
message (block 510) and generates an HTTP subscription response
message associated with the subscription request sent in 502 (see
Example 4) that includes the updated tuple data and optionally the
subscription identifier and/or session identifier (block 512). In
one embodiment, the pub/sub server 200 can format the updated tuple
data in the manner specified by the client 401 in the subscription
request message. If no such specification is made, the default
format can be PIDF, as specified in RFC 3863. Once the HTTP
subscription response message is completed, the pub/sub server 200
sends it to the client 401 (block 514). If the client 401 is behind
a firewall, the subscription response message is sent over the
persistent connection associated with the device 400. The
subscriber client 401 receives the HTTP subscription response
message that includes the updated tuple data (block 516), and waits
for subsequent updates.
[0115] The executable instructions of a computer program as
illustrated in FIG. 5 can be embodied in any computer readable
medium for use by or in connection with an instruction execution
system, apparatus, or device, such as a computer based system,
processor containing system, or other system that can fetch the
instructions from the instruction execution system, apparatus, or
device and execute the instructions.
[0116] As used here, a "computer readable medium" can be any means
that can contain and/or store the program for use by or in
connection with the instruction execution system, apparatus, or
device. The computer readable medium can be, for example, but not
limited to, an electronic, magnetic, optical, electromagnetic,
infrared, or semiconductor system, apparatus, device, or
medium.
[0117] More specific examples (a non-exhaustive list) of the
computer readable medium can include the following: a portable
computer diskette, a random access memory (RAM), a read only memory
(ROM), an erasable programmable read only memory (EPROM or Flash
memory) a portable compact disc (CD), a portable digital video disc
(DVD), and the like.
[0118] Methods for providing an HTTP pub/sub protocol and a system
for supporting such a protocol have been described. In one
embodiment, the HTTP pub/sub protocol uses existing HTTP
methods/commands to implement essential pub/sub commands, such as
PUBLISH, SUBSCRIBE and NOTIFY. Unlike other pub/sub protocols, such
as RVP and GENA, the HTTP pub/sub protocol does not introduce or
utilize new HTTP methods/commands. Thus, existing browsers that
normally can process HTTP messages, can also accept HTTP pub/sub
protocol messages.
[0119] Moreover, by using existing HTTP methods/commands to
implement pub/sub commands, one HTTP-based communication protocol
can be used to support asynchronous and synchronous interactions,
thereby merging the various communications protocols.
Interoperability issues become less complicated because HTTP is
well-known and widely accepted as a standard Internet communication
protocol. Furthermore, existing programming application program
interfaces (APIs) and tools related to HTTP can be easily extended
to support new pub/sub features, rather than requiring the
development of new APIs and tools. Finally, the HTTP pub/sub
protocol is compatible with existing browsers and web servers and
minimal modifications are required to support the new features of
the pub/sub protocol requirements.
[0120] It will be appreciated by those of ordinary skill in the art
that the concepts and techniques described here can be embodied in
various specific forms without departing from the essential
characteristics thereof. The presently disclosed embodiments are
considered in all respects to be illustrative and not restrictive.
The scope of the invention is indicated by the appended claims,
rather than the foregoing description, and all changes that come
within the meaning and range of equivalence thereof are intended to
be embraced.
* * * * *