CN111771191A

CN111771191A - Cross-domain inline event handler

Info

Publication number: CN111771191A
Application number: CN201980015493.7A
Authority: CN
Inventors: J·P·穆莱拉; E·哈克; J·R·沃伦; S·杨
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2018-02-26
Filing date: 2019-02-18
Publication date: 2020-10-13
Also published as: US10394628B1; EP3759603B1; EP3759603A1; US10684898B2; US20190266028A1; US20190310901A1; WO2019164774A1

Abstract

Event handler records for different event handlers in different domains are stored in the event handler coordinator service. The event handler record identifies the event handlers (in the various domains) that will be used to handle events raised in the different domains. When an event is raised, the event handler records will be filtered to identify event handlers that have indicated an interest in the raised event, and the endpoints corresponding to the identified event handlers will be provided back to the calling process. The calling process will then call the event handler for which the endpoint was returned.

Description

Cross-domain inline event handler

Background

Computing systems are now in widespread use. Some computing systems are used to host a wide variety of different services.

Services may be hosted in different domains. There are many different ways in which domains can be defined. For example, a domain is defined by a domain name, so two different services (or code bodies) with different domain names will run in different domains. In another definition, a domain is also defined as a microservice. A microservice is a process that communicates over a network (through a network interface) with another microservice (or process) using a technology-independent protocol, such as hypertext protocol (HTTP). The microservice may be deployed independently of other microservices. A single application may be decomposed into microservices. In this case, the application is structured as a collection of loosely coupled microservices. Each of these microservices is considered a different domain.

In such computing systems, when a process raises an event, an event handler is typically invoked. An inline (in-line) event handler is an event handler that is currently located in the same domain that runs the calling process and that executes in synchronization with the code that caused the event (or the calling process of the event source).

Running the event handler logic in-line with the code that caused the event allows the event handler to inject logic (e.g., verify data or operation failure) into the code that originated the event. For example, one event handler may update calculated data before one operation saves the data to disk, while another event handler may fail the operation because the data is invalid.

However, an event handler in a domain (or microservice) different from the domain (or microservice) that caused the event may be interested in the event. Currently, event handlers for other domains or microservices (outside the domain that caused the event) are called asynchronously. However, this makes it difficult to process the results from the asynchronous event handler before the operation that caused the event is completed. Thus, these event handlers do not inject logic as do inline event handlers.

The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.

Disclosure of Invention

Event handler records for different event handlers in different domains are stored in the event handler coordinator service. The event handler record identifies the event handlers (in the various domains) that will be used to handle events raised in the different domains. When an event is raised, the event handler record will be filtered to identify event handlers that have indicated an interest in the raised event, and the end point (end point) corresponding to the identified event handlers will be provided with a call back process. The calling process will then call the event handler for which the endpoint was returned.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the invention, nor is it intended to be used as an aid in limiting the scope of the invention. The subject matter of the present disclosure is not limited to implementations that solve any or all disadvantages noted in the background.

Drawings

FIG. 1 is a block diagram of one example of a computing system architecture.

FIG. 2 is a block diagram illustrating one example of an event handler coordinator service in more detail.

FIG. 3 is a flowchart illustrating one example of the operation of an event handler coordinator service when registering an event handler.

FIG. 4 is a flow diagram illustrating one example of the operation of an event handler coordinator service in response to an event raised by a calling service.

FIGS. 5A and 5B (collectively referred to herein as FIG. 5) show a flowchart illustrating one example of the operation of a calling process that raises an event when an event handler is called in a different domain.

Fig. 6 is a flowchart showing one example of the operation of a calling process when providing data to an event handler.

Fig. 7 is a partial block diagram and partial sequence diagram illustrating an example of the operation of the architecture shown in fig. 1 when event handler linking is performed.

FIG. 8 is a block diagram illustrating one example of the architecture shown in FIG. 1 deployed in a cloud computing architecture.

FIG. 9 is a block diagram illustrating one example of a computing environment that may be used in the architecture used in the previous figures.

Detailed Description

FIG. 1 is a block diagram illustrating one example of a computing system architecture 100. Architecture 100 illustratively includes a plurality of different domain computing systems 102 running separate domains or microservices 104. The domains or microservices running on

domain computing systems

102 and 104 are independently deployable modules or services that communicate with each other over network 106. Thus, each domain or microservice running on the computing system 102-104 communicates with each other through the network interface 108-110, respectively. A domain or microservice may be identified by a unique domain name. The domains or microservices running on

computing systems

102 and 104 also communicate with each other over network 106 using technology independent protocols such as hypertext transfer protocol (HTTP). Herein, the terms "domain" and "microservice" will be used interchangeably.

FIG. 1 also shows that the

domain computing system

102 and 104 are illustratively coupled to an event handler coordinator 112, where the event handler coordinator 112 can be a service. The event handler coordinator service 112 illustratively allows events raised in one of the

domain computing systems

102 and 104 to be synchronously acted upon by event handlers in the other of the

domain computing systems

102 and 104. Before describing the overall operation of the architecture 100 in more detail, a brief description of certain items in the architecture 100 and their operation will first be provided.

