Patent Application
20140129532
Designers of graphical user interface (GUI)-based management tools seek to provide the right combination of management use cases so that the tools support the majority of their users' needs. This leads to a dilemma as to how complex to design a tool. If too few use cases are supported, then the tooling will not meet the needs of the majority of their users, which impacts the uptake of the product. If too many use cases are supported, then the tooling tends to be overly complex, affecting the users' ability to learn the product and making it difficult for an organization to ensure consistency across a number of users.
To mitigate this problem, management tools such as the MMC (Microsoft® Management Console) have an extensibility model that enables new “plug-ins” to be defined. However, designers these plug-ins basically have the same challenge, that is, if they address too many use cases they become overly complex, if they address too few they do not meet a broad audiences needs. From an end user's perspective, there is only a limited ability to customize the experience to meet the user's needs—typically at the granularity of the snap-in—which is fairly course grained. There is also limited ability to define customize the layout of the UI by role/permissions, and the like.
This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which a guidance package comprising program code and associated metadata is provided according to a metamodel schema. The guidance package is stored in a storage repository according to a storage schema. Access to the guidance package is provided via an interface set associated with the storage repository.
In one aspect, a storage repository contains a plurality of guidance packages stored according to a storage schema. Each guidance package comprises program code configured to execute on a management tool and associated metadata configured according to a metamodel schema. The storage repository is accessible via an interface set.
In one aspect, a guidance package comprising management tool extension program code and associated metadata is received and stored at a repository. The guidance package is located in response to a request, and returned in response to the request or a subsequent request.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards various marketplace-type aspects (packaging, storing and distributing) of guidance packages and asset distribution models, where “guidance packages” as referred to herein comprise defined product management extensions. Note that a guidance package may appear to a user as a wizard as one straightforward example, however as will be understood, guidance package (extensions) may be significantly more complex than a wizard, e.g., any UI control or set of controls that solicits input and performs behavior.
In one implementation, there is described defining a packaging model for guidance packages along the lines of an information content model. This packaging model defines executable wizards, task usage context, narrative guidance, and other asset dependency maps. The guidance packages may be stored in any suitable location, e.g., locally in a user's computer, on an intranet, the internet and/or in a cloud repository.
A set of APIs or the like are provided for program-based searching, downloading, uploading, and managing the storage, e.g., to retrieve one or more specific guidance packages. Packages are defined or otherwise associated with metadata for package versioning, handling storage conflicts, and ensuring package consistency. Metadata also facilitates searching for specific guidance topics and for enhanced dependency checking to avoid conflicts, and for managing asset relationships. For example, versioning may be used to determine if updated versions of guidance packages may exist, so as to prompt the user to update as appropriate. Metadata may also be used to organize guidance packages following different taxonomies to help end users select an appropriate category. State and exception metadata may be maintained.
In a typical usage scenario, an end user is working on a computer using a management tool as described below. An interactive aspect of the tool initially identifies the user, identifies one or more scenarios, and/or collects information about the specific management task the user is performing. The tool looks for the latest guidance packages deployed to the local systems and/or searches online guidance marketplaces based upon the use cases and user context. Upon finding the guidance package or packages, the tool reads/downloads the package or packages to the management tool and enables the management tasks.
It should be understood that any of the examples herein are non-limiting. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computers and management tooling in general.
In this example, the user executes a model generator program 108 which takes as an input program 102 (e.g., the Windows® Powershell® cmdlet) for which a UI is to be generated. The program 108 may reflect on the signature of the cmdlet function, the number of parameters, the types of these parameters and whether they are optional or mandatory. This information is then used by the model generator program 108 to generate a default UI model 110 (e.g., a XAML based form, such as defining a set of pages in text files and how they interact with each other, e.g., an introduction page, interaction page and error-handling page) and appropriate input validation logic. The information is also used to generate a default code template 112.
Note that in extensible scenarios, the program 108 presents the generated model to the user to decide on single cmdlet versus a pipeline or a workflow. This user input allows for composing complex application execution scenarios. Additionally, experts can customize and provide default parameters and flow conditions/rules as desired.
A model interpreter 114 may take the generated model 104 (comprising the UI model 110 and template 112) and execute the model 104, providing a wizard 116 (e.g., a single page) or the like to an end-user within which to enter input parameters. Users may extend this model to include guidance topics, examples and links to knowledge articles, for example.
After the user completes the wizard 116, a transformation program 118 takes the input parameters and inserts them into the code template 112 via transformation. This results in a customized program 120 (e.g., a Windows® Powershell® script or a pipeline of Windows® Powershell® scripts that are executable by the Windows® Powershell® interpreter). Each script can be shown to the user prior to execution or executed transparently. The artifacts generated by these processes such as UI Wizards, associated models and context may be collectively referred to herein as guidance packages.
With respect to packaging, a set of models define a guidance package 222 at an atomic level. These models, e.g., implemented as a set of methods, packages the specific guidance assets into the guidance package 222, provides for searchable metadata regarding the package guidance, handles package interdependency, versioning, enumerates the user scenarios/tasks and applicable context. Another model provides a set of methods or the like that compose multiple atomic packages into a cohesive set. Another model may be used to compress and/or store assets in interdependent packages for straightforward synchronization.
In one implementation, a metamodel schema 224 (e.g., an XML schema) defines the guidance package asset model. The metamodel schema 224 defines a set of base elements, exemplified in
In general, the exemplified metadata 226 includes information as to guidance name, guidance type, version, dependencies, permission data, author, services needed, platform/operating system support, prerequisites, usage context, related product/technology, searchable metadata, and the like. Note that permission data may be additionally or alternatively enforced by the operating system, e.g., via ACLs, tokens roles, and so forth. Filtering and/or ranking may be used, e.g., a database manager searching for packages may not see the same packages that a website author sees even with the same search criteria; a user may not see packages that he or she does not have sufficient permission to execute.
Also shown is an instantiation of this schema for Wizards based guidance package UI. Attributes of this Wizard package include representations (e.g., dlls) representing the UI elements, a map that identifies product scenarios/use cases and usage context. Each such package thus may contain versioning information and additional metadata such as author, services needed, platform/operating system support, pre-requisites, and reference to any dependent packages within and/or outside the package.
It should be noted that
With respect to storage of guidance packages in a local and/or online storage repository 230, guidance packages may be stored in any appropriate source location, e.g., locally on a user's computer, and/on an intranet or internet repository or a cloud location, such as at the original author's publishing location. A taxonomy may be associated with the storage to facilitate discovery of guidance packages.
In one implementation, a storage schema 232 is built following the guidance package metamodel. The storage schema 232 may expose additional metadata to help searching. Also the storage schema 232 may allow the storage to extract atomic package level metadata for efficient searching. The storage also may include logic/schema to handle package storage conflicts using the metadata, as well as enable version verification.
The exemplified storage repository 230 of
Note that more than one type of repository may be available. For example, a staging repository may hold guidance packages for editing, testing and so forth before publishing to a publication repository.
Turning to the distribution of guidance packages, via the API set 234, users may access the storage repository 230 to locate a package and copy/download the package, may execute search commands to locate the packages, and may organize guidance packages as appropriate for the particular user's needs. Note that guidance packages (and possibly access thereto) may be enabled or disabled based on constraints such as permissions or lack of context. Guidance packages may be synchronized via change sets, with changed assets distributed to enable efficient data transfers.
In this way, guidance packages (product management extensions) will, over time, be defined consistently and at an atomic level of detail. The technology thus allows developing management shells separate from the atomic guidance tasks that will be developed, packaged, stored, and distributed separately. This helps build an extensible ecosystem of scenario-focused management tasks and provides consistency on discovery and integration with future management applications.
With respect to processing guidance packages to personalize the tooling experience, guidance packages may be composed and loaded dynamically inside a management tool 328 of
The management tool 328 may determine if updated versions of guidance packages exist, and may prompt the user to update if appropriate. The management tool 328 also may arrange the guidance packages as appropriate for the particular user's needs, and compose multiple packages to support multiple use cases into a cohesive set, depending on the usage context. Still further, the management tool 328 may enable or disable the guidance packages based on constraints such as permissions or lack of context, as well as activate guidance packages as context/permissions are granted.
In one implementation, the configuration of the management tool 328 is specified in a configuration file. These configurations may be nested, thus allowing groups of guidance packages for a particular domain to be packaged together. e.g., to provide a collection of capabilities (similar to those provided inside a Snap-In).
In one implementation, the management tool 238 comprises a set of shared functionality (e.g., as services) and is driven by a UI composition model 332. The shared services perform functions such as locating guidance packages from an appropriate source, checking to see if these guidance packages have been updated recently and enabling/disabling guidance packages based on availability of security claims (e.g., to run package A, role is manager, to run B, role is employee) and/or other relevant context. Different UI elements may appear depending on role, permissions, state, context and so forth.
The UI composition model 332 is the model that describes the combinations of guidance packages (e.g., group 1 to group n) that are currently being managed by the management tool 328. The UI composition model enables grouping of guidance packages together, thus enabling sets of functionality related to a common domain to be organized together, and/or sets of guidance packages appropriate for a particular user role to be organized together. The user can also modify the composition model 332, thus enabling a customized user interface. Depending on the user context and current targeted scenarios, the composition model 332 may consume multiple guidance packages and aggregate tasks suitable for the use case.
The management tool may contain and/or track state. For example, consider that a package or other task specifies that three steps are needed, step 1 which needs to complete before step 2, which needs to complete before step 3. The management tool thus does not run step 2 until step 1 completes, and step 3 until step 2 completes. Exceptions also may be tracked. Further, the decision process system may result in retrieving additional guidance packages (e.g., on demand) needed to complete the task.
While the above was an example of a simple linear state machine, more complex logic may be contained. For example, execution may branch depending on other state data 338 (e.g., available resources, time of day, date), and/or based upon user data, e.g., take one branch for an administrator level user, another for a lower privileged user, and so forth.
Step 408 represents arranging the guidance packages as appropriate for the particular user's needs. As described above, the various information including user needs and the like may be collected by the management tool interactive component 236 or the like as part of the overall process. Step 406 represents composing multiple packages to support multiple use cases into a cohesive set depending on a current context. For example, context information may be provided by the user, by other state data and so forth.
Step 410 is directed towards enabling the guidance packages or disabling them based on constraints such as permissions or lack of context. Note that interdependencies may be checked against permissions, roles and/or the like so that a user may not be able to use a package that depends upon completion of another package that has a higher level of permission and/or a different role than the user has. Step 412 represents activating guidance packages based upon context/as permissions are granted.
Another scenario allows users to customize the guidance package with additional metadata. The management tool may provide an option for users to customize the package metadata content for storage. A management model is described in copending U.S. patent application entitled “DYNAMIC MODEL-BASED MANAGEMENT TOOLING”, attorney docket no. 335262.01.
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices.
With reference to
The computer 510 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 510 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer 510. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above may also be included within the scope of computer-readable media.
The system memory 530 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 531 and random access memory (RAM) 532. A basic input/output system 533 (BIOS), containing the basic routines that help to transfer information between elements within computer 510, such as during start-up, is typically stored in ROM 531. RAM 532 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 520. By way of example, and not limitation,
The computer 510 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, described above and illustrated in
The computer 510 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 580. The remote computer 580 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 510, although only a memory storage device 581 has been illustrated in
When used in a LAN networking environment, the computer 510 is connected to the LAN 571 through a network interface or adapter 570. When used in a WAN networking environment, the computer 510 typically includes a modem 572 or other means for establishing communications over the WAN 573, such as the Internet. The modem 572, which may be internal or external, may be connected to the system bus 521 via the user input interface 560 or other appropriate mechanism. A wireless networking component 574 such as comprising an interface and antenna may be coupled through a suitable device such as an access point or peer computer to a WAN or LAN. In a networked environment, program modules depicted relative to the computer 510, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
An auxiliary subsystem 599 (e.g., for auxiliary display of content) may be connected via the user interface 560 to allow data such as program content, system status and event notifications to be provided to the user, even if the main portions of the computer system are in a low power state. The auxiliary subsystem 599 may be connected to the modem 572 and/or network interface 570 to allow communication between these systems while the main processing unit 520 is in a low power state.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
