MXPA06000648A - System and method for applying flexible attributes to execute asynchronous network requests - Google Patents

Abstract

Flexible attributes are attached to network requests that may be executed asynchronously. Any number of criteria may be attached to network requests. The requests are queued until the associated criteria are satisfied. Once the criteria are satisfied, the request is executed. Applications that make the requests are provided with simple success and failure notifications that they can respond to with various logic. Any type of criteria may be attached to a request. The criteria may be associated with the requests at design time of the application using a graphical user interface.

Description

SYSTEM AND METHOD FOR APPLYING FLEXIBLE ATTRIBUTES TO EXECUTE ASYNCHRONOUS NETWORK APPLICATIONS BACKGROUND OF THE INVENTION Mobile devices have become an integral part of an individual's life both in the business and at home. Similar to desktops and laptops, there are now rich applications available for running on mobile devices. Unlike desktops, and further away than laptops, mobile devices are constantly moving in and out of area network connectivity. Additionally, these mobile devices, and in particular mobile phones, are usually always switched on and are constant partners of their users. Typically, most of these devices are optimized primarily to work with a type of wireless network such as a CDMA network, a GSM or UMTS network, a Wi-Fi network, and the like. The network connections established with these mobile devices, however, are not constant. For example, mobile phone users travel in and out of connectivity zones all day. A person can be going up and down the earth and entering in and out of buildings all day. This movement results in the loss of network access for a few seconds at a time to large periods of time as they move from one point to another. Not only can network access be intermittent, the types of networks available may vary from location to location. Many locations also have "dead spots" where network connections do not exist. For example, deadlocks can occur in the centers of buildings as well as in elevators. In addition, many modern workplace sites offer their own private wireless networks (for example, Wi-Fi), some of the public mobile phone networks. Switching between these different network options and dealing extensively with the temporary absence of network connections is problematic for software applications running on the devices. Some locations are configured to prevent access to wireless networks as a matter of policy. These restricted areas include locations such as: aircraft; government embassies and offices around the world; as well as other safe areas. The end result is that ubiquitous connectivity for mobile devices does not exist. This is markedly different from desktop or laptop connectivity. Connectivity can always be close to a user, but it is often absent in an exact location of the user.

COMPENDIUM OF THE INVENTION The embodiments of the present invention are related to applying flexible attributes to execute asynchronous network requests. According to one aspect of the invention, any criterion number can be attached to these network requests. With the sending of the request, the requests are consulted until their associated criteria is satisfied. Once the criterion is satisfied, the request is executed. Applications that make requests are provided with success and failure notifications that can respond with different logic. For example, when the request happens a successful event is returned to the application and when the request fails a failure event is returned to the application. According to another aspect of the invention, a type of criterion can be attached to an application. For example, the criterion may be a related network (bandwidth, link quality, link type, etc.), related location, related time (executing the request for a particular time), and the like. In accordance with yet another aspect of the invention, the criterion may be associated with requests at the design time of the application using a graphical user interface. Alternatively, the criterion may be associated with the request that an API uses. The user interface is intended to provide an easy way to make declarative declarations on how to control network requests.

BRIEF DESCRIPTION OF THE DRAWINGS Figures 1 and 2 illustrate illustrative computing devices that can be used in illustrative embodiments of the present invention; Figure 3 is a functional block diagram that generally illustrates a system of network request criteria; Figure 4 shows a tree of exemplary criteria that can be applied to a consumed network request; Figure 5 illustrates several smart grid applications that have different criteria attributes associated with them; Figure 6 shows the operating time behavior of a network request administrator; Fig. 7 illustrates an illustrative user interface for configuring smart requests; and Figure 8 illustrates a detailed designer view showing the joining of criteria attributes to a Intelligent Network Request, in accordance with aspects of the invention.

DETAILED DESCRIPTION OF PREFERRED M ODALITY Generally, the embodiments of the present invention are related to applying flexible attributes to execute asynchronous network requests. The criteria can be linked to network requests. With the sending of the request, the request is consulted until its associated criterion is satisfied. Once the criterion is satisfied, the request is executed. The applications that make the request are provided with success and failure notifications that can respond with different logic. For example, when the application is successful, a successful event is returned to the application and when the request fails, a failure event is returned to the application. Any type of criteria can be attached to a request. For example, the criterion can be related network (bandwidth, link quality, link type, etc.), related location, related time (execute request in particular time), and the like. The group of possible criteria is designed to be extensible by the programmer. The criteria can be associated with applications at design time of the application using a graphical user interface. Alternatively, the criteria may be associated with the request that an API uses. The user interface is intended to provide an easy way to make declarative statements about how to control network requests.

