Priority messaging and priority scheduling

Systems and methods that set priority levels to messaging systems initiated between end points (e.g., two SQL point services) thru service brokers. A priority component can apply priority at a session level to add priority capabilities on top of service brokers, and enable setting priority for all the messages in a session or conversation. Such priority can further affect the order in which messages from different conversations are sent and the order in which they are received.

BACKGROUND

Computing and networking technologies have transformed many important aspects of everyday life. Computers have become a household staple instead of a luxury, and provide users with a tool to manage and forecast finances, control household operations like heating, cooling, lighting and security, and store records and images in a permanent and reliable medium. Networking technologies like the Internet provide users with virtually unlimited access to remote systems, information and associated applications.

Traditional business practices are evolving with computing and networking technologies. For example, a conventional banking transaction can include gathering information such as bank account number, passbook and identification, dedicating time to travel to the bank, procuring transportation, waiting in line and utilizing tellers to facilitate a banking transactions. Today, consumers can access their accounts via the Internet and perform a growing number of available transactions such as balance inquiries, funds transfers and bill payment with the click of a mouse button.

As computing and networking technologies become robust, secure and reliable, more consumers, wholesalers, retailers, entrepreneurs, educational institutions, advocacy groups and the like are shifting paradigms and employing the Internet to perform business instead of the traditional means. For example, many businesses and consumers are providing web sites and/or on-line services (e.g., for purchasing food and clothing, searching for information, sending email and playing interactive games). In another example, a stock market web site can provide the user with tools for retrieving stock quotes and purchasing stock.

Typically, a user interfaces with a client(s) application (e.g., a web page) to interact with a server(s) that stores information in a database that is accessible to the client application. Databases provide a persistent, durable store for data that can be shared across multiple users and applications. Client(s) applications generally retrieve data from the database through a query(s), which returns results containing the subset of data interesting to the application. The application then consumes, displays, transforms, stores, or acts on those results, and may submit changes based on the results retrieved.

Moreover, messaging systems are typically employed to transfer data between computers, databases and other entities. Each entity participating in message transfer (e.g., an “endpoint”) can be employed for various purposes, such as; archiving data, event notification, enabling loosely connected applications that have components on multiple endpoints, and the like.

In such systems, the message throughput and latency are limited by various resource constraints, including network connectivity, network bandwidth, processor speed, memory, and disk space. These constraints can exist in either endpoint or at other locations on the connecting network. As such, throughput and latency of the system are typically limited by the slowest component, resulting in a variable latency between the time a message is sent and the time it is received. For example, the message send rate may exceed the throughput the system is capable of and thus latency increases for some or all messages.

For example, a chain of retail stores can be connected to a central database. The central database can contains customer records, transaction records, inventory, product descriptions, and pricing. It can become necessary for a store to access a customer record or inventory while the customer is waiting at the cash register. Hence, messages related to retrieval of customer records from the central database are required to be delivered quickly. Likewise, updates to product descriptions and pricing are generally not time critical. Furthermore, such updates can be quite large and take a lot of time and resources to transfer.

SUMMARY

The subject innovation supplies prioritizing capabilities and sets priority levels to messaging systems via employing a priority component that operates on session initiated between end points (e.g., two SQL point services) thru service brokers. Such priority component can apply priority at a session level to add priority capabilities on top of service brokers, and enable setting priority for all the messages in a session or conversation. Accordingly, an administrator or application can set the priority for a specific conversation, either by configuration (e.g., via a configuration component) or programmatically (e.g., to enable configuring/applying priority to a session of messages.)

Such priority can further affect the order in which messages from different conversations are sent and the order in which they are received. Moreover, the configuration component can implement configuration rules that are exposable as Transactional Structured Query Language (TSQL) statements to apply configurations (e.g., automatically) to session(s), whenever the session is further associated with a contract (e.g., based on a local service name, remote service name, and the like.) The priority can be set automatically at each endpoint when the session is created, based on a set of Configuration Rules. At the initiator endpoint, the session is typically created programmatically, and at the target endpoint, the session is in general created when the first message of that session is received. Moreover, each configuration rule can contain a numeric identifier and a name that are unique and either can be used to identify the configuration rule.

