Patent Grant
7930696
The present invention is related to inventions disclosed in the following commonly-assigned U.S. patent application Ser. Nos. 10/795,008, entitled “Using Content Aggregation to Build Administration Consoles”, which was filed concurrently herewith on Mar. 5, 2004; and 10/754,375, entitled “Dynamic Composition of Help Information for an Aggregation of Applications”, which was filed on Jan. 9, 2004. The disclosures in these commonly-assigned patents are hereby incorporated herein by reference as if set forth fully.
1. Field of the Invention
The present invention relates to computing systems, and deals more particularly with techniques for federating, or joining, content from multiple administrative consoles (which may operate as legacy and/or remote consoles) into a central console, where that central console may be rendered (for example) for use by a systems administrator in performing operations such as resource configuration and systems management.
2. Description of the Related Art
Computer software and hardware systems are often configured, monitored, and managed by one or more administrators using graphical user interfaces called “consoles”. Often, each system component within an information technology (“IT”) environment has its own independently-developed console for carrying out these operations. Even a relatively small business can require a number of different computer-based products (including hardware components and/or software components) for its business solution, and a large business or other enterprise may have a very large number of such products in its IT environment. As a result, an administrator working in the IT environment may be faced with a large number of different consoles.
Many prior art console applications are written for administering a single system.
In an IT environment having even a relatively small number of systems to be managed, accessing information pertaining to one managed system at a time quickly becomes unwieldy, as the administrator must change back and forth between consoles. The related invention titled “Using Content Aggregation to Build Administration Consoles” (U.S. patent application Ser. No. 10/795,008), hereinafter referred to as “the related invention”, discloses techniques for aggregating content views for multiple managed resources (where the resources may be hardware and/or software resources), where preferred embodiments leverage a framework such as a portal/portlets model as an infrastructure. Thus, a console as disclosed in the related invention enables consolidating the administrative interfaces from any arbitrary collection of hardware and/or software resources into a single, integrated network console. This integrated network console is preferably deployed as a network-accessible console application (referred to equivalently herein as a Web-based console application), such that an administrator can invoke the console using a Uniform Resource Locator (“URL”) from a browser or similar client application. The integrated console of the related invention thereby provides a central point of access for administering a number of resources (and is also referred to herein as a “central console”).
The Web-based console application disclosed in the related invention solves a number of problems and provides a number of advantages. (Reference may be made to the disclosure of the related invention for a detailed discussion thereof) The Web-based console infrastructure offers a programming model for building new console snap-ins or plug-ins; when a portal infrastructure is used, for example, the plug-in functionality is preferably developed using a portlet/J2EE® programming model. (“J2EE” is a registered trademark of Sun Microsystems, Inc. in the United States, other countries, or both.) However, the existing administrative functions for many resources do not adhere to that model. Rather than requiring the administrator to switch between using the central console to manage some resources and a different console to manage other resources with these existing administrative functions, it would be preferable to allow the administrator to access the existing administrative functions directly from the central console. Furthermore, the goal of integrating administrative functions for a large number of resources in a single console will be achieved much more quickly if already-existing programming code that manages resources does not have to be rewritten to use the central console's programming model.
Accordingly, what is needed are improvements to administration consoles.
An object of the present invention is to provide improvements for administration consoles.
Another object of the present invention is to provide techniques for federating content from existing administrative functions into a central console.
A further object of the present invention is to provide techniques for federating content from legacy and/or remote consoles into a Web-based console infrastructure.
Still another object of the present invention is to provide techniques that enable an administrator to use a central console to access remote console functionality as if using the remote console directly.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention may be deployed as methods, systems, and/or computer program products embodied on one or more computer-readable media. In one aspect, the present invention provides techniques for aggregating content created by one or more tasks that may run in heterogeneous execution contexts and that produce information pertaining to one or more resources and rendering the aggregated content in a view.
In another aspect, the present invention provides techniques for rendering task-related content in a view provided by a central point of access, which preferably comprises: determining one or more invocable software entities of one or more tasks that are available for execution, wherein at least one of the invocable software entities of one or more of the tasks is executable on one or more remotely-located resources; presenting, to a user of the central point of access, a view from which execution of the available invocable software entities can be invoked; selecting, by the user, one of the tasks from the presented view; if one or more of the invocable software entities of the selected task is executable on one or more remotely-located resources, using address information associated with each of the remotely-located resources to send a message thereto, wherein the message requests execution of the invocable software entities of the selected task; aggregating results of the execution in an aggregated view; and rendering the aggregated view at the central point of access, without regard to whether the invoked software entities executed in an identical execution context at each of the remotely-located resources.
In yet another aspect, the present invention provides techniques for rendering content in a view provided by a central point of access, comprising: determining one or more functions that are available for execution, wherein at least one of the functions is executable on a remotely-located resource; presenting, to a user of the central point of access, a view from which execution of the available functions can be invoked; selecting, by the user, one of the functions from the presented view; if the selected function is executable on a remotely-located resource, using address information associated with that remotely-located resource to send a message thereto, wherein the message requests execution of the selected function; aggregating results of the function execution in an aggregated view; and rendering the aggregated view at the central point of access, without regard to whether the invoked function executed in an execution context identical to that of the central point of access.
These aspects are illustrative, but not limiting, of the scope of the present invention.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.
The present invention provides techniques for including content from legacy and/or remote consoles in an administration console (such as the central console disclosed in the related invention) that aggregates administrative functions from many sources. A single point of administration is thereby provided, even though resources may be distributed across a number of heterogeneous systems and their administrative functions may be written using a variety of programming models. According to preferred embodiments, this single point of administration provides an administrator with the ability to administer remotely-located resources as if he or she were interacting directly with the console of the remote resource (as will be discussed in more detail herein). Hereinafter, consoles federated by preferred embodiments are referred to as remote consoles, although this should be interpreted as also including legacy consoles that might be local to the system where the central console is deployed as well as legacy consoles that are remotely located.
Consoles created according to the present invention may be used advantageously in many ways, a number of which will be described herein. For example, administration consoles (which are referred to equivalently herein as “administrative consoles”) may be used for system set-up operations, resource configuration, run-time monitoring, and systems management. While a variety of operations may be performed using the consoles of the present invention, those operations are referred to herein using terms such as “management operations”, “systems management operations”, “administrative functions”, “administer”, and “manage”, for ease of reference (although these terms are not meant to limit the scope of the present invention).
Preferred embodiments are described herein with reference to using Web portals as the underlying content aggregation framework, and using software entities known as portlets for rendering content in the console. It should be noted, however, that references herein to using portals or portlets are by way of illustration and not of limitation. Alternatively, a different framework and/or different types of content-creating software entities may be used, without deviating from the scope of the present invention. As one example, a “struts and tiles” approach may be used to provide the framework and the content. (Struts is a framework for building Java® Web applications, and was created as part of the Apache Jakarta Project that is sponsored by the Apache Software Foundation. Refer to the Apache Web site or publications for more information. “Java” is a registered trademark of Sun Microsystems, Inc. in the United States, other countries, or both.)
It should also be noted that the functions that create the content to be rendered in the console do not need to be written as portlets, even when a portal model is used for the central console infrastructure. Instead, preferred embodiments of the present invention wrapper the output of those functions, such that the output can be delivered to a portlet that forms part of the central console. Accordingly, the output can be aggregated into a view on the central console without requiring the administrative functions that execute on the remote console(s) to be rewritten.
Administrator 300 is shown, in this example, as having access to console application 321, and therefore this administrator can manage Managed System 1341. Similarly, administrator 302 has access, in this example, to console application 322, and can therefore administer Managed System 2342. Administrator 301, on the other hand, is shown as having access to a federating console application 320 created according to the present invention, where this federating console application 320 is shown as federating content from console applications 321 and 322. Using federating console application 320, this administrator 301 can therefore manage either or both of the managed systems 341, 342. Console applications 321, 322 may be prior art console applications that provide access to administrative functions written according to various programming models. The federating console application 320 nevertheless federates content from those consoles, enabling administrator 301 to interact as if working directly with the functionality available from the remote console(s).
According to preferred embodiments, the plug-in 610 has knowledge of the hostname and port combinations associated with each managed resource, along with the URL that invokes a remotely-executing task on that resource, and thereby knows which task to launch when the administrator makes a selection from a rendered task list (or other representation of available tasks), as will be described in more detail below. If a selected remotely-executing function requires the administrator to be authenticated, the authentication mapping for the remote URL may be managed by a central repository on the federating console; or, the administrator's credentials can be propagated to the federated console. When the plug-in 610 sends a request to a remote URL, that request preferably specifies the central console work area (or a slot within the work area) as the target destination for the content to be returned. Preferably, the iFrame source attribute is dynamically built to target a particular remote console instance and task. When the available task list (such as a navigation pane) is populated, the task-specific portion of the URL used to invoke each task on a remote resource is preferably stored as a configuration parameter. Likewise, when a list of managed resources is populated (e.g., for displaying in a drop-down selection list), information required to contact the remote console for that resource (such as the hostname and port number for the remote console application) is preferably stored in a repository that is available to the central console. The manner in which information from the configuration parameters and the repository can be used to invoke a specific task on a target remote console will now be described.
In an example scenario, suppose the administrator has just selected a task from the navigation pane. In preferred embodiments, a wrapper portlet on the central console generates markup language syntax, including the iFrame, to present a view of the remote task on the central console. The configuration parameter information associated with the selected task, plus the hostname and port number of the selected managed resource, are used to dynamically build the source attribute value for the iFrame. The remote console can therefore determine where to deliver its output.
In preferred embodiments, the federating console application and the remote console applications each maintain their own information about currently-active sessions. When using iFrames for aggregation, as illustrated in
Note that it may be desirable to programmatically filter some HTML tags out of returned content. This filter may be added to the central console, or filters may be deployed at the remote consoles. For example, if returned content includes a <HEAD> tag, it may be desirable to remove this tag before passing the content to a renderer. (When using a portal/portlets model, for example, the portal code may be adapted for automatically supplying the <HEAD> tag. Thus, removing any such tags from the returned content avoids an error situation.)
As illustrated by the scenarios shown in
Using the present invention, on the other hand, a task's code is portable beyond its own run-time environment. The central console (which runs in its own particular run-time environment) can therefore be used to transparently manage more than one version of a resource, different resources, and/or homogeneous resources. In preferred embodiments, output from the management tasks is delivered using a device-independent markup language such as HTML, as discussed with reference to
A console's run-time environment is one example of internal dependencies of the architectures of consoles being federated that may make it impossible, when using prior art techniques, to deploy the separate console applications within a single integrated console application. This type of consolidated deployment may also be impossible in the prior art due to a large footprint that would result from collecting the various remote console applications together. Using embodiments of the present invention, on the other hand, these problems of the prior art are avoided. WebSphere® Systems Console (“WSC”), a product of International Business Machines Corporation (hereinafter “IBM”), is used in many existing IT environments to administer resources. WSC uses a struts/tiles, servlet-based architecture. In one advantageous embodiment, techniques disclosed herein may be used to federate content from one or more WebSphere Systems Consoles into a portal-based console that can run either locally or remotely from the WSC(s). (“WebSphere” is a registered trademark of IBM in the United States, other countries, or both.)
Preferred embodiments of techniques disclosed herein allow an administrator to access, from the central console, any task that is available to that administrator, among all of the systems being managed. In one approach, code such as a Web service, servlet, or JavaServer Page (“JSP®”) may be deployed at the remote console, where this code can be invoked from the central console at run-time to determine the set of tasks available from that remote console. (“JSP” is a registered trademark of Sun Microsystems, Inc. in the United States, other countries, or both.) In another approach, the available task information may be determined in other ways, such as consulting a configuration file or other repository. Optionally, the set of available tasks may be filtered to reflect only the subset of tasks for which the present administrator is an authorized user.
Embodiments of the present invention may provide role-specific views. Roles may be associated with individual users and/or with user groups, as is known in the art. Thus, the administrator's role may be used when determining the filtered list of tasks for which this administrator is authorized. (For example, certain tasks might be available to administrators having a “network administrator” role, while other tasks are available to administrators having a “security administrator” role, and so forth.)
Preferably, navigation pane 720 displays tasks that can be selected by the administrator, and work area 730 is used to select the resource(s) on which the selected task is to be performed. When the set of available tasks is determined dynamically, navigation elements making those tasks available for selection are preferably constructed dynamically as well. For example, suppose that the IT environment 800 shown in
Different and/or additional attributes may be used in this type of markup language document without deviating from the scope of the present invention. For example, in addition to a specification of available tasks, each remote console application might also return information identifying the users, user groups, and/or roles that are authorized to perform that task on the respective remote console. And, rather than specifying tasks as standalone entities, as has been illustrated in
After receiving the responses from the remote consoles, the central console application then preferably uses this information to construct navigation elements, associating each navigation element with a URL of a servlet, form, or other Web-accessible application that provides the function for the tasks identified in the response. For example, entries for each available task may be created for rendering in the navigation pane 720 of
A mapping or association is preferably maintained for the central console to easily determine which URL should be invoked when the administrator selects to execute a particular one of the available tasks. And, as discussed above with reference to
Turning now to
Responsive to this selection, view 1020 is rendered in the work area, requesting the administrator to select a target remote resource. A drop-down list 1021 may be provided in this view 1020. (View 1020 may be referred to also as a “resource selection portlet”, when using a portlet model.) Information obtained from the remote consoles using markup-language documents of the type illustrated in
Upon selecting a server at 1021 (and, optionally, activating a graphical button such as “Go” 1022), a portlet is then executed (in this example) that invokes a URL into the selected remote console 1021, where a view of the selected task 1012 gets rendered by the remote console. In this example, the output of the remote function (i.e., the remote console view) is rendered in view 1030. (This view 1030 may also be referred to as a “task portlet”, when using a portlet model.) A title bar 1031 is provided, in this example, that identifies the task selected from the navigation pane (and might also include the host name and the port number of the target resource). In addition, view 1030 provides, in this example, an indication 1032 that specifies the selected task (“Manage Application Servers”); task-specific introductory information 1034 and prompts for entering task-specific preference information 1036; and, for this manage application servers task, a table 1040 identifying application servers that are available for managing via the remote console application selected at 1021. Here, a single application server resource is presented in row 1042, and this resource is identified by a configured name 1044 (“server1”, for this example) and node name 1046 (“dexter”, in this example). Any other information relevant to the task, as rendered by the remote console application, is also presented in view 1030. In other words, the administrator may use view 1030 to manage application servers using a view provide by the remote system's console.
There may be additional subtasks displayed to the administrator within a rendered view, such as the Manage Application Servers view 1030. These additional subtasks may or may not be registered with the federating console (e.g., from information delivered in a document of the type illustrated in
In the example of
In the general case, any (sub)task selected by the administrator from the navigation pane or other area of the console may be launched and displayed in the task portlet 1030, and the task's output is preferably represented as it would appear on the native (i.e., remote) console, thereby giving the administrator the impression that he or she is working directly on the remote console. (Title bar 1031 may be used to provide helpful information to remind the administrator of the actual identification or location of the remote console, for example by including the host name and port number of the remote console application or remote resource.)
In the sample resource selection portlet 1220, drop-down list 1221 allows the administrator to select a specific server. Preferably, entries in this list 1221 are limited to the resources where this task is available for use by this administrator. After the administrator presses the “Go” button 1222, the selected server information is passed to the task portlet 1230, in order to surface the remote console task. The title bar of task portlet 1230 indicates, in preferred embodiments, the server that was selected and the task to be performed. In this example, the body of task portlet 1230 provides information about the number of run-time messages that have been generated on the selected server (where this information is returned to the central console, in preferred embodiments, responsive to sending an HTTP request message to a URL that provides the status function on the selected server).
Optionally, embodiments of the present invention may also enable administrators to customize their consoles using preferences. Or, preferences may be established for groups of users. As one example, the preferences to be defined for a particular administrator may specify a set of remote console applications to which connections should be established upon that administrator's logging in to the central console.
Turning now to
Suppose the administrator selects a task associated with the URL of the remote function in template/layout JSP 1454. A passthru portlet 1442 (i.e., a wrapper portlet) executing in a central console application 1440 preferably invokes that URL, responsive to the task selection, by issuing an HTTP request message (not shown). Responsive to receiving this HTTP request message at the remote console, JSP 1454 executes and generates output. This output, which typically comprises some type of content pertaining to a managed resource at the back-end, is shown as being passed 1421d (preferably using an HTTP response message flow) from the run-time 1451 to the passthru portlet 1442.
It may happen that multiple remote console applications supply content to be rendered as a single aggregated result. Passthru portlet 1442, in preferred embodiments, wraps a remote function that is a sub-element of a task, rather than the entire task. These portlets are preferably analogous to portlets that wrap task functions, except that they do not correspond to entries in the navigation area and their output may be aggregated into one view with one or more other passthru portlets for the same or a different remote console. (See, for example,
At the same time, another portlet 1443 executing locally in the central console application 1440 may send an HTTP message flow 1420 containing content for rendering in slot 1411 of HTML page 1400. For example, this message flow may deliver a navigation pane created by central console application 1440.
Logic for use during initialization of a manager component of the federating console application is shown in
The manner in which information is gathered and returned from the remote consoles has also been discussed above, and includes returning a list of composable elements and URLs as an XML document (by way of example), such as document 900 of
Block 1520 obtains the next composable element from the returned list(s). Block 1525 checks to see if processing of all composable elements is already finished. If so, processing of
Assuming that the administrator is properly authenticated, Block 1605 then checks to see if a composable element cache needs to be updated with information pertaining to this administrator's authorized tasks. Preferably, an administrator-specific version of the composable element cache created in Block 1515 of
In Block 1615, a determination is made as to whether this administrator is authorized to perform, within the federated console, each of the tasks retrieved in Block 1610. This preferably further comprises determining whether there is at least one of the currently-connected remote consoles where the administrator is authorized to use the task. In one approach, if the remote console application returns a specification of authorized users/groups/roles when identifying its available tasks, then this information may be used with the administrator's credentials to determine whether the administrator is an authorized user of each task. (Refer to the related invention for an example of a markup-language document that includes authorized-user information.) In another approach, the administrator's credentials may be used to access a directory database or other repository (or a plurality thereof) where mappings between credentials and authorized users of tasks are stored. The administrator may need to be authenticated to the remote console. An approach that may be used, if it is not possible to retrieve information as to whether a user is already authenticated to the remote console, is to expose to the set of all tasks to the administrator, and the first time the administrator selects to execute a particular task, the remote console may interject a log-in view or other authentication logic. Depending on whether the administrator successfully responds, the remote console may then render a view of the task (if authentication succeeds) or an error page may be rendered, warning the administrator that he or she is not recognized by the remote console. After successful authentication, the remote console preferably verifies that the authenticated administrator is authorized to perform the selected task.
Block 1620 then optionally removes, from the set of tasks obtained in Block 1610, each task for which Block 1615 determined that the administrator is not an authorized user at any of the remote consoles. Block 1625 stores the resulting task information, after which control transfers to Block 1635.
Control reaches Block 1630 when the test in Block 1605 has a negative result (i.e., information is already available as to which tasks are available to this administrator). Block 1630 retrieves, from the central console application's locally-accessible cache or other repository, information pertaining to the tasks for which this administrator is authorized. (This information is also available as a result of executing Blocks 1610-1625, when the test in Block 1605 has a positive result.) The list of tasks may include tasks that are defined locally, in addition to the ones federated from remote consoles.
The tasks for which this administrator is authorized are then displayed (Block 1635), preferably in a navigation pane of the central console. In an optimization of preferred embodiments, a filter may be deployed that searches for specific task identifiers or keywords within task names, and applies special handling when a matching task is found. As one example, each remote console application preferably provides some type of “Help” task, and it may be preferable to locate the hypertext link or other selectable representation of each Help task in a particular area of the central console. This optional filtering may be used to provide this type of special handling. (Furthermore, it may be desirable to render the actual help content in a separate browser window, rather than in the central console's work area; filtering may be used to provide this special handling.) As another example, some tasks that are thought to be used relatively infrequently may be specified in a filter, and the representation of those tasks may be programmatically relocated to an area of the central console that is outside the administrator's normal focus. As yet another example, tasks containing the word “Status” in their description might be grouped together under a “Status” tab, as illustrated in
Following completion of Block 1635, this iteration of the logic of
By rendering only those tasks that are both (1) currently available from some connected remote console and (2) authorized for use by the current administrator, embodiments of the present invention allow administrators to receive targeted and useful console views.
The related invention titled “Dynamic Composition of Help Information for an Aggregation of Applications” describes techniques for aligning the presentation of help information (or other information) with the presentation of content for which help may be requested, and those techniques may optionally be used with an implementation of the present invention for rendering help information in a federated console.
In Block 1715, a test is made to see if a server has been selected for this federated portlet. It may happen that a server has already been selected when the federated portlet starts to be rendered, for example from a context that is passed to the page using conventional means or selected in another portlet on the page. An identification of the current server may be presented, as a reminder to the administrator, for example, and this identification may be shown in successive pages. Furthermore, it may be possible in some scenarios to select more than one server, for example where more than one function is available from a page. Various means of selecting multiple servers may be used, such as providing a drop-down list from which multiple entries can be selected; displaying more than one server selection portlet; and so forth.
If a server is already selected, processing continues at Block 1730; otherwise, Block 1720 presents a list of the server(s) where the administrator is authorized to perform this function. (Preferably, this list is obtained from the central console's previously-stored administrator-specific task information; see, for example, the discussion of Blocks 1610-1625.) At Block 1725, the administrator selects a server from this list.
Block 1730 then checks to see whether there is an active connection for this administrator to the selected server. It may happen, for example, that the administrator's session with a remote console has timed out since the list of available tasks was obtained, and the administrator may have selected a task that is only available from this timed-out console. Conversely, if the administrator has already carried out some task with a server, and the connection to that server remains active, then it is not necessary to re-authenticate the administrator for that server. Accordingly, if the test in Block 1730 has a positive result, control transfers to Block 1755 of
According to preferred embodiments, when the administrator selects a remote console, that remote console's native log-in views are presented if the remote console is secured and the administrator has not already been authenticated within the remote console (as is the case when not using automatic credential mapping); otherwise, if the remote console is not secured, or the administrator is already authenticated for the remote console application, then this log-in view is preferably bypassed (and a task view is preferably presented in that case). For ease of illustration,
Preferred embodiments leave the authentication functions on the remote consoles, and use paired message exchanges to (i) request authentication of administrator-provided credentials and (ii) return a result of the authentication. Block 1740 therefore obtains the administrator's credentials at the central console, and Block 1745 sends those credentials to the remote console application for verification. A success or failure indication is transmitted back to the central console, according to preferred embodiments, and Block 1750 of
Control reaches Block 1755 after the administrator's credentials sent to the remote console in Block 1745 have been successfully authenticated, and alternatively when the server is already connected and this authentication is therefore bypassed (i.e., a “Yes” result at Block 1730). Block 1755 checks to see if the administrator is authorized to perform the selected task or the function of this one of its federated portlets. A round-trip to the remote server may be required to make this determination. Or, if the administrator is being authenticated at Block 1745, a result of this determination may be communicated with the authentication result. And if an authorization cache is used, then cached information about whether this administrator is authorized may be consulted. (Policy information may be used to determine how long an authorization persists, as in the prior art.) If the test in Block 1755 has a positive result, then in Block 1765, execution of the federated portlet is requested by sending a message to the remote console; otherwise, control transfers to Block 1760.
In some embodiments, the federating console application may be able to provide automatic authentication with remote consoles, by acting in the role of the administrator and programmatically filling out the remote log-in form to submit the administrator's credentials to the remote console application. (These embodiments preferably use a credential mapping registry in which mappings are maintained between each administrator's credentials on the federating console and that administrator's credentials on the remote consoles.)
Remote console applications typically present some type of “Welcome” view to the administrator, once the log-in process completes successfully. When using a central console that federates remote consoles, however, the administrator has preferably already been “welcomed” to the central console (e.g., at Block 1600 of
Responsive to Block 1765, the remote console application (or a container in which it executes) preferably redirects or forwards the administrator's access request to the function that the administrator is trying to access. Control then returns to Block 1705 to begin processing the next federated portlet for this page (if any). Upon reaching Block 1770 of
When the authentication performed at the remote console fails (a negative result at Block 1750) or the administrator is not authorized to perform this function, control reaches Block 1760, where an appropriate message is preferably rendered. If control reaches Block 1760 because of an authentication failure, or because the administrator is not authorized to perform a task, an error message is preferably rendered. An error message may optionally be transmitted from the remote console for this purpose, enabling the error processing to appear transparent to the administrator. Or, if control reaches Block 1760 because the administrator is not authorized to perform functionality of a federated portlet, then empty content is preferably returned for that portlet (and processing may return to Block 1705 of
In an optional enhancement to preferred embodiments, authentication information may be cached or otherwise persisted, thereby reducing the number of times a particular administrator has to provide his or her credentials. For example, an authentication token might be created when the administrator logs in to a first of the remote consoles, and this token might then be used in determining whether, when this same administrator selects a task to be executed on a different remote console, he or she must go through another iteration of providing credentials and having those credentials authenticated. Techniques for creating and evaluating authentication tokens (or using another credential persistence technique) are not depicted in
Block 1805 indicates that the history list is consulted. In preferred embodiments, the administrator is allowed to manually log out of individual remote consoles, as desired (and this log-out process preferably uses the remote console's native log-out processing). The history list is preferably updated to remove the URL for each remote console affected by the manual log-out, such that the list obtained at Block 1805 includes only those remote consoles to which the administrator is currently logged in. (The administrator's connection to selected remote consoles may also time out, due to inactivity or other triggers. If the URLs for these remote consoles are not removed from the history list, then Block 1805 may obtain URLs of remote consoles to which a connection is no longer active. Conditional logic may be added to
At Block 1810, a command is issued to each of the remote consoles identified by Block 1805, requesting that the administrator be logged out of that remote console. A logout servlet or JSP may be deployed at each remote console for receiving this request. Optionally, the federated view pertaining to each remote console may be removed from the central console as the log-out from that console is initiated (Block 1815). Finally, a log-out request from the central console is processed (Block 1820). This iteration of the logic of
Note that log-out actions of the remote consoles are typically secured, and a valid HTTP session is required for performing a log-out action. Therefore, protection is provided against malicious intruders being able to log administrators out of remote consoles.
As has been demonstrated, the present invention defines advantageous techniques for federating administrative consoles. As has been described, the presentation layer is preferably deployed on a central console, with the controller/view renderer deployed on remote consoles. Accordingly, the central console has a smaller footprint, and problems that might result from architectural differences among the remote consoles are avoided. In particular, it is not necessary when using techniques disclosed herein that the central console use the same run-time environment as the remote consoles. The wrappering approach disclosed herein also enables administering, from a central point of access, resources that were designed to be administered using only a local console, yet the administrative functions for those resources do not need to be rewritten to adhere to the central console programming model. Scenarios exist where administrative functions cannot be executed remotely using prior art techniques. One example is management of portal pages, such as configuring pages, adding users to groups, and so forth. Using an embodiment of the present invention, such administrative functions can be executed at one location (e.g., at a remote console) while their view is rendered at another location (e.g., at the central console).
A number of variations may be used with embodiments of the present invention. For example, the “Status” task described above with reference to
Preferred embodiments have been described with reference to determining a set of available tasks and then (when appropriate) selecting one or more resources against which that task is to be performed. Alternatively, an embodiment of the present invention may enable the administrator to first select one or more resources, and then determine which tasks can be performed with regard to those resources. (Refer, for example, to the discussion of
Preferred embodiments have also been described with reference to sending an HTTP request message to a remote console to determine that console's available tasks. Alternatives to this approach include using Web services, and a Web Services Description Language (“WSDL”) specification may be queried to determine the available tasks. As another alternative, the set of available tasks may be stored in a configuration file or other repository, and an implementation of the present invention may use this stored information when initializing the central console (and may then dynamically check for updates at periodic intervals or in response to various events).
As will be appreciated by one of skill in the art, embodiments of techniques of the present invention may be provided as methods, systems, or computer program products. Preferably, an implementation of techniques of the present invention is provided in software, although implementations provided in hardware or firmware, or combinations of software with hardware and/or firmware, are also within the scope of the present invention. Furthermore, an implementation of techniques of the present invention may take the form of a computer program product which is embodied on one or more computer-usable storage media (for example, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims shall be construed to include the preferred embodiments and all such variations and modifications as fall within the spirit and scope of the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5361361 | Hickman et al. | Nov 1994 | A |
| 5893916 | Dooley | Apr 1999 | A |
| 6011537 | Slotznick | Jan 2000 | A |
| 6043816 | Williams et al. | Mar 2000 | A |
| 6049799 | Mangat et al. | Apr 2000 | A |
| 6219700 | Chang et al. | Apr 2001 | B1 |
| 6240410 | Wical | May 2001 | B1 |
| 6256668 | Slivka et al. | Jul 2001 | B1 |
| 6281900 | Ishikawa | Aug 2001 | B1 |
| 6353446 | Vaughan et al. | Mar 2002 | B1 |
| 6510466 | Cox et al. | Jan 2003 | B1 |
| 6563514 | Samar | May 2003 | B1 |
| 6573906 | Harding | Jun 2003 | B1 |
| 6584496 | Ludtke | Jun 2003 | B1 |
| 6621505 | Beauchamp et al. | Sep 2003 | B1 |
| 6799198 | Huboi et al. | Sep 2004 | B1 |
| 6801222 | Dunham et al. | Oct 2004 | B1 |
| 6820094 | Ferguson et al. | Nov 2004 | B1 |
| 6918090 | Hesmer et al. | Jul 2005 | B2 |
| 6970869 | Slaughter et al. | Nov 2005 | B1 |
| 6993720 | Hanoch et al. | Jan 2006 | B1 |
| 7024658 | Cohen et al. | Apr 2006 | B1 |
| 7028264 | Santoro et al. | Apr 2006 | B2 |
| 7062511 | Poulsen | Jun 2006 | B1 |
| 7072807 | Brown et al. | Jul 2006 | B2 |
| 7203909 | Horvitz et al. | Apr 2007 | B1 |
| 7444633 | Bohn et al. | Oct 2008 | B2 |
| 7493563 | Bohn et al. | Feb 2009 | B2 |
| 7502833 | Schaeck | Mar 2009 | B2 |
| 7783638 | Choudhary et al. | Aug 2010 | B2 |
| 20010034771 | Hutsch et al. | Oct 2001 | A1 |
| 20020032763 | Cox et al. | Mar 2002 | A1 |
| 20020053020 | Teijido et al. | May 2002 | A1 |
| 20020054152 | Palaniappan et al. | May 2002 | A1 |
| 20020063735 | Tamir et al. | May 2002 | A1 |
| 20020091993 | Walley et al. | Jul 2002 | A1 |
| 20020116454 | Dyla et al. | Aug 2002 | A1 |
| 20020120607 | Price et al. | Aug 2002 | A1 |
| 20020129136 | Matharu | Sep 2002 | A1 |
| 20020143949 | Rajarajan et al. | Oct 2002 | A1 |
| 20020146018 | Kailamaki et al. | Oct 2002 | A1 |
| 20020147709 | Rajarajan et al. | Oct 2002 | A1 |
| 20020149601 | Rajarajan et al. | Oct 2002 | A1 |
| 20020158899 | Raymond | Oct 2002 | A1 |
| 20020161876 | Raymond | Oct 2002 | A1 |
| 20020165745 | Greene et al. | Nov 2002 | A1 |
| 20020178254 | Brittenham et al. | Nov 2002 | A1 |
| 20020178290 | Coulthard et al. | Nov 2002 | A1 |
| 20020188612 | Yu et al. | Dec 2002 | A1 |
| 20020188613 | Chakraborty et al. | Dec 2002 | A1 |
| 20030001875 | Black et al. | Jan 2003 | A1 |
| 20030018650 | Priestley | Jan 2003 | A1 |
| 20030055868 | Fletcher et al. | Mar 2003 | A1 |
| 20030055878 | Fletcher et al. | Mar 2003 | A1 |
| 20030056026 | Anuff et al. | Mar 2003 | A1 |
| 20030059009 | Meyerson et al. | Mar 2003 | A1 |
| 20030065827 | Skufoa et al. | Apr 2003 | A1 |
| 20030117437 | Cook et al. | Jun 2003 | A1 |
| 20030126558 | Griffin et al. | Jul 2003 | A1 |
| 20030137538 | Hesmer et al. | Jul 2003 | A1 |
| 20040002944 | Hauser et al. | Jan 2004 | A1 |
| 20040059705 | Wittke et al. | Mar 2004 | A1 |
| 20040104931 | Schmitt | Jun 2004 | A1 |
| 20040113948 | Shahrbabaki et al. | Jun 2004 | A1 |
| 20040133660 | Junghuber et al. | Jul 2004 | A1 |
| 20040148586 | Gilboa | Jul 2004 | A1 |
| 20040199392 | Khatri et al. | Oct 2004 | A1 |
| 20040230901 | Godwin et al. | Nov 2004 | A1 |
| 20040254884 | Haber et al. | Dec 2004 | A1 |
| 20050065913 | Lillie et al. | Mar 2005 | A1 |
| 20050065953 | Bower et al. | Mar 2005 | A1 |
| 20050102429 | Pinhas et al. | May 2005 | A1 |
| 20050154719 | Choudhary et al. | Jul 2005 | A1 |
| 20050154986 | Bartek et al. | Jul 2005 | A1 |
| 20050193001 | Shoham | Sep 2005 | A1 |
| 20050198042 | Davis | Sep 2005 | A1 |
| 20050198196 | Bohn et al. | Sep 2005 | A1 |
| 20050198201 | Bohn et al. | Sep 2005 | A1 |
| 20050198648 | Wray et al. | Sep 2005 | A1 |
| 20050246632 | Guido et al. | Nov 2005 | A1 |
| 20060031222 | Hannsmann | Feb 2006 | A1 |
| 20060031849 | Barta et al. | Feb 2006 | A1 |
| 20060271844 | Suldikar et al. | Nov 2006 | A1 |
| 20090044152 | Bohn et al. | Feb 2009 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20080270929 A1 | Oct 2008 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10795007 | Mar 2004 | US |
| Child | 12168784 | US |