Illustrative Network Criteria System Figure 3 is a functional block diagram that generally illustrates a network request criteria system 300, according to aspects of the invention. Generally, the system 300 is intended to allow an arbitrary number of criteria to be attached to network requests, to query the requests, and to execute them efficiently when the necessary criteria are met. The computation device 331 are counting devices such as that described in conjunction with Figure 1 and the mobile device 31 1 and the mobile device 315 are mobile computing devices such as that described in conjunction with Figure 2. The computing device 331 is configured to run an application design environment (332) which is intended to configure and associate criteria with network requests, such as network requests used within application 312 and 316, 317 running on devices 31 1 and 315 Generally, the application design environment 332 allows a user to graphically configure their communication needs, establish criteria, and then write communications code to respond to network requests. An event-driven time-to-run model for dealing with queried network requests and getting event notifications for both successes and communications failures. According to one embodiment of the invention, the design environment 332 is a graphical user interface that allows a user to configure and associate criteria with network requests (see Figures 7 and 8 and related discussion). The applications 312, 316, and 317 may have zero or more criteria (320, 321) associated with them. The criteria can represent any desired condition. For example, a criterion may have a requirement of a low level, such as the signal strength that must be greater than a predetermined level before attempting to send or retrieve information, or a complex higher-level requirement, such as the mobile device must be physically located within a specific location; the user must have a security signal attached to the device, the time must be between 9 AM and 5 PM and the server named "M I SERVER-14" must be accessible. By being available to define criteria of arbitrary complexity, which relate to different and corresponding requirements for both lower and higher levels of technical abstraction, application developers are provided with the flexibility to use these criteria declaratively. Applications 312, 316 and 317 must also dynamically view the queried requests and make simple determinations of what criteria have been satisfied and which remain unsatisfied; this information can be used to direct either programmatic or end user action to remedy the situation. For example: an application can inform the user that their request has still been processed because the signal strength is too low for reliable and efficient communication. Based on this information, the user can decide to move to a location with better signal strength and have the request automatically to run when the necessary criteria are met. The group of criteria (320, 321) is extendable. A programmer can use additional criteria and use them as predefined criteria and join them to requests. These declarative criteria (320, 321) can be dynamically in response to changing conditions. A given criterion established by a user (for example "server XXXX must be reachable", "bandwidth must be greater than 512k bit") can be linked to multiple network requests. If it is found that the criterion is not true in a test, it can be applied to all requests that have that criterion attached to them without the need to prove the condition repeatedly or for each request. In this way, common criteria only need to be reviewed once. Similarly, if a criterion is determined to be true by a network request administrator 312, it does not need to be reprimanded again and again for each request. The criteria can simply be assumed to be true until proven otherwise. In general, smart criteria can distinguish between intermittent and failure / final success and the application is available to take advantage of this information to make intelligent communications decisions. As discussed above, the criteria can be grouped. Clustering criteria not only allows a user to create more complex expressions but also allows the user to link criteria. For example, they are considered to declare a requested link speed criterion of 10 Mbs and a declaration of a "non-Wi-Fi" link type criteria. If the device currently has a GPRS connection and a Wi-Fi connection then the link speed criteria of 10 Mbs would be satisfied by the Wi-Fi adapter but the "no Wi-Fi" criterion would be satisfied by the connection of GPRS. Being available to a group and link criteria allow rich statements about acceptable connection conditions. Some criteria may be shared between applications, while other criteria may be unique to each application (see Figures 4-6 and related discussion). Generally, the network request manager 312 is configured to execute network requests when any criteria that is associated with the requests is satisfied. The network request administrator 312 obtains the attributes associated with the criteria and determines when they are satisfied (see Figures 6 and related discussion). The network request manager (312) interacts with network services through various protocols. For example, the network request administrator 312 may use plugins, HTTP requests, or web service requests. By using the network request manager 312 an asynchronous communications model can be used through the applications (312 and 316, 317). The plugs, HTTP communication models and web services were developed and refined for use on desktop and server computers.

