Method and system for providing data handling information for use by a publish/subscribe client

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND

More and more, users of electronic devices are exchanging digital information asynchronously in substantially real time over the Internet using asynchronous communication protocols. Unlike traditional communication protocols, such as HyperText Transport Protocol (HTTP), the commands of an asynchronous protocol, such as publish/subscribe (pub/sub) communication protocols, are structured such that there need not be a one-to-one correspondence between requests and responses exchanged between the devices. In some cases a sender of information via the protocol need not wait, nor expect a response from, a receiver. Moreover, a receiver need not have sent a request corresponding to each received response. That is, a receiver may receive multiple responses to a single request and/or may receive an unsolicited message from a device. Thus, unlike HTTP where the reply is sent directly (synchronously) and only in response to the entity's request, the information can instead be sent in response to the sender's posting of the information (i.e., asynchronous to the request of information).

According to pub/sub communication protocols, an entity, referred to as a subscriber or subscriber client, is allowed to subscribe to information provided by another entity, referred to as a publisher, via a pub/sub service. Publishers publish to a distinct ID, typically a uniform resource identifier (URI) or uniform resource locator URL (URL), and subscribers subscribe by providing the ID. The publisher posts, i.e., publishes, the information to the pub/sub service identifying the tuple to be created or updated, the service then transmits the published tuple information to all interested parties, i.e., subscribers, via notification messages. The published information can be read simultaneously by any number of subscribers. So long as the subscriber remains subscribed to the information, the subscriber will continue to receive notification messages corresponding to the publisher's postings.

Notably, as is used herein, the term “publish/subscribe” refers to the class of services and associated protocols where a subscriber receives only the most recently published information in a notification message resulting from a subscription. That is, the pub/sub service transmits to the subscriber only the most current state of the published information, and does not queue, or store, previously published data for retrieval when the subscriber is offline or otherwise unsubscribed, such as with email and traditional message queues. Thus, unlike typical message queuing services, when a subscriber logs on or subscribes to the pub/sub service, the subscriber receives only the current state of the information, as well as subsequent updates to the information while the subscriber is subscribed. The subscriber does not receive previous updates that may have occurred while the subscriber was offline or unsubscribed. In addition, the pub/sub services as described herein are not topic based subscription services where typically any number of publishers may contribute to a single subscription. In topic based subscription services, whether a published entity is sent to a subscriber is based on its topic or categorization. Such topic based subscription services are also sometimes referred to as pub/sub services.

Typically, when the subscriber receives a notification message that includes the published information from the pub/sub service, the information is displayed to the subscriber in a certain manner or otherwise handled by a software client on the subscriber's device. Thus, while the information to be handled is dynamic, the manner in which the information is displayed or handled is generally pre-defined and static.

To address this shortcoming, one approach suggests creating a template in response to receiving a subscription request. Nevertheless, this approach merely creates a static template at the pub/sub service. This template cannot be updated dynamically and therefore suffers the same disadvantages. In another approach, processing policies for rendering and for making other data handling decisions are stored at the pub/sub service and implemented at the pub/sub service. Nevertheless, as before, the policies are static and cannot be dynamically fine tuned by a publisher or by a subscriber.

In another approach, rules and attributes associated with user-defined status levels are provided and stored in a single data tuple so that the notification message to the subscriber includes the rules and attributes as well as the user-defined status level. This approach can be extended to placing data handling information in the data tuple along with the published information so that the subscriber can receive both the data handling information and the published information. Nevertheless, this introduces many disadvantages. For instance, because the data handling information can be voluminous compared to just the updated data, the notification messages can be bulky and therefore consume resources. This can be especially problematic for handheld client devices that have limited bandwidth. Moreover, the one-to-one relationship between the data handling information and the data tuple is inefficient when the same data handling information can be used for many data tuples or when many different data handling information sets can be combined and used for one data tuple. In short, each of the approaches above fails to describe a flexible and dynamic way to provide data handling information for use by a pub/sub client to handle data published by the pub/sub service.

SUMMARY

Accordingly, a system and method for providing data handling information for use by a client of a pub/sub service to handle data published by the pub/sub service are described. According to an exemplary embodiment, a method includes receiving a subscription request to a data tuple that includes source data from a client of the pub/sub service. When the request is received, a first subscription is provided for the client to the data tuple and a second subscription, distinct from the first subscription, is automatically provided for the client to a data handling tuple that is associated with the data tuple and that includes data handling information defining how the source data of the data tuple is to be handled by the client. A first notification message including the source data is generated and a second notification message, distinct from the first notification message, is generated that includes the data handling information.

According to another exemplary embodiment, a system is described for providing data handling information for use by a client of a pub/sub service to handle data published by the pub/sub service. The system includes a data store for storing a plurality of data tuples, each of which include source data, and a plurality of data handling tuples, each of which include data handling information defining how source data of an associated data tuple is to be handled by a client of the publish/subscribe service. The system also includes a tuple association handler component configured for managing an association between a data tuple of the plurality of data tuples and at least one of the plurality of data handling tuples, and a subscription handler component for receiving, from a client of the pub/sub service, a subscription request to a data tuple, and configured for providing, in response to the request, a first subscription for the client to the data tuple and for automatically providing a second subscription for the client to a data handling tuple that is associated with the data tuple, where the first subscription is distinct from the second subscription. The system also includes a notification handler component configured for generating, pursuant to the first subscription, a first notification message including the source data and for generating, pursuant to the second subscription, a second notification message including the data handling information, where the first and second notification messages are distinct from one another.

In another exemplary embodiment, a method for handling data from a pub/sub service by a client of the pub/sub service includes sending a subscription request to a pub/sub service to subscribe to a data tuple that includes source data and that is managed by the pub/sub service. In response to the request, a first notification message that includes the source data is received from the pub/sub service pursuant to the subscription to the data tuple. Moreover, a second notification message that includes data handling information defining how the source data of the data tuple is to be handled is received pursuant to a subscription to a data handling tuple that is associated with the data tuple and that includes the data handling information. The data handling information is then used to process the source data.

According to another exemplary embodiment, a system is described for handling data from a pub/sub service by a client of the pub/sub service and includes a watcher component configured for sending a subscription request to a pub/sub service to subscribe to a data tuple including source data managed by the pub/sub service. The system also includes a source data manager component configured for receiving, pursuant to the subscription to the data tuple, and for processing a first notification message including the source data from the publish/subscribe service, a data handling information manager component configured for receiving and processing a second notification message including data handling information defining how the source data of the data tuple is to be handled, where the second notification message is received pursuant to a subscription to a data handling tuple that includes the data handling information, and a data handler component configured for using the data handling information to process the source data.

