Patent ID: 12236170

While the invention is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the invention to the particular embodiments described. On the contrary, the invention is intended to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure.

DETAILED DESCRIPTION

FIG.1depicts an illustrative conception of a configurable domain environment100(referred to herein, interchangeably, as an “application”). In embodiments, the environment100can be, for example, packaged as an application or service, as part of an application or service, or the like. The illustrative domain environment100shown inFIG.1is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the inventions disclosed throughout this document. Neither should the illustrative domain environment100be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein.

Additionally, any one or more of the components depicted inFIG.1can be, in embodiments, integrated with various ones of the other components depicted therein (or components not illustrated). Any number of other components or combinations of components can be integrated with the illustrative domain environment100depicted inFIG.1, all of which are considered to be within the scope of the invention.

As illustrated, the environment100includes a domain model110that includes one or more model entities112and114. Model entities112and114can include any type of entities that can be used in the context of domain modeling and may include code written in a coding language such as, for example, C, C++, C#, Java, Ruby, or the like. Model entities112and114can include entity attributes116and118. Examples of entity attributes include aspects of state (e.g., attributes, variables, definitions, properties), behavior (e.g., methods, functions, algorithms, relations, events, event-handlers), and the like. Each of the model entities112and114can include any number of entity attributes116and118, respectively. In embodiments, one or more model entities112and114are combined to create the domain model110. According to embodiments, the domain model110can be used to model any number of different types of domain-based problems and perform any number of different types of domain-based tasks. Examples of such tasks include financial modeling, investment decision modeling, engineering modeling, performing numerical approximation to complex systems of equations, and the like.

To facilitate a clear illustration of various aspects of embodiments of the invention, a simple modeling problem involving the configuration of fruit baskets will be discussed throughout this disclosure. For example, a domain environment in accordance with embodiments of the invention may be used to configure a “fruit basket” domain model consisting of a fruit basket model entity and different fruit model entities (e.g. an apple model entity, an orange model entity, and a banana model entity), which may have various arbitrary attributes (e.g., properties, methods, relations, events, functions, methods, conditions, and the like) related to color, size, placement, or types of fruit to be included, relationships and/or interactions between model entities, and the like.

With continued reference toFIG.1, the illustrative domain environment100includes a representation entity120that provides a representation of one or more of the model entities112and114. In embodiments, the domain environment100can include any number of representation entities120. The representation entity120may interact with a user interface (UI) module122to present aspects of the domain model and/or model entity on a graphical user interface (GUI)124on a display device (not shown). Additionally, the representation entity120may be used with a model entity112and/or114directly, via code for example, to present aspects of the model entity112and/or114that may be exposed. In embodiments, representation entities120can be created via programming code or in XML, JSON, or other formats and can be used or configured to create a desired representation or experience of the underlying domain model110. For example, in embodiments, representation entities120can be defined, outside of run-time, to include all of the definitions, rules, and criteria used for selectively exposing attributes that are relevant to a particular task or representation of the domain model110. According to embodiments, this can simplify the representation of domain model110, allow re-use of model entities and domain models, and allow multiple representations of a domain model and/or its model entities.

As introduced above, a representation entity can be used to provide a representation of a model entity (or entities). The representation can include, for example, a representation of model entity inputs, outputs, and domain model structure.FIGS.2A,2B, and2C illustrate representation aspects associated with representation entities in accordance with embodiments of the invention.FIG.2Ashows two representation entities210and230based on the same model entity201. The model entity201may include a number of entity attributes. In the illustrated embodiments, for example, model entity201includes model entity input attributes C1, C2, and C3and model output attributes O1and O2.

The representation entity210provides a representation220(e.g., via a GUI or an API) of the model entity201. The representation220, which can be rendered in a GUI (e.g., GUI124depicted inFIG.1) on a display device, can include a grid222and outputs224and225. It should be understood that output definition210bcan also include additional features that may control the presentation of outputs such as state definitions, active criteria, and the like. Based on the type of application, and therefore, in embodiments, particular active states, settings, and the like, the representation entity210defines the grid222by exposing various model entity attributes and/or by defining the appearance of the grid222. For example, inFIG.2A, model entity201is instantiated and representation entity210defines bindings that bind to model entity attributes (e.g., C1and C2) using grid cells222a. In this example, representation entity210excludes input attribute C3from the representation perhaps, for example, because input attribute C3is not used in the representation240.