The domain computing system 102 illustratively includes one or more processors or servers 114, domain or microservice functions including a calling process 116, other domain or microservice functions 118, an event handler subsystem 120, a data store 122, a network interface 108, and it may include a wide variety of other items 124. The event handler subsystem 120 illustratively includes a set of event handlers 126 and 128, propagation service interaction logic 130, and it may include other items 132. Domain computing system 104 may also include one or more processors or servers 134, a set of domain or microservice functions 136 (which are different domains or microservices than those running on domain computing system 102), an event handler subsystem 138, a data store 140, network interfaces 110, and it may include a wide variety of other items 142. The event handler subsystem 138 may include a set of event handlers 144, 146, a propagation service interaction logic 148, and it may include other items 150.

Illustratively, the calling process 116 is a process that will raise an event when performing a domain function (of interest to an event handler) for a microservice or domain function running on the domain computing system 102. Thus, it will invoke the event handler of interest. Other domain functions 118 illustratively include the remaining functions and logic running on domains or microservices running on domain computing system 102.

The event handlers 126 and 128 in the event handler subsystem 120 illustratively process information generated by events raised within the domain computing system 102 or on another domain computing system (e.g., domain computing system 104). To process information caused by events on the different domain computing systems 104, the event handlers 126 and 128 illustratively use the propagation service interaction logic 130 to communicate with the event handler coordinator service 112. As will be described in greater detail below, the logic 130 illustratively provides for the identification of various events that are of interest to each event handler 126 and 128, as well as the endpoints (e.g., URLs) at which the corresponding event handler may be invoked by the invocation service. It may also provide a data identifier to identify data that is of interest to the event handler at the time of invocation.

Similarly, domain functions 136 are illustratively logic or functions performed by a microservice or domain running on domain computing system 104. It may itself comprise processes that raise events, and thus these processes may also become calling processes.

As with the event handlers 126 and 128, the event handlers 144 and 146 in the event handler subsystem 138 use the propagation service interaction logic 140 to indicate to the event handler coordinator service 112 the events that are of interest to those event handlers. They may also provide an indication of the endpoint (where the calling service may call the endpoint), and which event data is needed for the calling service.

As a brief overview, assume that the event handler 144 has indicated to the event handler coordinator service 112 that it is interested in events raised by the calling process 116. In this case, when the calling process 116 raises an event, it calls the event handler coordinator service 112 to discover a list of endpoints that the event handler interested in the event can call. It then calls the event handler 144 using the corresponding endpoint and provides it with event payload data so that the event handler 144 can perform its processing on the event. It waits for the event handler 144 to return a call before continuing with its own processing steps. In this way, it is possible to synchronously call even an event handler located in a different domain from the calling process and provide inline logic for the calling process without changing the code in the calling process or injecting any additional code into the calling process.

FIG. 2 is a block diagram illustrating one example of the event handler coordinator service 112 in more detail. In the example shown in FIG. 2, the service 112 illustratively includes one or more processors or servers 152, event handler interaction logic 154, a query processing system 156, event handler call storage 158, and it can include a wide variety of other items 160. The query processing system 156 itself illustratively includes communication logic 162, event handler record filtering/retrieval logic 164, and it may include other items 166. The event handler and call store 158 illustratively includes a call file 168 having one or more event handler records for events raised by different domains (e.g., domain 1-domain N). Each event handler record 170 and 172 illustratively includes a source domain type identifier 174 that identifies the type of domain that serves as the source of the event (where the calling process is located). Each record 170 and 172 also illustratively includes an endpoint 176 at which an event handler corresponding to the event handler record may be invoked 176. The record 170 includes 172 also illustratively filter criteria 178, the filter criteria 178 illustratively identifying a list of events in that particular domain that are of interest to the event handler corresponding to the record.

For example, assume the event handler record 170 corresponds to the event handler 144 in the domain computing system 104. Further, assume that event handler 144 is interested in events raised by calling process 116 in domain computing system 102. In this case, the source domain type 144 would identify the type of source domain 102 that is running the calling process 116. The endpoint 176 will identify a URL (or other endpoint) that may be called to launch the event handler 144. The filter criteria 178 will list the events that the event handler 144 elicited by the calling process 116 is interested in. The required data identifier 180 illustratively identifies the event payload (or event data) that will be used once the event handler 144 is invoked. The enable/disable indicator 182 includes a value that indicates whether the event handler is enabled or disabled for the particular event list identified in the filter criteria 178. The event handler record 170-172 may also include various other items 184. Additionally, event handler and call store 158 may include other items 186 in addition to call files 168.

The event handler interaction logic 154 illustratively handles communication between the propagation service interaction logics 130 and 148 (shown in FIG. 1) and the event handler coordinator service 112. For example, when an event handler (e.g., event handler 144) is registering an event, the event handler interaction logic 154 illustratively identifies the various items in the event handler record 170 that correspond to the event handler 144, as well as the one or more events it is registering.

Query processing system 156 then processes the query of the calling process when the calling process raises an event. For example, when the calling process 116 raises an event of interest to the event handler 144, it then communicates with the query processing system 156 through the network interface 108 and communication logic 162 via: provides an indication of the event it raises and requests the various event handlers that have registered as being interested in the event. The event handler record filter/retrieval logic 164 then filters the various event handler records 170 for domain 1 (the domain in which the calling process 116 is located) to identify those event handlers that indicate an interest in the event that the calling process 116 has just raised. It is determined whether these event handlers are enabled (by checking the value of the enable/disable indicator 182) and, for the enabled event handlers, it returns the endpoint 176 and the required data 180 to the calling process 116. The calling process 116 may then call an event handler on the endpoint and provide it with event data to be used in performing event handler processing of this event. Different methods of providing event data will also be discussed below.