BRIEF DESCRIPTION OF THE DRAWINGS

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:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an exemplary system according to an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an exemplary pub/sub server according to one exemplary embodiment;

<figref idref="DRAWINGS">FIG. 3</figref> is an exemplary data format of a data handling tuple according to one embodiment;

<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram illustrating an exemplary pub/sub client device according to one exemplary embodiment; and

<figref idref="DRAWINGS">FIG. 5</figref> a flow diagram illustrating a method for providing data handling information for use by a client of a pub/sub service to handle data published by the pub/sub service according to an exemplary embodiment.

DETAILED DESCRIPTION

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.

According to an exemplary embodiment, a method and system for providing data handling information for use by a client of a pub/sub service to handle data published by the pub/sub service is described. A pub/sub communication architecture and its underlying messaging protocol allow published information to be sent to a subscriber as it is received, in many instances, substantially in real-time in relation to the publication of the information. Information is published within the pub/sub communication architecture using a publish command. The published information can then be communicated to a subscriber using a notify command. The notify command can either include the published information or can provide a reference to the published information.

Well known pub/sub communication protocols include presence protocols, such as Extensible Messaging and Presence Protocol: Instant Messaging (XMPP-IM), Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging (SIMPLE), and rendezvous protocol (RVP), which are used by presence services, and Jabber Software Foundation's pub/sub protocol as specified in Jabber Enhancement Proposal (JEP) JEP0060: Publish-Subscribe. The architecture, models, and protocols associated with presence services in general are 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 published and owned by the Internet Society and incorporated here in their entirety by reference.

Generally speaking, one or more pub/sub servers are used to provide pub/sub services. The function of a pub/sub server, however, can be incorporated, either in whole or in part, into other entities. For example, according to the presence service model described in RFC 2778, two distinct agents of a pub/sub, e.g., presence, service client are defined. The first of these agents, called a “presentity” (combining the terms “presence” and “entity”), provides information to be stored and distributed throughout the pub/sub service on behalf of a pub/sub client. The second type of presence agent is referred to as a “watcher”. Watchers receive published information from a pub/sub (presence) service on behalf of a pub/sub (presence) client.

The presence model of RFC 2778 describes two types of watchers, referred to as “subscribers” and “fetchers”. A subscriber requests notification from the presence service of a change in some presentity client's presence information. The presence service establishes a subscription on behalf of the subscriber to a presentity client's presence information, such that future changes in the presentity client's presence information are “pushed” to the subscriber. In contrast, the fetcher class of watchers requests (or fetches) the current value of some presentity client's presence information from the presence service. As such, the presence information can be said to be “pulled” from the presence service to the watcher.

Users of the presence service are referred to in the presence model described in RFC 2778 as principals. Typically, a principal is a person or group that exists outside of the presence model, but can also represent software or other services capable of interacting with the presence service. A principal can interact with the presence system through a presence user agent (PUA) or a watcher user agent (WUA). As in the case of the presentity and watcher clients with which these service clients interact, the presence and watcher user agents can be combined functionally as a single user agent having both the characteristics of the presence and watcher user agents. User agents can be implemented such that their functionality exists within a presence service, external to a presence service, or a combination of both. Similar statements can be made about presentities and watchers.

By way of example, aspects of an exemplary embodiment described here can employ a presence protocol as the pub/sub communication protocol. It should be understood, however, the relevant techniques described here can be performed using any pub/sub communications protocol as defined herein. Additionally, the exemplary embodiment described herein is not limited to the use of a pub/sub protocol for all communications described. Other known protocols, e.g., Hypertext Transfer Protocol (HTTP), can also be used.

According to pub/sub communication protocols, the pub/sub service stores and organizes information provided by the publisher and by the subscriber in data entities referred to as tuples. A tuple, in its broadest sense, is a data object containing one or more elements. For example, a presence service manages presence tuples, each of which contain a status element that stores presence information relating to the principal associated with the presence tuple. Tuples can include other elements that can store other published information associated with the principal. The published information may include general contact information of the publisher, such as name, telephone number, email address, postal address, an IP address or URLs associated with the publisher, and the like, as well as other data or content. As used here, the tuple can also be a representation that maps field names to certain values to indicate that an entity or object (e.g., the principal) includes certain components, information, and/or perhaps has certain properties.

As stated above, a client of a pub/sub service can subscribe to a tuple and receive information published to that tuple pursuant to the subscription. The client typically handles the information received from the pub/sub service in a fixed manner according to the client's data handling instructions. Thus, while the information received can be dynamic and from more than one source, the data handling instructions are static.

According to an exemplary embodiment, data handling information can be stored in a data handling tuple and managed by a pub/sub service. The data handling tuple can be associated with one or more data tuples, each of which includes source data. In one embodiment, the data handling tuple includes information defining how the source data of the associated data tuple is to be handled by a client that receives the source data. In one embodiment, when a client subscribes to a data tuple, a subscription to the associated data handling tuple can also be provided automatically such that the client receives both the source data of the data tuple and the data handling information of the data handling tuple. In an exemplary embodiment, the client is configured to use the data handling information to process the source data.

By storing data handling information in data handling tuples, flexible relationships can be established between data tuples and data handling tuples. For example, one data tuple can be associated with several data handling tuples, several data tuples can be associated with one data handling tuple, or several data tuples can be associated with several data handling tuples. In addition, the data handling information in a data handling tuple can easily be updated by a client and the updated handling information can be distributed to all current subscribers via the pub/sub service. Thus, the handling instructions can be dynamic and easily distributed.

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an exemplary system according to one embodiment. The system <b>100</b> includes a plurality of client devices <b>400</b> in communication with a server <b>200</b> that hosts a pub/sub service <b>220</b>. Example types of such devices include a camera phone, a personal digital assistant (PDA), a personal computer (PC), a network-enabled camera, and the like. Each device <b>400</b> includes at least one pub/sub client <b>410</b>, such as a subscriber client, that is configured to communicate with the pub/sub service <b>220</b> using a pub/sub communication protocol. In one embodiment, the subscriber client <b>410</b> can be a subscription browser, as disclosed in 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 commonly owned with the present application and herein incorporated by reference.

