Three-layer web management protocol device emulation

A three-layer management protocol device emulator and method that emulates numerous Web management protocol devices using a single virtual machine. A client on a network believes that there are a large number of Web management protocol devices on the network. Embodiments of the emulator and method use a three-layer multiple-endpoint model. A proxy layer is used to emulate multiple devices by building an endpoint pool containing a large number of endpoint pairs corresponding to the emulated devices. The presentation layer is used to specifically translate and parse the Web management protocol, and the logic layer represents the logic for a specific Web management protocol device being emulated. Embodiments of the emulator and method receive a request from a client on the network, use the proxy layer, presentation layer and logic layer to process the request and obtain a response, and then send the response back to the requesting client.

BACKGROUND

A Web management protocol is a protocol for the management of servers, devices, applications, and a variety of Web services. One type of Web management protocol is called Web Services-Management (or WS-Management). The WS-Management protocol is a standard that was published in 2005 by a group of companies to ensure access and management of devices that comply with this standard regardless of their software and hardware infrastructure. There are an increasing number of devices, servers, software products and even other standards that support the WS-Management protocol.

In order to be viable a WS-Management software product needs to support and manage a wide variety of devices and systems. For example, some WS-Management software products support more than 100,000 different WS-Management devices. One difficulty, however, is that whenever a new WS-Management software product is released it is desirable that it be verified on each of these devices. This can be an enormous and expensive task requiring the use of tens of thousands or even more physical devices to build a verification environment in which to verify that the software product is compatible with each device.

SUMMARY

Embodiments of the three-layer management protocol device emulator and method are capable of emulating thousands of Web management protocol devices on a virtual machine. While embodiments of the emulator and method use a single virtual machine on a network, it seems to the software product being tested that there are hundreds and thousands of Web management protocol devices on the network. In some embodiments the Web management protocol used is the Web Services-Management. Embodiments of the three-layer management protocol device emulator and method use a three-layer multiple-endpoint model to provide large-scale emulation of Web management protocol devices. This allows a single emulator to emulate multiple instances of Web management protocol devices.

The three-layer multiple-endpoint model used by embodiments of the emulator and method contains three layers: (1) a proxy layer; (2) a presentation layer; and (3) a logic layer. Embodiments of the proxy layer interface with the Web management protocol devices or clients on the network. Embodiments of the proxy layer emulate multiple devices by building an endpoint pool containing a large number of endpoint corresponding to emulated devices. In some embodiments the endpoint pool contains Internet Protocol (IP) addresses and host names. This makes it appear to a client as if there are hundreds if not thousands of devices available on the network. Embodiments of the presentation layer are used to specifically parse the Web management protocol. Embodiments of the logic layer represent logic for a specific Web management protocol device.

Embodiments of the emulator and method allow large-scale verification for any software product that supports a Web management protocol (such as the WS-Management standard) in a cost-efficient and highly-manageable manner. This facilitates tremendous hardware and power savings as well as an improvement in the quality of a software product being verified. Moreover embodiments of the emulator and method allow application to virtually any kind of WS-Management device by simply replacing the logic layer of the model to match the logic of the WS-Management device being emulated.

Embodiments of the emulator and method receive a request from a client on the network at the proxy layer. The proxy layer then uses the endpoint pool to match up the client to a target device being emulated. The request and the target device data then are sent to the presentation layer which parses the request using the Web management protocol to obtain parsing results. The logic layer processes the parsing results and obtains a result. The result is sent back to the presentation layer which generates a response to the request based on the result. The response then is sent to the proxy layer which uses the endpoint pool to send the response back to the client that originally sent the request.

It should be noted that alternative embodiments are possible, and that steps and elements discussed herein may be changed, added, or eliminated, depending on the particular embodiment. These alternative embodiments include alternative steps and alternative elements that may be used, and structural changes that may be made, without departing from the scope of the invention.

DETAILED DESCRIPTION