In one example, when an event handler (e.g., event handler 144) is interested in events raised by calling processes in multiple different domain computing systems, then event handler records 170 and 172 will be created for the event handler under the different domains (e.g., domain 1-domain N) that will be the source of the events. Thus, if a particular event handler is interested in events raised in different domains, there may be more than one event handler record. In another example, event handler records may be arranged differently (ranges) so that all events for all domains are listed in the filter criteria and the event handler records are not divided by domain. These and other architectures or arrangements are also contemplated herein.

Fig. 3 is a flowchart illustrating an example of an operation of the event handler coordinator service 112 when registering an event handler to be revoked in response to an event in a different domain. First assume that the interaction logic 154 is running on the event handler coordinator service 112 or can be initiated. This is indicated by block 190 in the flow chart of fig. 3. The event handler interaction logic 154 then receives a call from an event handler (e.g., event handler 144) in a first domain (a domain running on the domain computing system 104) to register for events originating from a second domain (e.g., events originating from or caused by calling process 116 in a domain running on the domain computing system 102). Receipt of the call is indicated in block 192 of the flow diagram of fig. 3. In one example, the propagation service interaction logic 148 may place together the event handler record 170 corresponding to the event handler 144 and provide with the call. This is indicated by block 194. In another example, the event handler interaction logic 154 performs one or more round trips with the propagation service interaction logic 148 to obtain information to be included in the event handler record 170 of the event handler 144. This is indicated by block 196. The call may also be performed in other ways, as indicated by block 198.

If an event handler record 170 has not been generated, the event handler interaction logic 154 generates an event handler record for the event handler 144 that is registering the event. This is indicated by block 200. As described above, the record 170 identifies the domain of the event source, as shown at block 174. It identifies the endpoint (e.g., URL)176 of the event handler, it identifies the filter criteria (e.g., the event list of interest for the event handler) as indicated at block 178, it identifies the data (e.g., the event payload) to be sent to the event handler when the event handler is invoked (as indicated at block 180), and includes the value of the enable/disable indicator 182. The event handler record 170 may also include other items 184.

Once the event handler record 170 is generated (e.g., by the propagation service interaction logic 148 or by the event handler interaction logic 154), the logic 154 stores the event handler record in a portion of the invocation file 168 corresponding to the domain running on the domain computing system 102 (e.g., the domain that is the source of the event/invocation process). This is indicated by block 202 in the flow chart of fig. 3.

It should also be noted that in some examples, an event handler may call the event handler coordinator service 112 to update its own event handler record. For example, they may change the filtering information 178, enable or disable themselves by changing the value of the enable/disable indicator 182, or may change any other item in the event handler record. Likewise, they may provide other event handler records in other domains to register events in those domains. In this case, the event handler interaction logic 154 receives calls to update the registry file or other records and processes the updates accordingly. This is indicated by block 204 in the flow chart of fig. 3. Block 206 indicates changing the enable/disable state of the event handler based on the update call. Block 208 indicates that the identity of the data (or payload) information to be sent is updated when the event handler is invoked. Block 210 indicates updating various other items (e.g., register more events, delete registration of events, etc.).

FIG. 4 is a flow diagram illustrating one example of the operation of the event handler coordinator service 112 when a call is received from the calling process 116 (at which point some event occurs), and in response to the call. For purposes of illustration, it will again be assumed that the calling process 116 raised an event, wherein the event handler 144 has registered the event in the event handler coordinator service 112. When this occurs, the calling process 116 generates a call to the query processing system 156 in the event handler coordinator service 112. In the flow diagram of FIG. 4, receipt of a call from a calling process is indicated by block 212. In one example, the call may identify the source domain in which the calling process 116 is running. This is indicated by block 214. The call may identify a particular event that the calling process 116 caused. This is indicated by block 216. The call may also include a variety of other items, as indicated by block 218.

Query processing system 156 illustratively receives the call through appropriate communication logic 162. The event handler record filter/retrieval logic 164 then filters the event handler records 170 for the domain running the calling process 116 based on various filter criteria. This is indicated by block 220. For example, the logic 164 may first filter all event handler records 170 and 172 in the invocation file 168 based on the source domain that caused the event. This is indicated by block 222. In the example in question, this would mean: the logic 164 filters out all event handler records except the record 170 corresponding to domain 1 (since this is the domain where the calling process 116 is running).

The logic 164 then filters the event handler records 170 in domain 1 based on the filter criteria 178 in each event handler record. Recall that the filter criteria 178 identify various events in domain 1 that are of interest to the corresponding event handler. Thus, the logic 164 filters the event handler records 170 to identify those records 170, where those records 170 contain identifiers in the filter criteria 178 that identify the events that have just been raised by the calling process 116 and for which calls have been received. Filtering event handler records 170 based on event identifiers is indicated by block 224 in the flow diagram of fig. 4.