Also, as shown inFIG.2A, representation entity210defines outputs224and225that may be displayed. In embodiments, the outputs224and225can represent a selection of model entity201output attributes (e.g., O1, and O2), and can be selected, for example, based on the type of application, and therefore, in embodiments, based on particular active states, rules, settings, and the like. Additionally, as introduced above, representation entity210may define an appearance of outputs224and225. In embodiments, representation entity210can include active criteria or rules that provide for activation/deactivation of various states defined in the representation entity210, which determine the representations224and225of output attributes. According to embodiments, the representation entity210can also include report definitions that facilitate providing output reports (not shown), which may be based on various states, rules, settings, and the like.

InFIG.2A, representation entity230may define a different representation240(than that of representation entity210) of inputs and outputs corresponding to the same underlying model entity201. As illustrated, for example, representation240includes a grid242(which may include, as shown for example, a different arrangement of grid cells242a) and outputs244and246. For instance, in the fruit basket example, model entity201might be an apple model entity. Representation entity210might be a Fuji representation of apple model entity201whereas representation entity230might be a red delicious representation of apple model entity201. In the illustrated example, the representation246of output attribute O2is a function of the model entity output attribute O2. That is, in embodiments, a representation entity can include a definition of an output (e.g., (F(O2))) that facilitates providing an output that is based on a model entity output attribute. For example, a representation entity can include a formula that calculates an output, taking as input a model entity output attribute, whether that model entity output attribute is contained in the model entity, or model entities, associated with the representation entity, or another model entity attribute. Additionally, in embodiments, the representation entity can transform model entity output attributes, define which graphical depictions of model entity output attributes are available, and the like. In embodiments, Representation entity attributes defined in a representation entity may be stored or maintained in an underlying domain model via one or more model entities or model entity attributes.

For a particular representation utilizing a domain model, any number of different combinations of model entities and/or model entity attributes may be instantiated or exposed, while others may not be instantiated or exposed (e.g., some representations may not utilize particular entities). According to embodiments, in order to provide these different representations, different representation entities can be used. In this manner, a representation of a domain model can be redefined to perform different functions, have different appearances, and the like, by replacing, for example, a first representation entity, or a first set of representation entities, with another representation entity, or another set of representation entities. In embodiments, a representation entity can be modified to create a different representation entity. Additionally, in embodiments, a single representation entity (or set of representation entities) can be used to produce different representations such as, for example, by activating/deactivating different states, links, bindings, or the like.

FIG.2Billustrates an example of how a representation entity, or a set of representation entities, can be used to provide two different representations of the same domain model250, in accordance with embodiments of the invention. For example, as illustrated, domain model250includes a number of model entities252,254, and256(named, in this example, as “Model Entity 1,” “Model Entity 2,” and “Model Entity 3,” respectively). These model entities252,254, and256(or various attributes thereof) may be included or excluded in various different representations. For example, while representation entity260includes model entities252,254, and256in providing representation264, representation entity270includes only model entities252and256in providing representation274. In embodiments, representations264and274may be provided by two different representation entities, two different sets of representation entities, or the like.

Additionally, representation entities may define one or more relationships among model entities within a domain model. A set of relationships among model entities is referred to herein as a domain model structure, and a representation of a domain model structure is referred to herein as a representation structure. In embodiments, such run-time relationships and/or representations may be defined directly or indirectly such as, for example, by using definitions in one or more representation entities. Defining a domain model structure indirectly may be useful, for example, in models in which relationship definitions can be contained within the representation entities themselves. An example of this is a tree structure in which each representation entity can define a model entity's allowed children. In embodiments, other types of domain model structures and/or representation structures may be defined directly using one or more representation entities that define relationships among a number of model entities, as represented by representation entities.