In the following description of embodiments of the three-layer management protocol device emulator and method reference is made to the accompanying drawings, which form a part thereof, and in which is shown by way of illustration a specific example whereby embodiments of the three-layer management protocol device emulator and method may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the claimed subject matter.

I. System Overview

FIG. 1is a block diagram illustrating a general overview of embodiments of a three-layer management protocol device emulator100and method implemented on a computing device110. In general, embodiments of the three-layer management protocol device emulator100and method use a three-layer multiple-endpoint model to emulate Web management protocol devices on a large scale. Embodiments of the three-layer management protocol device emulator100and method communicate through a network120with client devices.

In particular, as shown inFIG. 1, Client #1130communicates through a first communication link135and the network120with embodiments of the three-layer management protocol device emulator100and method. Similarly, Client #140communicates through a second communication link145, Client #3150communicates through a third communication link155, and so forth until finally Client #N160communicates through an Nth communication link165with embodiments of the three-layer management protocol device emulator100and method. The ellipses170inFIG. 1denote that there may be any number of clients that are not shown. Moreover, it should be noted that although only four clients are shown inFIG. 1, typically N will be a large number (even in the tens of thousands).

FIG. 2is a block diagram illustrating details of interaction between a client computing device200and embodiments of the three-layer management protocol device emulator100and method shown inFIG. 1. The client computing device200may be one of the clients shown inFIG. 1. The client computing device200contains a software product to be tested (box210). As discussed above, the server computing device110and embodiments of the three-layer management protocol device emulator100and method communicate through the network120. It should be noted that the three-layer multiple-endpoint model based emulator is built on a single logic unit of the server computing device110(such that the server computing device110is the host machine of the logic unit). In other words, it is possible for the server computing device110to have multiple logic units, but embodiments of the system100and method resided on a single logic unit on the server computing device110. The single logic unit refers to one virtual machine or a one operating system running on the physical machine, which in this case is the server computing device110. The single logic unit can be a virtual machine hosting on a computer that has several virtual machines running on it. Alternatively, the logic unit can be defined as one operating system running on physical machine. Moreover, any computing devices connecting and accessing the server computing device110will be referred to as a client computing device200.