Once the event handler records 170 have been filtered based on the filtering criteria 178, they may also be filtered based on the values of the enable/disable indicator 182. Thus, only the record 170 that has registered events in domain 1 will be identified, which contains an event identifier (in the filter criteria 178) identifying the particular event just fired, and indicates that the corresponding event handler is enabled (as indicated by the enable/disable indicator 182). In the flow chart of fig. 4, the enable/disable indicator is indicated by block 226.

It should be appreciated that the logic 164 may also filter the various event handler records in a variety of other ways. It may apply the filtering criteria (source domain, event identifier, and enable/disable indicator values, etc.) in a different order, may process all of the filtering criteria simultaneously, or may filter the records in other ways. This is indicated by block 228 in the flow chart of fig. 4.

Once the logic 164 has applied all of the filter criteria, it identifies any matching event handlers (identified by the filtering process) from the event handler record 170. In the flow diagram of FIG. 4, the identification of any matching event handlers is indicated by block 230.

The logic 164 then retrieves the endpoint and payload data from the endpoint identifier 176 from the event handler record corresponding to the matching event handler, obtaining the data identifier 180 required for any matching event handler. This is indicated by block 232.

The logic 164 then returns, as a result of the received call, the endpoint list 176 to which the calling process 116 is to make calls to initiate event handlers, and the required data 180 to be provided when the calling process calls these event handlers. Returning these results to the calling process 116 is indicated by block 234 in the flow diagram of FIG. 4.

Fig. 5A and 5B (collectively referred to herein as fig. 5) show a flow diagram illustrating one example of the operation of the calling process 116 when an event is raised, the event handler coordinator service 112 is called, and any event handlers in other domains identified by the event handler coordinator service 112 are called. First assume that the calling process 116 is running on the domain computing system 102. This is indicated by block 240 in the flow chart of fig. 5. At some point, the calling process 116 takes action and generates an event. This is indicated by block 242. For example, a possible action is to modify some data and then save the modification or make changes to the data. This is just one example, and there are a wide variety of other activities that can also trigger events.

The calling process 116 may then use the propagation service interaction logic 130 to call the event handler coordinator service 112 to indicate that it has raised an event. It should be noted that the calling process 116 may also directly call the inter-domain and event propagation services 112. In the flow diagram of FIG. 5, invoking the event handler coordinator service 112 is indicated by block 244.

As described above, service 112 will identify various event handlers (event handlers 144 in this example for ease of description) that are interested in the events that have just been raised by calling process 116, where the event handlers are located in different domains (e.g., it is part of different domains or microservice functions running on different domain computing systems 104). Then, in response to the call, it will return to the endpoint (or URL) where the calling process 116 can call the event handler, the event payload information that the event handler wishes to receive, and it may also provide other items. Receipt of a response identifying the endpoint of the event handler to make the call is indicated by block 246. Receipt of the endpoint as a URL is indicated by block 248. Receiving event payload data is indicated by block 250. The response may also be provided in various other ways, as indicated by block 252.

Based on the raised event, service 112 returns a list of a number of different event handlers to be invoked by calling process 116 in various different domains. In this case, the calling process 116 illustratively selects an event handler to call. This is indicated by block 252. It then calls the selected event handler by calling the endpoint identified by the service 112 and corresponding to the selected event handler. Invocation of the selected event handler is indicated by block 254. Invoking the selected event handler by invoking the event handler endpoint is indicated by block 256. For the event handler, it can illustratively include an event payload (identified by the service 112). This is indicated by block 258. In another example, where the data may be relatively expensive to provide, the calling process 116 may call a selected event handler and embed a link that the event handler can call to obtain event payload data. This is indicated by block 260. It should be noted that there are other ways to handle scenarios where event handlers require event payload data. For example, an event handler may only conditionally require the data, rather than requiring it every time. The cost of acquiring or providing the data may also be relatively high (in terms of its size, the computational overhead or bandwidth required to provide the data, etc.). These types of scenarios are handled differently, some of which are described below with reference to fig. 6.

The event handler may also be invoked in various other ways, as indicated by block 262.

The calling process 116 illustratively waits for a response from the event handler it just called before proceeding with other processing related to the event. This is indicated by block 264 in the flow chart of fig. 5. The response from the event handler it just invoked may include a set of actions or processing results. For example, the event handler 144 may instruct the calling process 116 to take a set of steps or actions based on its processing of the event payload data. It may also indicate other results, e.g. its process failed, and thus the event should fail. In one example, the calling process 116, upon receiving these actions or results, performs (or applies) the actions or results. Thus, if the event handler returns a failure as a response, the request may fail immediately. In another example, the calling process 116 aggregates these actions or results with actions or results that have been received from any other event handlers that are called based on the current event. In the flow diagram of FIG. 5, aggregating or applying actions or results received from the invoked event handler is indicated by block 266.

The calling process 116 then determines whether any other event handlers need to be called for this process. If so, processing returns to block 252, where in block 252 the next event handler in the list of event handlers received from service 112 is selected and invoked. The determination of whether to invoke other event handlers is indicated by block 268.