In a related aspect, the configuration rules contain a set of criteria values, wherein the columns are employed to verify if a rule matches a specific session. For example, null values indicate wildcards that match any value, and there cannot be multiple configuration rules with identical sets of criteria value—however, there may be overlapping configuration rules with wildcards.

Hence, each end point can be configured independent of other end points, or send or receive processes. In a related aspect, a scheduling component can be associated with the priority component to employ a transport layer for sending messages with starvation prevention after sessions have been created and priority classes defined, wherein lower priority messages are conferred a chance to be sent, even if there are higher priority messages ready to send. Effective priorities can be defined that are incremented upon a predetermined number of times messages associated with a session or priority are processed.

According to a methodology of the subject innovation, initially a service broker can be configured by a program or a user, wherein SQL server objects for services and contracts, routes for remote servers, configuration of property rules, can be created, for example. Subsequently a programmer or user can open a service broker dialog or session, wherein configuration rules can be applied and priority assigned to an associated session. Likewise, a remote server includes independent set of priority rules and different settings/priority rules, so that end points have different priorities for the same session. Subsequently, a message is being sent for a session that is opened and assigned a priority, wherein a transmitter component includes a list of all sessions and associated messages that are ready to be sent. In addition, internal to the transmitter component services with various configurations can exist, wherein various priority classes can be defined. Moreover, a destination manager can manage corresponding destinations and remote end points for message exchange. Such destination manager can call process methods into the scheduling component for processing messages associated with a session.

DETAILED DESCRIPTION

FIG. 1illustrates a block diagram of a priority component110that operates in a session initiated thru service broker(s)120in accordance with an aspect of the subject innovation. It is to be appreciated that the system100illustrated inFIG. 1is schematic in nature, wherein a service broker(s) can exist as a non-centralized component for each endpoint. Moreover, the priority component110can be part of the service broker120. The service broker120can employ queues to provide loose coupling between the message sender102and the message receiver104. The sender102can implement commands to place a message in a queue and then continue with the application, relying on service broker120to ensure that the message reaches its destination. The system100enables prioritizing capabilities for exchanged messages between the sender102and receiver104, wherein the priority component110sets priority for messages in a session or conversation.

The service broker120can implement dialogs, which are bidirectional streams of messages between two endpoints of message senders102,104. Messages in a dialog can be ordered and prioritized, and dialog messages delivered based on the order set by the priority component110. Such order can be maintained across: transactions, input threads, output threads, crashes restarts, and the like. Each message can include a conversation handle that uniquely identifies the dialog that is associated with it.

Moreover, the priority component110can apply priority to messages across sessions to add priority capabilities on top of service broker(s)120, and enable setting priority for all the messages in a session or conversation. Accordingly, an administrator or application can set the priority for a specific conversation, either by configuration or programmatically (e.g., to enable configuring/applying priority to a session of messages.) Such priority can further affect the order in which messages from different conversations are sent and the order in which they are received. The messages can typically include any type of messages exchanged between sender(s) or receivers, and can include any type of data such as—but not limited to—registration messages, query information, and the like.

For example, the service broker120can facilitate conveyance of database query registration information and transmission of a database message associated with the sender102or receiver104, a queue to store database query registration information from the service broker, and a notification delivery service to transmit a database message. The system100can further employ various mechanisms for receiving registration requests, assembling registration messages, transmitting registration messages, detecting database changes, and providing database change notifications.

Such database query registration information can include plurality of queues to store database query registration information provided to the service broker120, and a notification delivery service (not shown) to transmit messages based at least in part on the database query registration information. It is to be appreciated that a component (e.g., a client, a user and an application) can register (e.g., subscribe) a database query with the system100. Query registration typically includes providing database query registration information in conjunction with and/or separate from a request for query results. Database query registration information can include a unique identifier, a delivery address, a queue name, a time-out period, and various communication and security options, for example.

FIG. 2illustrates a configuration component215as part of a priority component211in accordance with an exemplary aspect of the subject innovation. It is to be appreciated thatFIG. 2is schematic in nature and the priority component211, and/or the configuration component can be part of the service broker210and live on the server205. Moreover, priority can be applied at receive time, e.g. when a message has already arrived at the target queue, priority is used in determining which messages the receiver will pull from the queue. The configuration component215can implement configuration rules that are exposable as TSQL statements to apply configurations (e.g., automatically) to session(s). Such session(s) can further be associated with a contract (e.g., based on a local service name, remote service name, and the like.) The priority can be set automatically at each endpoint when the session is created, based on a set of Configuration Rules. At the initiator endpoint, the session is typically created programmatically, and at the target endpoint, the session is typically created when the first message of that session is received. Each configuration rule can contain a numeric identifier and a name that are unique and either is used to identify the configuration rule.

The server205includes the service broker210to facilitate storing and conveying messages, a queue220to store messages, and a notification delivery service230to transmit messages. The service broker210facilitates storing and transmitting messages. As noted supra, messages can be assembled when needed. For example, a message can be assembled and sent after a database query. The message can then be transmitted to the server205as a message, for example. Each message typically contains a unique identifier in addition to the content of the message. Messages can be associated with sessions, and sessions can be associated with services. Configuration information for sessions and services typically contains at least one of a unique identifier, a delivery address, a queue name and a time-out period.

The service broker210stores at least a portion of the message (e.g., the unique identifier) in the queue220and invokes the notification delivery service230. The queue220employed is typically determined by extracting the queue name from the configuration information. For example, invocation of the notification delivery service230includes activating the notification delivery service230, if it is not already active. Providing an activation mechanism mitigates the overhead associated with configuring and/or manually initiating the notification delivery service230prior to a database change that would affect the results of the registered query. However, the notification delivery service230and the queue220can be pre-configured. In addition, the activation mechanism provides “handshaking” to verify communication to mitigate transmitting information that can be lost if the notification delivery service230is not activated. It is to be appreciated that the notification delivery service230can additionally be activated by another component(s), for example upon system startup (e.g., a hard boot and a soft boot), by an external stimulus and/or a user.

An activated notification delivery service230can access the queue220. The activation period is typically determined by a parameter that can be provided via the configuration information, additional information transmitted prior to, concurrent with and/or subsequent to the configuration information, or during set-up (e.g., configuration) of the notification delivery service230, or dynamically while the notification delivery service230is activated as a default, or a combination thereof. The parameter can specify an absolute length of time (e.g., predetermined number seconds after being activated), a predetermined number of queue entries to service, and/or a period of inactivity (e.g., if no new database query registration information is delivered to the queue220for a specified period), for example.

The configuration information typically includes a delivery address signifying where to send the prioritized messages. The delivery address can be extracted and employed to transmit such prioritized messages. In addition, the configuration information typically includes a unique identifier that can be employed in the prioritized messages to facilitate the notification runtime service with delivering an invalidation notification (e.g., raise an event and set a flag) to a component(s) that registered to receive the notification.

It is to be appreciated that various techniques can be employed to determine whether the database prioritized message is delivered and/or received, for example. A first technique involves an acknowledgment (e.g., ACK) from the receiving device. The ACK can indicate a successful (e.g., uncorrupted) transmission of the prioritized message and can invoke the commitment of the priorities. Moreover, it is to be appreciated that although the service broker210is illustrated within the server200, the service broker210can reside in a client or in another server. In addition, the service broker210can be a database (e.g., SQL based), and can include more than one queue220and/or notification delivery service230. Furthermore, it is to be appreciated that more than one notification delivery service can be employed as described above. For example, more than one notification delivery service can access the queue220. In addition, more than one notification delivery service can access a plurality of queues (e.g., queues220), serially and/or concurrently, including a substantially similar queue (e.g., queue220).

FIG. 3illustrates configuration rules315that contain a set of criteria values, wherein columns are employed to verify if a rule matches a specific session. For example, null values indicate wildcards that match any value, and there cannot be multiple configuration rules with identical sets of criteria value—however, there may be overlapping configuration rules with wildcards. Hence, each end point310,320can be configured independent of: other end points, send or receive, for example. In a related aspect, a scheduling component317can be associated with the priority component322to employ a transport layer for sending messages with starvation prevention after sessions have been created and priority classes defined, wherein lower priority messages are conferred a chance to be sent, even if there are higher priority messages ready to send. Effective priorities are defined that are incremented upon a predetermined number of times messages associated with a session or priority are processed.

The scheduling component317or scheduler accounts for priority for ordering of: sessions (dialogs) within a message sender (service), message senders within a destination (connection) and destinations. As such, the priority of the scheduling component317can be defined as the priority of the highest priority scheduleable unit it contains. Such implies that the priority of a destination is the priority of the highest priority message sender it contains, and the priority of a service is the priority of the highest priority session it contains. Furthermore, destinations and message senders can change priority based on changes to the contained message senders or sessions. For example, the following terminology can be employed wherein:

PL=Priority Level=the priority of the dialog or for connections, the priority of the highest priority dialog on the connection.

EP=Effective Priority=The priority used for comparing the priorities of the corresponding PL's in determining which to select.

SU=Schedulable Unit=The item to be scheduled.

CU=Containing Unit=The higher level item containing lists of the CU's.

Likewise, for scheduling destinations within an instance, the following can be defined

Similarly, for scheduling message senders within a destination, the following can be defined

Moreover, for scheduling sessions within a message sender:

At each CU, an array of priority levels can be kept, e.g. 0-9. Each row in the array contains the priority (which equals the index), the effective priority, and the header for a list of SU's. Likewise, each SU is appended to the end of the list with the corresponding PL. The array element with the highest EP is chosen for processing. If a tie exists, the element with the lowest PL can be chosen. Moreover, the SU to be processed is taken from the head of the list at the chosen array element.

In one aspect, the effective priority is initially equal to the priority, and processing is ordered by the effective priority, wherein SU(s) within each list are processed round robin. The effective priority of an element in the array with SU(s) waiting to be processed can then be periodically incremented based on the number of SU(s) being processed, e.g., #SU's processed mod5. When an SU is processed, the effective priority of the corresponding array element is reset to the priority. Moreover, if an SU moves to a higher PL (due a higher priority dialog being added to the connection), set EP(PL New)=Greater(EP(PL New), EP(PL Old)). If an SU moves to a higher PL (due a higher priority dialog being added to the connection), such can be appended to the end of the list. Likewise, if an SU moves to a lower PL (due to its higher priority dialogs getting processed), such can be appended to the end of the list.

As illustrated, the system300includes end points in form of a client310, a server320, a memory330, a service broker340, a queue350, and a notification delivery service360. The client310can include a mechanism(s) (not shown) to register a database query(ies) with the server320and to receive an associated prioritized message from a notification delivery service, as described herein. Registration typically comprises constructing a database registration message that includes database query registration information, a delivery address, a unique identifier (e.g., a globally unique identifier, or GUID), a queue name, a time-out period, and optionally additional information such as communication (e.g., protocol and port) and security (e.g., encryption and authentication) options, for example. The database registration message can then be transmitted to the server320. It is to be appreciated that more than one client (e.g., more than one client310) and/or other component(s) can register one or more database queries, serially and/or concurrently, and in accordance with an aspect of the subject innovation. Furthermore, a plurality of clients can register queries that return substantially similar results.

In one aspect of the subject innovation, the prioritized messages can be transmitted to the server320with a query (e.g., a query associated with the database query registration information included in the database registration message). The query results can be stored in the memory330and/or in other storage devices, including storage on a web server. Storing the results in the memory330provides the client310, as well as any other clients, the ability to utilize the stored results instead of performing subsequent queries when the subsequent queries would return substantially similar results. The notification delivery service360can employ the database query registration information to construct and deliver prioritized messages to the client310. For example, the notification delivery service360can extract and utilize the delivery address and the unique identifier (e.g., GUID) from the database query registration information. The unique identifier is typically included within the prioritized messages, and the change message is generally delivered to the delivery address (e.g., the notification runtime service associated with the client310).

FIG. 4illustrates a methodology400of prioritizing and sending messages in accordance with an aspect of the subject innovation. While the exemplary method is illustrated and described herein as a series of blocks representative of various events and/or acts, the subject innovation is not limited by the illustrated ordering of such blocks. For instance, some acts or events may occur in different orders and/or concurrently with other acts or events, apart from the ordering illustrated herein, in accordance with the innovation. In addition, not all illustrated blocks, events or acts, may be required to implement a methodology in accordance with the subject innovation. Moreover, it will be appreciated that the exemplary method and other methods according to the innovation may be implemented in association with the method illustrated and described herein, as well as in association with other systems and apparatus not illustrated or described. Initially and at410a service broker can be configured by a program or a user, wherein SQL server objects for services and contracts, routes for remote servers, configuration of property rules, can be created, for example. Subsequently and at420, independent set of priority rules for end point(s) can be set. The methodology then proceeds to act430, wherein service broker dialog session can be opened. At440, the messages can then be sent.

FIG. 5illustrates a related methodology500prioritizing messages across sessions according to an aspect of the subject of innovation. Initially and at510multiple sessions can be identified between a sender(s) and a receiver(s). At520, messages across sessions can be prioritized, wherein end points can have different priorities for the same session. At530, a destination manager can call process methods into the scheduling component for processing messages associated with a session at540. Such destination manager can manage corresponding destinations and remote end points that exchange messages.

FIG. 6illustrates an exemplary application of a scheduling algorithm to arbitrary types of elements according to an aspect of the subject innovation. As illustrated, various classes can be defined such as CPrioritySchedulableUnit610, which contains all of the methods and data that are necessary for a Schedulable Unit. In general, all entities that need to be scheduled can descend from CPrioritySchedulableUnit.

Moreover, it is possible to nest instances of the Scheduler by associating a scheduler with a schedulable unit. For example, when a destination needs to be scheduled, the CDestination class620descends from CPrioritySchedulableUnit630. A destination also needs to schedule Message Senders, so it has member of type CPriorityScheduler. The Destination's priority is the aggregate priority exposed by the scheduler. In one aspect, the aggregate priority of a scheduler is equal to the priority level of the highest priority schedulable unit that it has available to be scheduled. It is to be appreciated that the aggregate priority can be calculated by formulas based on other factors, such as the number of schedulable units it has available to be scheduled, or the average priority of those units, and the like.

In a scenario for nested schedulers, priority changes at the lower levers can affect priorities at the higher levels. As such, a calling mechanism is defined to allow schedulers and schedulable units to call into the containing scheduler or schedulable unit to advise it of a priority change.

As illustrated inFIG. 6new instance of CSbTransmissionProxy660with a high priority is appended to the scheduler CBrokerService::m_SessionList. Likewise, CBrokerService::m_SessionList appends the new CSbTransmissionProxy to the appropriate list, and updates its aggregate priority. Similarly, CBrokerService::m_SessionList calls into the CPrioritySchedulableUnit that CBrokerService is descended from to advise it of its new aggregate priority. Moreover, the CPrioritySchedulableUnit that CBrokerService is descended from calls into CDestination::m_MessageSenderList to advise it of its new priority.

In addition, CDestination::m_MessageSenderList moves the CPrioritySchedulableUnit that CBrokerService is descended from to the appropriate list, and updates its aggregate priority. Moreover, CDestination::m_MessageSenderList calls into the CPrioritySchedulableUnit that CDestination is descended from to advise it of its new aggregate priority. In addition, the CPrioritySchedulableUnit that CDestination is descended from calls into CSbDestinationManager::m_ReadyDestinationList to advise it of its new priority. Furthermore, CSbDestinationManager::m_ReadyDestinationList moves the CPrioritySchedulableUnit that CDestination is descended from to the appropriate list, and updates its aggregate priority.

For example, priority setting on the dialog endpoint can include keeping priority in the “m_bPriority” member of CDialogEndpointMetadata. Likewise, CDialogEndpointMetadata can expose a GetPriority( ) method, wherein the priority will be passed in as a parameter to CDialogEndpointMetadata::InitService. Likewise, on the initiator endpoint, where a dialog is created with the “begin dialog conversation priority” command, CDialogEndpoint::BeginDialog can call LookupPriority. It will then pass it in to CDialogEndpointMetadata::InitService. Typically, all parameters for LookupPriority already exist in CDialogEndpoint::BeginDialog.

On the target endpoint where the dialog endpoint is created during receive of the first message, CDialogEndpoint::FCreateTarget can call LookupPriority. It will then pass it in to CDialogEndpointMetadata::InitService. In general, all parameters for LookupPriority are already available in CDialogEndpoint::FCreateTarget.k

FIG. 7illustrates a broker services system700in accordance with an aspect of the subject innovation. The system700includes an initiator system710and a target system720. The initiator system710includes an encryption component711and a decryption component723. The initiator system710has secure access to an initiator private key730and a session key722. Furthermore, the initiator system710has access to a target public key744. In general, the session key can be employed, for example, to encrypt and/or decrypt message(s) that form a dialog between an initiator system and target system(s). Such dialog refers to a single bidirectional streams of messages between two endpoints (e.g., initiator and target systems). For example, two endpoints can have zero, one or more dialog(s) ongoing at any particular time. In one example, all messages in a dialog are ordered and dialog messages are always delivered in the order sent. The order is maintained across transactions, across input threads, across output threads, and across crashes and restarts. Further, a “message” can include a conversation handle that uniquely identifies the dialog associated with it. For example, an order entry application can have dialogs open simultaneously with a shipping application, an inventory application and a billing application. Because messages from each application have a unique conversation handle, identifying which application sent each message can be readily performed.

The target system720includes an encryption component721and a decryption component713. The target system720has secure access to a target private key725. Further, the target system720has access to an initiator public key755. The encryption component711of the initiator system710encrypts the session key722with the initiator private key730. The result of this first encryption is further encrypted with the target public key744. The result of this second encryption is provided to the target system720(e.g., encrypted session key).

The decryption component713of the target system720receives the encrypted session key and decrypts it with the target private key725. The result of this first decryption is further decrypted with the initiator public key755. The result of the second decryption is the session key722that can be securely stored by the target system720. Thereafter, the initiator system710and the target system720can be engaged in a dialog employing message(s) encrypted with the session key735. In order to facilitate authenticity of the sending entity, the message(s) encrypted with the session key735can further be signed with the initiator private key730. It is to be appreciated that the broker services system700, the initiator system710and/or the target system720can be computer components as that term is defined herein.

The system700can apply priority across sessions to add priority capabilities on top of service brokers, and enable setting priority for all the messages in a session or conversation. Accordingly, an administrator or application can set the priority for a specific conversation, either by configuration or programmatically (e.g., to enable configuring/applying priority to a session of messages.) Such priority can further affect the order in which messages from different conversations are sent and the order in which they are received.

The AI component820can employ any of a variety of suitable AI-based schemes as described supra in connection with facilitating various aspects of the herein described invention. For example, a process for learning explicitly or implicitly how (or which) rule to employ can be facilitated via an automatic classification system and process. Classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed. For example, a support vector machine (SVM) classifier can be employed. Other classification approaches include Bayesian networks, decision trees, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority.