In one embodiment, the client devices <b>400</b> are configured to communicate with each other and with at least one the pub/sub server <b>200</b>, <b>200</b><i>a </i>via a network <b>110</b>, such as the Internet. As is shown, a proxy service <b>152</b> hosted by a server <b>150</b> serves as a proxy among the devices <b>400</b> in the network <b>110</b>. The proxy service <b>152</b> permits the devices <b>400</b> and the pub/sub service(s) <b>220</b>, <b>200</b><i>a </i>to communicate with one another through a firewall <b>204</b> in a known manner. In one embodiment, the proxy service <b>152</b> can be associated with the pub/sub service <b>220</b>, <b>220</b><i>a</i>, and/or associated with at least one of the client devices <b>400</b>. While shown residing in a separate server <b>150</b>, the proxy service <b>152</b> can also reside in the pub/sub server <b>200</b>, <b>200</b><i>a</i>. In addition, while only one proxy service <b>152</b> is shown in <figref idref="DRAWINGS">FIG. 1</figref>, a plurality of proxies <b>152</b> can be implemented to handle network access to and from client devices <b>400</b> that are protected by one or more firewalls <b>204</b>.

As is shown, the pub/sub server, e.g., <b>200</b>, hosts the pub/sub service <b>220</b>. The pub/sub service <b>220</b> is configured to process subscriptions by pub/sub clients <b>410</b> to information published by other pub/sub clients <b>410</b>. In an exemplary embodiment, tuple data and subscription information can be stored in a tuple data store <b>240</b> and a subscription data store, <b>230</b> respectively. The data stores <b>230</b>, <b>240</b> can include files, in memory caches, and databases, for example. In one embodiment, all data can be treated as tuple data meaning that it can be formatted for transfer using a data format compatible with the pub/sub communication protocol supported by the pub/sub service <b>220</b>. While the tuple data store <b>240</b> is shown separate from the subscription data store <b>230</b>, the tuple data and the subscription information can also be stored in a single data store. Moreover, although the data stores <b>230</b>, <b>240</b> are depicted as having a particular location remote from the devices <b>400</b>, nothing prevents them from being stored in another location. For example, all or a portion of the information may be stored in a memory structure (not shown) on the devices <b>400</b> or on another memory structure (not shown).

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary pub/sub server <b>200</b> according to one embodiment. The server <b>200</b> includes a pub/sub protocol stack component <b>211</b> coupled to a network stack component <b>210</b>. The network stack component <b>210</b> 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 <b>110</b>, 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 pub/sub protocol stack component <b>211</b> processes pub/sub commands received from the network <b>110</b> and passes the commands to the pub/sub service <b>220</b>.

The pub/sub service <b>220</b> includes a command router <b>222</b> configured to receive and process pub/sub commands from the pub/sub protocol stack component <b>211</b>. In one embodiment, the command router <b>222</b> directs subscribe commands to a subscription handler <b>224</b> that is configured to handle subscribe commands, directs publish commands to a publication handler <b>226</b> that is configured to handle publish commands, and sends notify commands on behalf of a notification handler <b>223</b>. The command router <b>222</b> can also be configured to process other pub/sub commands, such as PROBE and FETCH/POLL.

The subscription handler <b>224</b> processes subscribe commands and other tasks associated with subscriptions. In one embodiment, the subscription handler <b>224</b> processes a subscribe command by placing a subscribing client <b>410</b> on a subscription list associated with the tuple. In addition, the subscription handler <b>224</b> authenticates and authorizes the client <b>410</b>, manages rosters and subscription lists, and uses the notification handler <b>223</b> to construct notification response messages informing clients <b>410</b> when new information is available. The publication handler <b>226</b> processes publish commands and coordinates with the subscription handler <b>224</b> the publication of tuple data to ensure that subscribing clients <b>410</b>, if any, are notified via the notification handler <b>223</b>.

In one embodiment, the pub/sub service <b>220</b> is configured to host one or more service applications <b>250</b> via a service application programming interface (API) <b>235</b>. Such a configuration is described in co-pending U.S. patent application Ser. No. 11/323,762 entitled “METHOD AND APPARATUS FOR PROVIDING CUSTOMIZED SUBSCRIPTION DATA,” filed on Dec. 30, 2005, and commonly owned with the present application and herein incorporated by reference. In one embodiment, the service API <b>235</b> enables the pub/sub service <b>220</b> to pass subscription notification messages to any one of the service applications <b>250</b>. Because the service API <b>235</b> is independent of both the transport and pub/sub protocol, messages can be exchanged freely and securely between the pub/sub service <b>220</b> and any of the service applications <b>250</b>.

The pub/sub service <b>220</b> also includes a tuple manager <b>228</b> for managing data tuples <b>255</b>, data handling tuples <b>300</b>, and published information in the tuples <b>255</b>, <b>300</b>. In one embodiment, the tuple manager <b>228</b> can be configured also to manage rosters for security purposes and to store and to retrieve tuple data from the tuple store <b>240</b>. If the pub/sub service <b>220</b> archives published information, the tuple manager <b>228</b> can also be configured to archive and to retrieve the archived published information.

In an exemplary embodiment, the pub/sub service <b>220</b> includes means for providing a data handling tuple <b>300</b> that includes data handling information that defines how source data of a data tuple <b>255</b> is to be handled by a client <b>410</b> that receives the source data. For example, the publication handler <b>226</b> described above can be configured to perform this task. <figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary data model of a data handling tuple <b>300</b> according to one embodiment. The data handling tuple <b>300</b> can include a data handling information element <b>310</b> and a correlation value element <b>320</b>. According to an exemplary embodiment, a client <b>410</b> can publish data handling information to the data handling information element <b>310</b> using a pub/sub communication protocol.

In one embodiment, the data handling information can include display actions, which can be simple or complex, and can vary according to the client device <b>400</b> associated with the client <b>410</b>. For example, display actions can instruct the receiving client <b>410</b> to: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0039">display the temperature when the application is minimized;</li><li id="ul0002-0002" num="0040">cycle through the DOW, NASDAQ, and S&amp;P 500 when the application is minimized; and</li><li id="ul0002-0003" num="0041">pop the display window to the top window when a weather, traffic, stock or other important alert is received.</li></ul></li></ul>

Other examples of data handling information can relate to the storage of the source data on the client device <b>400</b>, accessing additional information or services to complete the processing, suppressing an action on the data, rules for processing the data, or any other action that is triggered by the receipt of an updated data tuple <b>255</b>.

