Patent Application
20090319951
This application is based on the claims the benefit of priority from European Patient Application No. EP08158534.1 filed Jun. 19, 2008.
The management of generic resources (for example, of a data processing system) is a critical activity. This is particularly true in modern systems, which include a number of different types of resources (such as computers, software programs, users, and the like) with a myriad of correlations (such as locations of the computers, installations of the software programs, authorizations of the users, and the like).
Resource management operations typically involve the execution of a long series of heterogeneous basic tasks in a specific sequence. For example, in order to verify compliance in a selected environment of the installed software programs with available licenses, it may be necessary to determine the software programs installed on each computer of interest, to meter their usage, to collect corresponding usage information from the different computers, and to compare the collected usage information with the available licenses.
Methods, systems, and computer program products for aggregating service components in a data processing system according to predefined aggregation rules. The method includes providing a plurality of visual elements, each visual element representing a corresponding service component: selecting a new visual element of a new service component for addition to an aggregation structure: determining a set of eligible visual elements of eligible service components among the instantiated service components: associating a visual cue with the eligible visual elements; and aggregating the new service component to a selected eligible service component of a selected eligible visual element in the aggregation structure. The new service component is compatible for aggregation with each eligible service component according to the aggregation rules. The aggregation structure includes an aggregation of instantiated visual elements of instantiated service components to define an aggregated service according to the aggregation of the instantiated service components.
One embodiment is a resource management system for aggregating service components in a data processing system according to predefined aggregation rules. The resource management system includes a container of a graphical user interface for providing a plurality of draggable widgets, each draggable widget representing a corresponding service component: a pointer for selecting a new widget of a new service component for addition to an aggregation structure of the graphical user interface: an analyzer for determining a set of eligible bricks of eligible service components among the instantiated service components, the new service component being compatible for aggregation with each eligible service component according to the aggregation rules: a rendering module for associating a visual cue with the eligible bricks: and an engine for aggregating the new service component to a selected eligible service component of a selected brick in the aggregation structure. The aggregation structure includes an aggregation of bricks of instantiated service components to define an aggregated service according to the aggregation of the instantiated service components.
The foregoing and other objects, features and advantages of the disclosure will be apparent from the following more particular descriptions of exemplary embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the invention.
Embodiments of the invention relate to defining a resource management operation in a consistent way by simply manipulating graphical objects. With reference in particular to
More specifically, the client 115 (for example, a personal computer) may include a central unit 120, which houses the electronic circuits controlling its operation. These electronic circuits may include a microprocessor, a working memory, drives for input/output units, a network adapter (for connecting the client 115 to the network 110, for example), and the like. The client 115 is also provided with a hard-disk and a drive 125 for reading CD-ROMs and/or DVD-ROMs 130. A monitor 135 is used to display images on a screen 140. Operation of the client 115 is controlled by means of a keyboard 145 and a mouse 150, which are connected to the central unit 120 in a conventional manner.
The operations used to manage the desired resources may be defined by aggregating corresponding service components: each service component defines a basic block that contributes in defining the whole resource management operation. The service component may comprise an actual executable task: in this case, the executable task may be abstracted as a service—defined by a black box that receives an input and provides a corresponding output (according to some sort of internal processing). Examples of executable tasks are queries for extracting information from databases, inventory functions for collecting information about installed software products, metering functions for determining usage of software products, compliance functions for verifying compliance with specific policies, monitoring functions for controlling system performance, and the like. Conversely, the service component may comprise a scope definition: the scope definition may be combined with other executable tasks and/or scope definitions to create an actual executable task. Examples of scope definitions are filtering criteria, operative parameters, query fragments, and so on.
For this purpose, as shown in
Each service component is represented in the container 205 with a corresponding window gadget (widget) 210. The widget 210 may include a control that can be manipulated graphically to interact with the resource management application. For example, the widget 210 is depicted as an icon with a label providing a short description of the corresponding service component. A more detailed description of the service component may be displayed (such as in a pop-up window) upon the user moving a pointer indicating a current position on the desktop 200 (not shown in the figure) over the widget 210 with the mouse. The widget 210 is a draggable object, on which it is possible to act with a drag-and-drop operation: for example, this result is achieved by moving the pointer over the widget 210, clicking on it by pressing a left button of the mouse, dragging the widget 210 to a specific position with the mouse while holding the button pressed, and then dropping the widget 210 in that position by releasing the button.
The reference to the drag-and-drop operation is for illustration only. In various embodiments, selecting the new service components to be added to the tower may be carried out by simply double-clicking over their widgets, by exploiting menu commands, and the like.
For each resource management operation, the corresponding service components are aggregated—according to predefined aggregation rules—into an aggregated service. The aggregated service is defined in an aggregation structure of the GUI—for example, in the form of a tower 215. Each service component included in the aggregated service is instantiated in a corresponding context: the instantiated service component is represented in the tower 215 with a brick 220, typically including the same icon and label of the corresponding widget 210. The user can select each service component to be added to the aggregated service by moving the corresponding widget 210 to the tower 215 (with a drag-and-drop operation in the example at issue).
In one embodiment of the invention (as described in detail in the following), in response thereto there are determined the instantiated service components (if any), which are compatible for aggregation of the new service component according to the aggregation rules (hereinafter referred to as eligible service components). The bricks 220 of the eligible service components are then highlighted in the lower 215 by means of a corresponding visual cue.
In this way, the user is driven step-by-step along the definition of the desired aggregated service, for each new service component, the aggregated service in its entirety (as currently defined by all the instantiated service components in their contexts) is taken into account to determine the eligible service components. Once the new service component has been added to the aggregated service, it is in turn taken into account (in the corresponding context) to define the eligible service components for a next new service component. In other words, the aggregated service is an expandable structure, wherein the eligible service components are determined dynamically according to its current definition.
Embodiments of the invention may facilitate the definition of any desired resource management operations, even by people without specific technical skills. Embodiments of the invention may allow enforcing the logic consistency of the aggregate service automatically. Particularly, it may be possible to remove (or at least reduce) any error directly in the definition of the aggregated service (i.e. before its execution), for example, in an embodiment of the invention, the instantiated service components are arranged in one or more sequences. Each service component may be instantiated in the context of the preceding instantiated service component of the corresponding sequence (starting from an entire universe of discourse for the first instantiated service component). For example, if the instantiated service component comprises an executable task, the executable task may receive the output of the preceding executable task as input. If the instantiated service component comprises a scope definition, it may be applied to the preceding executable task or composed with the preceding scope definition. Each sequence of instantiated service components is represented in the tower 215 with a stack of the corresponding bricks 220 (ordered along a growing direction of the tower 215 indicated by a corresponding arrow in the figure). For the sake of clarity, if multiple slacks have one or more lower bricks 220 in common, they may be condensed into a single element in the tower 215. For example, the tower 215 includes three slacks, all of them starting with the brick 220 of an instantiated service component SC1. The first stack (from the left) then includes the brick 220 of an instantiated service component SC2. The other two stacks have the brick 220 of an instantiated service component SC3 in common. The second slack then includes the bricks 220 of two instantiated service components SC4 and SC5, while the third stack includes the brick 220 of an instantiated service component SC6. Therefore, the resulting aggregated service will be defined by the sequences of instantiated service components SC1, SC2, SC1, SC3. SC4, SC5 and SC1, SC3, SC6.
In this case, the eligible service components are the ones after which the new service component can be added (in the corresponding sequences). Each service component may be associated with a domain of its application and a co-domain of a corresponding result. Therefore, the new service component is considered compatible with each instantiated service component if the intersection of the co-domain of the instantiated service component with the domain of the new service component is not null. More formally, we denote with F and Fn the functions corresponding to the application of the instantiated service component and of the new service component, respectively, with D, Dn their domains, and with C, Cn their co-domains:
F (D) u C.
Fn (Dn) u Cn.
The new service component is then suitable to be added in the aggregated service following the instantiated service component, so as to generate an aggregated function:
Fn(F(D)) u Cn.
only if the following condition is satisfied:
C & Dn < >
If the service components comprise executable tasks, the output of the instantiated service component may be compatible with the input of the new service component. The eligible service components may be determined as soon as the widget 210 of the new service component is selected (by clicking on it) for dragging to the tower 215, as shown by an arrow in the figure.
In response thereto, as shown in
Moving to
As shown in
Moving to
Considering
With reference now to
Referring to
Conversely, as shown in
Starting from
Moving to
As shown in
The process continues to
Referring to
Moving to
As shown in
Therefore, upon the aggregated service so obtained being executed, the system will monitor the operating systems (service component myMonitor) installed on the computers of the desired department (service component my Department) of the company (service component myCompany). Also, the system will verify the compliance with the desired policy (service component myCompliance) on all the computers of the company (service component myCompany).
Later, the user realizes that compliance with the policy myPolicy is only needed for the managers of the company. Therefore, as shown in
Continuing to
The above-described shrinking of the bricks (for displaying the required drop arrows) is merely illustrative. For example, in alternative implementations it is possible to display the drop arrows laterally, directly on the bricks of the eligible service components, and the like. Other embodiments may include dropping the same widget of the new service component on top of the bricks of two of more eligible service components, adding the widget of the new service component in the same position of the brick of the selected eligible service component (to combine them in logic OR), and so on. Similar considerations apply to the addition of the widget of the new service component between the two adjacent bricks of each pair of eligible service components.
The information defining the current structure of the aggregated service (for its rendering in the tower) may be stored in a stale matrix 405. The state matrix 405 may include cells for the instantiated service components, with each one including a corresponding identifier. The cells may be arranged in columns for the sequences of instantiated service components (with rows with an increasing index along the sequences).
Starting from
Moving to
As shown in
Continuing to
Considering now
Moving to
As shown in
Continuing to
Considering now
In detail, an editor 505 may be used to create, update, delete, classify, and perform any other edit operation on the service components and the related graphical representations (for the widgets and the bricks). The definition of the service components is stored into a corresponding repository 510 (action “A1.Edit”).
A graphical interface 515 accesses this repository 510, so as to display the widgets of the available service components in the corresponding container, organized in the different categories (action “A2.Display”). The stale matrix (representing the instantiated services) is stored in a corresponding table 520. The graphical interface 515 also accesses the table 520 to render the bricks of the instantiated service components in the tower (action “A3.Render”).
The user may drag the widget of a new service component towards the tower (action “A4.Drag”). In response thereto, an analyzer 525 identifies the eligible service components—i.e. the instantiated service components (in the table 520) that are compatible with the new service component (action “A5.Identify”). If no eligible service component is identified, the analyzer 525 instructs the graphical interface 515 to prevent the dropping of the widget of the new service component on the lower (action “A6.Prevent”). Conversely, the analyzer 525 builds the drag matrix from the stale matrix (in the table 520), according to the eligible service components so identified. The system temporarily stores the drag matrix into a corresponding table 530 (action “A7.Build”). The graphical interface 515 accesses the table 530 to update the rendering of the tower, so as to highlight the bricks of the eligible service components by means of the corresponding drop arrows (action “A8.Highlight”).
Assuming that at least one eligible service component has been identified, the user can drop the widget of the new service component on top of one of the bricks of the eligible service components (action “A9.Drop”). In this case, the analyzer 525 updates the drag matrix (in the table 530) by assigning the relevant new cell to the new service component and removing the other new columns and cells (action “A10.Update”). The analyzer 525 replaces the state matrix (in the table 520) with this updated drag matrix (in the table 530), which drag matrix is then deleted (action “A11.Replace”). The graphical interface 515 renders the tower according to the new content of the state matrix in the table 520 (same action “A3.Render”).
In some embodiments, the user may also drag the brick of an old instantiated service component outside the tower (action “A12.Move”). In response thereto, the analyzer 525 may verify whether the corresponding following instantiated service component is compatible with the corresponding preceding instantiated service component. If not, the analyzer 525 may instruct the graphical interface 515 to prevent the removal of the brick of the old instantiated service component from the lower (same action “A6.Prevent”). The analyzer 525 updates the state matrix (in the table 520) by removing the cell of the old instantiated service component (action “A14.Remove”). The lower is now rendered according to the new content of the state matrix in the table 520 (same action “A3.Render”).
Upon the definition of the aggregated service in the tower being completed, the corresponding resource management operation can be executed. I he resource management operation may be executed after saving the state matrix for future reference. For this purpose, an engine 535 extracts the state matrix from the repository 520. The engine 535 aggregates the instantiated service components according to their position in the stale matrix and controls the submission of the resulting executable tasks in the corresponding order (action “A15.Exec”). The engine 535 returns a result of the execution of the aggregated service to the graphical interface 515 for its display (action “A16.Display”).
In order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many logical and/or physical modifications and alterations. Although this solution has been described with a certain degree of particularity with reference to embodiment(s) thereof, it should be understood that various omissions, substitutions and changes in the form and details as well as other embodiments are possible.
It should be readily apparent that the above-described service components are merely illustrative. For example, the executable tasks may include parameters to be evaluated at run-time (for example, by entering them manually or by retrieving them automatically from environmental variables), or the scope definitions may also include instructions for their combination with other service components. Service components may consist only of executable tasks. Likewise, the service components may be aggregated according to any equivalent aggregation rules. For example, it is possible to execute the service components in parallel, to combine, correlate, and/or transform the output of the service components to obtain the input of the following service components (such as in logic NOT, OR, and the like).
The service components may be represented graphically with equivalent visual elements, such as, for example, elements of the textual type only. Moreover, it is possible to organize the widgets in various ways, such as, for example, in a tree structure or even in a simple list. Likewise, the tower may be replaced with the graphical metaphor of any other aggregation structure, such as a three-dimensional wall. Different visual cues may be used to highlight the bricks of the eligible service components (for example, by displaying them in different colors and/or shades). In different implementations, the sequences of bricks may be arranged horizontally, radially, in three dimensions, and the like. It is also possible to use multiple representations for the eligible service components (for example, to differentiate the more likely ones to be selected according to a user's past usage).
Compatibility of the new service component with the instantiated service components may be verified with other techniques as will occur to those of skill in the art (for example, according to dedicated information associated with the service components themselves). Additionally or alternatively, global rules may be used to determine the eligible service components—for example, rules based on a maximum number of specific service components that can be instantiated at the same time.
The same solution may also be implemented with a single matrix (which is updated directly in response to any drag operation and drop operation): in any case, the aggregated service may be represented with distinct arrays for its sequences, with pointer-based lists, or with any other vectors of a suitable artifact. Alternative and/or additional operations on the tower may also be implemented. For example, in various embodiments, it may be possible to remove whole columns of bricks (or pans thereof), to copy/cut and past bricks (or blocks thereof) in different positions, and so on. The old instantiated service component to be removed from the aggregated service may be selected in another way (for example, by double-clicking on its brick and then typing a delete key).
In some embodiments, the widgets of the service components that cannot be selected for addition to the tower at any moment may be temporarily disabled: it is also possible to always allow adding even new service component in the context of the whole universe of discourse.
Embodiments of the invention may be applied even if the aggregated service is executed in real-time (for example, with a preview of its result that is displayed in a dedicated frame). It is also possible to support the selecting of the bricks of specific instantiated service components to obtain partial results of the aggregated service.
Embodiments of the invention may be implemented as a stand-alone application, as a plug-in for the resource management application (or any equivalent program), or directly embedded within the resource management application. The proposed method may also be carried out on a system with a different architecture or including equivalent units. Software used to implement embodiments of the invention may be structured in various ways and may include alternative modules or functions. Embodiments of the invention may include a computer program product having computer program instructions implemented in any form suitable to be used by or in connection with any data processing system. Moreover, the program instructions may be provided on any computer-readable medium: the medium can be any element suitable to contain, store, communicate, propagate, or transfer the computer program product. Examples of such medium are fixed disks (where the program can be pre-loaded), removable disks, tapes, cards, wires, fibers, wireless connections, networks, and the like: for example, the medium may be of the electronic, magnetic, optical, electromagnetic, infrared, or semiconductor type.
It should be understood that the inventive concepts disclosed herein are capable of many modifications. To the extent such modifications fall within the scope of the appended claims and their equivalents, they are intended to be covered by this patent.
| Number | Date | Country | Kind |
|---|---|---|---|
| 08158534.1 | Jun 2008 | EP | regional |
