Patent Application
20100011411
The present invention relates to computing environments, and deals more particularly with using policy to control usage of computing assets (including remote, or external, assets) in a computing environment.
In large-scale software development projects, it is increasingly common for multiple teams to participate, where those teams are often in geographically-dispersed locations. Each team may have a number of team members such as software designers and developers (where these team members are referred to equivalently hereinafter as “developers” for ease of reference), and these team members may use any of a number of software development environments, and consumption of computing assets, to design and implement their respective code modules.
The present invention is directed to policy-based usage of computing assets. In one embodiment, this comprises: locating policy pertaining to a user of a computing environment, wherein the located policy specifies at least one of a plurality of computing assets which are allowed to be used by the user in the computing environment; resolving a location of each of the specified at least one computing asset; and automatically loading each of the at least one computing asset into the computing environment from the resolved location.
The locating, the resolving, and the automatically loading preferably occur automatically upon initializing the computing environment. The policy pertaining to the user is also preferably consulted, subsequent to initialization of the computing environment, upon each attempt to use a different one of the plurality of computing assets in the computing environment which is not yet loaded therein; and usage of the different one of the computing assets is preferably prevented if the different one is not allowed by the policy pertaining to the user.
Embodiments of these and other aspects of the present invention may be provided as method, systems, and/or computer program products. It should be noted that the foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined by the appended claims, will become apparent in the non-limiting detailed description set forth below.
The present invention will be described with reference to the following drawings, in which like reference numbers denote the same element throughout.
Embodiments of the present invention are directed toward policy-based usage of assets in a computing environment. Using techniques disclosed herein, policy definitions for computing assets (including remote, or external, assets) are provided in a consistent manner, and those policy definitions are preferably used when initializing a computing environment and also when subsequently importing an asset into that computing environment. The term “remote” assets is used herein, by way of illustration, to refer to the computing assets; “remote” refers generally to assets that are not locally stored at a team member's own computing environment. techniques disclosed herein do not actually depend on the location of the resources, however, and embodiments of the present invention may be used with locally-stored assets, remotely-stored assets, or a combination thereof. The disclosed techniques may also, or alternatively, be used to ensure that a secure computing environment is created whereby only hardware and/or software in a policy can be installed into the computing environment.
In large-scale software development projects, team members may use any of a number of software development environments to design and implement their respective code modules, as noted earlier. Different development environments may be used from one team to another, and even among the members of a single team. Interaction between entities in an existing software development environment will now be described with reference to the illustration in
In a multi-person software development effort, various techniques are used to control usage of remote assets (referred to alternatively herein as “external assets”). “Asset”, in this context, refers to a reusable software component. Such components may be stored in a centralized remote assets repository. See reference number 150.
In the environment illustrated in
The teams may access remote assets repository 150 through a network. This is illustrated generally by reference numbers 104, 114, 124. For example, a member of Team A may retrieve a copy of version 1.0 of a particular asset from repository 150, as noted as reference number 105. The team member may alter this copy within IDE 103, and might then integrate that altered copy with other assets that will then be tested within IDE 103 by members of Team A. As the teams progress on their respective contributions to the software project, those contributions may be aggregated and deployed to a run-time or production environment. See reference number 140.
The complexity of a multi-person software development effort increases significantly when more than a small number of developers are involved. Team A, for example, might work smoothly as long as all of its developers use the same version of a particular asset. However, if Team A uses version 1.0 of this asset, but Team B uses version 2.0 of that same asset (as depicted at reference number 115), this mismatch between the versions may prevent the development project from functioning correctly when the work of Team A is to be integrated with the work of Team B for use in production environment 140.
Existing approaches to usage of remote assets include IDE preferences and configuration files. As an example of using IDE preferences, an IDE might provide a preferences menu, for example, that allows an individual developer to select which of several available third-party tools that developer wishes to use with particular assets from a repository. As each member of the development team sets his or her own preferences, inconsistencies in remote asset usage may arise if different third-party tools are in use among the team members. Configuration files may specify preferences in a similar manner, where each developer may have different information in her or her configuration file, leading to the same type of inconsistencies.
Usage of remote assets may be further complicated due to inconsistent asset resolution interfaces or techniques. For example, there may be a number of mechanisms in use among the development team members for using assets of different types. Suppose a particular asset is provided by a third-party provider. A proprietary or provider-specific interface may be required for working with that asset. If an alternative implementation of that asset is also available from a different third party, it may happen that the interface for that alternative is completely different. The first provider might make the asset available from a container residing on a remote server, for example, where that container is accessed using a proxy, while the other provider's approach is to deliver a binary form of the asset for local storage directly on the developer's computing device. If developers must maintain an awareness of such differences, developer productivity may be reduced and likeliness of errors may increase.
Furthermore, no automated mechanism is known to the present inventors for ensuring that all team members are using the same version of the remote assets. In a small team, it may be sufficient for team members to verbally communicate which versions of which assets they are working with; however, this approach quickly becomes untenable as the size of the development effort grows.
An embodiment of the present invention uses a policy-based approach for remote asset usage. Preferably, this policy is applied using a centralized, organization-wide approach. Techniques are disclosed herein for defining the policy for the remote assets in a consistent manner, as well as for using the policy to enforce usage of those remote assets according to the definitions in the policy.
A policy definition (“PD”) engine is disclosed, according to an embodiment of the present invention. Standardizing a definition of the remote assets in the policy enables creating policies for usage of remote assets that is independent of which IDE may be in use in a particular computing environment. A policy enforcement (“PE”) engine is also disclosed, according to an embodiment of the present invention, and this PE engine preferably takes, as its input, policy created using the PD engine. In addition, the PE engine preferably sets up a developer's development environment according to the policy definition upon initialization of the environment and validates subsequent imports of remote assets into that development environment. The PE engine therefore enforces usage of the remote assets according to the defined policy.
Policies may be based on roles, remote repository information, and/or asset description, by way of example. Different policies may be defined, for example, for people working in different roles. A policy for people working in an integrator role, for example, might allow usage of a subset of the assets from the repository, such as assets which have already been created and compiled into executable form. These assets might be identified in the policy using an asset description such as their file type, as one example. As one alternative approach, the assets might be identified in the policy by specifying their location within a particular file structure at the remote asset repository. In yet another approach, a policy might specify a selected repository from which the assets must be retrieved. As yet a further approach, a combination of these types of information may be used to identify the remote assets within a policy.
Notably, although
In addition to identifying remote assets within a policy for controlling remote asset usage, the policy might specify certain permissions—such as read-only access—that are to be enforced for the asset. Permissions for using a particular asset may vary from one role to another, as defined in the policy.
A policy may be expressed using a markup language document, such as an XML (Extensible Markup Language) document. In one approach, a single XML document may be used as a “master”, organization-wide policy, where this document has different sections that define different roles. Attributes may be defined within the XML policy document to specify applicability of the roles defined in the various sections of this master policy. (See, for example, the “name” attribute 210 on the “<role>” element in document 200 of
One policy might be used for all members of a particular team, for example, or for all members having a particular role. Preferably, a policy defines which assets are to be used according to that policy by specifying at least one of the asset name, asset type, asset version, and asset location (e.g., as a remote asset repository location); in an alternative approach, other identifying characteristics may be used. Referring now to
Referring first to
By way of example, types of remote assets that may be specified in policy definitions include (but are not limited to) web services, .jar files, EJBs, and/or user-defined remote asset types. An asset resolver function is preferably provided with an embodiment of the present invention for resolving locations of one or more predefined asset types. Technology-specific considerations may be addressed in these asset resolvers, such as resolving a web service endpoint or selecting a jar file. Techniques for resolving such assets are known in the art, and do not form part of the inventive concepts of the present invention. User-defined types may be supported with an embodiment of the present invention by plugging an asset resolver into the IDE and configuring this asset resolver as needed (for example, by updating a mapping to identify the code of this asset resolver in association with the user-defined asset type, such that the asset resolver will be invoked for resolving such user-defined asset type).
The “version” attribute 323 illustrates a syntax whereby the policy specifies a range of allowable versions. In this example, when the PE engine processes policy document 300 and loads the developer's environment with assets according to this policy, it will load any assets named “util1.jar” (see reference number 322) that have a type of “jar” (see reference number 321), and which are stored in a remote repository that is accessible using the URL specified at reference number 324, and which also have a version number that falls in the range of 1.0 through 2.0 (see reference number 323).
Another example of using a “version” attribute is shown at reference number 353. In this example, a single version number of 4.3 is specified, and the PE engine will then load an asset of the specified type 351 with the specified name 352 from the specified URL 354 only if the version number of the asset matches the version number specified at 353.
Optionally, an embodiment of the present invention may support a wildcard feature. This is illustrated by element 360, where an “*” is specified as the asset name. See reference number 362. When processing this policy 300, the PE engine will load any asset of type “bar_type” (see reference number 361) that is stored at the specified URL 363, without regard to the name of that asset (because all names would be considered as matching the wildcard 362).
The policy syntax shown in
A policy definition for a large project may be quite complex, and the policy document may therefore contain many more definitions than the simple examples used herein for illustration. Using an XML document (or documents, when more than one XML document is used) to embody the policy definition makes the policy independent of the development environment where it will be deployed, as noted earlier. As a result, policies as disclosed herein may be imported and enforced in many different environments. Those environments include (by way of example) an Eclipse, NetBeans, or other Java-based IDE. Policies may alternatively (or additionally) be used in a non-Java-based IDE; when the PD engine is used to define policy for a non-Java environment, an adapter is preferably provided to support that environment in the PE engine. In preferred embodiments, the PD engine is implemented in a language chosen by the enterprise where the PD engine will be deployed (although the policy definition is technology-agnostic).
An embodiment of the present invention may support static policy and dynamic policy. When using a static policy, the defined policy specifications are processed by the PE engine, and remote asset usage is controlled accordingly for the assets defined in that policy. If assets are subsequently added to a remote asset repository but those assets do not meet the usage criteria specified in any policy definition, then those assets are essentially unusable during development (i.e., until such time as the policy may be revised to include those assets).
By contrast, when a dynamic policy is supported, the addition of assets to a remote asset repository preferably automatically triggers a corresponding addition to the policy definition. In this latter case, addition of the new asset preferably causes the PD engine to automatically create an entry in the policy file that will match this new asset. For example, the asset name and type may be programmatically determined, and an XML element may be programmatically constructed in the policy file that includes attribute name/value pairs to record that information. As an alternative approach, the developer adding the asset may ask a person with administrative authority to update the policy using the PD engine. As yet another alternative, an automatic request may be generated and sent to a person with administrative authority to request an update to the policy to thereby account for the added asset.
Turning now to
As shown at Block 400 of
As discussed earlier, dynamic policy may be supported by an embodiment of the present invention. In that case, the processing preferably occurs in a similar manner to that shown in
Referring now to
In an alternative embodiment, the PE engine is part of every team member's environment, and the PD engine is installed for those team members who are authorized to define policy.
As the development environment is initialized, an action is preferably triggered to import the policy definition file from the centralized repository (Block 510). User and system parameters may be taken into account when processing the imported policy, and such parameters are first analyzed (Block 520). For example, the team member's role may be programmatically determined and used to locate the role-specific policy statements within the policy file. The IDE for a particular user might be limited to the capabilities pertaining to that developer's job responsibilities. For example, a Web developer might not have capabilities for business logic creation or for database manipulation. As another example, of use of parameters, the developer's execution environment may be determined (such as what operating system is in use), and this information may impact which policy statements are applied from the policy file. Based on the policy file, as impacted by the analyzed parameters, the PE engine automatically resolves and downloads the remote assets as defined in the policy for that team member (Block 530). Note that the various remote assets may reside in potentially disparate asset repositories. The definition specified in the policy for this team member enables automatically locating and obtaining the specific remote assets that this team member is required to use. The team member's IDE (or, more generally, the team member's workspace) is configured for using the downloaded assets (Block 540). Configuring the PE engine may comprise, by way of example, invoking various asset resolvers to make the assets usable in the team member's IDE. For example, configuring a Web service may comprise invoking an asset resolver for the Web service to create stubs, and configuring a Web service for an asset type of jar may comprise adding the jar file to the class path for this IDE. The PE engine may then perform a validation of the team member's development environment (Block 550) to ensure that all presently-loaded assets conform to the policy for this team member, and if not, may prevent use of those non-conforming assets within this development environment (not shown in
While embodiments of the present invention have been discussed above with regard to defining and enforcing policy for remote asset usage in a software development environment, these techniques may also (or alternatively) be adapted for creating a secure computer system or environment where only the devices and/or software defined in the policy can be installed in this secure computer system/environment. In this case, the policy document created with the PD engine defines the installable devices/software, and the PE engine enforces that policy during installation of a device or software. Accordingly, the processing in
As will be appreciated by one of skill in the art, embodiments of the present invention may be provided as (for example) methods, systems, and/or computer program products. The invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes (but is not limited to) firmware, resident software, microcode, etc. Furthermore, the present invention may take the form of a computer program product which is embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein, where this computer program product may be used by or in connection with a computer or any instruction execution system. For purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (“RAM”), a read-only memory (“ROM”), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disk read-only memory (“CD-ROM”), compact disk read/write (“CD-R/W”), and DVD.
Referring now to
Input/output (“I/O”) devices (including but not limited to keyboards 718, displays 724, pointing devices 720, other interface devices 722, etc.) can be coupled to the system either directly or through intervening I/O controllers or adapters (716, 726).
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks (as shown generally at 732). Modems, cable modem attachments, wireless adapters, and Ethernet cards are just a few of the currently-available types of network adapters.
Still referring to
The gateway computer 846 may also be coupled 849 to a storage device (such as data repository 848).
Those skilled in the art will appreciate that the gateway computer 846 may be located a great geographic distance from the network 842, and similarly, the wireless devices 810 and/or workstations 811 may be located some distance from the networks 842 and 844, respectively. For example, the network 842 may be located in California, while the gateway 846 may be located in Texas, and one or more of the workstations 811 may be located in Florida. The wireless devices 810 may connect to the wireless network 842 using a networking protocol such as the Transmission Control Protocol/Internet Protocol (“TCP/IP”) over a number of alternative connection media, such as cellular phone, radio frequency networks, satellite networks, etc. The wireless network 842 preferably connects to the gateway 846 using a network connection 850a such as TCP or User Datagram Protocol (“UDP”) over IP, X.25, Frame Relay, Integrated Services Digital Network (“ISDN”), Public Switched Telephone Network (“PSTN”), etc. The workstations 811 may connect directly to the gateway 846 using dial connections 850b or 850c. Further, the wireless network 842 and network 844 may connect to one or more other networks (not shown), in an analogous manner to that depicted in
The present invention has been described with reference to flow diagrams and/or block diagrams according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 flow diagram flow or flows 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 flow diagram flow or flows 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 flow diagram flow or flows and/or block diagram block or blocks.
While 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 described embodiments and all such variations and modifications as fall within the spirit and scope of the invention.