In an embodiment, for example, as shown inFIG.2C, a domain model280(e.g., a fruit basket configuration model) includes model entities282and284. For instance, model entity282may be a fruit basket model entity and model entity284may be an apple model entity. A set286of representation entities286a,286b, and286c, define a first domain model structure, which is represented by representation structure288. A set290of representation entities290a,290b, and290c, define a second domain model structure, which is represented by representation structure292. For instance, representation entities286aand290amay correspond to fruit basket representations, representation entities286band290bmay correspond to red delicious apple representations, and representation entities286cand290cmay correspond to Fuji apple representations. The representation structure288may be provided to represent a first domain model structure, which may be defined indirectly via allowed parent-child relationships defined within each representation entity286a,286b, and286c. For example, as shown, representation structure288may be a tree having a parent node288athat corresponds to the fruit basket representation and two allowed child nodes288band288cthat correspond to red delicious and Fuji apple representations, respectively. Representation entity290amay define the Fuji apple representation as its only allowed child type, thereby resulting in the representation structure292that includes only one child node288c, which corresponds to the Fuji apple representation.

In embodiments, a representation structure definition can include any number of different types of functionality that may enable configuration of an instance of a domain model structure by, for example, defining an allowed model entity via a representation entity, instantiating a default model entity via a representation entity, searching for a representation entity type (e.g., as applied to model entities) within the structure, and the like. Embodiments of the invention allow access to a set of available views (e.g., representations) of a model entity. For example, in embodiments, a set of view options can be provided (e.g., via a drop-down menu) that correspond to a selected model entity in the structure.

With reference toFIG.2A, representation entity210includes a definition210aof a grid222, which can include any number of grid cells222a. As shown, representation entity210also includes a definition210bof outputs224and225. Similarly, representation entity230can include inputs and outputs definitions, as well, and representation entities210and230can include any number of other features in addition to, or in lieu of, the features illustrated inFIG.2A. In embodiments, the definition210acan specify a layout of cells222a. In embodiments, the representation entity210can include a number of definitions210athat define any number of different grids222. For example, in embodiments, representation entity210can define a first grid222that is presented in a representation220and underlying grids that can be accessed, for example, through a drilldown functionality defined on a cell222a(as discussed below, with reference toFIG.3). In embodiments, a grid222may be organized having particular conceptualizations (referred to herein as “representation properties”) represented by one or more rows of a grid222, while various attributes of the representation properties can be described by columns of the grid222. It should be understood that the description of representation properties and columns is merely one example of any number of possible types of organizations of representations. Examples of other types of representation organizations can include, but are not limited to, cubes, hypercubes, graphs, and the like.

In embodiments, grid definitions210a(and, in embodiments, any number of other definitions or attributes included in representation entities) can define states, active criteria, links, bindings, validation criteria (which can be used to test the validity of various cells, links, bindings, and the like, without having to feed test data into the domain model), defaults (e.g., default cell values, default bindings, default links, and the like), and the like. Any number of different types of states can be defined on (e.g., corresponding to) a cell. In embodiments, each cell, and its state, can be individually defined, and in embodiments, groupings (e.g., rows and columns, cubes, hypercubes, and the like) of cells may be defined in one or more states. A state can, for example, define a behavioral attribute. Such behavioral attributes can include, for example, whether a cell (or group of cells) is active or inactive, a set of allowed display values associated with a bound value set, whether a cell (or group of cells) is read-only or read/write, whether a cell (or group of cells) is linkable, one or more validation criterion associated with a cell (or group of cells), whether a binding, link, and/or drilldown is active or inactive, and the like. In this manner, states can be used to provide dynamic functionality based on events, model entity states, domain model states, and the like. States, cells, groups of cells, bindings, links, drilldowns, and the like, can be activated and deactivated according to active criteria.