Application developers who "try to open a communications socket" rely on the synchronous programming model and generally assume that the network infrastructure is in place and operational. But much less true for mobile devices. The cellular network / pager 350 is a network in response to delivering messages and receiving messages from wireless devices using a cellular network. The cellular network / pager 350 may include both wireless and wired components. For example, the cellular network / pager may include a cellular tower that is linked to a wired telephone network. Typically, the cell tower carries information to and from cell phones, long distance communication links, and the like. Input 360 routes messages between the cellular network / pager 350 and wireless network 340. For example, a computer user can send a message that is addressed to a cell phone. The input 360 provides a means for transporting the message from the network 340 to the cellular network / pager 350. Conversely, a user with a device connected to a cellular network may be browsing the web. The entry 360 allows hyperlink (HTTP) text protocol messages to be transferred between the network 340 and the cellular network / pager 350. The following exemplary scenarios illustrate various uses of the system. Suppose that a user, John lives through his mobile phone depending on him to deliver information and services on demand. John frequently travels in his city during the day, goes to meetings throughout the city, and frequently is on business trips. He already has his program and contacts on his mobile phone and wants smart services to help with his life. John is also obsessed with information and hates wasting time. You want your mobile phone not to maintain and serve with your information and services that you need throughout the day. To help you, your mobile phone has a series of custom applications that provide necessary information and help you. John wakes up in the morning and checks his daily schedule on his mobile phone before he goes to work. Reading the news on the way to work: John enters the subway in and out of network connectivity during the trip. While waiting for your train, take out your mobile phone and run the applications of "new cuts". Because John has Wi-Fi in his house and the mobile phone application he can use, the latest headers that John is interested in are already downloaded to his phone. Review several new articles and read the articles stored in the cache. Locate a link to an article to "emerge digital pets" in which you are interested and note that it has a green link, indicating that the content has not been cached. He applies it in the link to indicate that he would like the article to be downloaded for him whenever possible. When John makes this request, the network request administrator requests the request and determines if the criteria associated with the request is satisfied. When the criterion is satisfied and is associated with the application of new cuts, the request is processed at any time that the network conditions permit. Since John is in an area without connectivity, the request may not be satisfied at that time. Once John's train emerges from the subway and travels in the upper part of the open sky for several minutes the device is able to establish a GPRS connection for John and the network request administrator executes the request queried and the application downloads the new articles requested in the consultation of new cuts. When the work is contemplated the application receives a programmatic event from the network request administrator that the consulted work was successfully completed. Responding to this event, the application presents the non-obstructive "new full downloads" icon at the bottom of the new reader to indicate that a requested item has been downloaded. John finishes the article he is reading now and then switches to the new download and reads the articles on "emerging digital pets" and "ski holidays in South America". Meanwhile the train, has gone back to the subway and the network connectivity has again been lost, John is not aware and is not affected by this. When reading the article about "digital pets emerge" John decides that he would like to see one in action. The article offers a link to "click here for a store near you". John clicks on the link and a request is loaded using John's current location. Because John is offline, the request is cached locally and would be sent when it is back on acceptable network terrain. John is only aware that the application has been registered and will now be processed at any time that can be; you do not need to register the request for it. John's train soon arrives at work. A change in programming while at work: while at work a phone call comes in for John. Based on this telephone conversation, he agreed to a meeting later that afternoon in the city. The meeting organizer sends an SMS message containing the location of the meeting. John's programming application notes that he has a new board in a few hours in the city and consults a network request to download a detailed map of the board area. Since John's phone is at work he accesses the Wi-Fi network which can immediately start downloading the requested maps and saving them in the cache on the device. This work consists of a series of network requests (for example, a series of individual requests for various maps and addresses); All this work is consulted and starts to run when the requirements are satisfied while they are determined by the network request administrator. In the middle of the application and download of the maps John walks to the elevator, the doors close and his network connection is lost. The network failure is detected by the network request manager and the interrupted job is placed back in the network request query (along with the other job here) to be handled when a suitable network connection is restored. Several minutes after John has left the elevator and his phone again has a Wi-Fi network access the phone briefly wakes up from its low power mode and downloads the remaining requested maps. Another example is used to wish to download music files. While the user is buying music on their mobile phones and consulting songs that they wish to download, the download will take place in the background. If the download for all songs can not be completed before the connection is lost due to user mobility, the downloads will be summarized below. The user can even continue buying music while he is offline and consult requested downloads. Figure 4 shows a tree of criteria that can be applied to a network request queried, according to aspects of the present invention. According to one modality, the criteria are derived from a class of Smart Request Attribute (402). As discussed above, the criteria may relate to many different articles. For example, a group of criteria may be a network link criterion (408). Some network link criteria include, but are not limited to, link speed, link type, available bandwidth, IP address, and the like. The application design criteria (410) includes an article such as if a particular server was reachable. The miscellaneous criteria (412) may include a variety of items such as physical location, time of day, the result of previously completed requests, whether successful or failure, costs, security, and the like. Any type of criteria can be attached to a request. A programmer can add criteria based on a variety of factors. For example, a programmer can add a group of criteria that relate to the characteristics of network cards, used networks, visited locations, and the like. As discussed above, the common criteria can be reviewed an individual time by the request administrator, thereby saving available resources. The criteria collected can also be added (406). You can also group different criteria to create relationships between several criteria (404). Figure 5 illustrates several intelligent network requests that have different criteria attributes associated with them, according to aspects of the invention. These criteria attributes can be shared between requests, which means that an attribute that holds true for a request can be assumed to be true by others and inversely if it is false for a request it can be assumed to be false for all requests. In this aspect the attributes can be shared and can be closed. This closing behavior is particularly valuable for attribute criteria that are costly to test. An example of such criteria is an attribute that tests whether a given service on a server is reachable. The only way to know definitively if a specific server service in a network is reachable is to try to contact the server and determine when an acceptable response is returned. In a mobile network such as a request may be a high latency, which requires conrable battery power and may incur monetary cost when performed. For these reasons, if an attribute criterion is determined to be true, it is closed in the true position until it is proven to be false or reestablished by the application logic. Requests that share this attribute can benefit from their intelligent behavior. Referring to the first application in Figure 5, the 510 application does not include any criteria that need to be satisfied. Therefore, the request 510 is ready to run immediately. The 520 application includes three different criteria that must be satisfied before they run. The criteria that must be satisfied before the 520 request is run include that the server "XX" is reachable, the bandwidth of the connection is greater than 300 Kb / s, and a coercion of physical location is complied with. When all these criteria are met, application 520 will be run. Application 530 shows the different work requests (pending work 3 and pending work 4 that share common criteria.) The shared criteria are the physical location criteria and the amplitude criteria. While the two dependent work units include some common criteria, they can also include criteria that are very unique to one another, for example, pending work 3 requires that server "XX" be reachable, while pending work 4 requires that the server "??? M is reachable together with the type of link being a" Wi-Fi "link. Figure 6 shows the operating time behavior of a network request administrator, according to aspects of the invention Each application, such as application 602 is that it is coupled to the network request manager 604, place the job in the application query pendie nte 610. According to one modality, each network request is initially placed in the query of pending requests. As illustrated, the query of pending 610 applications includes five job applications, including job 7, job 2, job 3, job 1, and job 9. Each job article includes zero or more "criteria attributes" (see labels 605) -609). Periodically, the request administrator (604) observes the work items in the query and determines which items are ready to run. A work item is ready to be executed if all of its criteria attributes are true. When the criteria attributes are true, the article is removed from the query of pending requests 610 and its code is executed in a controlled environment that can detect faults. According to one modality, the requests are made as soon as the criteria associated with the satisfied requests. While the work is started, an asynchronous event is contracted for the client application (602) so that the application can perform some action, such as notifying the user or taking some other appropriate action. The work executed will either be successful or fail. The job is placed in a success query (612) or the failure query (614) after the execution of the application (602) is notified of success or failure through an asynchronous event. According to a modality, events include, work path, job success, and failed work. While a request is within the system 600, an application (602) can examine which job is present in the file request query 610 and what are the states of each of the attribute criteria of the work item. For example, the application that submitted job request 2 can request the criteria attribute number 2. An application can also remove work from the pending job query if it no longer makes sense to run the job. For example, a user may have requested a new communications task that exceeds the existing work that has already been requested. A simple function call can be used to remove the work from the query. Similar to the case request query, applications can also examine what job is in the success query (612) with the failure query (614). When desired, the application can move the job currently in the failure query (614) back to the file request query (610).