FIG. 2also illustrates additional details of embodiments of the three-layer management protocol device emulator100and method. In particular, the three-layer multiple-endpoint model includes a proxy layer220, a presentation layer230, and a logic layer240. Embodiments of the proxy layer220serve as an interface between embodiments of the three-layer management protocol device emulator100and method and the client computing device200. In particular, embodiments of the proxy layer220emulate multiple devices using multiple addresses. In some embodiments this is achieved for each instance of a device by using an Internet Protocol (IP) address pool, a Fully Qualified Domain Name (FQDN) pool (or called as a Domain Name System (DNS) name entry, and a listening model. But each IP address and FQDN represent a single instance of a device. This makes it seem the clients on the network that there are a large number of devices available on the network.

Embodiments of the presentation layer230are used to parse the Web management protocol. Embodiments of the logic layer240represent logic for specific Web management protocol device. Embodiments of the three-layer management protocol device emulator100and method can emulate any other Web management protocol-compatible device by plugging in a new embodiment of the logic layer240without modifying embodiments of the proxy layer220and presentation layer230.

II. Operational Overview

FIG. 3is a flow diagram illustrating the general operation of embodiments of the three-layer management protocol device emulator100shown inFIGS. 1 and 2. In general, embodiments of the three-layer management protocol device emulation method emulate multiple instances of Web management protocol devices by using a single emulator. Referring toFIG. 3, the method begins by starting an embodiment of the three-layer management protocol device emulator100on the server computing device110(box300). The three layers include the proxy layer220, the presentation layer230, and the logic layer240(box305).

Embodiments of the proxy layer220emulate multiple devices on the network (box310). This involves registering multiple DNS, IP addresses, and so forth, and listening and responding to any requests to these resources. In particular, embodiments of the proxy layer220receive a request from a client computing device (box315). The request is directed at one of the many devices that is being emulated by embodiments of the three-layer management protocol device emulator100. This request is processed by embodiments of the proxy layer220in order to match up the requesting client with the target device being emulated (box320). This matching is performed using an endpoint pool containing IP addresses and host names (box325).

Embodiments of the presentation layer230parse the request and transfer to this information to embodiments of the logic layer240(box330). More specifically, embodiments of the presentation layer230receive the request and then parse the request using the Web management protocol to obtain parsing results (box335). The parsing results then are sent to embodiments of the logic layer240(box340).

Embodiments of the logic layer240simulate the logic of the target device and return the results (box345). In particular, embodiments of the logic layer240process the request based on the parsing results to obtain a result (box350). This result then is sent to embodiments of the presentation layer230(box355). Embodiments of the presentation layer230then generate a response to the request based on the result (box360), and the response is sent to embodiments of the proxy layer220(box365). Embodiments of the proxy layer220use the endpoint pool to send the response back to the client that sent the request (box370).

III. System and Operational Details

The system and the operational details of embodiments of the three-layer management protocol device emulator100and method now will be discussed. These embodiments include embodiments of the proxy layer220, the presentation layer230, and the logic layer240. The system and operational details of each of these modules now will be discussed in detail.

Embodiments of the proxy layer220are the bottom layer of the three-layer multiple-endpoint model used by embodiments of the three-layer management protocol emulator100and method. In general, embodiments of the proxy layer200expose a web service to any Web management protocol client (such as WS-Management client) that connects to embodiments of the proxy layer220. More specifically, embodiments of the proxy layer220have two major functions. First, embodiments of the proxy layer220simulate multiple instances on a single logic unit. This means that embodiments of the proxy layer220bind multiple endpoints to the logic unit on the server computing device110such that those multiple endpoints are associated with and can be found on the server computing device110. Each of the multiple endpoints includes an IP address and a FQDN (or host name). The IP address and corresponding FQDN (or host name) represents one device instance. Usually, the client's request target an IP address or a FQDN, which represents the destination of that request. When the request is received by the proxy layer, the proxy layer determines which emulated device instance the request is going to by the IP address or by the FQDN (or host name). Embodiments of the proxy layer220make any Web management protocol client consider that every endpoint is an emulator instance on the network. Every endpoint includes one IP address & corresponding FQDN (or host name), and every endpoint then represents one emulated device instance.

Second, embodiments of the proxy layer220redirect Web management protocol requests from any endpoint to the presentation layer230. Again, each endpoint represents one instance on the network of an emulated device. Embodiments of the proxy layer220also send Web management protocol responses to Web management protocol client through an endpoint from where the request was received.

FIG. 4is a flow diagram illustrating the operational details of embodiments of the proxy layer220shown inFIG. 2. The operation begins by installing and starting embodiments of the emulator100on the server computing device110(box400). Once embodiments of the emulator100are installed, embodiments of the proxy layer220receive from the client computing device one or more requests (box410). Each request in this series of requests is directed to a device that can be emulated by embodiments of the emulator100.

Each request in the series of requests then is matched to one of the multiple endpoints contained in an endpoint pool (box420). In other words, proxy layer220matches the request by using an endpoint's IP address or FQDN (host name), The request is matched to an endpoint from the endpoint pool using the IP address that pairs to a corresponding FQDN, which is resolvable in DNS system. Embodiments of the proxy layer220then determine which of the multiple devices that embodiments of the emulator100can emulate are the target of the request (box430). The target of the request is called the emulator instance, and a target emulator instance identification is assigned to each request. Embodiments of the proxy layer220then forward each request to the presentation layer230along with the target emulator instance identification (box440).

The forwarded request then is processed by embodiments of the presentation layer230and the logic layer240. Embodiments of the proxy layer220then receive from the presentation layer230a response to each forwarded request (box450). Embodiments of the proxy layer220then match each response to the forwarded request, which corresponds to the request that was initially received at the proxy layer from the client computing device (box460). This matching is performed based each request's corresponding target emulator instance identification. Based on this matching, embodiments of the proxy layer220send a response back to the client computing device that initially sent the request (box470).

In order to simulate multiple instances of Web management protocol devices on network using a single logic unit on the server computing device110, embodiments of the proxy layer220are multiple instances capable. Multiple instances allow the isolation of resources associated with a given instance.FIG. 5is a block diagram illustrating details of an exemplary embodiment of the three-layer management protocol device emulator and method shown inFIGS. 1-3. Embodiments of the proxy layer220shown inFIG. 5contain an endpoint pool500. The endpoint pool500contains multiple pairs of IP addresses and host names, where each pair represents a single emulator instance. Each emulator instance has one IP address and a FQDN (or host name). The IP address and FQDN are pair and can be resolved to each other through DNS. By way of example, inFIG. 5the endpoint pool500illustrates a pair having an IP address of “170.10.10.15” and a host name of “WSMachine-1.abc.com.” This pair corresponds to a single emulator instance. The ellipses510denote that there can be more pairs in the endpoint pool500than are shown inFIG. 5. The IP address and host name will be registered to DNS, Dynamic Host Configuration Protocol (DHCP), WINDOWS® Internet Name Service (WINS) by MICROSOFT® Corporation of Redmond, Wash., and so forth. All of these IP address will be mapped to the identical Media Access Control (MAC) address associated with the logic unit on the server computing device110. Thus, by way of example, when a WS-Management client connects to any instance with either an IP address or a host name, the request will be directed to the logic unit on the server computing device110.

Referring again toFIG. 5, embodiments of the proxy layer220also include a listening module520that accepts incoming Web management protocol requests targeting any IP address or host name contained in the endpoint pool500. Embodiments of the listening module520then forward these requests to the embodiments of the presentation layer230. When a request is handled and a response is returned by embodiments of the presentation layer230, a response module530identifies the IP address that the request originally targeted. Embodiments of the response module530then send the response to the client computing device using the corresponding IP address or host name.

In the exemplary embodiment shown inFIG. 5the three-layer management protocol device emulator100emulates multiple WS-Management devices and is based on the three-layer multiple-endpoints model. The proxy layer is220is implemented independently which binds multiple endpoints. When the WS-Management requests are received and are directed to these endpoints, the proxy layer220will process them and forward it to embodiments of the presentation layer230.

In the embodiment of the presentation layer230shown inFIG. 5, WINDOWS® Remote Management (WinRM)540made by MICROSOFT® Corporation of Redmond, Wash., is used as the presentation layer230. WinRM540understands the WS-Management protocol. Moreover, WinRM540parses the WS-Management request and passes that to the logic layer240. WinRM540presentation layer230also contains a WS-Management protocol550and a WINDOWS® Management Infrastructure (WMI) plug-in560. WMI is made by MICROSOFT® Corporation of Redmond, Wash. WinRM540also assembles the WS-Management response using the results provided by the logic layer240.

The logic layer240is implemented based on a WMI provider570. The WMI provider570contains the logic portion of the emulated device. In particular, as shown inFIG. 5, the WMI provider570contains a WS-Management device logic580. The WMI provider570processes the request and then returns the result to the WinRM540. It should be noted that the exemplary embodiment shown inFIG. 5and the services used therein may be replaced by any number of other types of similar services.

FIG. 6is a flow diagram illustrating a detailed operation of an exemplary embodiment of the proxy layer220shown inFIGS. 2,4, and5. The operation of this exemplary embodiment begins by binding embodiments of the emulator100to multiple endpoints (box600). This is achieved by having embodiments of the proxy layer220allocate multiple IP addresses and host names in its endpoint pool and register them to DHCP, DNS, Wins, and so forth. Next, the exemplary embodiment of the proxy layer220starts the web service to listen from any WS-Management request (box605). A determination then is made as to whether a WS-Management request has been received (box610). If not, then the exemplary embodiment of the proxy layer220remains idle until it gets any WS-Management request (box615).

When a request is received the exemplary embodiment of the proxy layer220checks the authentication provided by the WS-Management client (box620). A determination then is made as to whether the WS-Management client needs a security channel (box625). If so, then in some embodiments a Transport Layer Security (TLS) channel is setup with a WS-Management client (box630). If not, then the TLS channel setup is skipped.

Next, the exemplary embodiment of the proxy layer220identifies which emulator instance the request is targeting (box635). In some embodiments this is achieved by obtaining the Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) data. Then exemplary embodiments of the proxy layer220direct the request to embodiments of the presentation layer230along with a target emulator instance identification (box640).