Once the calling process 116 has called all of the event handlers identified by the event handler coordinator service 112, it will continue to apply any aggregated operations or results received from those event handlers if they have not already been applied. This is indicated by block 270. For example, it may continue to take steps or actions with respect to the process based on the event. This is indicated by block 272. In another example, when an event handler fails an event, then the event handler may fail the action to be taken. For example, when an event is that data has been modified and the modification is to be saved, if one of the event handlers returns a failure, the calling process 116 may fail the modification action and avoid saving the modification to the data. Failure to take action is indicated by block 274 in the flow chart of FIG. 5. The calling process 116 may perform other actions specified by one or more event handlers that have been called. Performing these other actions is indicated by block 276. Application of the aggregated actions and results may also be accomplished in a variety of other ways, as indicated by block 278.

Fig. 6 is a flowchart illustrating one example of the operation of calling process 116 to call an event handler that needs to provide relatively expensive event payload data. As discussed above with respect to block 260 in FIG. 5, the calling process (when it calls the event handler) may be handled in a variety of different ways. In the examples discussed above, the calling process may be embedded with a link to event payload data (or other data) that is needed by the event handler to perform its operations. The event handler itself may then access the data through the link. In the example described with respect to FIG. 6, the calling process 116 first calls an event handler using a URL provided by the event handler coordinator service 112. This is indicated by block 280 in the flow chart of fig. 6. For purposes of example, assume that calling process 116 calls event handler 144. In the example discussed with respect to FIG. 6, the event handler 144 illustratively fails the request from the calling process 116 and also requests more data from the calling process 116. This is indicated by block 282.

In response to the failure and the request for more data, the calling process 116 calls the event handler 142 with more data. This is indicated by block 284 in the flow chart of fig. 6. This can be done in a number of different ways. For example, calling process 116 may know that event handler 144 only conditionally requires the full range of event payload data. Thus, when calling process 116 first calls event handler 144, it provides only a subset of the data, or no data at all. This is because the event handler 144 may often be able to perform its processing without any event payload data, or with a relatively small subset of payload data.

When the event handler 144 does require additional data, then as indicated at block 282, if the request fails and additional data is requested from the calling process 116. The calling process 116 can then use the raw data it provides again to call the event handler 144, as well as other data. This is indicated by block 286. When the calling process 116 calls the event handler 144 with the raw data it provides, as well as other data, this means that the event handler 144 does not need to cache the raw data received when the calling process 116 makes the call. Conversely, when the event handler 144 is re-invoked again using other data, the calling process 116 again provides the data.

In another example, the calling process 116 may embed a link to other data again and provide it to the event handler 144 when the event handler 144 is re-called. The links embedded to the data are indicated by block 288. The calling process 116 may call the event handler 144 to provide other data thereto in other ways. This is indicated by block 290.

FIG. 7 is a partial block diagram, partial sequence diagram illustrating another example of the operation of the architecture 100 in processing events with an event handler that spans multiple different domains. Some of the items shown in fig. 7 are similar to those shown in previous figures and they have similar numbering. FIG. 7 illustrates an architecture 300 in which

domain computing systems

102 and 104 operate with domain computing system 302 in architecture 300. Domain computing systems 104 and 302 illustratively have

event handlers

144 and 304. FIG. 7 shows that the calling process 116 illustratively performs a set of actions 306 and 308, and in the process, an event 310 named "Save item" is raised. Illustratively, the event handler 144 has registered with the event handler coordinator service 112 to be invoked by the calling process 116 when the process 116 causes a save project event 310. In addition, the event handlers 304 in the domain computing system 302 have registered with the event handler coordinator service 112 for invocation by the event handlers 144 when the event handlers 144 raise an event (which indicates that the event handlers 144 themselves have been invoked). This type of processing may be referred to as "linking".

Specifically, in one example, when the calling process 116 raises a save project event 310, it calls the event handler coordinator service 112 (as indicated by arrow 314) to obtain a list of various event handlers (including the event handlers 144) to be called based on raising the save project event 310. It then selects the event handler 144 and invokes it, as indicated by arrow 316. In response, the event handler 144 raises an event indicating that it has been invoked, and therefore invokes the event handler coordinator service 112 based on the event, to identify other event handlers to be invoked. This is indicated by arrow 318. Service 112 illustratively responds to this call identifying event handler 304, where event handler 304 has been registered as making the call when event handler 144 is called. Accordingly, event handler 144 invokes event handler 304, as indicated by block 320.

The event handler 304 then performs its actions and responds to the event handler 144, as indicated at block 322. Response 322 may include an action or result from event handler 304. Event handler 144 then performs its actions, aggregates its own results or actions with those in response 322 of event handler 304, and provides these items as response 324 to calling process 116 (specifically, save project event 310). In this manner, when calling process 116 raises a single event, multiple nested event handlers may be called. The plurality of nested event handlers can be located in a plurality of different domains and can aggregate their processing results and provide them to the calling process 116. Thus, all event handlers in the chain can efficiently insert logic into the calling process without actually altering the logic of the calling process itself. Instead, event handlers in different domains may be invoked in a cross-domain manner, in a nested manner, or in a combination of these different manners, through the use of the event handler coordinator service 112.

It should be noted that the above discussion describes a variety of different systems, components, and/or logic. It should be understood that such systems, components, and/or logic may include hardware items (e.g., processors and associated memory, or other processing components, some of which are described below) for performing functions associated with such systems, components, and/or logic. Additionally, these systems, components, and/or logic may include software that is loaded into memory and then executed by a processor or server or other computing component, as described below. The systems, components, and/or logic may also include various combinations of hardware, software, firmware, etc., some examples of which are described below. These are merely a few examples of different structures that may be used to form the systems, components, and/or logic described above. Other configurations may also be used.