FIG.3is a schematic block diagram depicting aspects of input representation provided by representation entities in accordance with embodiments of the invention. As shown, a model entity300can include a number of different model entity attributes322,324,326,328,330,332,334,336, and338. A grid binding312can be defined between a grid310and the model entity300. For example, in embodiments, a representation entity (not shown inFIG.3), can define the grid binding312. In embodiments, the grid binding312can be active or inactive based on a state which may be determined based on one or more active criteria. In some embodiments, a grid310can be directly bound (e.g., via grid binding312) to a model entity300while, in other embodiments, the grid binding312can be indirect. For example, in embodiments, the grid binding312can bind the grid310to an intermediary construct (e.g., a transfer object or entity, a translation component, a network service component, a deduplication component, and the like), which can be bound to, or in effect, alter the state of, the model entity300. According to embodiments, whether the grid binding312is direct or indirect, the grid binding312can allow for changes applied at the representation level (e.g., via the grid310) to affect one or more states of the model entity300.

In embodiments, one or more cell bindings may be defined (e.g., by a representation entity). In embodiments, a cell binding can bind a grid cell to a model entity or model entity attribute. As depicted inFIG.3, a first cell binding360binds a cell342to an entity attribute322, a second cell binding362binds a cell350to an entity attribute324, and a third cell binding364binds a cell358to an entity attribute326. It should be understood that, in the context of embodiments of the invention, a binding can be created between a representation (e.g., a grid cell) and one (e.g., via a single state definition) or more (e.g., via multiple state definitions) model entities or model entity attributes. Additionally, in embodiments, cell bindings may bind a grid cell to more than one model entity or model entity attribute. For example,FIG.3depicts a cell binding366that binds the cell342to an entity attribute328, which may be in addition to the binding360that binds the cell342to the entity attribute322.

FIGS.4A and4Bdepict illustrative binding aspects associated with state definitions in representation entities in accordance with embodiments of the invention. InFIGS.4A and4B, a model entity400is represented, via a representation entity (not shown), by a grid402. As illustrated, a cell binding404binds a cell406to a model entity attribute408. A cell binding410binds a cell412to a model entity attribute414. A cell binding416binds a cell418to a model entity attribute420and an additional cell binding422binds the cell418to another model entity attribute424. A cell426includes an enumeration428of a number of options430and432, which may, for example, correspond to different domain tasks facilitated by the model entity400. In embodiments, a button434can be provided that, when selected, causes the enumeration428to be displayed, allowing selection of the model430or432. In some embodiments, the grid402might not include an enumeration428.

InFIG.4A, “Option 1” has been selected. As a result of the “Option 1” being selected, one or more active criteria corresponding to the cell418causes one or more states to be activated or deactivated based on the selection. For example, inFIG.4A, as a result of selection of “Option 1”, an active criterion corresponding to the cell418causes the binding416to be active and another active criterion (or, in embodiments, the same active criterion) causes the binding422to be inactive. InFIG.4B, “Option 2” has been selected and, as a result, the active criteria causes binding416to be inactive and binding422to be active. Whether bindings416and422are active may be determined, in embodiments, according to an active criterion that is triggered by something other than selection of a member of an enumeration428(e.g., a model entity or domain model being in a particular state, an event, and the like).

For instance, in the fruit basket example, the model entity400might be an “apple” entity and a property of the apple represented by the grid402might be the sweetness of the apple. The state, for example, may correspond to the units (e.g., variables) upon which a determination of the sweetness is based. Thus, for example, a first state may correspond to an expression of sweetness as a function of sunlight exposure (e.g., relating to the effect that exposure to sunlight has upon the sweetness) and a second state might correspond to an expression of sweetness as a function of humidity exposure (e.g., relating to the effect that exposure to humidity has upon the sweetness).