Figure 7 illustrates an illustrative user interface for configuring smart requests, according to aspects of the invention. As can be seen by referring to the 710 ellipse, both the Smart Network Requests and the Smart Network Request Manager can be added to the application design surface (730) and configured by the software developer in the properties portion. (720) of the user interface. By using the user interface 700, the developer can configure the Network Request Manager operating time behavior. For example, behaviors such as how many requests can run in parallel in the background can be configured. Developers can also write code to respond to events provided by the request administrator. For example, the code can be written to respond to events such as: a Smart Network Request that is obtained by taking the "file request query" and being run, a Successful Smart Network Request and a Network Request Intelligent that fails. A user can configure intelligent network requests by dragging and releasing them from the design surface (730). Each Smart Network Request represents a communications task that the developer wants to run when the specific criteria are met. Similar to developing the code for the network request administrator, the developer can double-click on a Smart Network Request and write code for that request. This is analogous to the very common practice of double-clicking on a Button control in a form designer and the write code that will run when the button is pressed in the operating time. From there, the code that the developer writes will get the call by the Request Manager when the Criteria attributes of the I nteligent Network Request are satisfied. This code corresponds to the work that the development wants to perform when the criterion is satisfied. Figure 8 illustrates a detailed designer view showing the joining of criteria attributes to a Smart Network Request, according to aspects of the invention. Any number of criteria may be associated with a smart grid request. As illustrated by ipses 81 0 two criteria are currently associated with a network request. A developer can add and remove criteria for a network request through the graphical interface 830. The scroll list 830 includes twelve illustrative criteria. As discussed above, there may be many more types of criteria. The user interface can also be used to link the criteria.