As will be readily appreciated from the subject specification, the subject innovation can employ classifiers that are explicitly trained (e.g., via a generic training data) as well as implicitly trained (e.g., via observing user behavior, receiving extrinsic information) so that the classifier is used to automatically determine according to a predetermined criteria which answer to return to a question. For example, with respect to SVM's that are well understood, SVM's are configured via a learning or training phase within a classifier constructor and feature selection module. A classifier is a function that maps an input attribute vector, x=(x1, x2, x3, x4, xn), to a confidence that the input belongs to a class—that is, f(x)=confidence(class).

The word “exemplary” is used herein to mean serving as an example, instance or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Similarly, examples are provided herein solely for purposes of clarity and understanding and are not meant to limit the subject innovation or portion thereof in any manner. It is to be appreciated that a myriad of additional or alternate examples could have been presented, but have been omitted for purposes of brevity.

In order to provide a context for the various aspects of the disclosed subject matter,FIGS. 9 and 10as well as the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter may be implemented. While the subject matter has been described above in the general context of computer-executable instructions of a computer program that runs on a computer and/or computers, those skilled in the art will recognize that the innovation also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, and the like, which perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the innovative methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as personal computers, hand-held computing devices (e.g., personal digital assistant (PDA), phone, watch . . . ), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of the innovation can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference toFIG. 9, an exemplary environment910for implementing various aspects of the subject innovation is described that includes a computer912. The computer912includes a processing unit914, a system memory916, and a system bus918. The system bus918couples system components including, but not limited to, the system memory916to the processing unit914. The processing unit914can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit914.

The system memory916includes volatile memory920and nonvolatile memory922. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer912, such as during start-up, is stored in nonvolatile memory922. By way of illustration, and not limitation, nonvolatile memory922can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory920includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).

Computer912also includes removable/non-removable, volatile/non-volatile computer storage media.FIG. 9illustrates a disk storage924, wherein such disk storage924includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-60 drive, flash memory card, or memory stick. In addition, disk storage924can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage devices924to the system bus918, a removable or non-removable interface is typically used such as interface926.

It is to be appreciated thatFIG. 9describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment910. Such software includes an operating system928. Operating system928, which can be stored on disk storage924, acts to control and allocate resources of the computer system912. System applications930take advantage of the management of resources by operating system928through program modules932and program data934stored either in system memory916or on disk storage924. It is to be appreciated that various components described herein can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into the computer912through input device(s)936. Input devices936include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit914through the system bus918via interface port(s)938. Interface port(s)938include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s)940use some of the same type of ports as input device(s)936. Thus, for example, a USB port may be used to provide input to computer912, and to output information from computer912to an output device940. Output adapter942is provided to illustrate that there are some output devices940like monitors, speakers, and printers, among other output devices940that require special adapters. The output adapters942include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device940and the system bus918. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s)944.

Computer912can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s)944. The remote computer(s)944can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer912. For purposes of brevity, only a memory storage device946is illustrated with remote computer(s)944. Remote computer(s)944is logically connected to computer912through a network interface948and then physically connected via communication connection950. Network interface948encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

Communication connection(s)950refers to the hardware/software employed to connect the network interface948to the bus918. While communication connection950is shown for illustrative clarity inside computer912, it can also be external to computer912. The hardware/software necessary for connection to the network interface948includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

FIG. 10is a schematic block diagram of a sample-computing environment1000that can be employed as part of prioritizing messages in accordance with an aspect of the subject innovation. The system1000includes one or more client(s)1010. The client(s)1010can be hardware and/or software (e.g., threads, processes, computing devices). The system1000also includes one or more server(s)1030. The server(s)1030can also be hardware and/or software (e.g., threads, processes, computing devices). The servers1030can house threads to perform transformations by employing the components described herein, for example. One possible communication between a client1010and a server1030may be in the form of a data packet adapted to be transmitted between two or more computer processes. The system1000includes a communication framework1050that can be employed to facilitate communications between the client(s)1010and the server(s)1030. The client(s)1010are operatively connected to one or more client data store(s)1060that can be employed to store information local to the client(s)1010. Similarly, the server(s)1030are operatively connected to one or more server data store(s)1040that can be employed to store information local to the servers1030.

What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.