The discussion presented refers to processors and servers. In one embodiment, the processor and server comprise a computer processor with associated memory and timing circuitry (not separately shown). These processors and servers are functional parts of the systems or devices to which they pertain and are activated by, and facilitate the functionality of, other components or items in these systems.

In addition, a number of user interface displays have been discussed. They may take a variety of different forms and may have a variety of different user-actuatable input controls disposed thereon. For example, the user-actuatable input control can be a text box, a check box, an icon, a link, a drop down menu, a search box, and the like. They may also be actuated in a variety of different ways. For example, they may be actuated using a pointing and clicking device (e.g., a trackball or mouse). They may be actuated using hardware buttons, switches, a joystick or keyboard, thumb switches or thumb pads, or the like. They may also be actuated using a virtual keyboard or other virtual actuators. Additionally, where the screen on which they are displayed is a touch-sensitive screen, they may be actuated using touch gestures. Also, where the devices on which they are displayed have voice recognition components, they may be actuated using voice commands.

Various data stores are also discussed. It should be noted that they may be divided into multiple data stores. All data stores may be local to the system accessing them, all data stores may be remote, or some may be local while others are remote. All of these configurations are contemplated herein.

Further, the drawings show a plurality of blocks having functions ascribed to each block. It should be noted that fewer blocks may be used and thus functions are performed by fewer components. Further, more blocks may be used, where the functionality is distributed among more components.

Fig. 8 is a block diagram of the architecture 100 shown in fig. 1, except that elements thereof are arranged in a cloud computing architecture 500. Cloud computing provides computing, software, data access, and storage services that do not require the end user to know the physical location or configuration of the system delivering the services. In various examples, cloud computing uses appropriate protocols to deliver services over a wide area network, such as the internet. For example, cloud computing providers provide applications over a wide area network and may access them through a web browser or any other computing component. The software or components of architecture 100 and corresponding data may be stored on a server at a remote location. The computing resources in a cloud computing environment may be consolidated at a remote data center location, or may be dispersed. Cloud computing infrastructures can provide services through shared data centers, even though they appear as a single point of access for users. Accordingly, the components and functionality described herein may be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they may be provided from a conventional server, or they may be installed directly or otherwise on the client device.

The description herein is intended to include public cloud computing and private cloud computing. Cloud computing (both public and private) provides a large seamless pool of resources, as well as reducing the need to manage and configure the underlying hardware infrastructure.

Public clouds are managed by suppliers and often support multiple customers using the same infrastructure. In addition, public clouds can free end users from managing hardware as compared to private clouds. Private clouds may be managed by the organization itself and do not typically share infrastructure with other organizations. Organizations still maintain hardware to some extent, such as for installation and repair, and so forth.

In the example shown in FIG. 8, some items are similar to those shown in FIG. 1, and so they are numbered similarly. Fig. 8 specifically illustrates that computing

systems

102 and 104 and service 112 may be located in cloud 502 (where cloud 502 may be public, private, or a combination where some portions are public and others are private). Thus, user 508 accesses those systems through cloud 502 using user device 504 and user interface 506.

FIG. 8 also depicts another example of a cloud architecture. Fig. 8 shows that it is also contemplated that some elements of architecture 100 may be disposed in cloud 502 while other elements are not disposed in cloud 502. For example,

data stores

122, 140, 158 may be disposed outside of cloud 502 and may be accessed through cloud 502. In another example, service 112 (or other items) may be outside of cloud 502. Wherever they are located, devices 504 may access them directly over a network via other systems or servers, they may be hosted at remote sites through services, or they may be provided as services through the cloud, or accessed by a connectivity service residing in the cloud. All of these architectures are contemplated herein.

It should also be noted that architecture 100, or portions thereof, may be disposed on a variety of different devices. Some of these devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices such as palm top computers, cellular phones, smart phones, multimedia players, personal digital assistants, and the like.

FIG. 9 is an example of a computing environment in which a portion of architecture 100 may be deployed. With reference to FIG. 10, an exemplary system for implementing some embodiments includes a general purpose computing device in the form of a computer 810. Components of computer 810 may include, but are not limited to, a processing unit 820 (which may include a processor or server from the previous figures), a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 may 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 memory and programs described with respect to fig. 1 may be deployed in corresponding portions of fig. 9.

Computer 810 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 810 and 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. The computer storage medium is distinct from and does not include a modulated data signal or a carrier wave. Computer storage media includes hardware storage media including 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 accessed by computer 810. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. 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 memory 830 includes computer storage media in the form of volatile and/or nonvolatile memory such as Read Only Memory (ROM)831 and Random Access Memory (RAM) 832. A basic input/output system 833(BIOS), containing the basic routines that help to transfer information between elements within computer 810, such as during start-up, is typically stored in ROM 831. RAM 832 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 820. By way of example, and not limitation, fig. 9 illustrates operating system 834, application programs 835, other program modules 836, and program data 837.