In embodiments, links can be defined according to types of linkable components (e.g., model entities, model entity attributes, model entities that are of a representation entity type or types, and/or model entity attributes that are included in a representation entity type or types, and the like). In embodiments, a link to a linkable component may cause the linkable component to become a part of a calculation chain associated with, or otherwise establish a relationship with, the domain model. In embodiments, a representation entity may include definitions that specify that a particular cell can only be linked to a particular entity type, attribute type, or the like. In embodiments, link types can be defined at the model entity level, representation entity level, model entity attribute level, and/or representation entity attribute level. For example, in the above example, a model entity attribute may be bound to an apple model entity and, using representation entities, links can be further restricted to types of Fuji, Granny Smith, or both.

FIG.5depicts examples of such linking aspects in accordance with embodiments of the invention. In embodiments, a state can be defined on a cell that allows the cell to be linkable. Additionally, in embodiments, the types of components to which the cell can be linked (“linkable components”) can also be defined in the representation entity (e.g., using states, explicit definitions, and/or the like). In embodiments, allowable bindings can be defined between the linkable cells and the linkable components. The cell can then be bound to linkable component such as, for example, a model entity (e.g., an Apple entity), a model entity attribute (e.g., a property defined on an Apple model entity), a model entity that is of a representation entity type (e.g., a Fuji entity), or a model entity attribute that is defined in a representation entity type (e.g., a property defined in the Fuji entity). As shown inFIG.5, a grid510includes a cell522that is linked to a model entity524(which is represented by a representation entity526), and a cell528that is linked to a model entity attribute530of a model entity532(which is represented by a representation entity534).

In embodiments, a collapsed representation of a grid222may also be defined. For example, using a collapsed representation, a set of rows and columns can be represented in a single row, while preserving row and column identifiers in column headers associated with the columns. In this manner, the representation (e.g., grid) can be collapsed without losing information used to completely identify a specific cell using the same nomenclature that would be used to identify the same cell in a non-collapsed representation. In embodiments, nomenclature consistency may be useful for functional aspects of domain models such as identifying a link or a path to a cell. Collapsed representations can be used, in embodiments, to represent multiple model entities, composite model entities, and the like in the same grid.

According to embodiments, collapsed representations can also be used to provide filter views, which can include a set (which may include all or a subset) of related model entities, or of related model entities of a particular representation entity type or types, and which can allow for creation or editing of numerous model entities, or numerous model entities of a representation entity type or types, in a single view. For example, an apple filter view may be selected from a fruit basket entity, causing a collapsed representation of attributes related to all of the available apple types, or specific apple types. In embodiments, filter views can correspond to model entities, representation entities, and the like.

FIGS.6A and6Billustrate examples of collapsing grids in accordance with embodiments of the invention. For instance, in the fruit basket example, grid610amay be used to provide inputs to an apple model entity (“Apple 1”) and may include a representation property622arelated to the size of the apple, identified by a row header623a; a representation property624arelated to a color of the apple, identified by a row header625a; a value column626a(e.g., magnitude of some measurement of size, indication of color, and/or the like), identified by a column header627a; and a units column628a(e.g., units in which the magnitude is expressed such as cubic centimeters, cubic inches, and the like), also identified by a column header628a. Because color, in this example, may be expressed with a single, independent word or phrase, the units column628amay not be active for the color property624a. However, in other embodiments, color may be expressed in other ways (e.g., related to pixel counts or densities, intensities, saturations, and/or the like) and may include a units column.

Thus, the grid610amay include input cells614a,616a, and618a. A grid612acan be defined to collapse the representation of grid610awithout losing information (e.g., information represented in the cells, the column headers, and the like). As shown, the grid612aincludes one row630aof input cells614a,616a, and618a. Additionally, the grid612apreserves the column headers627aand629ain a header row634aand the row headers623aand625ain a higher-level header row636a. Additionally, the grid612acan include a higher-level header row638athat includes a header identifying the associated model entity and may, in embodiments, include a row header640aidentifying the associated model entity as represented by a particular representation entity.

Similarly, as shown inFIG.6B, grid610bmay be used, for example, to provide inputs to an orange model entity (e.g., as represented by an “Orange 1” representation entity) and may include a representation property622brelated to the size of the orange, identified by a row header623b; a representation property624brelated to a color of the orange, identified by a row header625b; a value column626b(e.g., magnitude of some measurement of size, indication of color, and/or the like), identified by a column header627b; and a units column628b(e.g., units in which the magnitude is expressed such as cubic centimeters, cubic inches, or the like), also identified by a column header629b.