According to an exemplary embodiment, the data handling information element <b>310</b> can include a program module element <b>312</b> that can store at least one of an executable program block, a script, and an identifier of a program module executable. In one embodiment, the identifier can be a uniform resource identifier (URI) or locator (URL) that can be used to retrieve the program module executable. In another embodiment, the data handling information element <b>310</b> can also include at least one of a template element <b>314</b> for storing a template, a parameters element <b>316</b> for storing customization parameters and a rule element <b>319</b> for storing a rule.

According to one exemplary embodiment, the client <b>410</b> can be a generic pub/sub client <b>410</b> that is configured to support any type of data so that new data types can be provided without necessarily modifying the client <b>410</b>. In this embodiment, the data handling information element <b>310</b> can include a user interface element <b>318</b> that stores instructions defining a user interface or a reference to such instructions. In this embodiment, a user interface for a generic pub/sub client can be defined using user interface markup languages, which are often based on Extensible Markup Language (XML). Examples of XML-based user interface markup languages include XUL (the XML User Interface Language) and XAML (Extensible Application Markup Language). The pub/sub client <b>410</b> can replace variables in the user interface definition with the updated or current source data values of the data tuple <b>255</b>.

For example, parsed, general XML entities could be used in the user interface markup that reference parsed general entities using an ampersand (&amp;) and semicolon (;) as delimiters. Thus, if the user interface markup requires the current temperature in Fahrenheit, it could refer to the temperature as &amp;tempFahrenheit; and the corresponding source data value received in the most recent data tuple <b>255</b> can replace the referenced entity. In one embodiment, the data tuple <b>255</b> can be formatted so that a file Document Type Definition (DTD) can easily be created and the data substitution can take place automatically, using an XML processor, but other techniques are equally acceptable. For example, if the user interface markup uses a script, then properties files created from the received data tuple <b>255</b> can be used in addition to or instead of parsed entities.

According to an exemplary embodiment, the correlation value element <b>320</b> can store a correlation value. In one embodiment, the correlation value can be used to associate the data handling tuple <b>300</b> with one or more data tuples <b>255</b> that share the same correlation value.

The data handling tuple <b>300</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> and described above is an exemplary data model. Those skilled in the art would readily recognize that the data handling tuple <b>300</b> can, and most likely would, include additional elements and/or sub-tuples. For example, the data handling tuple <b>300</b> can include a status element and contact information, as well as other information. Accordingly, the description above should not be interpreted as limiting the structure of the data handling tuple <b>300</b>.

Referring again to <figref idref="DRAWINGS">FIG. 2</figref>, according to an exemplary embodiment, the pub/sub service <b>220</b> includes means for managing associations between data tuples <b>255</b> and data handing tuples <b>300</b>. For example, the pub/sub service <b>220</b> can include a tuple association handler component <b>260</b> to perform this function. In one embodiment, the tuple association handler component <b>260</b> is configured to update and manage association information between a given data tuple <b>255</b> and at least one data handling tuple <b>300</b>. The association information can be stored in an association store <b>270</b> which is accessible by the tuple association handler component <b>260</b>. In an exemplary embodiment, associations between data tuples <b>255</b> and data handling tuples <b>300</b> can be flexible in that a plurality of data tuples <b>255</b> can be associated with a single data handling tuple <b>300</b>, a single data tuple <b>255</b> can be associated with a plurality of data handling tuples <b>300</b>, or a single data tuple <b>255</b> can be associated with a single data handling tuple <b>300</b>.

In one embodiment, the tuple association handler component <b>260</b> can determine which, if any, data handling tuples <b>300</b> are associated with a given data tuple <b>255</b> when the subscription handler <b>224</b> receives a new subscription to the data tuple <b>255</b>. If a data handling tuple <b>300</b> is determined, the tuple association handler component <b>260</b> can retrieve and provide information relating to the data handling tuple <b>300</b> so that a subscription to the data handling tuple <b>300</b> can be provided.

In one embodiment, the pub/sub service <b>220</b> includes means for receiving a subscription request from a pub/sub client <b>410</b> to a data tuple <b>255</b> that includes source data, means for providing, in response to the request, a first subscription for the client <b>410</b> to the data tuple <b>255</b>, and means for automatically providing a second subscription for the client <b>410</b> to a data handling tuple <b>300</b> that is associated with the data tuple <b>255</b>. In one embodiment, the subscription handler <b>224</b>, described above, can be configured to perform these functions.

In addition, the pub/sub service <b>220</b> includes means for generating a first notification message including source data pursuant to a subscription to a data tuple <b>255</b>, and means for generating a second notification message that includes the data handling information pursuant to a subscription to a data handling tuple. For example, the notification handler <b>223</b>, described above, can be configured to generate the first and second notification messages. Moreover, the notification handler <b>223</b> can be configured to send via the command router <b>222</b> the first and second notification messages to a pub/sub client <b>410</b> that subscribes to the data tuple <b>255</b> and which is automatically subscribed to the data handling tuple <b>300</b>.

<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram illustrating an exemplary client device <b>400</b> according to one embodiment. The client device <b>400</b> includes the pub/sub client <b>410</b> that is configured to communicate with the pub/sub service <b>220</b> using a pub/sub communication protocol. In one embodiment, the pub/sub client <b>410</b> can send and receive information to and from the pub/sub server <b>200</b> via a pub/sub protocol layer <b>404</b> and a network stack component <b>402</b>. The network stack component <b>402</b> is used to exchange information received or transmitted at the physical layer of the network <b>110</b>, through the data link, transport/network and application layers of the stack. The pub/sub protocol layer <b>404</b> processes messages received from the pub/sub server <b>200</b> over the network <b>110</b>.

The client device <b>400</b> includes a watcher component <b>412</b> and a watcher user agent (“WUA”) <b>414</b> associated with the pub/sub client <b>410</b>. In one embodiment, the watcher component <b>412</b> translates requests between the pub/sub server <b>200</b> and the WUA <b>414</b>, that is, it translates between the pub/sub communication protocol of the server <b>200</b> and the data format used by the WUA <b>414</b> (typically proprietary). The watcher component <b>412</b> serves watching/subscribing clients <b>410</b> by sending, for example, subscribe commands on behalf of the WUA <b>414</b> and by routing notification messages to the WUA <b>414</b>.

