Patent Application
20120078944
The present disclosure relates generally to service-oriented architectures (SOAs), and more particularly, to a provider service within a network service provider service-oriented architecture with scriptable, extensible, and customizable calculation engines.
Power management software collects data measured by various monitoring devices in a power monitoring system, such as power meters, and analyzes the measured data to help a facility operator lower energy-related costs, avoid downtime by allowing the operator to respond quickly to alarms to avoid critical situations, and optimize equipment utilization by identifying opportunities for increasing efficiency, for example. This software typically runs on a server or a workstation that collects the measured data over a network. Functionality in the form of modules can be provided with the software, but the software is not particularly scalable, extensible, and customizable. Adding new modules to perform different calculations on measured data is presently a time and labor intensive task, particularly by third parties. A lack of centrally managed processing of requested calculations leads to duplicative storage and calculations, and a non-cohesive coordination and management of tasks, which delays the ultimate reporting of relevant, meaningful information to the facility operator and results in inefficient use of processing and memory resources.
According to an aspect of the present disclosure, a method is disclosed of acquiring data and performing calculations on the data using a provider service. The method includes: receiving, at a provider ticket service, a plurality of tickets from one or more clients, each of the tickets including a calculation identifier and a payload, the calculation identifier identifying a calculation to be performed using at least information indicated in the payload of the ticket; for each of the tickets received at the provider ticket service, associating a unique ticket identifier with each of the corresponding tickets; a ticket manager submitting the selected ticket from the provider ticket service to a provider host service; determining which one or more of a plurality of providers is to perform the calculation identified by the calculation identifier of the selected ticket; the provider host service launching at least one provider host thread that invokes or instantiates the one or more providers determined to perform the calculation identified by the calculation identifier of the selected ticket; receiving at the provider ticket service from the provider host service a result of the calculation carried out by the invoked one or more providers; and returning the result to the requesting client associated with the selected ticket.
The method can further include, prior to performing the calculation requested by the selected ticket, determining whether the calculation requested by the selected ticket has been performed already, and, if so, retrieving the previously calculated result and returning the previously calculated result as the result to be returned to the requesting client associated with the selected ticket. The method can further include storing the previously calculated result in a data store of the provider ticket service. The method can further include, prior to performing the calculation requested by the selected ticket, determining whether another of the providers is in the process of performing the calculation requested by the selected ticket, and if so, waiting for the other provider to perform the calculation and provide the result and returning the result from the other provider as the result to be returned to the requesting client associated with the selected ticket. The method can further include: determining whether to store the result based on at least one criterion; and responsive to the at least one criterion being satisfied, storing the result in a data store of the provider ticket service.
The at least one criterion can include: (a) whether the calculation requested by the selected ticket has been requested by at least one other of the clients; (b) a frequency with which the result is expected to be requested or has been requested; or (c) whether data used to perform the calculation is within a predetermined time period. The criterion can also or alternately be based on how frequently the calculation requested by the selected tickets is requested by other clients of the one or more clients.
The method can further include: receiving, from the client that provided the first ticket, a request for the result using the ticket identifier associated with the first ticket; and responsive to receiving the request from the requesting client, querying the data store for the result. The method can further include inserting into the selected ticket a provider identification that identifies which of the one or more of providers is to be invoked for carrying out the calculation identified by the calculation identifier of the selected ticket. The method can further include communicating to the client that communicated the selected ticket the ticket identifier associated with the selected ticket. The method can further include: receiving from the one or more clients a request for a status of the selected ticket; responsive to receiving the request for the status of the selected ticket, the provider ticket service querying a ticket status table for the status of the selected ticket; and the provider ticket service communicating, to the client that requested the status of the selected ticket, the status of the selected ticket, the status including an indication of whether processing of the selected ticket is pending or in-progress, and if the status of the selected ticket is in-progress, the ticket provider service further communicating an indication as to how much processing has been completed or remains to be completed to produce the result. The invoked provider can carry out the calculation to be performed using input data hosted locally by the provider host service or externally to the provider host service based at least in further part on the local or external data.
The method can further include: the invoked provider requesting the information indicated in the payload of the ticket from a data store hosted by the provider ticket service or from a data service hosted external to the provider host service and to the provider ticket service; and responsive to the invoked provider requesting the information, the invoked provider receiving input data from the data store or external data service and using the received input data to perform the calculation requested by the selected ticket. The method can further include: storing, using a ticket manager, the tickets in a ticket store according to a queue; identifying a status of each of the tickets and storing an indication of the status of each of the tickets, including the selected ticket, in a ticket status table; increasing a pending ticket counter each time the status of selected ones of the tickets is identified as pending; querying the ticket store for a first one of the tickets at the front of the queue; and identifying from the first ticket at least a provider to be invoked from the plurality of providers for carrying out the calculation indicated by the calculation identifier of the first ticket.
The method can further include, responsive to receiving the selected ticket at the provider ticket service, updating the status of the selected ticket in the ticket status table from pending to in-progress. The method can further include: storing the result in a data store of the provider ticket service; and responsive to storing the result in the data store of the provider ticket service, updating the status of the selected ticket in the ticket status table from in-progress to completed.
Each of at least some of the tickets can further include a priority field indicating a priority order of invocation relative to the other tickets, the first ticket including a higher priority order in the corresponding priority field compared to at least some of the other tickets. The method can further include, responsive to returning the result to the client associated with the selected ticket, deleting the selected ticket from the ticket store and deleting the status of the selected ticket from the ticket status table. The method can further include: receiving, at the provider ticket service, a request to cancel one of the tickets; the provider ticket service determining which of the providers to notify based on provider identification information in the ticket to be canceled; notifying the provider determined to be associated with the ticket to be canceled that the ticket to be canceled has received the request to cancel; and canceling the ticket to be canceled.
The method can further include, responsive to receiving the plurality of tickets at the provider ticket service, formatting each of the tickets by an extensible markup language (XML) or into a JavaScript Object Notation (JSON) format. The payload can include a set of inputs or parameters needed to perform the calculation associated with the calculation identifier. The set of inputs or parameters can include a source identification indicating a source of at least some of the data needed to perform the calculation associated with the calculation identifier.
The method can further include: the invoked provider associated with the selected ticket carrying out the calculation to be performed as indicated by the calculation identifier of the selected ticket based at least in part on the payload of the selected ticket; and responsive to the carrying out the calculation, the invoked provider outputting the result of the calculation associated with the selected ticket. The method can further include: the provider host service further hosting the one or more providers determined to perform the calculation identified by the calculation identifier of the selected ticket. The method can further include: the provider host service notifying the provider ticket service how many provider host threads are available to perform calculations requested by the tickets.
The launching the at least one provider host thread can include invoking a plurality of providers and chaining the plurality of providers together, some of the chained providers performing an intermediate calculation and producing an intermediate result to produce the result as the result to be returned to the requesting client associated with the selected ticket. The method can further include reading a configuration file to determine how to chain together the chained providers, the configuration file indicating at least a sequence order of processing each of the chained providers. The method can further include storing the intermediate result on a data store that is hosted local to the provider ticket service.
The selected ticket can include a source identification, a topic identification, and a date or a date range, the source identification identifying a source of data used to perform the calculation identified by the calculation identifier of the selected ticket, the topic information identifying topical information about the data from the source identification, and the date or date range corresponding to a date or date range of the topical data from the source of the data. The selected ticket can further include a dependency identification associated with the source identification and the topic identification, the dependency identification having a unique value relative to dependency identifications associated with every other one of the tickets to permit multiple instances of the same source-topic combinations having the same source identification and the same topic identification. The dependency identification can identify one of a plurality of time-of-use (TOU) schedules, each of the TOU schedules being associated with the same source identification and the same topic identification, the calculation determining a time-of-use (TOU) pricing or an energy usage based on the TOU schedule identified by the dependency identification. The information can include values indicative of or calculated from a characteristic of a utility that is measured by one or more intelligent electronic devices in a utility system.
The utility can be water, air, gas, electricity, or steam. For example, the utility can be electricity and the characteristic can include current or voltage. The values calculated from the current or voltage can include energy. The provider ticket service can be hosted on a computing machine and the provider host service is hosted on the computing machine. The provider host service can include a plurality of provider host services, the provider ticket service being hosted on a computing machine and at least some of the plurality of provider host services being hosted on other computing machines communicatively coupled to the computing machine that hosts the provider ticket service. The method can further include associating a Uniform Resource Identifier (URI) with the provider host service.
The foregoing and additional aspects and implementations of the present disclosure will be apparent to those of ordinary skill in the art in view of the detailed description of various embodiments and/or aspects, which is made with reference to the drawings, a brief description of which is provided next.
The foregoing and other advantages of the present disclosure will become apparent upon reading the following detailed description and upon reference to the drawings.
The present disclosure specifies a software architecture, such as a network service provider service-oriented (SOA) architecture, with scriptable, extensible, and customizable calculation engines that are pluggable into the SOA architecture to extend the types of calculations and data that a Provider Service (PS) 100 offers. The Provider Service 100 can be used for analyzing information from a utility system. This information includes values indicative of or calculated from a characteristic of a utility that is measured by one or more intelligent electronic devices in the utility system. The utility can be water, air, gas, electricity, or steam. In the case of electricity, the characteristic can be current or voltage, for example. An energy value can be calculated from a measured current and voltage. An intelligent electronic device measures and stores various characteristics of a utility being monitored (e.g., voltage, current, waveform distortion, power, etc.), and the data from each intelligent electronic device can be collected by local data collection points within the system and uploaded to one or more computing machines, such as servers, for storage or analysis.
(a) Accept requests from one or more clients, such as a Silverlight gadget 110, to perform work, such as calculations;
(b) Consolidate requests so that redundant work is eliminated;
(c) Manage and report (when requested) status of ongoing work;
(d) Acquire data and metadata needed to perform calculations;
(e) Perform the calculations requested by the client(s); and
(f) Deliver the calculation results to the requesting client when requested.
The Provider Services can use pluggable dynamic-link libraries (DLLs) called Providers, such as the Provider 208 shown in
The logical design of the Provider Service 100 includes at least three parts (see
1. A Provider Ticket Service 102;
2. One or more Provider Host Services 104; and
3. Plug-in Providers 208;
The Provider Ticket Service 102 (PTS) represents the “public face” of the Provider Service 100. One or more external clients, such as the gadget 110, communicate with the Provider Ticket Service 102. Functions of the Provider Ticket Service 102 include: accepting requests to perform or carry out work such as calculations, consolidating requests so that redundant work is eliminated, managing and reporting a status of ongoing work, and delivering calculation results when requested.
The Provider Host Service 104 (PHS) is responsible for seeing that the true work of the Provider Service 100—running calculations on input data—is completed and delivered to the results cache or Data Store 200 (shown in
Providers are plug-in dynamic link libraries (DLLs) instantiated (or invoked) and managed by a Provider Host Service 106. A Provider gathers input data needed to perform one or more calculations, performs one or more calculations, and returns results from the calculation(s). A Provider, such as the Provider 208, includes logic to (a) gather the input data needed to perform the calculation, (b) perform a given calculation, and (c) provide status information (when requested) regarding the progress of an ongoing calculation. This status information can include a percentage complete, success or failure, and a reason for failure, a retry count, etc.
The correspondence between a Provider Ticket Service 102 and a Provider Host Service 104 can be one-to-one or one-to-many. For example, one Provider Ticket Service 102 and one Provider Host Service 104 can be executed on one computing machine, such as a computer. Alternately, one Provider Ticket Service 102 can communicate with more than one Provider Host Services 104. These Provider Host Services's can be hosted and executed on one or more than one computing machines, but each returns its respective results from a calculation to one Provider Ticket Service. Put differently, one way of referring to the Provider Ticket Service 102 relative to the Provider Host Service(s) is that the PTS 102 is a master/controller and the PHS 104 is its “worker.”
Non-limiting responsibilities of the Provider Ticket Service 104 includes handling any combination of the following (in no particular order):
1. Receiving a work request “Payload” (such as in the form of an XML fragment or JSON string) via a WCF call from a client, such as the gadget 110, requesting a calculation to be performed, embedding this Payload into a “Ticket” 202 (a properly-formed XML document) and returning a unique Ticket identifier (a GUID string) to the client as a token. As used herein, WCF refers to Windows Communication Foundation, which is an application programming interface in the .NET Framework for building connected, service-oriented applications. XML refers to the extensible markup language. JSON refers to JavaScript Object Notation. GUID refers to a globally unique identifier as that term is understood by software developers.
2. Storing the XML-formatted Ticket in a Ticket Store 204 and creating objects to track the progress of the Ticket as it is being worked on (e.g., as the calculation specified in the Ticket is being carried out).
3. Receiving and processing Ticket cancellation requests and notifying any worker processes (i.e. Provider Host Services) regarding Ticket cancellations in a Ticket Manager 206.
4. Reporting Ticket progress/status to clients when requested in a Status Manager 210.
5. Returning final Ticket result data (i.e., the result of the requested calculation) to clients when requested.
6. Allowing external entities to read data that has been previously stored.
7. Handing queued Tickets to Provider Host Services in a PHS Queue 212.
In an exemplary implementation, the Provider Ticket Service 102 is “wrapped” by a Windows Communication Foundation (WCF) service 106 that will registers itself as a Messaging Service client. The WCF service 106 allows Silverlight-enabled components, such as the Silverlight gadget 110, to communicate with either Silverlight-enabled or non-Silverlight-enabled WCF services, so the greatest flexibility is gained by using a standard WCF service and the Provider Ticket Service 102 need not be Silverlight-enabled. The WCF API (Application Program Interface) allows client access to all public functionality of the Provider Ticket Service 102. The Messaging Service will be used by the Provider Service 100 for accessing other Application Module blocks such as authentication and configuration. As used herein, Silverlight refers to the MICROSOFT® SILVERLIGHT™ web application framework available from Microsoft Corporation. Silverlight is a web application framework that integrates multimedia, computer graphics, animation, and interactivity into a single runtime environment.
The Provider Host Service 104 manages and executes the pluggable Providers, such as the Provider 208. The Provider Host Service 104 can host multiple provider host threads 108, each thread 108 executing one or more Providers 208. The maximum number of threads 108 that a Provider Host Service 104 allows to run is configurable. A Provider Host Service 104 can also be configured to handle only certain types of calculations and Providers.
Providers 208 can also be chained. For example, a single thread can run multiple Providers in a determined sequence, with each output of one Provider acting as an input to the next Provider in the sequence, and the last Provider in the chain produces the final result. Providers can be configured to accept such chaining, and only pre-configured combinations of Providers can be permitted. These combinations can be determined by information obtained from a configuration file residing with the Provider Ticket Service 102.
Responsibilities of the Provider Host Service 104 include any combination of the following (in no particular order):
Responsibilities of each provider host thread 108 include any combination of the following (in no particular order):
In an example configuration, Providers 208 can reside in plug-in dynamic link libraries (DLLs), which are consumed by Provider Host Services 104. One dynamic link library can include multiple Providers, allowing third-parties to extend the functionality of the Provider Service 100 by creating new Providers that perform new calculations, produce new types of aggregated data, work with new types of hierarchies, and so on. The Provider developer can code their Provider (using a supplied Software Development Kit or SDK) to handle any combination of the following tasks (in no particular order):
The architecture disclosed herein supports the creation of a Provider, such as the Provider 208, that allows scripted calculations, removing the need to create Provider plug-ins, as virtually any calculation can be implemented by creating a new script. However, creating customized Providers for specific calculations can provide an opportunity for optimizations not possible with a scriptable Provider.
The operation of the Provider Service 100 will now be described by detailing an exemplary progress of a client work request, from the moment the request is made, to the delivery of the result data. A client or gadget project 110 should first be configured to invoke methods or Providers on the Provider Service 100. Assuming that the Provider Service 100 is installed and configured properly on a computing machine such as a server, a gadget or other client is configured to call the Provider Service 100 in the following non-limiting example:
1. In the project for the gadget or client 110, a reference is added to a dynamic link library called (in this example) ProviderMethods.dll 112. This DLL 112 includes interfaces that publish the high-level methods Gadgets 110 will call to request calculations.
2. A “using” statement is added to the gadget/client code, such as “using Company.Modules.Calculation.Provider.”
3. Locate the name of a desired calculation to be performed or carried out.
4. Add a call in the gadget/client code to the located calculation, such as, for example, “Provider.GetEnergyRolledUp,” which is a call to a Provider named GetEnergyRolledUp, which returns a rolled-up energy calculation on input data indicative of values needed to calculate energy consumption over a desired time period.
5. For gadget developers using MICROSOFT® VISUAL STUDIO®, the Intellisense function will reveal the appropriate method arguments to provide to the calculation Provider.
In this example, the methods in the ProviderMethods.dll file 112 are high-level, easy-to-invoke calls that are present for the convenience of gadget developers. In an alternate implementation, some or all of the providers do not have high-level calls in a ProviderMethods.dll file 112. In such a case, that developer can publish a separate DLL 112 that includes high-level methods to invoke the desired calculation(s). This separate DLL 112 would need to be referenced in the gadget project 110. Another example involves the gadget/client developer looking up the actual calculation identifier and XML format for the data that needs to be passed to a particular Provider and make a direct WCF call to the Provider Service. This bypasses the high-level method calls in DLLs such as ProviderMethods.dll 112 but, ultimately produces the same result.
This section describes an example of a path that a request makes from the Client 110 submitting the work request (
1. The Client 110 submits a Ticket Payload to the Provider Ticket Service 102 (PTS) (
2. The PTS 102 embeds the received Payload in a Ticket 202, which is placed in a Ticket Store 204 accessible by the PTS 102 (
3. A Provider Host Service (PHS) 104 notifies the PTS 102 that it is ready to accept one or more Tickets 202 (
4. The PTS 102 submits the Ticket to a PHS 104 (
5. The Thread Manager 216 of the PHS 104 launches a thread 108 in which to run the appropriate Provider 208 (
6. The calculation associated with the Ticket 202 is worked on by the Provider 208 to perform the requested calculation.
7. The Provider 208 writes the result or results from the calculation to the Data Store 200 (
8. Client 110 checks on progress (
9. Client retrieves the results, such as from the Data Store 200. In
A more detailed description of each of the foregoing blocks follows, using the same numbered paragraphs.
1. The Client 110 submits a Ticket Payload and the Provider Ticket Service 102 receives the Payload (see
Clients 110 are not responsible for submitting Ticket Payloads or Tickets, although they can submit Ticket Payloads directly through WCF calls if desired. Instead, Clients make high-level calls on the interface methods in ProviderMethods.dll 112, and these methods 112 generate Ticket Payloads from the provided parameters. An example payload can look like this:
In the above payload example, the client 110 provides information about the devices (i.e., sources of data needed for the requested calculation), topics (e.g., topical information such as current, voltage, energy, power, and the like, about the data from the identified sources), and date or date ranges over which a calculation is requested to be performed. It should be noted that this is not enough information to perform the requested calculation. In this example, the desired calculation is not even indicated in the above XML fragment. Instead, the high-level method implementations can pass additional parameters to the Provider Ticket Service 102 along with the payload. Specifically, the methods 112 can provide a GUID that identifies the specific calculation desired, a URI that can be called back with result status (for future use), and an integer indicating the priority of the request (also for future use). As used herein, a URI refers to a Uniform Resource Locator in the context of the Internet. GUID refers to a globally unique identifier as understood in the context of software applications. Examples of topical information encoded in the topical identifier (topicId) are provided below in Table 1.
Each payload can have an “id” attribute, which is a GUID that uniquely identifies the structure of this particular payload. Any changes to the payload structure should result in that payload's being assigned a new GUID. A Provider 208 can be written to expect specific combinations of payload identifications, and by recognizing older combinations of payload identifications, the Provider 208 can support backward compatibility with older Payload identifications.
In addition to the source and topic identification information, the ticket can further include a dependency identification associated with the source identification and the topic identification. The dependency identification has a unique value relative to dependency identifications associated with every other one of the tickets to permit multiple instances of the same source-topic combinations having the same source identification and the same topic identification. For example, the dependency identification can identify one of several time-of-use (TOU) schedules, each of the TOU schedules being associated with the same source identification and the same topic identification. Alternately, the dependency identification can be associated with a different cost schedule. For example, a TOU schedule can have three different periods of energy consumption: on-peak, shoulder-peak, and off-peak. Depending on the source of the energy data, the TOU schedule can be different. For example, the on-peak period may occur between 8 am-10 am for one source of data, but at a different time of year, the on-peak period may occur between 9 am-12 pm for the same source of data. Without the dependency identification, the PHS 104 would have no way of differentiating the data for purposes of calculating an energy consumption according to a particular TOU schedule. Moreover, different cost schedules apply during different periods of usage. For example, the cost schedule during on-peak periods is typically higher than during off-peak periods. The dependency identification allows the same source-topic data to be used to calculate energy usage according to different cost schedules or according to different TOU schedules. In essence, the dependency identification is a third identifier that allows multiple instances of the same source-topic identifiers to be stored and indexed for use in different calculations.
The ProviderMethods.dll wrapper method passes the payload information to a standard method on the Provider Ticket Service 102 called, in this example, SubmitRequest. An example of a method signature for SubmitRequest is: string SubmitRequest(int calculationId, string payload, URI endpoint, int priority).
To prevent the need to add associated methods to the ProviderMethods.dll 112, and thus recompile and distribute the DLL, Provider developers can distribute a dynamic link library (or even the Provider DLL itself), which exports an interface that includes its high-level methods.
2. The Provider Ticket Service 102 embeds the payload in a Ticket, and the Ticket together with the embedded payload is placed in the Ticket Store 204 as shown in
Additional, standardized information has been added to the above example Ticket 202. Specifically, any combination of the following fields can appear in the Ticket 202:
The ticketId field is a ticket identifier that includes an MD5 (Message-Digest algorithm 5) checksum run over the Payload portion of the Ticket 202. This ticket identifier is the identifier used to uniquely identify this particular work request in the Provider Service 100. Note that another SubmitRequest call that passes in the same Payload will result in the generation of the same ticketId value. In this way, duplicate/redundant work requests can be identified. In fact, when the Provider Ticket Service 102 first generates the Ticket 202 for newly-passed in Payload, it checks with the Status Manager 210 component of the Provider Ticket Service 102 (a component that tracks the ongoing status of each work item) to see if an identical work request (i.e. a request with the same ticketId) is already in a Ticket Store 204 component of the Provider Ticket Service 102. If so, instead of creating new structures to track a new work request, the existing structures are updated in the Status Manager 210 to reflect the fact that a new request has been made against it, and the previously-stored Ticket (in the Ticket Store 204) is updated with the URI endpoint of the new requester. If an identical request is not present in the system, new structures in the Status Manager 210 are created to track the work, and the new Ticket is stored in the Ticket Store 204 component of the PTS 102.
The calculationId field is a calculation identifier corresponding to a GUID used to uniquely identify the calculation being requested. In an example implementation, the calculation identifier corresponds directly to a single Provider 208. In other implementations involving chaining of multiple Providers together, a calculation identifier can correspond to an ordered list of Providers. An XML-based configuration file which resides on the machine that hosts the PTS 102 provides these mappings that indicates a sequence order that each of the Providers in the list are to be invoked.
A priority field optionally allows callers (e.g., Clients, such as the client 110) to indicate that their calculation request has higher/lower priority than other calls.
The creationDateTimeUtc field refers to the date and time in UTC (Coordinated Universal Time) format at which the Ticket (not the payload) was created. This information can be used to expire requests (i.e. indicate that they have timed out).
The rawDataAvailable field indicates whether or not raw data (needed to perform the requested calculation) was provided with the request. Some clients may desire to provide data obtained from an external source, rather than rely on other parts of Application Modules (such as the Data Source Drivers) to supply data. In this case, a WCF method is invoked that allows the user to pass in their own data with the ticket, and this flag will be set in the Ticket. Normally, the ticket includes a source identification that identifies the source of the raw data to be used to perform the requested calculation, and the Provider that is tasked with the calculation retrieves the raw data from the identified source(s).
The endpoints field refers to the endpoints or URIs of all the Ticket's requesters, allowing the ticket to track these requesters. If a payload arrives at the Provider Ticket Service 102 (PTS), and a payload with the same ticketId is already in progress, the caller's URI is added to this list. For a new ticketId, a new Ticket is created, and the endpoints section includes a single URI.
The providerOrderedListOfIds field specifies an ordered list of Providers, along with their identifiers and the names of the dynamic link libraries that contain them. The order indicates (in the case of chained Providers) the order or sequence in which the Providers are to be run to perform the desired calculation. Note that because one DLL might contain multiple Providers, a DLL name can be referenced by more than one Provider identifier. The mapping from the calculationId field to this information can be obtained from an XML-based configuration file located on the computing machine hosting the Provider Ticket Service 102. Because this mapping has been resolved on the PTS 102, no mapping or lookup needs to occur in the Provider Host Service (PHS) 104. The PHS 104 simply needs to have access to Provider DLLs so that the PHS can load and run the DLLs.
3. A Provider Host Service 104 (PHS) notifies the Provider Ticket Service 102 (PTS) that it is ready to accept Tickets, such as by requesting one or more Tickets as shown in
The Provider Host Service (PHS) class includes a method that returns the number of provider host threads 108 that it has available to perform work by examining the data structure that holds the thread identifiers mapped to the calculation identifiers, for example. The PHS class can perform simple or complex logic to determine how many more threads it can take on.
A PHS 104 calls a method on the PTS 102, called in this example, RequestTicket, and the PTS 102 places the PHS's URI in a list or queue 212. The URI for a PHS can exist more than once in this queue 212, as the PHS 104 may be willing to work on more than one calculation at a time on different threads. The PTS 102 maintains a list of which calculations a PHS 104 is capable of handling. If there is no entry in this list for a PHS 104 that has made a Ticket request, the PTS 102 calls a method on the PHS 104 asking for this list. As work becomes available, the PTS 102 attempts to send Tickets to the PHS URI's that are on its queue. The various PHS's (if there are more than one) may accept or refuse the Tickets 202, and may return a status result indicating the reason for their refusal. The PTS 102 can make decisions about whether to send the Ticket 202 to another PHS on the queue 212, to fail the Ticket, etc. A PHS 104 might refuse a Ticket because it is too busy (i.e. all allowable threads are active), or for some other reason.
4. The PTS 102 submits a Ticket 202 to the PHS 104, such as shown in
Logic for SubmitTicket can proceed as follows. If the PHS 104 is too busy, return Busy. If the PHS 104 is not too busy, for each Provider, ask if the DLL supports the Provider and the Provider's payload identifications. If so, return Accepted, otherwise return an indication of whether the provider identification or the payload identification was rejected.
The SubmitTicket method creates, but does not launch, a Provider Host Thread (PHT) 108 (the Thread Manager 216 will do that later), and stores a reference to the launched thread in a data structure 214. This data structure 214 stores the thread identifier, calculation identifier, checksum, and a thread expiration or “Time to Live” (TTL) and the class instance of the PHT 108. It will also return code for when the PHT 108 finishes. The Thread Manager 216 uses the TTL to determine whether the calculation has taken too long.
5. The Provider Host Service (PHS) 104 launches a thread in which to run the appropriate Provider 208. The PHS 104 receives a Ticket 202 when a WCF thread runs the ISubmitTicket::Submit method of the PHS class. Inside this method, a new Provider Host Thread (PHT) 108 is instantiated or invoked, but not run, for the request. The Ticket 202, thread instance, and other information about the request will be placed in a structure in the PHS class for later reference.
The PHS 104 includes a Thread Manager 216, which is a method of the PHS class running on a thread and monitors the threads 108 and terminates them if they exceed a timeout limit. The Thread Manager 216 prevents a locked thread from tying up resources and never exiting. The Thread Manager 216 also launches any PHTs instantiated in the previous step.
The provider host thread (PHT) 108 has members and makes certain allocations at startup, as described next. The PHT 108 receives from the Thread Manager 216 an interface with which to access the Data Store 200 (i.e. IDataAccess). It also obtains the provider count if chained, and stores it in a member property. The PHT 108 also has a member that is a reference to an instantiated Provider 208, which points to the current Provider 208 instantiated, even in the chaining example. The PHT 108 has a member that holds the Ticket 202, as well as a member that is an event or other signal-able object, which is used by the Thread Manager 216 to signal the PHT 108 that it has run out of time. If the Thread Manager 216 gets no response from the PHT 108, it calls TerminateThread, which terminates the thread. After signaling the PHT 108 that it has run out of time and to terminate, the Thread Manager 216 places a block on the PHT 108 thread identifier, and waits a reasonable amount of time for it to terminate. If it does not terminate after the waiting period, the Thread Manager 216 calls TerminateThread to terminate the thread.
While the PHT 108 is within its time to live and has not reported completion, the Thread Manager 216 does nothing about the thread. If the exit status has changed to some sort of completion, the Thread Manager 216 reports completed or failed and proceeds to Block(0) on the thread identification until the thread ends. If the thread 108 does not end in a reasonable time period, it needs TerminateThread anyway. If the thread successfully terminate itself, the thread manager can request more tickets.
If the thread 108 exceeds its TTL, the Thread Manager 216 first attempts to notify the thread 108; if that fails, the Thread Manager 216 forcefully terminates the thread. Either way the Thread Manager 216 reports a thread failure.
In the PHT 108, the “local data store” is an IDataAccess interface (part of the API) that allows communications with the same database utilized by the Data Store of the Provider Ticket Service 102, shown in
The PHT 108, after running all Providers, but before signaling completion, writes data to the Data Store 200 (i.e., the data store 200 of the Provider Ticket Service 102) as follows: The PHT 108 owns an array or dictionary that maps a Provider identification to a TransportDataObject or objects. After the PHT 108 runs all Providers, it pulls out the TransportDataObject for the final Provider's Result data and passes it to WriteTicketResults on IDataAccess, thus writing result data to the Data Store 200, which represents the result of the calculation.
The Ticket 202 can include a field that indicates whether or not raw data is retrievable from the DataStore 200. If so, the Provider 208 can read this data from the data store 200 by calling a method on IDataAccess and passing it in the Ticket identifier.
The PHT 108 has three read/write functions: ReadInputData, in which the input data for the calculation to be performed by the Provider 208 is read, WriteIntermediateData, in which the PHT 108 outputs an intermediate result for another chained Provider, WriteResultData, in which the PHT 108 outputs the result of the calculation when the PHT 108 is the last chained Provider or the only Provider needed to carry out the requested calculation. The PHT 108 determines what logic is involved in the case where third party data is provided, and for different Providers in a chain.
6.
A combination of the above can also be utilized. For example, a gadget 110 displaying information from the past hour refreshes every 15 minutes. A Provider 208 can retrieve the results of the first 45 minutes from the Data Store 200 and thus only needs to acquire 15 minutes worth of raw data from the DSB 600.
While running, a Provider 208 calls UpdateTicketStatus on an interface that is implemented in the Provider Host Thread class, and has access to the PHT class member that shows the number of Providers in the chain. This allows the PHT code, which is aware that the percentage complete from a particular Provider is only part of the picture, to calculate the overall percentage complete and pass that completion status to the PTS 102.
The Provider 208 can also check whether the Ticket 202 has been canceled so that the Provider 208 can terminate the calculation early and free up resources for other Tickets. The Provider's coder can perform these updates and checks and to write applicable intermediate date to the Data Store 200 of the PTS 102.
7.
8.
9. When the client 110 determines that there are results ready for it, it requests the result data, again using its token. The Provider Service 100 passes this request to the Ticket Manager 206. The Ticket Manager 206 queries the Data Store 200 for the corresponding result and returns it.
At this point the Ticket 202 is considered to have completed its life cycle. It is deleted from the Ticket Store 204 and its status information is erased from the Ticket status table.
The Provider Service's Communication Wrapper 106 can include an interface to allow for callback notification. Additionally, when multiple Providers are chained together to perform a sequence of calculations, the Ticket Manager 206 uses the Ticket to determine which Provider's result(s) to pass back. In addition to submitting Tickets, checking on progress, and retrieving results, a Client 110 can also cancel a Ticket. When the Provider Service 100 receives a cancel request, the Ticket Manger 206 marks the Ticket canceled status as “true.” The Ticket Manager 206 should not immediately delete the Ticket for several reasons. First, a Provider might already be working on that Ticket. Second, the Ticket might still be pending, but its ID might be in the middle of a queue or it is in the middle of being handed off to a PHS 104.
If a Provider 208 is working on the Ticket 202, it should periodically check to see if a Ticket is marked for cancel. Upon discovering this, the Provider 208 should immediately, and gracefully, terminate, performing any necessary clean-up. If a Provider does not check for cancellation, then it merely runs to completion. All that is affected is that a thread is tied up working on an expired Ticket. After the Provider has terminated, the PHS 104 sets the Ticket status to “completed” as it normally does.
If the Ticket is still pending, as the Ticket Manager 206 is retrieving Tickets from the Ticket Store 204 in Block 3 above, the Ticket Manager 206 deletes any Tickets that have been flagged as canceled.
The Ticket Manger 206 will occasionally perform a cleanup of any canceled Tickets that are ready to be deleted. In other words, it deletes any Ticket that has an is-canceled flag of “true” and a status of “completed.”
The component named Status Manager 210 resides in the Provider Ticket Service 102, and includes a state machine (or other means of managing state logic) and two dictionaries. The first dictionary in the Status Manager 210 maps a Ticket checksum (i.e. a ticket identifier, ticketId) to a status object, which includes all status information about a particular work item. The second dictionary maps a client token (i.e., a requesterId or client requester identification) to the Ticket checksum (ticketId). This allows indexing into a status object using either a ticketId or a requesterId. An exemplary diagram of the logic for the state machine used by the Status Manager 210 is shown in
The Status Manager 210 receives a new request for a ticket status. In this example, the ticket can have any of six statuses: pending, in-progress, pending-canceled, failed, in-progress-canceled, or completed. Initially, the status of a ticket is pending. When a work request is received, the status of the ticket is changed to in-progress, and when the calculation result has been completed, the status of the ticket is changed from in-progress to completed, and the Ticket Manager 206 removes the ticket from the Ticket Store 204. If a request to cancel the ticket is received while the ticket status is pending, the status of the ticket is changed to pending-canceled. A request to cancel the ticket can be reversed, reverting the ticket's status back to pending. If the ticket is canceled, the Ticket Manager 206 removes the ticket from the Ticket Store 204. While a ticket's status is in-progress, if an error occurs, for example a timeout limit is reached for completing the calculation, the ticket's status is changed to failed. Once in the failed state, the Ticket Manager 206 can resubmit the ticket to retry the calculation, in which case the ticket's status is changed back to pending and placed in the pending queue. Alternately, the Ticket Manager 206 can remove a failed ticket from the Ticket Store 204 and notify the client 110 of the removal and optionally the reason for the failure. While the calculation is being performed and the ticket's status is in-progress, a request to cancel the ticket can be made, changing the ticket's status to in-progress-canceled. For example, another Provider may have just completed the same calculation, and the ticket can be canceled to avoid duplicating the effort. The other Provider's result can be returned to the client, and the ticket's status can be changed to completed and then removed. A cancel request can be reversed, reverting the ticket back to in-progress status. If the ticket is canceled, the Ticket Manager 206 removes the canceled ticket from the Ticket Store 204.
The following exemplary code corresponds to an interface for submitting work requests, monitoring work status, and retrieving results.
The Provider Service 100 can function as a stand-alone component. In a stand-alone deployment, the Provider Service 100 obtains its configuration information from a local configuration file or store. If deployed as part of an Application Modules system, it can obtain its configuration information directly from the Configuration Service.
The Provider Service 100 can be customizable in that the Provider Service 100 can load plug-in dynamic link libraries called Providers that customize and extend the types of available calculations.
While the components for the Provider Service 100 can be implemented using any known combination of platforms, frameworks, and interfaces, in the examples provided herein, the Provider Ticket Service 102 is wrapped by a Windows Communication Foundation (WCF) service 106. The WCF API allows client access to all public functionality of the Provider Ticket Service 102. The software framework for coding the components of the Provider Service 100 can be the MICROSOFT®.NET Framework using the Enterprise Library Cache Application Block.
The algorithm 1000 associates a unique ticket identifier (e.g., an MD5 checksum described above), with each of the tickets (1004). A Ticket Manager 206 of the Provider Ticket Service 102 submits a selected ticket from the PTS 102 to the PHS 104 (1006). The PTS 102 inspects the calculation identifier in the ticket to determine which provider or providers is to perform the calculation identified by the calculation identifier of the selected ticket (1008).
The algorithm 1000 determines whether the requested calculation indicated by the calculation identifier has already been performed and previously stored in the data store 200 (1010). If so, the PTS 102 retrieves the previously calculated result from the data store 200 and returns that previously calculated result to the requesting client 110 (1014). If not, the PTS 102 determines whether another provider is in the process of performing the calculation requested by the selected ticket (1012). If so, the PTS 102 waits for the other provider to perform the calculation, and when the other provider has returned the result of the calculation, the PTS 102 provides that result to the requesting client associated with the selected ticket (1016). Note that blocks 1010 and 1012 can be performed in any order.
If the requested calculation has not already been performed and is not being worked on currently, the PHS 104 launches a provider host thread 108 that invokes or instantiates the provider (1018) that performs the calculation identified by the calculation identifier of the selected ticket (1020). The PTS 102 receives from the PHS 104 a result of the calculation carried out by the invoked provider 108 (1020), and returns the result to the requesting client associated with the selected ticket (1022).
It should be noted that any of the algorithms illustrated and discussed herein, including the algorithm 1000, have various modules that perform particular functions and can interact with one another. It should be understood that these modules are merely segregated based on their function for the sake of description and represent computer hardware and/or executable software code which is stored on a non-transitory, computer-readable medium for execution on appropriate computing hardware. The various functions of the different modules and units can be combined or segregated as hardware and/or software stored on a computer-readable medium as above as modules in any manner, and can be used separately or in combination.
Furthermore, any of the algorithms disclosed herein include machine readable instructions for execution by: (a) a microprocessor, (b) a microcontroller, and/or (c) any other suitable processing device. It will be readily understood that the Provider Ticket Service 102 and the Provider Host Service 104 can be implemented on any one or more suitable processing device(s). Any algorithm, such as the algorithm 1000, disclosed herein can be embodied in software stored on a non-transitory, tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.). Although specific algorithms are described with reference to flowcharts or functional block diagrams depicted herein, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.
The following table identifies examples of topical information that can be encoded in the topic identification (topicId) for various topical groups:
While particular implementations and applications of the present disclosure have been illustrated and described, it is to be understood that the present disclosure is not limited to the precise construction and compositions disclosed herein and that various modifications, changes, and variations can be apparent from the foregoing descriptions without departing from the spirit and scope of the invention as defined in the appended claims.