The computer 810 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 9 illustrates a hard disk drive 841 that reads from or writes to non-removable, nonvolatile magnetic media, and an optical disk drive 855 that reads from or writes to a removable, nonvolatile optical disk 856 such 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 cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 841 is typically connected to the system bus 821 through a non-removable memory interface such as interface 840, and optical disk drive 855 is typically connected to the system bus 821 by a removable memory interface, such as interface 850.

Alternatively or in addition, the functions described herein may be performed, at least in part, by one or more hardware logic components. By way of example, and not limitation, exemplary types of hardware logic components that may be used include Field Programmable Gate Arrays (FPGAs), program specific integrated circuits (ASICs), program specific standard products (ASSPs), system on a chip (SOCs), Complex Programmable Logic Devices (CPLDs), and so forth.

The drives and their associated computer storage media discussed above and illustrated in FIG. 9, provide storage of computer readable instructions, data structures, program modules and other data for the computer 810. In fig. 9, for example, hard disk drive 841 is illustrated as storing operating system 844, application programs 845, other program modules 846, and program data 847. Note that these components can either be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to illustrate that, at a minimum, they are different copies.

A user may enter commands and information into the computer 810 through input devices such as a keyboard 862, microphone 863, and pointing device 861, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 820 through a user input interface 860 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a Universal Serial Bus (USB). A visual display 891 or other type of display device is also connected to the system bus 821 via an interface, such as a video interface 890. In addition to the monitor, computers may also include other peripheral output devices such as speakers 897 and printer 896, which may be connected through an output peripheral interface 895.

The computer 810 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 880. The remote computer 880 may be a personal computer, a hand-held device, 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 computer 810. The logical connections depicted in FIG. 9 include a Local Area Network (LAN)871 and a Wide Area Network (WAN)873, 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 computer 810 is connected to the LAN871 through a network interface or adapter 870. When used in a WAN networking environment, the computer 810 typically includes a modem 872 or other means for establishing communications over the WAN 873, such as the Internet. The modem 872, which may be internal or external, may be connected to the system bus 821 via the user input interface 860, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 810, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 9 illustrates remote application programs 885 as residing on remote computer 880. 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.

It should also be noted that the different embodiments described herein may be combined in different ways. That is, portions of one or more embodiments may be combined with portions of one or more other embodiments. All of which are contemplated herein.

Example 1 is a computing system, comprising:

a computer processor;

a communication system in communication with a first domain computing system and a second domain computing system different from the first domain computing system via a network interface, the first domain computing system and the second domain computing system in communication with each other via respective network interfaces; and

an event handler coordinator service to store in the first domain computing system a first event handler record corresponding to a first event handler, the first event handler record including filter criteria to identify an event of interest raised by a calling process running the second domain computing system, the event handler coordinator service to receive a call from the calling process when the event of interest is raised by the calling process in the second domain computing system and to return to the calling process an endpoint in the first domain computing system corresponding to the first event handler for calling the first event handler.

Example 2 is the computing system of any or all of the previous examples, wherein the event handler coordinator service comprises:

event handler interaction logic configured to receive a call from the first event handler in the first domain computing system and, based on the call, store in the first event handler record the endpoint corresponding to the first event handler and filter criteria corresponding to the first event handler, the filter criteria indicating events of interest to the first event handler caused by the calling process running in the second domain computing system.

Example 3 is the computing system of any or all of the previous examples, wherein the event handler coordinator service stores, in different domain computing systems, a plurality of different event handler records corresponding to different event handlers, each event handler record having filter criteria indicating an event of interest of the corresponding event handler.

Example 4 is the computing system of any or all of the previous examples, wherein the event handler coordinator service comprises:

event handler record filtering logic configured to receive the call from the calling process upon raising an event of interest of the first event handler, the call from the calling process including an event identifier for identifying the raised event, and the event handler record filtering logic configured to filter the event handler record based on the filtering criteria and the event identifier to identify the first event handler record.

Example 5 is the computing system of any or all of the previous examples, wherein the event handler coordinator service comprises:

event handler record retrieval logic configured to obtain the endpoint for invoking the first event handler from the first event handler record and return the endpoint to the invoking process in response to the call from the invoking process.

Example 6 is the computing system of any or all of the previous examples, wherein the event handler interaction logic is configured to: receiving the call from the first event handler in the first domain computing system and, based on the call, storing an event payload indicator in the first event handler record, the event payload indicator indicating data to be used by the first event handler upon the call by the calling process based on an event of interest of the first event handler.

Example 7 is the computing system of any or all of the previous examples, wherein the event handler record retrieval logic is configured to: the event payload indicator is obtained from the first event handler record and returned to the calling process in response to the call from the calling process.

Example 8 is the computing system of any or all of the previous examples, wherein the event handler interaction logic is configured to: an update call is received from the first event handler and the first event handler record is changed based on the update call.

Example 9 is a computer-implemented method of invoking an event handler based on a raised event, the method comprising:

raising an event in a process running on a first domain computing system;

generating, via a network interface, a call to an event handler coordinator service, the call including an indication of the raised event;

receiving, from the event handler coordinator service and in response to the call, an endpoint corresponding to an event handler in a second domain computing system;

invoking, using the endpoint, the event handler through the network interface;

waiting to perform other operations corresponding to the raised event until a response is received in response to invoking the event handler in the second domain computing system;