A grid612bcan be defined to collapse the representation of grids610aand610bwithout losing information, in which, for example, the apple and orange representation entities may be related or allowed related entities of fruit basket model entities. In embodiments, the apple and orange representation may be included within one or more fruit basket model entities. As shown, the grid612bincludes one row630bof input cells614a,616a,618a,614b,616b, and618band preserves the column headers627a,627b,629a, and629bin a header row634b. The grid612balso preserves the row headers623a,625a,623b, and625bin a higher-level header row636b. In the illustrated example, the row630bis identified by a row header640bthat identifies that the row corresponds to a “Fruit Basket 1” model entity. In this manner, a grid612bcan, for example, be used to show collapsed representations of attributes associated with a number of model entities, where each row may correspond to a model entity that may be a parent of, contain, or be otherwise related to the other model entities represented in the row. For example, similar features of a second fruit basket model entity could be represented in a second row, which may be labeled “Fruit Basket 2.”

By preserving the header and cell information when forming a grid612aor612b, embodiments of the invention allow the representation to be consistent between both grid representations610a/610band612a/612b. Additionally, by retaining each cell representation, embodiments of the invention allow preservation of information such as, for example, identifications of links or paths. For example, cell614aof the grid610acan be represented by the same path name, “[Apple1]$Size$Value”, as cell614aof the grid612b. Note, however, that, in embodiments, a grid610acan be associated with a particular model entity type (e.g., [Apple1]) and, therefore, it may be sufficient for the cell614ain the grid610ato be represented by “$Size$Value” within grid610a, whereas, in the grid612b, it may be useful for the cell614ato include “[Apple1]” as part of its path in grid612b, to indicate the model entity to which the cell relates. The use of relative path names described above simplifies the path based on where the cell is referenced and does not affect the preservation of information; the full path name may still be used to identify the cell and will be consistent between the collapsed and non-collapsed grid representations.

FIG.7depicts a portion700of an illustrative domain environment such as, for example, the illustrative domain environment100depicted inFIG.1. As shown inFIG.7, a domain model710is represented using a domain model representation file (DMRE)712. The DMRE contains representation entities718,720,722, and724. For example, in embodiments, the environment can be packaged as an application and, in the application, all of the representation entities718,720,722, and724used to produce the application experience can be contained in a DMRE712. As illustrated, the DMRE712can include, for example, a high-level representation entity718that interacts with, and/or organizes additional, lower-level representation entities720,722, and724. For instance, in the fruit-basket example, the DMRE712can be a “project” that includes all of the representation entities718,720,722, and724used in the fruit-basket application. Any one or more of the representation entities718,720,722, and724can provide representations of any one or more of the model entities714and716. Additionally, in embodiments, active criteria can be applied throughout the DMRE712and can be used, for example, to facilitate configuring various aspects of a representation of the domain model710.

FIG.8is a flow diagram depicting an illustrative method800for creating a representation of a domain model in accordance with embodiments of the invention. The illustrative method800is just one example of a method that could be performed in accordance with embodiments of the invention and is not intended to imply any particular order among or between various steps herein disclosed (or other steps that may be employed that are not explicitly disclosed in the context ofFIG.8). For instance, in embodiments, additional states may be added after active criteria are added; representational aspects of a cell, such as link and drilldown view definitions may be defined before active criteria are defined; and the like. In embodiments, the domain model and representation (or representations) can be combined to create an application. In embodiments, an application can include application components such as, for example, model entities, model entity attributes, representation entities, representation entity attributes, and the like. The representation of the domain model can include, for example, one or more representation entities. In embodiments, the domain model includes one or more model entities, each of which can include one or more model entity attributes such as, for example, model entity members, properties, methods, events, and the like.

As shown at block810, the illustrative method800includes defining a grid. Defining the grid can include defining cells, defining rows of cells, defining columns of cells, defining higher-order dimensional arrangements of cells, and defining a visual layout of a grid having one or more cells. In embodiments, for example, defining the visual layout can include defining a set of cells each identified by a row and a column. Embodiments of the illustrative method800include defining a collapsed representation of the set of cells, where the collapsed representation preserves row and column identifiers for each cell in column headers. At block812, the illustrative method800includes defining one or more states corresponding to a cell. In embodiments, states can also correspond to any number of other application components, as described above. Embodiments of the illustrative method800also include defining one or more bindings (block814). Each binding can bind a cell to a model entity or model entity attribute. Additionally, in embodiments, a binding (and associated states) can be defined such that the binding is active when a particular state is active.

As shown at block818, the illustrative method800includes defining active criteria associated with states. For example, in embodiments, a state corresponding to a cell may define a behavioral attribute that includes at least one of whether the cell is active or inactive, a set of allowed display values associated with a bound value set, whether the cell is read only or read/write, whether the cell is linkable, and validation criteria associated with the cell. In embodiments, an active criterion can be defined that determines the behavioral attribute. At block820, the illustrative method800includes defining a link associated with an application component. In embodiments, defining the representation of the domain model can also include defining outputs, output behaviors, a domain model structure, and any number of other features associated with representing a domain model or portions thereof.

Embodiments of the disclosed subject matter are described in the general context of computer-executable instructions. Computer-executable instructions can include, for example, computer code, machine-useable instructions, and the like such as, for example, program components, capable of being executed by one or more processors associated with a computing device. Generally, program components including routines, programs, model entities, objects, modules, data structures, and the like, refer to code that, when executed, causes a computing device to perform particular tasks (e.g., methods, calculations, and the like) or implement or manipulate various abstract data types. Some or all of the functionality contemplated herein can also be implemented in hardware and/or firmware.

Computer-readable media include both volatile and non-volatile media, removable and nonremovable media, and contemplate media readable by a database, a processor, a router, and various other networked devices. By way of example, and not limitation, computer-readable media can include computer-storage media, which is media implemented in any method or technology for storing information. Examples of stored information include computer-executable instructions, data structures, program modules, and other data representations. Media examples include, but are not limited to, Random Access Memory (RAM); Read Only Memory (ROM); Electronically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technologies; Compact Disc Read-Only Memory (CD-ROM), digital versatile disks (DVDs) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; data transmissions; or any other medium that can be used to encode information and can be accessed by a computing device such as, for example, quantum state memory, and the like.

Embodiments may be practiced in a variety of system configurations, including handheld devices, general-purpose computers, specialty computing devices, servers, workstations, cloud computing platforms, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by a number of computing devices that are linked through a communications network. According to embodiments, a computing device can include any type of computing device suitable for implementing embodiments of the invention. Examples of computing devices include “workstations,” “servers,” “laptops,” “desktops,” “tablet computers,” “hand-held devices,” and the like, all of which are contemplated within the scope ofFIG.1and reference to various components of the domain environment100.

In embodiments, a computing device includes a bus that, directly and/or indirectly, couples the following devices: a processor, a memory, an input/output (I/O) port, an I/O component, and a power supply. Any number of additional components, different components, and/or combinations of components can also be included in the computing device. The bus represents what may be one or more busses (such as, for example, an address bus, data bus, or combination thereof). Similarly, in embodiments, the computing device can include a number of processors, a number of memory components, a number of I/O ports, a number of I/O components, and/or a number of power supplies. Additionally any number of these components or combinations thereof can be distributed and/or duplicated across a number of computing devices.

Any number of other various types of embodiments may be contemplated within the ambit of the invention. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations as fall within the scope of the present disclosure, together with all equivalents thereof. While the subject matter of embodiments of the inventions disclosed herein is described with specificity, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or features, or combinations of steps or features similar to the ones described in this document, in conjunction with other technologies. Moreover, although the term “block” may be used herein to connote different elements of methods employed, the term should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly called for.