BACKGROUND
[0001] Many systems have computing devices that need a single external resource to perform operations of a particular type but have multiple resources from which to choose. Assume, for example, that a bank's computing system has two devices that have each prepared half of a particular document for printing and many available printing resources (e.g., laser printers). To print the document on one printer, the bank's computing system needs to allocate one of many available printers and commit the system's two devices to that one printer. If both of the devices are committed to that one printer, that same printer can print both halves of the document. Or, also for example, assume that a conferencing system has many devices each of which handles audio from different conference users but needs one of multiple audio multi-point control units (MCUs) to handle all of the different users' audio. To enable this, the system may allocate one audio MCU and commit all of its devices to it. [0002] Some current solutions rely on a leader device to commit all of the system's devices to one of the resources. The leader device is often one of the system's computing devices that has been pre-selected and altered to be capable of committing the system. These current solutions, however, may be vulnerable to the leader device failing in some way. If the leader device commits the system to a particular resource and then crashes, for example, other computing devices may no longer be able to use the resource or may have their operations fail.
SUMMARY
[0003] This document describes tools that enable fault-tolerant resource
committal for a system having computing devices needing to have operations of a particular type performed by one of multiple external resources. The tools may do so without relying on leadership from a pre-selected or altered computing device. Assume, for example, that the system is a conferencing system, the computing devices are front-end servers, the operations of a