receiving the response from the event handler in the second domain computing system; and

based on the response from the event handler in the second domain computing system, performing other operations corresponding to the event.

Example 10 is a computer-implemented method of any or all of the previous examples, further comprising:

receiving, from the event handler coordinator service, a data indicator for indicating data to be used by the event handler.

Example 11 is the computer-implemented method of any or all of the previous examples, wherein invoking the event handler comprises:

providing, to the event handler, the data identified by the data indicator through the network interface.

Example 12 is the computer-implemented method of any or all of the previous examples, wherein invoking the event handler comprises:

providing a link to the data identified by the data indicator to the event handler.

Example 13 is the computer-implemented method of any or all of the previous examples, wherein invoking the event handler comprises: providing at least a portion of the data identified by the data indicator to the event handler, and wherein receiving the response from the event handler comprises: a request for additional data is received.

Example 14 is the computer-implemented method of any or all of the previous examples, further comprising:

responding to the request for other data using the portion of data and the other data.

Example 15 is a computer-implemented method, comprising:

receiving, from a calling process running in a first domain computing system, a call at an event handler coordinator service through a network interface when the calling process in the first domain computing system raises an event, the call including an event identifier for identifying the event raised by the calling process;

accessing a set of event handler records corresponding to a set of event handlers, at least a first one of the event handlers being located in a second domain computing system, each of the event handler records including filter criteria for identifying events of interest of the corresponding event handler;

filtering the set of event handler records based on the event identifier and the filtering criteria to identify a first event handler record that includes filtering criteria corresponding to the event identifier, the first event handler record corresponding to the first event handler; and

returning an endpoint in the second domain computing system identified in the first event handler record corresponding to the first event handler to the calling process to call the first event handler.

Example 16 is the computer-implemented method of any or all of the previous examples, further comprising:

receiving, at the event handler coordinator service, a call from the first event handler in the second domain computing system; and

based on the call, storing in the first event handler record the endpoint corresponding to the first event handler and filter criteria corresponding to the first event handler, the filter criteria indicating the event caused by the calling process running in the first domain computing system.

Example 17 is the computer-implemented method of any or all of the previous examples, wherein receiving, at the event handler coordinator service, the call from the first event handler comprises: receiving the call from the first event handler in the second domain computing system; and storing, in the first event handler record based on the call, an event payload indicator indicating data to be used by the first event handler when the calling process invokes, based on the event invoked by the calling process.

Example 18 is the computer-implemented method of any or all of the previous examples, further comprising:

obtaining the event payload indicator from the first event handler record; and

returning the event payload indicator to the calling process in response to the call from the calling process.

Example 19 is the computer-implemented method of any or all of the previous examples, further comprising:

receiving, at the event handler coordinator service, an update call from the first event handler indicating a change to the first event handler record; and

based on the update call, altering the first event handler record.

Example 20 is the computer-implemented method of any or all of the preceding examples, wherein each of the event handler records comprises: a respective enable/disable indicator for indicating an enable status of the respective event handler record, and a domain indicator for indicating a domain of a calling process that caused the event of interest identified by the filter criteria, wherein filtering comprises:

filtering the event handler record based on the enable/disable indicator and the domain indicator.

Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the invention.

Claims

1. A computing system, comprising:

a computer processor;

2. The computing system of claim 1, wherein the event handler coordinator service comprises:

event handler interaction logic configured to receive a call from the first event handler in the first domain computing system and, based on the call, store in the first event handler record the endpoint corresponding to the first event handler and filter criteria corresponding to the first event handler that indicate the event of interest of the first event handler caused by the calling process running in the second domain computing system.

3. The computing system of claim 2, wherein the event handler coordinator service stores a plurality of different event handler records in different domain computing systems corresponding to different event handlers, each event handler record having filter criteria indicating an event of interest of the corresponding event handler.

4. The computing system of claim 3, wherein the event handler coordinator service comprises:

5. The computing system of claim 4, wherein the event handler coordinator service comprises:

6. The computing system of claim 5, wherein the event handler interaction logic is configured to: receiving the call from the first event handler in the first domain computing system and, based on the call, storing an event payload indicator in the first event handler record, the event payload indicator indicating data to be used by the first event handler upon the call by the calling process based on an event of interest of the first event handler.

7. The computing system of claim 6, wherein the event handler record retrieval logic is configured to: the event payload indicator is obtained from the first event handler record and returned to the calling process in response to the call from the calling process.

8. The computing system of claim 2, wherein the event handler interaction logic is configured to: an update call is received from the first event handler and the first event handler record is changed based on the update call.

9. A computer-implemented method of invoking an event handler based on a raised event, the method comprising:

raising an event in a process running on a first domain computing system;

invoking, using the endpoint, the event handler through the network interface;

10. The computer-implemented method of claim 9, further comprising:

11. The computer-implemented method of claim 10, wherein invoking the event handler comprises:

12. The computer-implemented method of claim 10, wherein invoking the event handler comprises:

13. The computer-implemented method of claim 10, wherein invoking the event handler comprises: providing at least a portion of the data identified by the data indicator to the event handler, and wherein receiving the response from the event handler comprises: a request for additional data is received.

14. The computer-implemented method of claim 13, further comprising:

15. A computer-implemented method, comprising: