US20090235282A1

Movatterモバイル変換

Info

Publication number: US20090235282A1
Application number: US12/046,550
Authority: US
Inventors: Erik Meijer; Jeffrey van Gogh; John Wesley Dyer
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2008-03-12
Filing date: 2008-03-12
Publication date: 2009-09-17

Abstract

Application remote control is affected across execution contexts. In one instance, input can be acquired from controlled applications and employed by other applications. Additionally or alternatively, remote control can be employed to test applications while minimizing unintended changes to applications under test caused by observation.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The subject application is related to U.S. patent application Ser. No. 11/752,662, filed May 23, 2007, and entitled NATIVE ACCESS TO FOREIGN CODE ENVIRONMENT and U.S. patent application Ser. No. 11/941,638, filed Nov. 16, 2007, and entitled DEBUGGING MULTI-EXECUTION ENVIRONMENT APPLICATIONS, the entireties of which are incorporated herein by reference.

BACKGROUND

Application software provides users with specific useful functionality. Computers and other processor-based devices provide hardware that is harnessed by applications to affect such functionality. Accordingly, application software converts computers into specialized machines that perform tasks prescribed by the application. Some applications have tight links to processing machines. Conventional client applications, for instance, are tied to particular computing platforms or hardware architectures. For example, applications designed for platform “X” are not executable on platform “Y” and vice versa. Furthermore, if it is desirous to employ an application on another machine even of the same platform, the application needs to be installed thereon.

With the advent of the Internet and World Wide Web (“Web”), informational access became much less platform dependent. The Internet provides a publically accessible interconnected network of computers. The Web is a collection of documents that are available via the Internet. Web browsers are applications that provide a portal to the Internet and collections of accessible information in the form of websites. While browsers themselves are platform dependent, the information and presentation thereof is platform independent. Accordingly, individuals employing disparate machines can all view the same websites.

The Web is continually evolving into much richer computing environment. For the most part, early versions of the Web enabled users to do little more than retrieve published information. Today's version, referred to by some as “Web2.0,” provides a much more interactive experience. Among other things, the network itself is now an application platform. Users are thus able to execute and interact with software applications entirely within web browsers replacing actual machine dependency with virtual machine dependency (e.g. Java Virtual Machine (JVM), Common Language Runtime (CLR) . . . ), for instance.

Furthermore, participation is encouraged in the evolving Web. Rather than simply being a receiver of information of a particular form, users are encouraged to contribute to network content and are able to control how information is provided to them. For example, in addition to those provided by companies, individuals author reusable application components or small programs such as gadgets or widgets that provide an interface for data interaction. Users can then select and employ one or more of these components (e.g., stock ticker, weather, Web feeds . . . ) for use on a desktop or within a browser, for instance.

SUMMARY

The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview. It is not intended to identify key/critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

Briefly described, the subject disclosure pertains to remote application control. In accordance with an aspect of the disclosure, an application of a first execution context can be controlled by a control application of a second execution context. Control can be affected by simulating human action with respect to a user interface, with direct object model calls or the like, or a combination thereof In general, control can be employed to acquire information from an application. In one particular instance, control can be utilized to test an application to ensure intended results. Furthermore, control can be imposed upon any application including, without limitation, conventional client applications, as well as web applications.

According to another aspect, control code including associated application programming interfaces (APIs) can be written once and utilized to control a plurality of applications across different execution contexts. Mechanisms are provided to facilitate translation or transformation from source, control code executable in one context to target, control code executable in another context. In this manner, control functionality need only be specified once but used repeatedly in various contexts, rather than writing new control code for each context.

To the accomplishment of the foregoing and related ends, certain illustrative aspects of the claimed subject matter are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the subject matter may be practiced, all of which are intended to be within the scope of the claimed subject matter. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an application remote control system in accordance with an aspect of the disclosed subject matter.

FIG. 2 is a block diagram of a representative control component according to a disclosed aspect.

FIG. 3 is a block diagram of a representative control component in accordance with an aspect of the disclosure.

FIG. 4 is a block diagram of a representative initialization component according to an aspect of the disclosed subject matter.

FIG. 5 is a block diagram of an application testing system in accordance with a disclosed aspect.

FIG. 6 is a flow chart diagram of a remote control method in accordance with an aspect of the disclosed subject matter.

FIG. 7 is a flow chart diagram of a remote control communication method according to an aspect of the disclosure.

FIG. 8 is a flow chart diagram a remote control support method according to an aspect of the subject disclosure.

FIG. 9 is a schematic block diagram illustrating a suitable operating environment for aspects of the subject disclosure.

FIG. 10 is a schematic block diagram of a sample-computing environment.

DETAILED DESCRIPTION

Systems and method pertaining to remote application control are described in detail hereinafter. A control component executable in one execution context can control an application executable in a different execution context. Control can be affected though a user interface, document object model or the like, or a combination thereof. A number of mechanisms are provided to facilitate such interaction including a call translator and a marshalling component, among others. Control can be employed with respect to traditional applications as well as web applications. Furthermore, control can be utilized to interact with applications for instance to acquire particular information or to test an application.

Various aspects of the subject disclosure are now described with reference to the annexed drawings, wherein like numerals refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the claimed subject matter.

Referring initially toFIG. 1, an applicationremote control system100 is illustrated in accordance with an aspect of the claimed subject matter. As shown, thesystem100 includes acontrol component110 and anapplication component120. Theapplication component120 can be any software application, web application, or component thereof. For example, the application component can be embodied as a spreadsheet application, a macro, or widget, among other things. Thecontrol component110 is a mechanism for controlling theapplication component120. In one embodiment, this can be accomplished utilizing an existing plug-in model of the application. Alternatively, if such a plug-in model is not available, this can be accomplished through injection of code within theapplication component120 and/or associatedexecution context122 so as not to alter theapplication component120.

In one instance, thecontrol component110 can acquire data from the application. By way of example, where theapplication component110 is embodied as an email application, thecontrol component110 can control the email application in a way that enables email to be retrieved. The retrieved email can subsequently be provided to another application or otherwise utilized. It is to be appreciated that the functionality associated withcontrol component110 goes beyond simple interaction since that implies that theapplication component120 has provided some mechanisms or hooks to enable such interaction. That need not be the case. In this instance, the email application does not need to provide an interface to enable thecontrol component110 to interact with it. As will be described further infra, thecontrol component110 can utilize higher-level mechanisms (e.g., accessibility/window messaging APIs, native execution environment APIs . . . ) to take control of theapplication component120. Accordingly, thecontrol component110 can interact with almost any application.

In another embodiment, thecontrol component110 can be employed to test theapplication component120. Here, a number of actions are performed followed by one or more tests. These tests can then be executed on a newly developed or updatedapplication component120, for instance, to verify that it functions as intended. For instance, spreadsheet macros can be tested to ensure that they operate as desired.

Note that control is performed in a remote manner. In particular, thecontrol component110 andapplication component120 are illustrated in different execution contexts, namelyexecution context A112 andexecution context B122, respectively. The execution context can include any execution environment, engine, framework or the like that executes/interprets instructions to perform an action. Execution context, can include, but are not limited to virtual machine environments, such as a Java Virtual Machine (JVM), Parrot, or the Common Language Runtime (CLR); native environments, such as native machine instructions; a component object model environment, such as COM and XPCOM; or a scripting environment, such as JavaScript or VBScript. Further, context can differ as a function of execution location (e.g., web browser vs. server-side vs. specific application software).

Often an execution context will have one or more programming languages associated with it (e.g., Java with the Java Virtual Machine, or C# and Visual Basic on the Common Language Runtime) although some programming languages can be compiled/interpreted to result in code that operates in more than one execution context (e.g., C++ to COM and native computer instructions). It is to be appreciated that different execution contexts can refer to dissimilar types of execution environments (e.g., scripting and virtual machine environments) or can include different versions of the same execution environment.

The separation ofcontrol component110 andapplication component120 has added benefits in the testing embodiment. By separating thecontrol component110 andapplication component120 across

different execution contexts

112 and122, respectively, it can be ensured that a test will not hang should something go wrong with theapplication component120. In other words, the separation provides a deterministic exit even in the event of an application failure. Furthermore, the Heisenberg effect can be minimized or completely avoided where thecontrol component110 andapplication component120 act independently. Otherwise, the act of observing the result of tests could change the application itself by adding additional memory pressure, among other things.

FIG. 2 depicts arepresentative control component110 in accordance with an aspect of the claimed subject matter. As shown, thecontrol component110 includes auser interface component210 and anobject model component220 as control mechanisms. Theuser interface component210 enables thecontrol component110 to simulate human actions such as cursor movements, mouse clicks, text entry, and the like. In a testing scenario, this is helpful to replicate human behavior to ensure an application will respond appropriately with respect to various human inputs and combinations thereof Theobject model component220 enables thecontrol component110 to access an applications underlying structure or representation. For example, rather than simulating keyboard entries in a text box to set a value, the object model associated with an application, or the like, can be employed to directly set the value via a particular API, for instance. This is a fundamentally more powerful control mechanism, because it is not dependent upon the interface or style thereof. For instance, there may be a style in which a value of interest is invisible, or otherwise inaccessible via the provided interface, but it is still available in the object model. Furthermore, theobject model component220 enables direct testing of application programming interfaces (APIs).

Thecontrol component110 provides a range of control from broad interface control to fine object model control. Conventional, testing frameworks only allow action of the user interface level. Here, control is enabled at high through low levels. Mouse or keyboard actions can be simulated, a specific API can be called or a combination thereof

Sometimes it is good to test what happens when keystrokes are sent, because there might be some timing involved. For instance, if for each keystroke a network call is made, it might make sense in a test to send keystrokes one by one and maybe have some non-determinism where they are sent at different intervals. In other cases, the only thing that may be sought is a value inserted upon a click of a button. In this scenario, it is unnecessary to insert keystrokes one by one. This is not what is being tested. Rather, one may desire to observe how the application reacts upon clicking the button. Just using user interface functionality will not provide that ability. Conversely, if only object model control was enable then UI control would not be available to do other things. Accordingly,control component110 includes the best of both worlds.

Turning attention toFIG. 3, arepresentative control component110 is illustrated in accordance with an aspect of the claimed subject matter. Here, thecontrol component110 includes various mechanisms to facilitate remote control including initialization component,control code component320,execution engine330,translation component340, marshallingcomponent350 andcode generation component360. Accordingly, thecontrol component110 can also be referred to as a control framework or in a testing scenario as a test framework.

Theinitialization component310 provides initialization and/or support functionality needed to commence control of an application and later terminate control. Turning briefly toFIG. 4, arepresentative initialization component310 is illustrated that further details particular functionality that can be provided thereby. As depicted, theinitialization component310 includes alaunch component410 that launches or spawns a particular execution context. For example, thecomponent410 can launch a web browser and/or a particular execution engine (e.g., Java Virtual Machine, flash, Common Language Runtime . . . ).Application loader component420 loads anapplication component120 with respect to the launched execution context. For instance, theapplication loader component420 can load a web application or webpage within a web browser. Call/callback component430 can inject a piece of code within the loadedapplication component120 and/or associated execution context to facilitate calling into and returning callbacks from theapplication component120.Communication setup component440 sets up a communication channel between the execution context of a control application and the execution context of the application to be controlled.

Returning toFIG. 3, thecontrol code component320 specifies control and/or test functionality in a particular language (e.g., C#, C++, VB, Java . . . ). This is beneficial to developers since they can choose to implement control code in a language of their choice and take advantage of development tools including debuggers associated with the language and/or integrated development environment (IDE). Furthermore, the same application programming interfaces (APIs) that are used in program development can be employed to specify control and/or test code. Such control can be user interface based, object model based or a combination thereof. For example, the code can attempt to simulate human interaction with an application (e.g., cursor movement, mouse clicks, keyboard entries . . . ) and/or call directly into an object model or other APIs.

The execution engine330 (also a component as defined here) executes code afforded by thecontrol code component320 to affect the intent specified thereby. Theexecution engine330 alone or in conjunction with thecontrol code component320 can communicate with theinitialization component310 to configure and start initialization. For example, theexecution engine330 can initiate initialization by passing parameters indicative of an application and execution context.

Thetranslation component340 aids execution with respect to a target execution context by translating or facilitating translation of calls specified by the control code to application calls automatically. Accordingly, a single control application can be specified that can control any application regardless of environment. For example, a lone controlling application can operate with respect different web browsers without requiring changes to the controlling application. In a simple embodiment, the control code can include attributes and additional code identifying a specific implementation for various scenarios. Once contextual information is available pertaining to an application and/or execution thereof, the relevant code can be identified, generated based thereon, or otherwise employed in a translation. For example, each control call can include a code for specific browsers such that once a browser is identified the translation component can simply translate, select, and/or generate appropriate code as a function of the associated code. In one implementation, thetranslation component340 can act as a foreign function interface, for example as described in the incorporated application entitled NATIVE ACCESS TO FOREIGN CODE ENVIRONMENT.

Themarshalling component350 is a mechanism that enables cross-execution or environment communication between a control execution context or environment114 (FIG. 1) and an application execution context or environment122 (FIG. 1). For example, themarshalling component350 can maintain caches between the two environments to ensure object identity and initiate or perform serialization. Further yet, it is to be noted that since data types between the environments can be different, themarshalling component350 can cast parameters to their correct data type when exchanging between execution environments. In this manner, themarshalling component350 affords an execution environment bridge that mediates specific communications such as events, messages, or API calls between a controller and a controlee. In one embodiment, thetranslation component340 can simply identify how calls are to be translated and themarshalling component350 can perform the actual translation. See, for example, the related applications incorporated herein by reference.

Thecode generation component360 facilitates generation of control code or application programming interfaces (APIs) employable by the code. More specifically, thecode generation component360 is a mechanism that automatically generates code in a source language that facilitates translation into a target language. By way of example, a developer can simply specify a signature and optionally a specific attribute and perhaps related code and thecode generation component360 can generate the implementation. Moreover, the generated code can be produced in a manner that facilitates translation to a target language via thetranslation component340 and/or marshallingcomponent350. For example, the generated code can include a specific attribute such as “IMPORT” with target language code that implements the source language code to which it is attached. This can be accomplished as detailed further in the incorporated application entitled NATIVE ACCESS TO FOREIGN CODE ENVIRONMENT.

Referring toFIG. 5, anapplication testing system500 is illustrated in accordance with a specific embodiment of the claimed subject matter. Thesystem500 includes a specific embodiment of thecontrol component110 for testing, namely test component110. Thetest component110 is executable inside execution context orenvironment112. Thetest component110 seeks to testapplication component120. In this embodiment, theapplication component120 is a web application executable within abrowser510 and optional morespecific execution context122 including but not limited to a virtual machine.

Theweb browser510 includes abrowser helper component520 such as a testing plug-in. Thetest component110 and/or associated component functionality can ensure that theweb browser510 includes or loads thebrowser helper component520. Thiscomponent520 can include theinitialization component310 or described functionality that can launchbrowser510 and/orexecution context122, load theapplication component120 under test therein, and open a communication channel between thetest component110 and theapplication component120 via the execution context112,web browser510, andexecution context122. It is also to be noted that thebrowser helper component520 can inject code into theapplication component120, such as that provided by a supportedbrowser scripting API530, to facilitate making calls and callbacks to and from theapplication component120 through thebrowser helper component520, for example.

Once initialization is performed, the test component can execute test code within the execution context. This code can then be translated or transformed and transmitted to theapplication component120 for execution. In one instance, calls can be made to browser scripting code embodied by the browser scripting API. Information can be exchanged in both directions between the test and

application components

110 and120, respectively. When the test terminates, the browser helper component can facilitate reversing the initialization process by closing theapplication component120,execution context122, and browser510, among other things.

To facilitate further clarity with respect tosystem500 as well as other disclosed aspects, the following detailed portion is provided. It is to be appreciated that these details are provided solely to aid clarity and understanding with respect to aspects of the claimed subject matter. They are not meant to limit the spirit or scope of the claims in any manner.

The browser helper component or plug-in520 can include code that facilitates testing within the browser510. The plug-in520 can connect back totest component110 and register an object that will be responsible for marshalling generated JavaScript to the browser. It can also inject a piece of JavaScript into the loadedweb application120 that helps the plug-in520 perform JavaScript calls and callbacks. After initialization, testing can commence. The test can use APIs written in the same language as the test itself and they can be transformed or utilized to generate correct JavaScript code for thebrowser510. The APIs can be similar to others used to test web application with the exception that they can specify a particular browser to use as follows in the exemplary code snippet:


	public sealed class BrowserDriver : IDisposable
	{
	public BrowserDriver(BrowserType type, string url);
	public BrowserDriver(BrowserType type, string url, int
	timeOutInSeconds);
	public Keyboard Keyboard { get; }
	public BrowserType Type { get; }
	public void Dispose( );
	public static BrowserType[ ] AvailableBrowsers { get; }
	}
	public enum BrowserType
	{
	InternetExplorer = 0,
	Firefox = 1,
	}

This API also implements “IDisposable” which is a pattern where a developer writes his/her test employing a “using” statement and the moment the test completes, the test code will be automatically cleaned up and make sure the browser is closed and the communication channel is closed, among other things.

The following is sample code to test a web page “http://www.example.com”:


	foreach (var browser in BrowserDriver.AvailableBrowsers)
	{
	using (var bd = new BrowserDriver(browser,
	@“http://www.example.com”))
	{
	var q = Browser.Document.GetById<Input>(“q”);
	q.PerformFocus( );
	q.Value = “Sarpedon”;
	var btnG = Browser.Document.GetById(“go”);
	q.PerformClick( );
	HtmlFutures.AssertNavigationTo(“http://www.example.com/
	result.aspx”).Block( );
	Assert.IsTrue(Browser.Document.Body.InnerHtml.Contains(
	“Sarpedon”));
	}
	}

The “foreach” loop finds all available browsers a machine executing the test. The “using” statement indicates that for each browser the specified test should be run on the web page “example.com” and the browser closed thereafter. In the test, the HTML input element from the webpage identified as “q” is retrieved and made the active element, the value of “q” is then set to “Sarpedon,” the associated “GO” button is identified and a click is simulated thereon, and the test waits for a result page to be loaded. Subsequently, the result page is checked to determine if it include the intended result. It should be appreciated that element interaction could have been on a user interface level rather than utilizing direct object model calls and that events could be utilized in place of sleep/busy loops.

It is to be noted that a tester does not notice any difference between programming any other application in his/her favorite programming language even thought the test uses JavaScript and different browsers with APIs exposed through different frameworks.

APIs can also be tested as part of the web page. Conventional test frameworks lack direct support for such scenarios since they usually support purely UI testing and do not understand JavaScript APIs used on a webpage. Hence, testing such APIs cannot be done in a high-level language in which the test is written. For example, when testing a mapping application embedded in the webpage, the test can call into the API provided by the mapping application. To do so, the test code defines an API in the source language and employs the import mechanism described by NATIVE ACCESS TO FOREIGN CODE ENVIRONMENT incorporated herein by reference:


	[Import(ScriptMemberNameCasing = Casing.Pascal,
	PassInstanceAsArgument = false)]
	public class Map
	{
	private static int s_counter;
	[Import(“function(id) { return new VEMap(id); }”)]
	public extern Map(string id);
	public extern LatLong GetCenter( );
	}

Now the test can access information about the map in the application (by fetching a value of type Map from the page) without having to write a lot of glue to call out to the JavaScript in the page.

The aforementioned systems, architectures, and the like have been described with respect to interaction between several components. It should be appreciated that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. Sub-components could also be implemented as components communicatively coupled to other components rather than included within parent components. Further yet, one or more components and/or sub-components may be combined into a single component to provide aggregate functionality. Communication between systems, components and/or sub-components can be accomplished in accordance with either a push and/or pull model. The components may also interact with one or more other components not specifically described herein for the sake of brevity, but known by those of skill in the art.

Furthermore, as will be appreciated, various portions of the disclosed systems above and methods below can include or consist of artificial intelligence, machine learning, or knowledge or rule based components, sub-components, processes, means, methodologies, or mechanisms (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, classifiers . . . ). Such components, inter alia, can automate certain mechanisms or processes performed thereby to make portions of the systems and methods more adaptive as well as efficient and intelligent. By way of example and not limitation, thecode generation component360 can employ such mechanism to determine or infer test code to be generated from limited information.

In view of the exemplary systems described supra, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts ofFIGS. 6-8. While for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the claimed subject matter is not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the methodologies described hereinafter.

Referring toFIG. 6, aremote control method600 is illustrated in accordance with an aspect of the claimed subject matter. Atreference numeral610, a control application is executed within a first execution context. Atnumeral620, the action of an application in a second execution context is controlled by the control application. In this manner, control applications can be generated for and executed within a first execution context and used to control applications in different context. Control can be embodied as user interface simulations, direct object model level calls or a combination thereof. Control can be employed to retrieve information from the application for subsequent use or for testing the application among other things. For example, a client email application can be controlled to retrieve email and provide them to another application. Alternatively, a web application can be tested to ensure proper operation. In the case of testing, the separation of test and application under test allows the application under test to fail without causing the test to hang enables testing without disturbing the application under test, among other things.

FIG. 7 depicts a remotecontrol communication method700 according to an aspect of the disclosure. Atreference numeral700, a control application is executed in a first execution context. For example, a high-level object oriented language control program can be executed with a multi-language execution framework. Atnumeral720, control application calls are translated from a first to a second execution context. In on instance this can be done automatically as a function of an attribute on a control application construct identifying an alternate implementation. Atreference730, the translated calls are transmitted to the second execution context for execution. At reference numeral,740 callbacks can be received from the second execution context in a first execution context format. Accordingly, a test can be developed from and executed within a single execution context and utilized to control any other application associated with a different execution context.

Referring toFIG. 8, a flow chart diagram illustrates acontrol support method800 in accordance with an aspect of the claimed subject matter. In one embodiment, themethod800 can be executed by a browser helper or plug-in. However, the claimed subject matter is not limited thereto. Atreference numeral810, an execution context is launched. This can correspond to initiating one or more execution engines, among other things. For example, a web browser is spawned and a virtual machine initiated. Atnumeral820, a target application is loaded within the launched execution context. For instance, a web page is loaded within a web browser. Atreference830, a communication channel is setup or otherwise established between a control application in a first execution context and a target application in a second execution context. Atreference numeral840, control is passed to the controlling application. Atnumeral850, a determination is made as to whether the controlling application is finished or done. If no, the method continues to loop until it is done. When the control application is fished, the controlled application, execution engine and communication channel are all closed at860 and the method terminates.

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

As used herein, the term “inference” or “infer” refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines . . . ) can be employed in connection with performing automatic and/or inferred action in connection with the subject innovation.

Furthermore, all or portions of the subject innovation may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed innovation. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

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

With reference toFIG. 9, anexemplary environment910 for implementing various aspects disclosed herein includes a computer912 (e.g., desktop, laptop, server, hand held, programmable consumer or industrial electronics . . . ). Thecomputer912 includes aprocessing unit914, asystem memory916, and asystem bus918. Thesystem bus918 couples system components including, but not limited to, thesystem memory916 to theprocessing unit914. Theprocessing unit914 can be any of various available microprocessors. It is to be appreciated that dual microprocessors, multi-core and other multiprocessor architectures can be employed as theprocessing unit914.

Thesystem memory916 includes volatile and nonvolatile memory. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within thecomputer912, such as during start-up, is stored in nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM). Volatile memory includes random access memory (RAM), which can act as external cache memory to facilitate processing.

Computer

912 also includes removable/non-removable, volatile/non-volatile computer storage media.FIG. 9 illustrates, for example,mass storage924.Mass storage924 includes, but is not limited to, devices like a magnetic or optical disk drive, floppy disk drive, flash memory, or memory stick. In addition,mass storage924 can include storage media separately or in combination with other storage media.

FIG. 9 provides software application(s)928 that act as an intermediary between users and/or other computers and the basic computer resources described insuitable operating environment910. Such software application(s)928 include one or both of system and application software. System software can include an operating system, which can be stored onmass storage924, that acts to control and allocate resources of thecomputer system912. Application software takes advantage of the management of resources by system software through program modules and data stored on either or both ofsystem memory916 andmass storage924.

Thecomputer912 also includes one ormore interface components926 that are communicatively coupled to thebus918 and facilitate interaction with thecomputer912. By way of example, theinterface component926 can be a port (e.g., serial, parallel, PCMCIA, USB, FireWire . . . ) or an interface card (e.g., sound, video, network . . . ) or the like. Theinterface component926 can receive input and provide output (wired or wirelessly). For instance, input can be received from devices including but not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, camera, other computer and the like. Output can also be supplied by thecomputer912 to output device(s) viainterface component926. Output devices can include displays (e.g., CRT, LCD, plasma . . . ), speakers, printers and other computers, among other things.

FIG. 10 is a schematic block diagram of a sample-computing environment1000 with which the subject innovation can interact. Thesystem1000 includes one or more client(s)1010. The client(s)1010 can be hardware and/or software (e.g., threads, processes, computing devices). Thesystem1000 also includes one or more server(s)1030. Thus,system1000 can correspond to a two-tier client server model or a multi-tier model (e.g., client, middle tier server, data server), amongst other models. The server(s)1030 can also be hardware and/or software (e.g., threads, processes, computing devices). Theservers1030 can house threads to perform transformations by employing the aspects of the subject innovation, for example. One possible communication between aclient1010 and aserver1030 may be in the form of a data packet transmitted between two or more computer processes.

Thesystem1000 includes acommunication framework1050 that can be employed to facilitate communications between the client(s)1010 and the server(s)1030. The client(s)1010 are operatively connected to one or more client data store(s)1060 that can be employed to store information local to the client(s)1010. Similarly, the server(s)1030 are operatively connected to one or more server data store(s)1040 that can be employed to store information local to theservers1030.

Client/server interactions can be utilized with respect with respect to various aspects of the claimed subject matter. By way of example and not limitation, a test can execute on aclient1010 control an application resident on anotherclient1010 or aserver1030 across thecommunication framework1050.

What has been described above includes examples of aspects of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the disclosed subject matter are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the terms “includes,” “contains,” “has,” “having” or variations in form thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.