The present invention relates generally to computer system software applications and, more particularly, to customizable and configurable re-usable applications.
Today's software applications typically allow for some level of customization and/or configuration. Customization may occur before the application ships from the manufacturer. For example, localized versions of an application (i.e., English, German, Japanese, etc.) may be created by the software developer prior to publication and distribution. Customization can also occur after the user has installed the product, as is the case for a service pack or other software update. Users can also generally configure settings and options within installed software such as color or sound schemes, icons, startup screens, etc.
Often deployers of applications will need to customize and configure the applications they deploy. An Information Technology Administrator, for example, may need to standardize the look and feel and/or feature set of applications that are being used within their network domain. In another example an Internet Service Provider may desire to distribute a branded version of an application for its subscribers. Routinely, this customization is done by modifying the setup of the application or by modifying the state of the deployed application after its setup runs using another custom program. While the resultant state of the machine may in fact now have the application in its customized form, there is no authoritative definition or handle to manipulate this customized application.
The above situation can be problematic as once the application has been customized and has either lost its original application identity and possesses an unrelated new identity, or still has the original identity as opposed to the customized identity, there will be no way to identify the customized application as being a customized variant of the original application. Thus it becomes particularly challenging to ensure that throughout the application's life-cycle (i.e., installing, customizing, updating, executing, and retiring the application) it will be able to be maintained and to function as necessary—according to the original application.
In view of the foregoing, the present invention provides a framework to build, deploy, service, and manage customizable and configurable re-usable applications. Specifically, the present invention presents a framework for an application (i.e., a component that controls its execution context and can be activated) to be defined declaratively as a manifest possessing an identity, including but not necessarily, a strong identity (see application Ser. No. 09/605,602, entitled “Shared Names”, filed on Jun. 28, 2000 which is herein incorporated in its entirety for everything it describes). The application manifest can declare appropriate ways to configure or customize the application securely and provides the ability to only grant such a right to authorized parties.
A further aspect of the present invention is that is also provides a framework for an application deployment to be defined declaratively as a manifest possessing an identity of the customized application. Such a framework offers a way for the system, state infrastructure, setup programs, authoring tools, management tools and other interested parties to deploy, install, service and manage the customized application using an authoritative composite application identity. The customized application can also be further customized.
The application manifest as well as the deployment manifest can be made available through out the lifecycle of the deployed application—including at runtime—which assists in consistent manipulation of the customized application. The support for allowing multiple such customized applications to be available in the same scope (i.e., user, machine, network, etc.) makes it possible to have true re-usable applications much like side by side components.
While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
In the description that follows, the invention is described with reference to acts and symbolic representations of operations that are performed by one or more computers, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains them at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data are maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that several of the acts and operations described hereinafter may also be implemented in hardware.
Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. The following description is based on illustrated embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein.
Referring to
In its most basic configuration, a computing device 100 typically includes at least one processing unit 102 and memory 104. The memory 104 may be volatile (such as RAM), non-volatile (such as ROM and flash memory), or some combination of the two. This most basic configuration is illustrated in
Computing device 100 can also contain storage media devices 108 and 110 that may have additional features and functionality. For example, they may include additional storage (removable and non-removable) including, but not limited to, PCMCIA cards, magnetic and optical disks, and magnetic tape. Such additional storage is illustrated in
Computing device 100 can also contain communication channels 112 that allow it to communicate with other devices. Communication channels 112 are examples of communications media. Communications media typically embody 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 include 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, communications media include wired media, such as wired networks and direct-wired connections, and wireless media such as acoustic, radio, infrared, and other wireless media. The term computer-readable media as used herein includes both storage media and communications media. The computing device 100 may also have input components 114 such as a keyboard, mouse, pen, a voice-input component, and a touch-input device. Output components 116 include screen displays, speakers, printers, and rendering modules (often called “adapters”) for driving them. The computing device 100 has a power supply 118. All these components are well known in the art and need not be discussed at length here.
The present invention is directed to a framework to build, deploy, service, and manage customizable and configurable re-usable applications. Simply stated, an application is a set of one of more components that controls its execution context, as permitted by the host, and can be activated. A component may be described as an atomic, immutable set of files. It should be noted that “control” as used here is relative; there are some factors (e.g., machine-wide component servicing/settings, etc.) that even an application cannot control. Also, there are different levels of contexts (e.g., machine, process, appdomain) that provide different guarantees and levels of control and isolation to an application. Additionally, an application need not necessarily be an executable file and may not run in its own process, but rather may run in an application domain. Referring to
By employing a shared names scheme (see application Ser. No. 09/605,602, entitled “Shared Names”, filed on Jun. 28, 2000 which is herein incorporated in its entirety for everything it describes) a unique identifier for a component—a component identity—can be derived. A component identity comprises the component name, version, and public key token. An application identity can similarly be derived. An application identity is a path through the dependency graph of an application or deployment (i.e., a component that customizes one or more applications establishes a name resolution scope around the applications and other components that it and its applications contain), represented as an ordered list of the component identities of the components along that path. The last component on that path is usually an application.
It is possible to define a manifest for the ChatApplication example. A manifest is an authored document containing meta-data about a component. An effective manifest is a compilation of an application's or deployment's manifest content, including the content of manifests of all its constituent and dependent components, considering (component binding) policy statements that might be in effect on a given system for any of the components. A merged application manifest, on the other hand, is a compilation of an application's or deployment's manifest content including the content of manifests of all its constituent components, not considering any component binding policy and not considering any external/pre-requisite dependencies (i.e., on OS components).
Referring once again to the exemplary application architecture of
In one preferred embodiment, a declarative Extensible Markup Language (XML) based scheme can be employed to implement the application manifest. An exemplary implementation follows:
As discussed above, many applications expose settings that allow the application to be substantially customized or even branded. In many scenarios it may even be necessary to allow multiple customizations of the same application to be installed simultaneously on the same machine. The present invention can be particularly useful in overcoming the difficulties associated with achieving such a result by employing the state of the art. Turning to
In one preferred embodiment, a declarative XML based scheme can be employed to implement the deployment manifest. An exemplary implementation follows:
The above example illustrates how MSNChat 300 is able to customize the install and UI experience for ChatApplication so it is branded and looks like it is MSN. It also suggests how MSNChat 300 can configure the application through an overriding configuration file. For example, if the configuration file had a setting BackgroundColor=Blue, then the configuration file provided by the deployment could override this to say BackgroundColor=White. Additionally, this example also shows how Language satellites, such as the French satellite for CapiComm as shown above, can be added.
Finally, the system can use certificates and other rights management technologies to ensure that the deployer only customizes the application in acceptable/application author authorized ways. In the above example a trivial way this is illustrated is that both the application and the deployment have the same ‘public key’ as evidenced by the public key token attribute in the assembly identity. This ensures that they have a trust relationship.
When the user launches a shortcut, the shortcut will contain the full application identity (AppID). This means that if the application is customized the application identity includes the full identity of the deployment(s) as well as the application. For example:
The binder itself can also use the AppID and the set of manifests that are associated with each segment of the ID (the AppID can be used to obtain the “effective manifest” or the “merged application manifest” and thus any data within such structures) in order to provide support to bind to the right version of the assembly or other DLLs, as well as location information for the same, out of the manifest. The binder has the ability to be very selectively in choosing the right binding environment for the customized application. This allows the system to provide a model where one deployment (or customized application) can use versions of components without interfering with other customized versions of the same application or entirely different applications. This scenario relies on the ability of the underlying components to be isolatable.
In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of invention. For example, for performance reasons the framework of the present invention may be implemented in hardware, rather than in software. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
This application claims the benefit of U.S. Provisional Application Ser. No. 60/514,069 filed Oct. 24, 2003.
Number | Date | Country | |
---|---|---|---|
60514069 | Oct 2003 | US |