The exemplary embodiment of the proxy layer220then enters an idle mode (box645) and waits for response from the embodiments of the presentation layer230. Specifically, a determination is made as to whether a response has been received from the presentation layer230(box650). If a response has not been received then the exemplary embodiment of the proxy layer220continues in an idle mode (box655). Otherwise, when the response is received from embodiments of the presentation layer230, the exemplary embodiment of the proxy layer220sends the response back to the client. This response is sent back to the client by the proxy layer220using the endpoint that corresponds to the emulated device originally targeted by the request (box660). By doing this, it makes the response seems like sent from a WS-Management device on network (box665). An idle mode then is entered and the exemplary embodiment of the proxy layer220waits for another request from a client on the network (box670).

III.B. Presentation Layer

Embodiments of the presentation layer230are the middle layer of the three-layer multiple-endpoint model. One function of this layer is to understand the Web management protocol and to perform translation for the other two layers. In general, embodiments of the presentation layer230parse a Web management protocol request and send it to the correct location in embodiments of the logic layer240. Embodiments of the presentation layer230also assemble a Web management protocol response package containing results from embodiments of the logic layer240and forward it to embodiments of the proxy layer220.

FIG. 7is a flow diagram illustrating the operational details of embodiments of the presentation layer230shown inFIGS. 2 and 5. The operation begins by receiving from embodiments of the proxy layer220a request sent by a client along with the target emulator instance identification associated with the request (box700). Next, the results are parsed according to the Web management protocol in order to obtain parsing results (box710). Parsing means that the presentation layer230reads the request in the format of the Web management protocol, unpacks it according to the protocol, and understands the data contained in the request. Based on the parsing results, embodiments of the presentation layer230invoke corresponding methods in embodiments of the logic layer240by using the target emulator instance identification (box720). This passes the request on to embodiments of the logic layer240for processing.

Once embodiments of the logic layer240have completed processing, embodiments of the presentation layer230receives results from embodiments of the logic layer240(box730). These received results are assembled by embodiments of the presentation layer230into a response based on the Web management protocol (box740). This response then is sent to embodiments of the proxy layer220(box750).

III.C. Logic Layer

Embodiments of the logic layer240are the top of the three-layer multiple-endpoint model. Embodiments of the logic layer240are fulfilled by the simulated device's logic. In addition, embodiments of the logic layer240maintain an exclusive copy of metadata for every emulator instance. In some embodiments this metadata includes configuration, status and data.

FIG. 8is a flow diagram illustrating the operational details of embodiments of the logic layer240shown inFIGS. 2 and 5. The operation begins by receiving a request and the corresponding target emulator instance identification from embodiments of the presentation layer (box800). Once it accepts the request from embodiments of the presentation layer230, embodiments of the logic layer240locate and retrieve metadata corresponding to the target emulator instance identification (box810). In particular, the data of a specific emulator instance is located and retrieved. Next, the request is processed using the retrieved metadata to obtain a result (box820). Embodiments of the logic layer240then send or return the result to embodiments of the presentation layer230(box830).

One benefit from the three-layer multiple endpoint model is that embodiments of the logic layer240are independent from the Web management protocol. Embodiments of the logic layer240only need to focus on a Web management protocol device's specific logic and functionality. Embodiments of the logic layer240also manage every copy of metadata for each emulator instance. This means that every for every emulator instance the logic unit of the server computing device110is able to maintain its own data and status. Therefore, every emulator instance is an independent unit. With this approach a single logic unit on the server computing device110can behave as if it were multiple Web management protocol devices on the network.

IV. Exemplary Operating Environment

Embodiments of the three-layer management protocol device emulator100and method are designed to operate in a computing environment. The following discussion is intended to provide a brief, general description of a suitable computing environment in which embodiments of the three-layer management protocol device emulator100and method may be implemented.

FIG. 9illustrates an example of a suitable computing system environment in which embodiments of the three-layer management protocol device emulator100and method shown inFIGS. 1-8may be implemented. The computing system environment900is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment900be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment.

Embodiments of the three-layer management protocol device emulator100and method are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with embodiments of the three-layer management protocol device emulator100and method include, but are not limited to, personal computers, server computers, hand-held (including smartphones), laptop or mobile computer or communications devices such as cell phones and PDA's, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Embodiments of the three-layer management protocol device emulator100and method may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Embodiments of the three-layer management protocol device emulator100and method may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices. With reference toFIG. 9, an exemplary system for embodiments of the three-layer management protocol device emulator100and method includes a general-purpose computing device in the form of a computer910.

Components of the computer910may include, but are not limited to, a processing unit920(such as a central processing unit, CPU), a system memory930, and a system bus921that couples various system components including the system memory to the processing unit920. The system bus921may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

The computer910typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by the computer910and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.

Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer910. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The system memory930includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM)931and random access memory (RAM)932. A basic input/output system933(BIOS), containing the basic routines that help to transfer information between elements within the computer910, such as during start-up, is typically stored in ROM931. RAM932typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit920. By way of example, and not limitation,FIG. 9illustrates operating system934, application programs935, other program modules936, and program data937.

The computer910may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,FIG. 9illustrates a hard disk drive941that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive951that reads from or writes to a removable, nonvolatile magnetic disk952, and an optical disk drive955that reads from or writes to a removable, nonvolatile optical disk956such as a CD ROM or other optical media.

Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive941is typically connected to the system bus921through a non-removable memory interface such as interface940, and magnetic disk drive951and optical disk drive955are typically connected to the system bus921by a removable memory interface, such as interface950.

The drives and their associated computer storage media discussed above and illustrated inFIG. 9, provide storage of computer readable instructions, data structures, program modules and other data for the computer910. InFIG. 9, for example, hard disk drive941is illustrated as storing operating system944, application programs945, other program modules946, and program data947. Note that these components can either be the same as or different from operating system934, application programs935, other program modules936, and program data937. Operating system944, application programs945, other program modules946, and program data947are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information (or data) into the computer910through input devices such as a keyboard962, pointing device961, commonly referred to as a mouse, trackball or touch pad, and a touch panel or touch screen (not shown).

Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, radio receiver, or a television or broadcast video receiver, or the like. These and other input devices are often connected to the processing unit920through a user input interface960that is coupled to the system bus921, but may be connected by other interface and bus structures, such as, for example, a parallel port, game port or a universal serial bus (USB). A monitor991or other type of display device is also connected to the system bus921via an interface, such as a video interface990. In addition to the monitor, computers may also include other peripheral output devices such as speakers997and printer996, which may be connected through an output peripheral interface995.

The computer910may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer980. The remote computer980may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer910, although only a memory storage device981has been illustrated inFIG. 9. The logical connections depicted inFIG. 9include a local area network (LAN)971and a wide area network (WAN)973, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer910is connected to the LAN971through a network interface or adapter970. When used in a WAN networking environment, the computer910typically includes a modem972or other means for establishing communications over the WAN973, such as the Internet. The modem972, which may be internal or external, may be connected to the system bus921via the user input interface960, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer910, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,FIG. 9illustrates remote application programs985as residing on memory device981. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.