Illustrative Operative Environment With reference to Figure 1, an illustrative system for implementing the invention includes a computing device, such as computing device 100. In a very basic configuration, the computing device 100 typically includes at least one processing unit 102 and system memory 104. Depending on the exact configuration and type of computing device, the system memory 104 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of both. The system memory 104 typically includes an operating system 105, one or more applications 106, and may include program data 107. In one embodiment, the application 106 may include an intelligent network request design tool 120 that is intended to configure network request criteria. This basic configuration is illustrated in Figure 1 by those components within the dotted line 108. The computing device 100 may also have additional features or functionality. For example, the computing device 100 may also include additional data storage devices (removable and / or non-removable) such as, for example, magnetic disks, optical discs, or tapes. Such additional storage is illustrated in Figure 1 through removable storage 109 and non-removable storage 1 10. Computer storage media includes both volatile and non-volatile, removable and non-removable media, implemented in any method or technology for storing information , such as computer-readable instructions, data structures, program modules or other data. The system memory 104, removable storage 109 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, storage on a magnetic disk or other magnetic storage devices, or any other means that can be used to store the desired information and that can be accessed by the computing device 100. Any such computer storage means can be part of the device 100. The computing device 100 may also have the input device (s) 12 such as keyboard, mouse, pen, voice input device, touch input device, etc. The output device (s) 14 such as presentation, speakers, printer, etc. They can also be included. The computing device 100 may also contain communication connections 1 16 which allow the device to communicate with another computing device 1 18, such as in a network. The communication connection 1 16 is an example of communication media. The media may typically be represented by computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and include any means of supplying information. The term "modulated data signal" means a signal having one or more of its characteristics set or changed in such a way that it encodes the information in the signal. By way of example, and not limitation, the communication means include means by cables, such as a network with cables or a direct cable connection, and wireless means such as acoustic, RF, infrared and other wireless media. The term "computer-readable media" as used herein includes both storage media and communication modes. Figure 2 illustrates a mobile computing device that can be used in an illustrative embodiment of the present invention. With reference to Figure 2, an illustrative system for implementing the invention includes a mobile computing device, such as a mobile computing device 200. The mobile computing device 200 includes the processor 260, memory 262, presentation 228, and key pad. 232. Memory 262 generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, flash memory, or the like). The mobile computing device 200 includes the operating system 264, such as the Windows CE operating system of Microsoft Corporation, or another operating system, which is resident in the memory 262 and is executed in the processor 260. The key pad 232 may be a push button number dial pad (such as a typical telephone), a multiple key pad (such as a conventional key). The presentation 228 may be a liquid crystal display or any other type of presentation commonly used in a mobile computing device. The presentation 228 may be touch sensitive and then also act as an input device. One or more application programs 266 are loaded into the memory 262 and run on the operating system 264. An application using intelligent network requests resides in the mobile computing device 200 and is programmed to interact with a network request administrator to execute network requests asynchronously. The application may reside in the hardware or software of the device. The mobile computing device 200 also includes non-volatile storage 268 within the memory 262. The non-volatile storage 268 can be used to store persistent information that should not be lost if the mobile computing device 200 is turned off. The mobile computing device 200 includes 270 power source, which can be implemented as one or more batteries. The power source 270 may further include an external power source, such as an AC adapter or a powered dock stand that powers or recharges the batteries. The mobile computing device 200 is shown with two types of optional external notification mechanisms: LED 240 and audio interface 274. These devices can be directly coupled to the power source 270 so that when they are activated, they remain on for a mandated duration by the notification mechanism even though the processor 260 and other components can be closed to conserve battery power. The audio interface 274 is used to provide audible signals and to receive audible signals from the user. For example, the audio interface 274 may be coupled to a speaker to provide audible output and to a microphone to receive audible input, such as to facilitate a telephone conversation. The mobile computing device 200 also includes communication connection (s), such as wireless interface design, which performs the function of transmitting and receiving communications. The communications connection 272 facilitates wireless connectivity between the mobile computing device 200 and the outside world. The communication connection can be configured to connect to any type of wireless network. According to one embodiment, the transmissions to and from the communications connection 272 are conducted under the control of the operating system 264. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims appended hereto.