particular type are those that require handling of audio from users in the conference, and the external resources are homogeneous audio multi-point control units (MCUs) each of which is capable of handling audio from all of the users. The tools may enable, in one embodiment, any of the front-end servers to allocate a single audio MCU and commit all of the other front-end servers to use that single MCU for their audio operations. [0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term "tools," for instance, may refer to system(s), method(s), computer-readable media, and/or technique(s) as permitted by the context above and throughout the document. BRIEF DESCRIPTION OF THE DRAWINGS
[0005] Fig. 1 illustrates an exemplary operating environment in which various embodiments of the tools may operate.
[0006] Fig. 2 is an exemplary process illustrating ways in which the tools enable a front-end server of a conferencing system to allocate an audio multi¬point control unit for use by all of the front-end servers of the conferencing system.
[0007] Fig. 3 illustrates exemplary elements, some of which are examples of those set forth in Fig. 1, that are used in the description of the process of Fig. 2. [0008] Fig. 4 is an exemplary process illustrating various embodiments and manners in which the tools may enable fault-tolerant committal of external resources.
[0009] The same numbers are used throughout the disclosure and figures to reference like components and features. DETAILED DESCRIPTION Overview
[0010] The following document describes tools capable of enabling fault-tolerant resource committal for a system having computing devices needing to

have operations of a particular type performed by one of multiple available external resources.
[0011] The tools may do so, in some embodiments, using a shared data store. Assume, for example, that two of a system's devices determine based on information in the shared data store that the system has not committed to an external resource. In response, they may each allocate different external resources independently. Then one of the devices contacts the shared data store more quickly than the other, determines anew based on information currently in the shared data store that the system is still not committed to an external resource, and then indicates its external resource in the shared data store. This indication in the shared data store commits the system to the first external resource.
[0012] The second device then determines, based on the indication from the first device in the shared data store, that the system is now committed to the first device's external resource. This second device rolls back its allocation of a different external resource and then uses that first external resource. Any other devices that later need to allocate an external resource may check the shared data store and determine that an external resource has already been committed. And if the first device fails the other devices may continue to use the external resource.
[0013] An environment in which the tools may enable these and other actions is set forth below in a section entitled Exemplary Operating Environment. This section is followed by another section 'describing an exemplary way in which front-end servers of a conferencing system may act to enable fault-tolerant committal of an audio MCU and is entitled Example Conferencing System. A final section describes various other embodiments and manners in which the tools may enable fault-tolerant committal and is entitled Other Embodiments of the Tools. This overview, including these section titles and summaries, is provided for the reader's convenience and is not intended to limit the scope of the claims or the entitled sections.

Exemplary Operating Environment
[0014] Before describing the tools in detail, the following discussion of an exemplary operating environment is provided to assist the reader in understanding ways in which various inventive aspects of the tools may be employed. The environment described below constitutes but one example and is not intended to limit application of the tools to any one particular operating environment, system, type of computing device, type of external resource, or operation. Others may be used without departing from the spirit and scope of the claimed subject matter.
[0015] Figure 1 illustrates one such operating environment generally at 100 comprising a computing system 102 having one or more processors 104 and computer-readable media 106. The system's processors are capable of accessing and/or executing computer-readable instructions on the computer-readable media. The system comprises or has access to an arbitrary number, n, of computing devices 108. These devices may stand alone or be executable on the system's processors and stored in the system's computer-readable media. The system may have many different structures and uses, as will be understood by the skilled artisan. The system may include, for example: a conferencing system; a printing system; a file-using system; and a processing system with its computing devices being processing threads.
[0016] The computing devices are designated 108a, 108b, 108c, through 108n. Each computing device's processors 110 are capable of accessing and/or executing computer-readable instructions on their computer-readable media 112. Each device's computer-readable media comprises or has access to an allocate/commit module 114. Note that each of these elements is designated with "a", "b", "c", and "n" corresponding to their computing device. [0017] The computing devices may have more than one type of operation for which they use external resources. For example, the computing devices may send their audio to one external resource and their video to another. [0018] The computing devices may be homogenous (and thus the system be distributed) in the sense that no particular computing device is a coordinator of

the others, preferred, and/or pre-selected to commit the system to a particular external resource. Furthermore, in some embodiments all of the computing devices are identical in the sense that an action (e.g., handling audio sent from a user) is guaranteed to succeed if sent to any one of the computing devices. The computing devices are also capable of communicating with a shared data store 118 and, in some embodiments, may each retain information locally. [0019] External resources 116 are designated 116a, 116b, 116c, through 116p in Figure 1. Any one of the external resources is capable of handling a particular type of operation from multiple computing devices 108 (shown with a dashed line between the resources and the system). Exemplary external resources may include, for example: printers; recording components; publishing components; file-system directories for storing content; and MCUs (audio media, video media, application sharing, recording, gaming, or otherwise).
[0020] Date store 118 is accessible, directly or indirectly, by computing devices 108 and may be part of or separate from computing system 102 (both shown with a dashed line) and may execute operations through elements of the computing system including with its own allocate/commit module (not shown). The data store may, for instance, execute operations on behalf of computing devices 108 and in a transactional manner. At some point the data store may include information indicating whether the system or a computing device has allocated or committed to a particular external resource. In some embodiments the data store is one that Will not necessarily fail when any one of the computing devices fails, including the computing device that commits the system to a particular external resource. Example Conferencing System
[0021] In this section a conferencing system using two front-end servers, audio MCUs, and a shared data store are used to describe one exemplary way in which the tools act to enable fault-tolerant resource committal. This example is provided for the reader's understanding; it is not intended to limit the scope of the tools or the claimed embodiments. This example is primarily

illustrated in Figures 2 and 3. A more-general embodiment referring to this and other examples is set forth in Figure 4.
[0022] Process 200 of Figure 2 is illustrated as a series of blocks representing individual operations or acts performed by front-end servers of Figure 3. These and other processes described herein may be implemented in any suitable hardware, software, firmware, or combination thereof; in the case of software and firmware, these processes represent sets of operations implemented as computer-executable instructions stored in computer-readable media and executable by one or more processors.
[0023] At block 202, users 302a and 302b of Figure 3 attempt to join a conference. The users have audio and video media to send to the conference, here through a communications network 304, and desire to receive audio and video of other conference members. For clarity and simplicity, this example process is concerned only with handling audio media received from two users 302a and 302b.
[0024] Figure 3 illustrates particular examples of elements described in Figure 1 and other elements all of which will be used in describing this embodiment. Users 302a and 302b are shown with desktop computers, which have audio and video receiving and displaying abilities, though other computers or non-computers (e.g., some telephones) may also be used. Conferencing system 306 is one example of computing system 102 and has processors and computer-readable media (not shown). Front-end servers 308a and 308b are "examples of computing devices 108a and 108b and have processors, computer-readable media, and allocate/commit modules through which actions of process 200 may be performed (not shown). Audio multi¬point control units (MCUs) 310a, 310b, and 310c are examples of external resources 116. Conference data store 312 is an example of data store 118 and may include a SQL database or a distributed hash table.
[0025] At block 204, front-end servers 308a and 308b manage different users, here users 302a and 302b, respectively. At this point each of the front-end servers may have already determined that the conferencing system has

committed to a particular audio MCU, though here we assume that neither has done so yet.
[0026] At block 206, both of the front-end servers communicate with conference data store 312 to receive information indicating whether or not the conference has committed to an audio MCU. If the conferencing server has, then both front-end servers can use the committed-to audio MCU (jump to block 222). Here we assume that the conferencing system is not committed. [0027] The conference data store contains information about which conference (if the system may manage multiple conferences), which types of external resources are or may in the future be committed to, which version of the particular type of external resource is used (or not being used), and which particular external resource for each type is being used, if any. Here the conference is the conference the users are attempting to join, the type of external resource is an audio MCU (indicated by in the data store), and no audio MCU has been committed to (indicated by in the data store). When the front-end servers contact the data store and ask whether or not an audio MCU is being used for the conference desired by the users, they both receive ("null" indicating that no audio MCU is committed to and "0" indicating a zero version) because the system has not committed to an audio MCU.
[0028] At block 208, each of the front-end servers store information (here ) in their local memories (not shown).
■[0029] At block 210, each of the front-end servers allocate different Audio MCUs, here through a GetMCU command made to an MCU factory 314 shown in Figure 3. The MCU factory determines which of its resources is appropriate to handle the requested operation (here the particular operation of handling audio from a user and intended for a conference). The MCU factory returns audio MCU 310a to front-end server 308a and audio MCU 310b to front-end server 308b, respectively. [0030] At block 212, each of the front end servers updates their local

MCU allocated, here with <0,AudioMCUa>. Likewise, front-end server 308b updates its memory by recording the audio MCU allocated, here with <0,AudioMCUb>
[0031] At block 214, each of the front-end servers communicates with the conference data store at a different time. Here front-end server 308a communicates with the conference data store first. This communication includes a call to the conference data store with the information that the front-end server previously stored. Note that each of the front-end servers has allocated an audio MCU independent of the other front-end server or information local to the other front-end server (e.g., the other front-end server's transient state). The process will return to actions of front-end server 308b later below.
[0032] At block 216, the conference data store on behalf of the front-end server and in a transactional manner determines if the conferencing system is committed. If no, the process continues to block 218. If yes, to block 220. Here conference data store 312 on behalf of front-end server 308a compares the current information in the conference data store, , with the information in the server's local memory, also . These same version numbers "0" and "0" indicate that the system has not committed to an audio MCU since the front-end server last contacted the conference data store. In response, the process continues to block 218.
[0033] At block 218, the conference data store on behalf of the front-end server commits the conferencing system to its allocated audio MCU by indicating audio MCU 310a in the conference data store. Thus, the store is updated with <0,AudioMCUa>, which reflects the new resource and that it is a new version. Thus, it replaces "null" with "AudioMCUa" and "0" with "1" for: .
[0034] At block 222, the front-end server uses the conferencing system's committed-to audio MCU, here audio MCU 310a to handle user 302a's audio. [0035] After front-end server 308a communicates with the conference data store front-end server 308b communicates with it, also according to block 214.

The second front-end server (308b) receives from the conference data store the audio MCU to which the system is committed, if any. Here the conference data store returns , not . This is because the first front-end server 308a caused the update to the conference data store responsive to its communication at block 216.
[0036] At block 216 the conference data store on behalf of the front-end server and in a transactional manner determines if the conferencing system is committed. Here conference data store 312 on behalf of front-end server 308b compares, from the front-end server's local memory, with the current information in the conference data store, . The different version numbers "0" and "1" indicate that the system has committed to an audio MCU since the front-end server 308b last contacted the conference data store. In response, the process continues to block 220.
[0037] At block 220, the conference data store on behalf of the front-end server rolls back its allocation of audio MCU 310b. At block 222, the front-end server uses the committed-to audio MCU 31 Oa. These last two blocks are effective to reallocate audio MCU 310a thereby replacing audio MCU 310b. [0038] If audio MCU 310a fails, the process may be repeated but with some differences. Both of the front-end servers may communicate with the data store at block 206 and, if the resource has not yet been replaced, learn that the current version is still "1" (from receiving ). At block 208, both front-end servers record this in local memory, and then at block 210 allocate different audio MCUs. Here the newly allocated audio MCUs comprise audio MCU 310b and audio MCU 310c, which the front-end servers would record at block 212. At block 214, the front-end servers communicate again with the data store but again at different times. Assume here that front-end server 308b communicates first and receives again from the data store.
[0039] At block 216 the conference data store on behalf of this front-end server determines that the conference is still not committed to a valid MCU (it may be committed to audio MCU 310a, but the front-end server knows that this

resource is invalid) because the version number just received "1" is the same as the one received at block 206, also "1". Because the conference is not committed to a valid audio MCU, the process for this front-end server 308b proceeds to block 218 and commits the conferencing system to the newly allocated audio MCU 310b. Again, this committal is done with an indication in the conference data store (here with ). The process for this front-end server then proceeds to block 222 and uses the committed-to audio MCU 310b.
[0040] The other front-end server 308a, through the conference data store, determines that the conference system has committed to a valid audio MCU 310b at block 216 and based on information from actions at block 214 and 206. Thus, the conference data store on behalf of this front-end server compares the current version number in the conference data store "2" from when front-end server 308b indicated to the front-end server's previously received version, namely "1". As the conference system has committed, front-end server 308a proceeds to blocks 220 and 222, reallocating its allocated audio MCU 310c with audio MCU 310b. Note that each of the front-end servers (on its own or transactionally through the data store) is equally capable of allocating and then committing the conference system to a resource, whether that be an initial resource or a replacement. The front-end servers may do so independent of each other's local information. Other Embodiments of the Tools
[0041] The section above describes exemplary ways in which the tools may act to enable fault-tolerant resource committal in a conferencing system using a data store. The section below describes additional embodiments of the tools, including a process 400 shown in Figure 4, which is illustrated as a series of blocks representing individual operations or acts preformed by the tools. These embodiments of the tools are not intended to limit the scope of the tools or the claims.
[0042] Block 402 determines, based on information in a data store accessible by devices of the system, that a system having computing devices

needing to have operations of a particular type performed by one of multiple external resources all of which are capable of performing operations of the particular type has not committed its computing devices to a valid external resource. The tools may do so through an allocate/commit module 114 in one or more of computing devices 108 or 308, for example.
[0043] The tools may receive information from the data store (e.g., data store 118 or conference data store 312) indicating that no valid external resource capable of handling the particular type of operation is committed to by the system. This information may indicate that the system is not committed to an external resource or that it is committed and the resource is invalid or is known by the devices to be invalid. In either case, the tools enable a new and valid external resource to be allocated and committed for the system. [0044] This information may also include indications of the type of external resource (one that is capable of handling the type of operation desired) and an order or commitment-time for that external resource. The order or time of the external resource (or lack thereof) may include a version number (e.g., as described in the above example of Figures 2 and 3) or time-stamp, for example. This information may also indicate whether a committed-to external resource is valid or not, though that may already be known by the computing devices. [0045] Block 404 allocates an external resource capable of handling the particular type of operation. The tools may do so in manners known to a skilled artisan, such as through an internal computation by a computing device or by contacting some other entity (e.g., the allocate/commit module 114 of one of the computing devices 308 commanding an MCU factory to allocate a resource). Note that at this point one or many computing devices of the system may have determined that the system is not yet committed to a valid external resource. In response each may allocate an external resource at block 404. [0046] Block 406 determines, based on information in a data store accessible by the devices of the system, whether or not the system has committed its computing devices to a valid external resource. This information may be from the same data store contacted at block 402 or otherwise.

[0047] In some embodiments the allocate/commit module of one of the computing devices of the system determines whether a version or time-stamp in the data store indicates that a newer external resource is now being used by the system. If at block 402 the data store indicated a version number, such as "0" or "1" or a time-stamp that is now out-of-date, such as with a "1" or "2" or higher time-stamp, the allocate/commit module may determine that the system has now committed to a valid external resource. If the system is not committed, the tools proceed to block 408. If it is committed, the tools proceed to block 410.
[0048] Block 408 indicates in a shared data store an allocated external resource effective to commit the system to that allocated external resource. Note that any future computing device does not need to contact or rely on a computing device that allocated and committed the system to the external resource. Instead, each device may determine the system's committed-to external resource through this indication in the data store, such as with a handle or path name for the resource. Thus, all of the computing devices that now or later desire to use an external resource for the particular type of operation will use the indicated external resource (unless it is later replaced). Devices that have allocated another external resource may determine that the indicated resource should be used instead, such as with a version number or time-stamp higher in number or later in time than the other device received at block 402. In the above example of Figures 2 and 3, for instance, the tools indicated this with a version number.
[0049] Block 412 uses the external resource to which the system is committed. Here the external resource is an allocated external resource indicated in the data store by the computing device that most quickly contactea the data store with a valid allocated external resource.
[0050] Block 410 rolls back an allocated external resource. Here the computing device or other entity allocated an external resource but determined, at block 406, that the system is already committed to a valid external resource. Every computing device that allocates an external resource when one is already

committed to by the system may dump its allocatea resource in preparation or using the system's committed-to external resource. In the above example, all of the front-end servers are enabled by the tools to send their user's audio to the same audio MCU even if they have allocated a different audio MCU. [0051] In some cases only one computing device determines that the system is not committed to an external resource. Later computing devices may then learn at block 402 that the system is committed and then jump to block 412 to use that resource. In some other cases, however, many devices may learn that the system is not committed at block 402 before any one of them commits the system at block 408. All of the devices after the first (the one that commits the system at block 408) will then determine that their allocated external resource is not needed, roll it back, and then use the system's committed-to resource. Note that all of the devices that later need to use the system's committed-to resource may do so without relying on the robustness of the computing device that committed the system. If that computing device fails, the data store will not likely also fail, thereby permitting the other devices to determine that the system is committed and to which external resource.
[0052] The tools may enable any of the computing devices to replace an external resource with a new resource (e.g., to replace an invalid resource such as described in the embodiment of Figures 2 and 3). They may do so without regard to any one of the computing devices being preferred or leading the others or information local to it. Any of the computing devices may do so at any time, such as during the middle of a telephone conference when an audio MCU fails or otherwise should be replaced.
[0053] Note that the tools may also enable these actions for many types of systems, computing devices, operations, and external resources. For example, the system can be a printing system, each of the devices can be capable of preparing a portion of a document for printing, the particular type of operation can be printing the document for which the portions are prepared, and the external resources can be printers each of which is capable of printing all of the portions of the document.

Conclusion
[0054] The above-described tools enable fault-tolerant resource committal for a system having computing devices needing to have operations of a particular type performed by one of multiple external resources. The tools may do so without relying on leadership from a pre-selected or altered computing device. By so doing, systems with computing devices needing to use one of multiple external resources may be made more fault-tolerant. Although the tools have been described in language specific to structural features and/or methodological acts, it is to be understood that the tools defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the tools.

lAVE CLAIM:
1. A method implemented at least in part by one or more computer
processors comprising:
determining [402] that a system [102] having computing devices [108] needing to have operations of a particular type performed by one of multiple external resources [116] all of which are capable of performing operations of the particular type has not committed its computing devices [108] to one of the resources [116] and based on information in a data store [118] accessible by all of the computing devices [108];
allocating [404] one of the resources [116] to perform an operation of the particular type
determining [406], based on information in the data store [118], that the system [102] still has not committed to another of the resources [116]; and
indicating [408] in the data store [118] said one of the resources [116] effective to enable any of the devices [108] to determine that the system [102] is committed to said one of the resources [116].
2. The method of claim 1, further comprising:
determining that said one of the resources indicated in the data store is invalid;
allocating a new one of the resources;
determining, based on information in the data store, that the system still has not committed to another new resource of the resources; and
indicating in the data store said new one of the resources effective to enable any of the devices to determine that the system is committed to said new one of the resources.
3. The method of claim 1, wherein the act of indicating is effective to
enable any of the devices to determine that the system is committed to said one of the
resources without any of the devices needing to communicate with any other of the
devices.

4. The method of claim 1, wherein the acts of determining, allocating,
determining, and indicating are performed by a first computing device of the
computing devices of the system, and further comprising performance of the
following acts by a second computing device of the computing devices of the system:
determining, prior to the first device's act of indicating and based on information in the data store, that the system has not committed its computing devices to one of the resources;
allocating another of the resources to perform an operation of the particular type for the second of the computing devices;
determining, based on information in the data store including the indication and after the first device's act of indicating, that the system has committed to said one of the resources; and
rolling back said another of the resources and reallocating said one of the resources to perform the operation of the particular type.
5. A system [102] comprising computing devices [108], each of the
devices [108]:
needing to have an operation of a particular type performed by one of multiple external resources [116] all of which are capable of performing operations of the particular type and can be allocated to the system [102]; and
independently capable of committing the system [102] to one of the resources [116] by indicating in a data store [118] accessible by any other of the computing devices [108] said one of the resources [116] effective to enable said other devices [108] to determine that the system [102] is committed to said one of the resources [116] without relying oh information available only through the computing device [108] that committed the system [102].
6. The system of claim 5, wherein the capability of committing the system
is enabled by:
determining, based on information in the data store, that the system ib not committed to any of the resources;
allocating said one of the resources; and

determining, based on information in the data store, that the system is still not committed to any one of the resources,
wherein the act of indicating is responsive to determining that the system is still not committed.
7. The system of claim 5, wherein each of the computing devices is further independently capable of replacing said one of the resources to which the system is committed with a new one of the resources using information available in the data store accessible by all of the computing devices and without relying on information available only through any other of the computing devices.
8. The system of claim 5, wherein the capability of committing the system is capable of requiring all of the devices to use said one of the resources for their operation of the particular type.
9. The system of claim 5, wherein each of the computing devices is leaderless to the extent that no one of the computing devices is pre-selected to commit the system.

10. The system of claim 5, wherein each of the devices is independently capable of committing the system using its own local information.
11. The system of claim 5, wherein the information available only through the computing device that committed the system comprises that device's transient state.
12. The system of claim 5, wherein the system is a conferencing system, each of the devices is a front-end server, the particular type is audio or video media, and the external resources are audio multi-point control units or video multi-point control units.
13. The system of claim 12, wherein each of the front-end servers is equally capable of committing the system to one of said audio multi-point control units or one of said video multi-point control units.
14. The system of claim 5, wherein the system is a printing system, each of the devices is capable of preparing a portion of a document for printing, the particular type is printing the document for which the portions are prepared, and the external resources are printers each of which is capable of printing all of the portions of the document.

15. The system of claim 5, wherein the system is a processing system and each of the computing devices is a processing thread.
16. One or more computer-readable media [112] having computer-readable instructions [114] therein that, when executed by one or more processors [110], cause the processors [110] to perform acts comprising:
determining [402] that a conferencing system [306] having front-end servers [308] needing to have media from users [302] handled by one of multiple external multi-point control units (MCUs) [310] all of which are capable of handling the media has not committed its front-end servers [308] to one of the MCUs [310] and based on information in a conference data store [312] accessible by the front-end servers [308];
allocating [210] one of the MCUs [310] to handle the media for one of the front-end servers [308];
determining [216], based on information in the conference data store [312], that the conferencing system [306] still has not committed to another of the MCUs [310]; and
indicating [218, 408] in the conference data store [312] said one of the MCUs [310] effective to enable other of the front-end servers [308] to determine that the conferencing system [306] is committed to said one of the MCUs [310].
17. The media of claim 16, wherein the first act of determining comprises receiving a first version number from the conference data store and the second act of determining comprises receiving the first version number again effective to indicate that the conferencing system has still not committed to another of the MCUs.
18. The media of claim 16, wherein the act of indicating comprises storing a version number or time-stamp different from an original version number or original time-stamp received based on the information in the conference data store as part of the first act of determining.
19. The media of claim 16, wherein the media is audio media and the MCUs are audio MCUs.
20. The media of claim 16, further comprising:

determining, responsive to determining that said one of the MCUs is and is committed to by the conferencing system and based on information in the conference data store, that the conferencing system has not committed to a new MCU of the MCUs; and
indicating in the data store a new one of the MCUs effective to enable other of the front-end servers to determine that the conferencing system is committed to said new one of the MCUs.