The WUA <b>414</b> can be integrated into the client <b>410</b> (as shown) or external to the client <b>410</b>. In one embodiment, the WUA <b>414</b> is configured to translate between a data format known to the watcher component <b>412</b> and WUA <b>414</b> and a data format known to the client <b>410</b>. The WUA <b>414</b> also is configured to route messages between the client <b>410</b> and the watcher component <b>412</b>. For example, the WUA <b>414</b> can send subscribe requests to the watcher component <b>412</b> on behalf of the client <b>410</b> and can pass notification messages received from the watcher component <b>412</b> to the client <b>410</b> for processing.

According to one embodiment, the pub/sub client <b>410</b> includes means for sending a subscription request to the pub/sub service <b>220</b> to subscribe to a data tuple <b>255</b> that includes source data and means for receiving and processing a notification message that includes the source data from the pub/sub service <b>220</b>. For example, in one embodiment, the pub/sub client <b>410</b> can include a source data manager component <b>416</b> to perform these functions. The source data manager component <b>416</b> can store, update and retrieve the source data received pursuant to subscriptions to data tuples <b>255</b> in a source data store <b>417</b>.

In an exemplary embodiment, the pub/sub client <b>410</b> also includes means for receiving and processing a notification message that includes data handling information, such as a data handling information manager component <b>418</b>. In one embodiment, the data handling information manager component <b>418</b> can process the data handling information by downloading an executable program module or changing a font used to display text. The data handling information can be stored and retrieved in a handling information store <b>419</b>.

In one embodiment, the pub/sub client <b>410</b> also includes means for using the data handling information to process source data corresponding to a data tuple <b>255</b> associated with the data handling information. For example, the pub/sub client <b>410</b> can include a data handler component <b>420</b> to perform this task. According to one embodiment, when updated source data is received, the data handler component <b>420</b> can handle, e.g., display on a user interface <b>430</b>, the source data in accordance with the current data handling information. In another embodiment, when updated or new data handling information is received and processed, the data handler component <b>420</b> can update, i.e., refresh, how the current source data is being displayed. For example, when the client <b>410</b> is currently displaying weather data and a new skin is provided via new data handling information, the data handler component <b>420</b> can apply the new skin immediately to the current source data displayed. When, however, the source data has already been handled, for example by storing or forwarding, then the updated client data handling information can be applied to the next update to the source data.

<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram illustrating a method for providing data handling information for use by a client <b>410</b> of a pub/sub service <b>220</b> to handle data published by the pub/sub service <b>220</b> according to an exemplary embodiment. Referring to <figref idref="DRAWINGS">FIGS. 1-5</figref>, the method begins when the pub/sub client <b>410</b> sends a subscription request to the pub/sub service <b>220</b> to subscribe to a data tuple <b>255</b> (block <b>500</b>). As stated above, the data tuple <b>255</b> includes source data and is managed by the pub/sub service <b>220</b>. In one embodiment, the subscription request can include an identifier that identifies the data tuple <b>255</b>. In another embodiment, the subscription request can also include other information such as information relating to at least one of the client device <b>400</b> and its capabilities, an identifier of a user of the client <b>410</b>, and preferences of the client <b>410</b>. The source data manager component <b>416</b> generates the subscription request and uses the WUA <b>414</b> and watcher component <b>412</b> to transmit the request to the pub/sub service <b>220</b> via the pub/sub protocol layer <b>404</b> and network protocol stack <b>402</b> using a pub/sub communication protocol.

The pub/sub service <b>220</b> receives the subscription request to the data tuple <b>255</b> (block <b>502</b>) and proceeds to process the request. For example, when the subscription request is received at the pub/sub service <b>220</b>, it is routed by the command router <b>222</b> to the subscription handler <b>224</b>. In response to the request, the subscription handler <b>224</b> provides a first subscription for the client <b>410</b> to the data tuple <b>255</b> identified in the request (block <b>504</b>).

According to an exemplary embodiment, the subscription handler <b>224</b> also automatically provides a second subscription for the client <b>410</b> to a data handling tuple <b>300</b> that is associated with the data tuple <b>255</b> (block <b>506</b>). As stated above, the data handling tuple <b>300</b> includes data handling information that defines how the source data of the data tuple <b>255</b> is to be handled by the client <b>410</b>. In one embodiment, the first subscription to the data tuple <b>255</b> is distinct from the second subscription to the data handling tuple <b>300</b>.

In one embodiment, the subscription handler <b>224</b> automatically provides the second subscription by invoking the tuple association handler component <b>260</b> and passing it the identifier associated with the data tuple <b>255</b>. The tuple association handler component <b>260</b> can use the data tuple identifier to access the association store <b>270</b> and determine which, if any, data handling tuples <b>300</b> are associated with the data tuple <b>255</b>. As stated above, the association store <b>270</b> includes association information between data tuples <b>255</b> and data handling tuples <b>300</b>. In one embodiment, the data tuples <b>255</b> can include correlation values that indicate with which data handling tuples <b>300</b> each data tuple <b>255</b> is associated. Thus, the association between the data tuple <b>255</b> and the data handling tuple <b>300</b> can be based on shared correlation values.

In another embodiment, the subscription handler <b>224</b> can also pass to the tuple association handler component <b>260</b> information relating to the device capabilities of the subscribing client <b>410</b>, a user identifier of the subscribing client <b>410</b>, and/or preferences of the subscribing client <b>410</b> in addition to the data tuple identifier. In this embodiment, the subscription request from the subscribing client <b>410</b> can include such device specific, user specific and client specific information. Thus, when the data tuple <b>255</b> is associated with a plurality of data handling tuples <b>300</b>, the tuple association handler component <b>260</b> can be configured to use this additional information as a filtering mechanism to select at least one of the plurality of associated data handling tuples <b>300</b>. For example, when a user subscribes to weather data tuple from a particular handheld device <b>400</b>, the tuple association handler component <b>260</b> can select an associated data handling tuple <b>300</b> that includes handling instructions optimized for that handheld device <b>400</b>. When another user subscribes to the same weather data tuple <b>255</b> from a desktop computer <b>400</b>, the tuple association handler component <b>260</b> can select a different data handling tuple <b>300</b> that includes handling instructions better suited to the desktop computer <b>400</b>.

When the tuple association handler component <b>260</b> determines one or more data handling tuples <b>300</b> associated with the data tuple <b>255</b>, it can pass this information back to the subscription handler <b>224</b>. In another embodiment, the tuple association handler component <b>260</b> can be bypassed when the data tuple <b>255</b>, itself, includes an element that contains a reference to one or more data handling tuples <b>300</b>, or when the association is provided through a naming convention. In this case, the subscription handler <b>224</b> can determine the association without invoking the tuple association handler component <b>260</b>, and then automatically subscribe the pub/sub client <b>410</b> to the associated data handling tuple(s) <b>300</b>.