Claims (5)

1. CLAIMS 1 .- A method implemented by computer to attribute network requests with criteria, comprising: creating a network request that is associated with an application; associate criteria with the network request before the network request is sent for execution; configure the criteria, where the configuration of the criteria includes adjusting properties that are related to the criteria; send the network request to be made; and determine when the criteria that are associated with the network request are satisfied, and when the criteria are satisfied; Try to execute the request.
2. 2. The method according to claim 1, further comprising determining when the execution of the network request is successful and providing the application with an event indicating the success of the execution of the request.
3. 3. The method according to claim 2, further comprising associating the code directed by the event that is executed in response to the event provided to the application.
4. 4. The method according to claim 3, wherein the criterion is selected from at least one of: network link criteria and application criteria. 5. - The method according to claim 4, wherein the criteria include at least one of: bandwidth; type of link; weather; Location; achievable server; address of I P; signal strength; and safety signal. 6. The method according to claim 2, wherein the criteria can be logically linked. 7. The method according to claim 2, wherein the network request can be executed using different types of network. '8.- A computer-readable medium that has computer executable instructions for attributing network requests with criteria, the instructions include: creating a network request that is associated with an application; associate criteria with the network request and configure the criteria before the network request is sent for execution, where the criteria are related to network link criteria; send the network request for it to be done; determine when the criteria that are associated with the network request are satisfied, and when the criteria are satisfied; try to execute the request; determine when the link execution of the network request is successful and provide the application with an event that indicates the successful execution of the request. 9. The computer readable medium according to claim 8, which links at least one of the criteria. 10. The computer readable medium according to claim 8, wherein determining when the criteria are satisfied comprises determining if each of the criteria is satisfied once the criterion is associated with more than one application. 1 - The computer readable medium according to claim 10, wherein the criteria include at least one of: bandwidth; type of link; weather; Location; achievable server; IP address; signal strength; a safety signal. 12. - The computer readable medium according to claim 10, wherein the network request can be executed using more than one type of network. 13. A system for processing network requests, comprising: an application coupled to a network and configured to send network requests for execution, wherein the network requests have zero or more associated criteria; a network request administrator coupled to the application and configured to perform actions, including: receiving a network request submission from the application; determine when the criteria that are associated with the network request are satisfied; and when the criteria are satisfied: execute the network request asynchronously; determine a result of the execution; and provide an event for the application that indicates the result of the execution. 14. The system according to claim 13, where the network request administrator is also configured to place the network request in a query of pending requests until it is determined that the criteria are satisfied.
5. 5. The system according to claim 14, wherein the network request administrator is further configured to move the network request to a successful query when the execution summary indicates success and move the network solitude. for a query failure when the execution result indicates failure. 16. The system according to claim 13, wherein the application is further configured to activate the rigid code per event that is associated with the result of the network request. 17. - The system according to claim 1, wherein the criteria associated with the network request are selected from at least one of: bandwidth; type of link; weather; Location; achievable server; address of I P; signal strength; a safety signal. The system according to claim 14, wherein the network request administrator is further configured to determine when the lapse of criteria is associated with multiple applications, and when the criteria are associated with more than one application that determines if the criteria are satisfied only once. 9. The system according to claim 13, further comprising a graphical user interface configured to associate the criteria with network requests. 20. The system according to claim 19, wherein the graphical user interface is further configured to associate code with the criteria to be executed in response to the result of the execution of the network request. SUMMARY Flexible attributes are linked to network requests that can be executed asynchronously. Any number of criteria can be linked to network requests. The requests are consulted until the associated criteria are met. Once the criteria are satisfied, the request is executed. The applications that make the requests are provided with simple success and failure notifications that respond with varied logic. Any type of criteria can be attached to a request. The criteria may be associated with applications at design time of the application using a graphical user interface.