In one embodiment, the associated data handling tuple <b>300</b> and the data tuple <b>255</b> can be managed by the same pub/sub service <b>220</b>. In another embodiment, the associated data handling tuple <b>300</b> can be managed by a different pub/sub service <b>220</b><i>a </i>than that managing the data tuple <b>255</b>. In this embodiment, the subscription handler <b>224</b> can be configured to send, on behalf of the subscribing client <b>410</b>, a subscription request for the data handling tuple <b>300</b> to the other pub/sub service <b>220</b><i>a</i>. The other pub/sub service <b>220</b><i>a </i>can then process the subscription request according to standard and known methods.

As stated above, the first subscription to the data tuple <b>255</b> is distinct from the second subscription to the data handling tuple <b>300</b>. Thus, each subscription operates independently from the other. When either tuple <b>255</b> or <b>300</b> is updated, the pub/sub service <b>220</b> will send a notification message informing the subscribing client <b>410</b> of the newly published information. In one embodiment, the exception to this independence is when the subscribing client <b>410</b> cancels its subscription to the data tuple <b>255</b>. Here, the subscription to the associated data handling tuple <b>300</b> can also be cancelled.

According to an exemplary embodiment, once the client <b>410</b> is subscribed to the data tuple <b>255</b> and to at least one data handling tuple <b>300</b>, the notification handler <b>223</b> generates, pursuant to the first subscription to the data tuple <b>255</b>, a first notification message that includes the source data (block <b>508</b>) and generates, pursuant to the second subscription to the data handling tuple <b>300</b>, a second notification message that includes the data handling information (block <b>510</b>). In one embodiment, the first notification message can include the data tuple <b>255</b>, and the second notification message can include the data handling tuple <b>300</b>. Both notification messages are sent independently of one another and in no particular order to the subscribing client <b>410</b> by the command router <b>222</b> via the pub/sub protocol stack <b>211</b> and network stack <b>210</b> using the pub/sub protocol.

In one embodiment, an on-the-wire format for the data handling tuple <b>300</b> and the data tuple <b>255</b> can be based on the general purpose Jabber pub/sub protocol defined in XEP-0060: Publish-Subscribe (http://www.xmpp.org/extensions/xep-0060.html). For instance, in Example 1, below, a notification message includes a data handling tuple <b>300</b> that provides parameters for displaying weather source data.

EXAMPLE 1

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>&lt;message from=‘pubsub.exampleHandlerService.net’</entry></row><row><entry /><entry> to=‘bob@example.com’ id=‘foo’&gt;</entry></row><row><entry /><entry> &lt;event xmlns=‘http://jabber.org/protocol/pubsub#event’&gt;</entry></row><row><entry /><entry>  &lt;items node=‘weather_data_handler’&gt;</entry></row><row><entry /><entry>   &lt;item id=‘0123456789’&gt;</entry></row><row><entry /><entry>    &lt;dataHandler</entry></row><row><entry /><entry>    xmlns=’http://www.example.net/weatherHandlerParms’&gt;</entry></row><row><entry /><entry>     &lt;correlation&gt;weather&lt;/correlation&gt;</entry></row><row><entry /><entry>     &lt;minimize&gt;tempFahrenheit&lt;/minimize&gt;</entry></row><row><entry /><entry>     &lt;pop&gt;severeWeatherAlert&lt;/pop&gt;</entry></row><row><entry /><entry>     &lt;skin&gt;default&lt;/default&gt;</entry></row><row><entry /><entry>    &lt;/dataHandler&gt;</entry></row><row><entry /><entry>   &lt;/item&gt;</entry></row><row><entry /><entry>  &lt;/items&gt;</entry></row><row><entry /><entry> &lt;/event&gt;</entry></row><row><entry /><entry>&lt;/message&gt;</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The “dataHandler” element provides an example schema for the data handling tuple <b>300</b> where the namespace is “weatherHandlerParms,” informing the subscribing client <b>410</b> that this data handling tuple <b>300</b> defines handling for weather source data. A correlation element is used by the subscribing client <b>410</b> to correlate the notification message including the source data with the associated notification message including the data handling information. Both messages can carry the same correlation value, e.g., “weather.” The content of the minimize element is “tempFahrenheit,” indicating to the subscribing client <b>410</b> that when the application is minimized the temperature source data should be displayed in the application icon. The content of the pop element is “severeWeatherAlert,” indicating to the subscribing client <b>410</b> that if severe weather alert data is received, then a popup window should be created. The content of the skin element is “default,” indicating to the subscribing client <b>410</b> that it should use the default skin for the application window.

In Example 2 below, a notification message includes a weather data tuple <b>255</b> to which the data handling tuple <b>300</b>, in Example 1, would be applied.

EXAMPLE 2

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>&lt;message from=‘pubsub.exampleDataService.net’</entry></row><row><entry>to=‘bob@example.com’ id=‘foo’&gt;</entry></row><row><entry> &lt;event xmlns=‘http://jabber.org/protocol/pubsub#event’&gt;</entry></row><row><entry>  &lt;items node=‘weather_data’&gt;</entry></row><row><entry>   &lt;item id=‘0987654321’&gt;</entry></row><row><entry>    &lt;data xmlns=’http://www.example.net/weatherData’&gt;</entry></row><row><entry>     &lt;correlation&gt;weather&lt;/correlation&gt;</entry></row><row><entry>     &lt;usesDataHandler&gt;yes&lt;/usesDataHandler&gt;</entry></row><row><entry>     &lt;weatherArea&gt;Cary, NC&lt;/weather Area&gt;</entry></row><row><entry>     &lt;tempFahrenheit&gt;78&lt;/tempFahrenheit&gt;</entry></row><row><entry>     &lt; severeWeatherAlert &gt;Severe thunderstorm warning until</entry></row><row><entry>     7:00 PM</entry></row><row><entry>    &lt;/severeWeatherAlert&gt;</entry></row><row><entry>     &lt;humidity&gt;65&lt;/ humidity &gt;</entry></row><row><entry>     &lt;windMPH&gt;15&lt;/windMPH&gt;</entry></row><row><entry>    &lt;/data&gt;</entry></row><row><entry>   &lt;/item&gt;</entry></row><row><entry>  &lt;/items&gt;</entry></row><row><entry> &lt;/event&gt;</entry></row><row><entry>&lt;/message&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The “usesDataHandler” element is used to inform the subscribing client <b>410</b> whether this data tuple <b>255</b> is associated with a data handling tuple <b>300</b>. In this example, the value of “yes” indicates that it is, and that this source data should be processed by the subscribing client <b>410</b> in accordance with the data handling instructions contained in the associated data handling tuple <b>300</b>. Note that the correlation element includes the value “weather,” which matches the correlation value in the notification message in Example 1.

In an exemplary embodiment, the data tuple <b>255</b> and data handling tuple <b>300</b> are compatible with the subscribing client <b>410</b>. The client <b>410</b> can be configured in multiple ways, e.g., it can be a specialized client that handles a fixed set of data types (e.g., weather and news), or it can be a generic client that handles any type of data. In one embodiment, a specialized client <b>410</b> can be written to handle a specific type of data, such as weather. The data tuple <b>255</b> to which the client <b>410</b> subscribes would contain weather information, such as temperature and wind speed, as shown in Example 2 above.

The behavior of the client <b>410</b> can be parameterized and the parameters can be provided in the data handling tuple <b>300</b>, as shown in Example 1 above. Thus, for example, the client <b>410</b> would understand the “weatherArea” parameter in the data tuple <b>255</b> and display it in the correct place on the user interface <b>430</b> using the correct font, size and color, which could all be specified in the data handling information if desired by the application developer. In the above examples, the client <b>410</b> understands certain parameters that are provided in the data handling information.

Other techniques for providing the data handling information to the client <b>410</b>, such as templates or executables, could also be used instead of, or in conjunction with, the use of parameters. For example, the data handling tuple <b>300</b> can include an executable program module, or a reference to such a module, that is to be downloaded and/or installed by the client <b>410</b>. In another embodiment, the data handling tuple <b>300</b> can include multipart data of different formats. This can be accomplished by using Multipurpose Internet Mail Extension (MIME) formatting. Extensions to Jabber-XML to support MIME are described in the document to Robinson et al., titled “Multipurpose Internet Mail Extensions within Jabber-XML—A recommended practice specification for encoding MIME into the Jabber-XML protocol” (Core Jabber Group, 1999), accessible via the Internet at URL: “http://www.jabber.org/old-core/MIME.html” on Dec. 8, 2006.

In Example 3, below, a notification message includes a data handling tuple <b>300</b> that has a reference to data handling information, which the client <b>410</b> can then use to retrieve the data handling information. The data handling information, for example, can be an executable file that when retrieved and installed would update the data handling function of the client <b>410</b>.

EXAMPLE 3

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>&lt;message from=‘pubsub.exampleHandlerService.net’</entry></row><row><entry>to=‘bob@example.com’ id=‘foo’&gt;</entry></row><row><entry> &lt;event xmlns=‘http://jabber.org/protocol/pubsub#event’&gt;</entry></row><row><entry>  &lt;items node=‘weather_data_handler’&gt;</entry></row><row><entry>   &lt;item id=‘0123456789’&gt;</entry></row><row><entry>    &lt;dataHandler</entry></row><row><entry>    xmlns=’http://www.example.net/weatherHandlerExe’&gt;</entry></row><row><entry>     &lt;correlator&gt;weather&lt;/correlator&gt;</entry></row><row><entry>     &lt;href&gt;www.example.net/executables/weatherHandler&lt;/href&gt;</entry></row><row><entry>    &lt;/dataHandler&gt;</entry></row><row><entry>   &lt;/item&gt;</entry></row><row><entry>  &lt;/items&gt;</entry></row><row><entry> &lt;/event&gt;</entry></row><row><entry>&lt;/message&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Referring again to <figref idref="DRAWINGS">FIG. 5</figref>, once the first and second notification messages are sent to the subscribing client <b>410</b> (blocks <b>508</b>, <b>510</b>), the client <b>410</b> receives and processes the first notification message (block <b>509</b>) and receives and process the second notification message (block <b>511</b>). The order in which the first and second messages are received is arbitrary, i.e., the client <b>410</b> can receive the second notification message before the first notification message or vice versa.

In one embodiment, the client <b>410</b> receives the first or second notification message via the pub/sub protocol layer <b>404</b> and watcher component <b>412</b>. The watcher component <b>412</b> routes the first or second notification message to the WUA <b>414</b>, which determines whether the message includes the data tuple <b>255</b> (first notification message) or the data handling tuple <b>300</b> (second notification message). In one embodiment, when the WUA <b>414</b> detects that the message includes the data tuple <b>255</b>, e.g., the message includes a “data” element, as opposed to a “dataHandler” element, the message is passed to the source data manager component <b>416</b> for processing. Otherwise, when the WUA <b>414</b> detects that the message includes the data handling tuple <b>300</b>, e.g., it includes a “dataHandler” element, the message is passed to the data handling information manager component <b>418</b> for processing.

In one embodiment, when the data handling information manager component <b>418</b> receives the second notification message, it processes the data handling tuple <b>300</b> in accordance with the data handling techniques used by the data handling subscription and the correlation value. For example, in one embodiment, when the data handling tuple <b>300</b> includes data handling parameters for weather, the weather parameters in the client <b>410</b> are updated with the new values. Alternatively, or in addition, when the data handling tuple <b>300</b> includes a reference to an executable, then the data handling information manager component <b>418</b> can retrieve and install that executable. In another embodiment, the data handling information manager component <b>418</b> can also modify the data handling information to conform with the client's <b>410</b> preferences. When processing of the data handling tuple <b>300</b> is completed, the data handling information manager component <b>418</b> can record that the data handling information has been processed, and store the correlation value and the data handling information in the handling information store <b>419</b>. Then, the correlation value and a completion indication are provided to the data handler component <b>420</b> for further processing.

In an exemplary embodiment, when the source data manager component <b>416</b> receives the first notification message, it determines whether the data tuple <b>255</b> is associated with a data handling tuple <b>300</b>. For example, the source data manager component <b>416</b> can check for the presence of a “userDataHandler” element and, if there is one, whether its value is “yes.” When such an element is not present or when the value is not “yes,” then the notification message is treated in the standard manner. In one embodiment, the source data in the data tuple <b>255</b> can be handled using default handling instructions. Otherwise, when the value of the “userDataHandler” element is “yes,” the notification message including the data tuple <b>255</b> is passed to the data handler component <b>420</b> for further processing.

When the data handler component <b>420</b> receives the data tuple <b>255</b> from the source data manager component <b>416</b>, the data handler component <b>420</b> can determine whether the associated data handling tuple <b>300</b> has been received and processed based, for example, on the correlation value. When such is not the case, the data handler component <b>420</b> can store the source data in the source data store <b>417</b> until the associated data handling tuple <b>300</b> is processed. Alternatively, when the client <b>410</b> is so configured, the data handler component <b>420</b> can use default data handling information to handle the source data.

When the associated data handling tuple <b>300</b> has been received and processed, the data handler component <b>420</b> can use the data handling information in the associated data handling tuple <b>300</b> to process the source data (block <b>512</b>). In one embodiment, when the source data is currently being handled pursuant to old data handling information, the data handler component <b>420</b> can refresh the handling, e.g., display, of the source data using the newly processed data handling information. For example, when the application is currently minimized and the newly processed data handling information indicates that the temperature in Fahrenheit is to be displayed when the application is minimized, then the data handler component <b>420</b> will display the temperature in Fahrenheit from the current data tuple <b>255</b> in an icon representing the minimized view of the application. In another embodiment, when the source data is not currently being handled, the data handler component <b>420</b> can retrieve the source data from the source data store <b>417</b> and use the data handling information to process the source data.

According to an exemplary embodiment, the subscribing client <b>410</b> can receive notification messages including updated source data and notification messages including updated data handling information independently from the pub/sub service <b>220</b> pursuant to the first and second subscriptions. In an exemplary embodiment, the notification messages can be processed in the manner described above. For example, when updated source data is received pursuant to the subscription to the data tuple <b>255</b>, the client <b>410</b> can identify the data handing information associated with the source data using, for example, the correlation value, and use the identified data handling information to process the updated source data. Alternatively, when updated data handling information is received pursuant to the subscription to the data handling tuple <b>300</b>, the client <b>410</b> can store the updated data handling information and then use it to process the associated source data.

In the embodiments described above, the data handling tuples <b>300</b> are provided by clients <b>410</b> other than the subscribing client <b>410</b>. In another embodiment, the subscribing client <b>410</b> can be configured to create and maintain personalized data handling tuples <b>300</b> and to publish data handling information to the personalized data handling tuples at the pub/sub service <b>220</b>. In this embodiment, the subscribing client <b>410</b> can specify in a subscription request to a data tuple <b>255</b> an association between the data tuple <b>255</b> and the personalized data handling tuple <b>300</b>. In this embodiment, the subscription handler component <b>224</b> at the pub/sub service <b>220</b> can automatically subscribe the client <b>410</b> to the data tuple <b>255</b> and to the personalized data handing tuple <b>300</b> so that the second notification message includes the published data handling information.

Variations to the embodiments described above are also available. For example, in the described embodiments, the subscription handler <b>224</b> automatically provides the subscription to the data handling tuple <b>300</b> associated with the data tuple <b>255</b> without input from the client <b>410</b>. In other words, the subscription to the data handling tuple <b>300</b> is transparent to the subscribing client <b>410</b>. In another embodiment, the subscribing client <b>410</b> can participate in the process of subscribing to the data handling tuple <b>300</b>. For example, in one embodiment, the subscription handler <b>224</b> can instruct the notification handler <b>223</b> to include in the first notification message the data tuple <b>255</b> as well as information relating to the associated data handling tuple <b>300</b>. The source data manager component <b>416</b> can use the information relating to the data handling tuple <b>300</b> to subscribe to the data handling tuple <b>300</b> at a pub/sub service <b>220</b>.

In another embodiment, the client <b>410</b> can use a naming convention to subscribe to the data tuple <b>255</b> and to the data handling tuple <b>300</b>. For example, the subscription request for the data tuple <b>255</b> can include an identifier that is related to both the data tuple <b>255</b> and to the associated data handling tuple <b>300</b>.

In yet another embodiment, the client <b>410</b> can be configured to invoke the tuple association handler component <b>260</b> directly, for example, via an out-of-band remote procedure call, and to retrieve the association information relating to the data tuple <b>255</b>. In this embodiment, the client <b>410</b> can send information relating to the data tuple <b>255</b> to the tuple association handler component <b>260</b> and the tuple association handler component <b>260</b> can return information relating to the data handling tuple <b>300</b> associated with the data tuple <b>255</b>. In another embodiment, the client <b>410</b> can establish a “one-time subscription” to perform this task. A discussion of one-time subscriptions may be found in the document to Chen et al., titled “Context Aggregation and Dissemination in Ubiquitous Computing Systems” (Dartmouth Computer Science Technical Report TR2002-420, 2002), available via the Internet at the URL: http://www.cs.dartmouth.edu/reports/TR2002-420.pdf on Dec. 8, 2006. In this embodiment, the pub/sub service <b>220</b> can respond with a notification including the association information and then automatically cancel the subscription. The client <b>410</b> can then use this information to subscribe to the data handling tuple <b>300</b>.

Through aspects of the various embodiments, data handling information can be provided more efficiently and easily. Because the information is stored in separate and distinct data handling tuples <b>300</b>, the associations between data tuples <b>255</b> and data handling tuples <b>300</b> can be complex and flexible. Subscriptions to the data tuples <b>255</b> and data handling tuples <b>300</b> are also separate and distinct. Accordingly, updates to the data handling information can be easily implemented and distributed to subscribing clients <b>410</b>.

The executable instructions of a computer program for carrying out the methods illustrated in <figref idref="DRAWINGS">FIG. 5</figref> can be embodied in any machine or computer readable medium for use by or in connection with an instruction execution machine, system, apparatus, or device, such as a computer-based or processor-containing machine, system, apparatus, or device, that can read or fetch the instructions from the machine or computer readable medium and execute the instructions.

As used here, a “computer readable medium” can be any means that can contain, store, communicate, propagate, or transport the computer program for use by or in connection with the instruction execution machine, system, apparatus, or device. The computer readable medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor machine, system, apparatus, device, or propagation medium.

More specific examples (a non-exhaustive list) of the computer readable medium can include the following: a wired network connection and associated transmission medium, such as an ETHERNET transmission system, a wireless network connection and associated transmission medium, such as an IEEE 802.11(a), (b), or (g) or a BLUETOOTH transmission system, a wide-area network (WAN), a local-area network (LAN), the Internet, an intranet, a portable computer diskette, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM or Flash memory), an optical fiber, a portable compact disc (CD), a portable digital video disc (DVD), and the like.

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.