System And Method For Abstract Configuration

Field of the Invention

[0001] The field of invention relates generally to the software arts, and, more

specifically, to configuring an instance.

Background

[0002] In previous system configurations system dependent information (such

as the number of CPUs and memory available) was statically and redundantly

distributed across the cluster. Each node was manually, individually configured

with this static system dependent information. Accordingly, when more

memory was added to the system each node had to be manually updated to

reflect that. The programmer therefore not only had to know what nodes where

on the system, but where they were stored (the path) and the proper syntax for

defining each node properly.

[0003] Figure 1 illustrates an exemplary system of multiple physical machines.

Each physical machine 101, 115 of the system 129 includes at least one instance

103, 113, 117, 119 and node 105, 107, 109, 111, 121, 123, 125, 127. Of course, a

physical machine 101, 115, such as a server, developer computer, or personal

computer, may have multiple instances 103, 113, 117, 119 with each instance

having more than one node 105, 107, 109, 111, 121, 123, 125, 127. In a physical

machine utilizing a Java runtime environment, the nodes are Java containers

such as J2EE, servlet, etc.

[0004] Additionally, each physical machine 101, 115 commonly had different

hardware and software components that were not compatible with other

physical machines in the system. With each node individually configured to fit a

particular machine's setup, it was nearly impossible to move a configuration (as

is) from one physical machine to another. For example, if the configuration for a

machine_l 101 includes 1024MB of memory, runs a Microsoft Windows

operating system, and a SUN virtual machine one could not simply port this

configuration to a machine_21115 that has 512MB of memory, runs a Linux

operating system, and uses a IBM Java virtual machine.

[0005] When a change was made a machine in a system, nodes where changes

should be applied had to be restarted. The VM settings changes will take place

only after restarting the whole instance, which can lead to downtime only if the

system has only one instance. In many business environments (for example, web

services), this downtime can cause not only user frustration at not being able to

access needed information or programs, but loss of income for the duration of

the machine being offline.

[0006] Additionally in prior scenarios, Java parameters were stored in one single

property. AU child configurations would hide the parameters of their parents, as

the child completely overwrites its parent's property. Accordingly, in the single

configuration scenario, if the parent's property changed, there would be no way

of propagating that change to the child.

[0007] A cluster is a group of at least one system. A bootstrap synchronizes the

components in the file system (FS) of a cluster. Prior J2EE engine versions stored

the information about FS archives deployed in the cluster on the file systems of

the cluster nodes. Many times the data on the FS was deleted and it could be

restored only by redeployment.

Summary

[0008] A specification and method for the configuration of an instance are described. Inheritable configurations/profiles from an abstract configuration model are used to define the instance dynamically. The inheritable configurations/profiles may be written in XML.

Brief Description of the Drawings

[0009] The present invention is illustrated by way of example, and not

limitation, in the figures of the accompanying drawings in which like references

indicate similar elements and in which:

[0010] Figure 1 illustrates an exemplary system of multiple physical machines;

[0011] Figure 2 illustrates one embodiment of a model to abstractly configure an

entire cluster (multiple systems) or portions of the cluster dynamically;

[0012] Figure 3 illustrates an embodiment of the top level of a default template;

[0013] Figure 4 illustrates an a more detailed embodiment of the types of

content of a template;

[0014] Figure 5 illustrates an exemplary virtual machine section for a default

template;

[0015] Figure 6 illustrates an exemplary embodiment of a method to configure

an instance;

[0016] Figure 7 illustrates an exemplary filter portion of a default template;

[0017] Figure 8 illustrates an exemplary component configuration portion of a

default template;

[0018] Figure 9 illustrates an exemplary template file;

[0019] Figure 10 illustrates the use of exemplary filters in a model system;

[0020] Figure 11 illustrates an exemplary graph at a root level;

[0021] Figure 12 illustrates an embodiment of configuration using abstract

system information;

[0022] Figure 13 illustrates an exemplary file synchronization using bootstrap

configuration;

[0023] Figure 14 illustrates an embodiment of a method for using a bootstrap to

synchronize a local file system with a cluster file system and database; and

[0024] Figure 15 shows an embodiment of a computing system (e.g., a

computer).

Detailed Description

[0025] Described below is a system and method for computing system

administration using an abstract configuration model. Throughout the

description, for the purposes of explanation, numerous specific details are set

forth in order to provide a thorough understanding of the present invention. It

will be apparent, however, to one skilled in the art that the present invention

may be practiced without some of these specific details. In other instances, well-

known structures and devices are shown in block diagram form to avoid

obscuring the underlying principles of the present invention.

[0026] Note that in this detailed description, references to "one embodiment" or

"an embodiment" mean that the feature being referred to is included in at least

one embodiment of the invention. Moreover, separate references to "one

embodiment" in this description do not necessarily refer to the same

embodiment; however, neither are such embodiments mutually exclusive, unless

so stated, and except as will be readily apparent to those skilled in the art. Thus,

the invention can include any variety of combinations and/ or integrations of the

embodiments described herein.

Abstract Configuration Model

[0027] As described in the background, previous systems, configurations where

completely system dependent. For example, the number of CPUs and memory

available, OS, VM, type, etc. were known prior to starting the system and

statically and redundantly distributed across the system or cluster. Each node

was manually, individually configured with this static system dependent

information.

[0028] Figure 2 illustrates one embodiment of a model to abstractly configure an

entire cluster (multiple systems) or portions of the cluster dynamically. This

model is broken into several different levels of abstraction 219, 221, 223, 225, and

227, with each level offering a different level of abstractness. The order of 219,

221, 223, 225, and 227 goes from the highest level of abstraction (219) to the

lowest level (227). Additionally, each level of lower abstraction inherits the

properties of the level higher than it unless the lower level overwrites the higher

level. For example, level 223 inherits the properties of level 221 unless a conflict

exists. If a conflict exists, the properties of level 223 control. In an embodiment,

the files at each level are written in XML.

[0029] A configuration is a collection of settings (properties) that determine the

J2EE engine behavior. A configuration of the engine that is level based for allows

for greater usability and flexibility. As the smallest entity for configuration is the

instance (no explicit configuration for separate server nodes is available and all

the nodes inside an instance are configured identically) the structure of the

configuration settings on all the configuration levels is the same and represents

the instance configuration settings.

[0030] The actual configuration structure of the engine in the database is

complicated so it is generally not a good ideal to let the users (service manager,

administration tools, offline configuration tools) work directly with it. A

configuration abstraction layer provides an API which (1) exposes the settings at

each configuration level to be accessed in the right access mode (read/ write) and

(2) hides the real representation and paths of the settings in the database.

Further changes on the structure or paths won't affect the users because will be

handled by the abstraction layer.

[0031] The basic level 219 is the highest level of abstraction. As will be

discussed later, the properties at the basic level 219 are used to help define

different physical machines of a multiple systems. The basic instance 201 defines

the basic structure of an instance configuration for the entire system or multiple

systems. The definitions of the basic instance 201 are name-value property pairs

that are common to each system. The number of CPUs, amount of memory,

location of a Java installation, number of nodes, instance type, thread count, etc.

are examples of the names of the pairs. These are configuration constants and

are also system parameters. These system parameters are installation dependent

and system dependent and may be used as constants in the parameterized

values. They are evaluated at runtime depending on the actual system resources

of each machine and installation configuration of each instance. However, while

the name is defined the value is not defined. This value is defined upon

installation and is system specific. The definitions from this instance are applied

system wide and generally are not subject to change by an end-user. As will be

described later, these settings are common for and inherited by the other

configuration levels. All the levels down the inheritance chain get this structure

and all the settings already defined from their parent configuration. If there is

nothing more changed in the settings on some configuration level the data

(settings/ properties) it keeps is just the same as the data in its parent level.

Effectively the current configuration level is just linked to its parent level and

"sees" all the settings defined on the parent level. If there are any changes in the

settings of the current level, only these changes are described and written in the

level, all the ones that are not changed are still received from the parent via

inheritance.

[0032] A specific system is described at the system level 221. At this level, a

customized basic instance 203 may add system level settings not covered by the

basic instance 201 or change existing settings from the basic instance 201. For

example, additional name-value pairs may be added and/ or the value portion of

the basic structure 201 changed. A system may include multiple physical

machines, instances, and nodes as illustrated by Figure 1. Changes made at this

level are available globally to the entire system. For example, a change at this

level will affect every physical machine 101, 115 of system 129.

[0033] Deployable configuration templates for different instance types may be

included in the multiple instance (sometimes referred to as the default template)

level 223. At this level 223, multiple instance definitions on the same system may

be defined and/ or reconfigured using configuration templates. These

configuration templates contain pre-defined instance configurations for specific

use cases and scenarios like portal 209, batch processing, minimal 205, J2EE

developer 207, etc. The settings provided at this level are common for the

scenario, for the optimal execution of the engine in this scenario, and, in one

embodiment, cannot be changed by end users with configuration tools. For

example, the number of threads dedicated for HTTP request processing may be

different for different scenarios.

[0034] While a system may have different types of instances, instances of a

single type are normally identically configured. For example, with respect to

Figure 1, the J2EE instances are configured identically. However, if, for example

both instances from the same type are running on different machines and one of

the machines is really slow or hosts other resource consuming programs it is may

be beneficial to change the default configuration and let the engine use only part

of the system resources.

[0035] Additionally, each container node (J2EE, etc.) has one VM. Each template

of a type is inheritable by the subsequent instances and/ or customized

configuration template assigned to it. A configuration template does not usually

contain any system dependent information (like number of CPUs) and is

therefore system independent. The system dependant information is used in

parameterized settings allowing the system to be configured independent from

the system resources/ JVM/ OS. When the engine is started all the parameters

are substituted at runtime with the specific values for each machine environment

(to be described in detail below).

[0036] A configuration template may contain one or more of the following

configuration information: (1) An instance layout contains the configuration

about the number of server nodes running on this instance. The instance layout

may be configured via a simple arithmetic property which specifies the number

of server nodes. Thus, the instance layout dynamically adapts itself to the

environment on which the instance is running. In a high-end environment an

instance will consist of a higher amount of server nodes whereas in a low-end

environment (e.g. developer PC) only one server node is usually running on the

instance.; (2) A virtual machine (VM) configuration contains the VM memory

settings and the VM parameters. These settings are again specified in a system

independent way via parameterized and computed configuration entries. For

example, the maximum heap size may be configured as an arithmetic expression

dependent on the amount of physical memory and the number of server nodes

running on this instance.; (3) A kernel configuration contains the system

independent properties of the manager components of the engine. System

dependent settings are abstracted via parameterized and computed settings

(parameterized and computed settings will be described in detail below).; (4)

Service settings contain the system independent service properties of each

service component which is part of the installation. System dependent settings

are abstracted via parameterized and computed settings.; (5) An application

configuration contains the system independent application configuration of each

application which is part of the installation.; (6) A cluster file system

configuration contains the system independent configuration of the components

which are deployed into the file system. The bootstrap process is responsible for

synchronizing this configuration (together with the components itself) to the file

system. During the synchronization, a configuration manager transparently

substitutes dynamic settings.; (7) A runtime filter configuration contains the

configuration for enabling and disabling components according to the use

case/ scenario the template belongs to.

[0037] As discussed above, the abstract configuration model utilizes

configuration templates to pre-define and simplify the configuration of a system.

In one embodiment, a configuration template is represented by a single XML file,

which is parsed during deployment and its content gets fitted into a dedicated

configuration level (level 223). The template may bring in the following

information and override the originally deployed values: modified

kernel/ services properties, modified application properties, modified VM

I l

parameters, modified startup filters, number of nodes, instance type, and/ or

system information centralization settings.

[0038] In general, the installation that deploys a template contains many more

components than those which are actually used in a specific use case and

scenario. The components which are not needed are disabled and those which

are needed are enabled via the runtime filter configuration. In a J2EE developer

template 207, for example, the runtime filter configuration may disable

everything except those components which are needed in a J2EE developer

scenario.

[0039] The minimal template 205 is used during instance installation and

contains elements needed in order to run a central configuration manager which

selects and sets the specific use case template for the instance to be configured.

This configuration manager may be a J2EE engine service.

[0040] Customized scenario templates 211 are in the customized level 225. The

template 211 adds or changes settings from what is defined in a configuration

template or templates of the system level 223. In an embodiment, the relation

between the default scenario based templates and the customized templates is

1:1. In other words, there is a single customized configuration template 211

corresponding to minimal 205 and a single customized configuration template

211 corresponding to J2EE development 207. Changes are visible in all the

instances that inherit from this customized template 211. Exemplary uses

include the need for customizing additional engine components. Changes on the

instance level 227 are made the instance configurations: 213, 215, 217. There may

be one or more customized configuration templates associated with each

configuration template of level 223.

[0041] A customized configuration template for a specific scenario template is

created when an instance of this scenario template is to be created. Initially, the

customized template is a link to its parent scenario template, i.e. inherits all the

settings of the scenario template. For example, the customized configuration

template 211 may inherit from the minimal 205, J2EE development 207, and/ or

portal 209. It is possible this template to be to not need custom changes for the

lifetime of the engine. However, if at some point the user needs to make a

change in the settings (for example, to add a debug VM parameter or to change

some service property) and this change should be effective for all the instances

that belong to this scenario template, this change may be done in the customized

template. In one embodiment, these changes are done only manually through

configuration tools. The result of the change is a locally written setting (name,

value pair) for this customized template (all other settings will be still inherited

from the hierarchy).

[0042] Finally, the configuration of specific instance 213, 215, 217 is finalized at

the instance level 227. This is the lowest level in the hierarchy (the least abstract).

The settings at the level concern only single instance. The instance settings are

gathered from all the levels above having in mind the rule that if there are

settings with local values on a certain level they (the local values) are used

instead of the inherited ones. On this configuration level are the real/ final

settings that are used to configure the instance resources and behavior. The

changes may be made with configuration tools and are local for the instance

(changes to not propagate up to a higher level of abstraction). For example

number of nodes could be configured to 1 although the machine has 3 CPUs and

the default value is 2*CPU_COUNT.

[0043] Specific system parameters (such as the number of CPUs or amount of

memory available) are propagated through the configuration model beginning at

the basic instance customized, with each subsequent level further defining the

details of the instance to be created. In an embodiment, system parameters

included in a component separate from the instance.

[0044] Levels 221, 225, and 227 make up the custom system configuration. These

are the levels where changes can generally be done on the fly by an end user. On

the other hand, levels 219 and 223 contain configuration settings common for the

engine and common for specific scenarios and are propagated as is and are not

normally alterable with custom values. The system configuration contains the

configuration of the instances of a deployed system. An instance is assigned to a

use case and scenario which is to be executed by the instance during runtime.

For example, the system may be a developer system or a server, which are

different use cases.

[0045] Configuration changes on the level of the custom layer 225 are visible

across all instances, which are assigned to the same configuration template. If a

setting for a particular instance or instances needs to be changed, the

configuration change is done on the instance level 227.

[0046] In rare cases, there may be the need to change a setting not only on the

level of one usage (for one template), but for the whole system and thus for all

usages which are activated in the system. In this case, the configuration change

is to be done on the level of the basic instance customized 203 level 221 because

that will be propagated throughout the entire system as all instances inherit there

configuration from the basic instance customized 203 configuration and thus a

configuration change on this level is visible globally (as long as the setting is not

locally overwritten).

[0047] The above described templates and configurations may be stored in a

local (to the physical system) and/ or remote configuration database. In an

embodiment, they are stored in a tree structure.

[0048] Of course it should be understood that other levels of abstraction may be

added or some of the levels illustrated in Figure 2 may be removed without

departing from the principles discussed above. Additionally, the specific

configurations or templates at a particular level are illustrative and not

exhaustive.

Inheritance Principles of the Abstract Configuration Model

[0049] The abstract model of Figure 2 provides for inheritance between levels of

abstraction. The information at the highest level of abstraction 219 is passed to

the levels below it (221, 223, 225, 227). The system level 221 therefore inherits the

configuration settings of level 219. Likewise, level 223 inherits the configurations

of levels 219 and 221; level 225 inherits the configurations of levels 219, 221, and

223; and level 225 inherits the configurations of levels 219, 221, 223, and 225.

[0050] The semantics of this configuration inheritance scheme applied to the

case of lower level of abstraction, configuration B (for example, customized

configuration template 211) derived from a higher level of abstraction,

configuration A (for example, portal 209), are described below. Configuration

content, which does not locally exist in configuration B, but which is available in

A will be inherited and thus is visible to configuration B.

[0051] In an embodiment, the lower level of abstraction controls if there is a

conflict between levels. For example, the local content of configuration B has

priority over inherited content from configuration A. Accordingly, when content

settings are overwritten in configuration B, the overwritten local content (and not

the inherited content from configuration A) will be visible in configuration B.

[0052] In an embodiment, the properties of the higher level of abstract are saved

before being overwritten by the lower level content. This allows for an easier

transition back to an initial state.

[0053] The contents of a configuration (including configuration entries, files,

sub-configurations) are subject to inheritance. The inheritance relationship is

assigned to the whole configuration sub-tree (not to one configuration node

only). This means, a local sub-configuration of configuration B (e.g. B/ sub) has

implicitly an inheritance relationship to the according sub-configuration of

configuration A (e.g. A/ sub). In an embodiment, this is true in the case where

the corresponding sub-configuration in A does not exist. Of course, depending

upon the overall model configuration, certain of these contents may be excluded

from inheritance.

Template Structure

[0054] Figure 3 illustrates an embodiment of the top level of a default template.

At this top level 301, the template the instance layout is defined. This includes an

name for the instance 303 being installed. Additionally, the top level may

include the number of nodes 305 of the instance (as described above, this could

be done using parameterized values, computed values, or value links) and the

type of instance 307 (for example, J2EE, JMS, etc.). Of coures, the principles of

the default template may be applied to other templates.

[0055] Figure 4 illustrates an a more detailed embodiment of the types of

content that a default template may describe. Generically, a template may define

parameters for one or more of the following: filters 401, virtual machines (VMs)

403, and/ or component configuraitons 405.

VM Settings

[0056] For greater flexibilty, VM settings are divided by VM-vendor and

platform (operating system (OS)). This division allows for parameters to be

specified for any OS/VM (all OSs and all VMs) combination; for any OS, but for

a particular VM; or for a particular VM/ OS combination.

[0057] Figure 5 illustrates an exemplary VM 403 setup for a default template. As

discussed above, multiple vendors 501, 503 and general parameters 505, 507 may

be defined under the VM portion of a template. Because there are numerous

choices for vendors (SAP, Microsoft, IBM, Sun, etc.) it is important to allow for

the broadest number of cases to be available to the template for dynamic system

configuration. For example, it is desirable to have a template cover Microsoft

and SAP products in a large enterprise environment where both are used

extensively.

[0058] Of course, even a single vendor may have several different platforms

(OSs) that could be deployed. Microsoft alone has several different operating

systems in use today and will have even more in the future. Accordingly, a

vendor may have multiple platforms 509, 511 described in the VM portion of the

template.

[0059] Several different parameter value levels may be included under the VM

portion of a template. At the broadest level, "global" virtual machine parameters

such as 505, 507 are visible (inheritable) and used from any VM/ OS combination,

unless overridden at a more detailed level. The visibility of a property specified

at that level is "all VMs" and "all OSs". For example, the global VM parameters

505, 507, 521 are applicable to any vendor 501, 503 and their particular platforms

such as platforms 509, 511 of Vendor_l 501.

[0060] Under the VM vendor level, a particular property is visible (inheritable)

and used only on a particular VM vendor, but still on all platforms it runs on,

unless overridden at a local level there. The visibility of a property specified at

this level is "particular VM" and "all OSs". For example, the parameters 517,

519, 525 apply to any of Vendor_l's 501 (particular VM vendor) platforms 509,

511 (all OSs under Vendor_l 501) unless overridden by more specific parameters.

Parameters 515, 521, and 507 are examples of parameters that would override the

vendor global parameters 517, 525, 519 with respect to Platform_l 509.

[0061] Under the platform level a particular property is visible (inheritable) and

used only on a particular VM and on a particular platform. It overrides any

values of this property, specified at a more generic level. The visibility of a

property specified at that level is "particular VM", "particular OS". For example,

the parameters 513, 515, 523 are specific to Platform_l 509 (particular OS) which

is specific to Vendor_l 501 (particular VM).

[0062] A parameter represents a single Java parameter of any type. Each

parameter may have attribues such as name, type, value, disabled, and

desciption. The type is selected from one of the Java parameter groups above.

Disabled specifies whether the current setting shouldbe visible (or used by) more

concrete (less abstract) configuration levels or not. Value specifies a local value

used when overriding inherited values. The description describes what the

template sets and/ or why.

Dynamic VM Settings

[0063] In one embodiment, VM Java parameters are divided into separate

groups as shown in Figure 5 instead of being grouped together as in the prior

art. Since configurations may be inherited, if the Java parameters were stored in

one single property, all child configurations would hide the parameters of their

parents, as the child completely overwrites its parent's property. Accordingly, in

the single configuration scenario, if the parent's property changed, there would

be no way of propagating that change to the child. Additionally, there would be

no way to define relations between parameters using parameterized values or to

define different parameters for each platform and VM vendor combination.

[0064] The memory group parameters (for example, 513, 517, 505) include name-

value pairs (name and number) such as heap size (initial and maximum) and

permanent memory size (new and maximum). These pairings may be

parameterized, calculated, or contain value links as described above.

[0065] The system properties group parameters (for example, 523, 525, 521)

includes name-value pairs (name and path) such as the security policy and

COBRA information.

[0066] The additional properties group parameters (for example, 515, 519, 507)

include garbage collection (GC) parameters. Garbage collection is the Java

mechanism for removing unused objects from memory.

[0067] Properties are generally inheritable as described above. Additionally,

properties from the system and additional groups may be disabled. This

disablement is propagated down the inheritance chain. In one embodiment, the

original value(s) are preserved so that the property can be re-enabled.

Filter Templates

[0068] As will be discussed later, runtime filters are used to start or stop

components and therefore help define a system. The filters are represented as

start/ stop rules. In one embodiment, each of the rules has the same structure

and attributes. The order in which the filters are evaluated is important, since it

may change the complete startup semantics. Each filter can be either in the stop

list or in the start list. A first component matching a stop filter will be stopped

unless another component that refers the first component is set to be started by a

subsequent filter rule. Likewise, a first component matching a start filter will be

started unless another component that refers the first component is set to be

sttopped by a subsequent filter rule. A filter at a lower level of abstraction will

overrule the filter at a higher level of abstraction.

[0069] Figure 7 illustrates an exemplary filter portion 401 for a default template.

Each filter tag 701, 703 represents one particular rule for filtering components.

Each configuration level may have several or no filters present. It can match one

or several components, or not match components at all, depending on the

specified filter fields and the deployed components. The filter tag may have

several attributes such as action (start or stop), component type (library, service,

interface, or application), component name, and component provider name.

Component Configuration Settings

[0070] A template allows properties of of a deployed engine component to be

set. Different types of engine components may be set such as applications,

managers, services, etc.

[0071] Figure 8 illustrates an exemplary component configuration portion 405 of

a default template. Each type of component (manager 801, 811; service 803, 813;

or application 805, 815, interface, etc.) may be further described by one or more

properties. Every component property is described as a property tag containing

value and name attributes. The name attribute specifies the name of the property

to be changed. The value attribute represents the actual property value you want

to specify.

[0072] Additional attributes may also be described. For example, a secure

attribute indicates whether the property must be encrypted or not; a

parameterized attribute indicates whether the property can contain

parameterized value and must be passed through a substitution routine; a

computed attribute indicates whether the value must be passed through an

expression calculator when evaluating or left as it is; a contains link attribute

indicates whether a link should be evaluated out of the parameter value; a final

attribute forces that a particular property to be unchangable by a lower level of

abstraction; and/ or a description attribute contains the description of the

particularly added property. Addtionally, one may choose to explain inside

why this particular value was entered configuration component.

Exemplary Template

[0073] Figure 9 illustrates an exemplary default template file. This particular

template 901 is called "test" and is of the instance type J2EE. The definitions of

the filters of the template begin at 903. The first filter is a "stop" filter that is

applicable to components of any name, provider, or type. It will stop all

components from starting. The second filter is "start" filter that overrules a

portion of the first filter. This starts the "jms_provider" service component made

by sap.com. Filters will be described in greater detail later.

[0074] The definitions of the VM parameters of the template are defined

beginning at 905. For this particular configuration of an instance, the vendor is

Sun and one platform is "ntintel." For this platform the maximum heap size is

512 MB. For other Sun platforms, the maximum heap size is 1024 MB. For other

vendors, the maximum heap size is 2048 MB.

[0075] The configuration section is begins at 907. The manager is named

"ServiceManager" and two properties are set for it. The service is named

"jms_provider" and is supplied by sap.com. Finally, a system information

property is defined for a timeout value.

Dynamic Configuration of a System Using the Abstract Configuration Model

[0076] Previous systems were statically configured. As discussed previously,

this approach required tedious maintenance of nodes and detailed knowledge of

the computing system that was to be deployed.

[0077] Dynamic configuration uses parameterized settings, computed settings,

and value links to configure a system. Parameterized settings are used instead of

static values for system dependent configuration. These settings are resolvable

by simple parameter substitution instead of being duplicated in each instance

during runtime or prior to runtime. Parameterized settings are system

parameters such as CPU count, OS type (name, 32/64 bit, etc.), memory, etc.

These parameters may be transparently (from the user's viewpoint) substituted

during runtime. In an embodiment, parameterized settings are stored in a

system profile.

[0078] Computed settings are simple arithmetic expressions usually containing

system parameters from the system profile. During runtime, the parameters are

transparently substituted and the arithmetic expression is evaluated. Computed

settings may be used when a simple parameter substitution is not sufficient, but

instead the value needs to be calculated out of specific system parameters (such

as cache sizes, heap size, etc.) For example, the number of nodes in an instance

may be CPU dependent. A computed setting such as "number of nodes = 2*CPU

number" allows for a dynamic number of nodes based on the CPU count, instead

of "hard coding" this number in the system, which may change at a later point in

time.

[0079] Value links contain a link to other settings. These may be used when a

setting depends on another setting which is stored somewhere else. During

runtime a value link is transparently resolved and substituted. In one

embodiment, settings containing value links may be combined with the feature

of computed values.

[0080] Because of this dynamic configuration approach (since configuration

templates may contain the system dependencies in a dynamic way (via

parameterized and computed settings)), there is no need to overwrite these

settings in the actual instance configuration. The system dependent

configuration dynamically adapts itself to the actual system environment.

Therefore, the engine runtime itself does not need any additional configuration.

It is already functional without overwriting any settings inherited from the

configuration template.

[0081] System installation provides delivered system database content including

J2EE configuration templates (these are the scenario based templates that are

meant to be deployed). Furthermore, the installation provides the file system

environment for each physical machine.

[0082] Instance installation provides the file system environment of the instance

and prepares the instance within the configuration database. When installing an

application instance, the instance installation itself does not know the particular

usage of the instance because of inheritance.

[0083] As described earlier, in an embodiment, the central configuration

manager is a tool which runs within a J2EE engine. The central configuration

manages the configuration of system landscapes via corresponding configuration

templates. The scope of a configuration template managed by the central

configuration is not only one instance or a group of instances of one system, but

a landscape of several systems.

[0084] In one embodiment, the J2EE engine configuration templates are

available as archive files (such as SDAs). These files are deployed into the J2EE

engine before installing and configuring J2EE instances. The central

configuration uses the J2EE configuration templates during instance

configuration by assigning the instance configuration to the appropriate J2EE

configuration template and generates a custom template for this J2EE

configuration template and assigns the instances to it.

[0085] During installation of an application instance, the usage of the instance is

not known. Therefore, during installation, an application instance is configured

via the "minimal instance" 205 configuration template. The minimal instance

configuration is sufficient to run the central configuration.

[0086] The central configuration is used to configure the instance for the specific

usage. During this configuration, the instance configuration (within the

configuration database) is assigned to the J2EE configuration template according

to the particular usage of the instance. The central configuration uses the API

(the configuration abstraction layer API) provided by the engine runtime in

order to assign the instance configuration to the particular configuration

template.

[0087] If this is the first instance within the system assigned to the selected usage

template, a custom configuration is created for the selected configuration

template. The custom configuration is derived from the selected configuration

template and the instance configuration is derived from the custom

configuration.

[0088] As the configuration templates provided within the J2EE engine are

system independent (by configuring the system dependent settings via

parameterized and arithmetic expressions) most of the settings are already

correct and do not need to be touched during instance configuration again. This

holds especially for instance layout, VM configuration, kernel configuration and

several system dependent application and service settings. Nevertheless, there

might be the need for customizing additional engine components.

[0089] An instance is essentially configured by traversing through the different

levels of abstraction (for example, highest to lowest) until the specific instance is

configured. Each level inherits the values of its parent and may overwrite these

values and therefore allows for the further customization of the

properties/ values.

[0090] Figure 6 illustrates an exemplary embodiment of a method to configure

an instance. At 601, the properties of the basic instance are acquired. This

defines the basic structure of an instance configuration for the entire system or

multiple systems.

[0091] At 603, the properties of the basic instance inherited and the

properties/ values of the basic instance customized are applied to the inherited

basic instance. As discussed earlier, this provides for further customization as

the basic instance customized provides a lower level of detail than the basic

instance. Of course, the properties/ values from the basic instance customized

take priority (overwrite) over the properties of the basic instance.

[0092] The properties/ values from the properties of the basic instance

customized are inherited and the properties/ values of the default template for

the specific use case and scenario deployed are applied to the inherited basic

instance customized at 605. Again, these values further narrow the values that

have already been defined/ refined by the basic instance and the basic instance

customized.

[0093] The properties of the default template inherited are inherited and the

properties/ values of the customized configuration template are applied to the

inherited customized configuration template at 607. Again, these values further

narrow the values that have already been defined/ refined by the basic instance,

the basic instance customized, and the default template.

[0094] Finally, the properties/ values of the customized configuration template

are inherited and the properties/ values of the configuration of the instance itself

are applied to the inherited properties/ values at 609. Again, these values further

narrow the values that have already been defined/ refined by the basic instance,

the basic instance customized, the default template, and the customized

configuration template.

[0095] As discussed above, certain of these properties/ values for the various

levels of abstraction are adjustable during runtime and others are preferably not.

Applying Filters with the Abstract Configuration Model

[0096] End-users and developers have different needs with respect to what

components should be available to use and/ or modify. Generally, it is best to

hide certain components from the all but expert end-users to prevent

modifications that would decrease the performance of the system. Through the

use of filters, individual or sets of components may be started or stopped.

Generally these filters are applied during startup, however, in an embodiment

filters may be evaluated at anytime. The filters may be stored locally using local

memory and/ or persisted in a database. In one embodiment, filters may also be

disabled.

[0097] As described earlier, a filter is a template which describes a set of rules for

starting or stopping. Filters are definable at each of the abstract levels 221, 223,

225, and 227. The combination of these levels creates a set of rules for starting or

stopping components in the system. In one embodiment, the filters from all the

levels are collected in a list and are resolved from the top to the bottom. Unlike

all the other settings in which the local value overwrites the inherited one, for

filtering this is not quite true because all the values are combined and evaluated

together. Of course, if there are contradicting filters in the different levels the

most bottom (less abstract) one will be executed. In an embodiment, the filters

are simply evaluated from the lowest level of abstraction to the highest level but

if there is a conflict between levels of abstraction, the lowest level still controls.

Additionally, more than one filter may be present for each level of abstraction.

[0098] These filters may be predefined (before system deployment) and changed

after deployment. Filters are not necessarily tied to any single syntax, however,

filters generally include at least the following attributes: action to be performed

(start or stop a component); component type (for example, service, library,

interface, application); vendor name; and component name. The type attribute

specifies the type of the component which this particular filter works on. The

component name attribute specifies the name of the component which this

particular filter works on. And the vendor name attribute specifies the name of

the component provider. For start or stop, all components that match the rule

are marked for starting or stopping respectively, including dependents.

[0099] In at least one syntax, at least the wildcard characters * and ? may be used

for to define at least one of the information in the syntax. The wildcard character

* is open-ended. For example, "sap*" means that the filter applies to anything

that begins with "sap" and "*" means that the filter applies to everything. The

wildcard character ? may be used as a place holder. For example, "s?p" means

that any string that begins with a "s" and ends with a "p" and is three characters

long is covered by the filter.

[0100] In one embodiment, the filter syntax is the following:

"action:component_type:vendor:name". Figure 10 illustrates the use of

exemplary filters in a model system. At the default level 221, filter 1001 is

defined as "start:*:*:*". This filter turns on all components of every vendor in the

system.

[0101] At the next level of abstraction 223, the filter 1003 is defined as

"stop:application:*:*". As this creates a conflict with filter 1001, this filter

overrides the filter 1001 and causes any application to be stopped. Every other

component type will still be started.

[0102] The filter 1005, at level 225, is defined as "stop:services:*:dsr". This filter

stops any service, by any vendor, with the name "dsr." The services that depend

on the dsr service will also be stopped. All other services will be started.

[0103] Finally, at level 227, filter 1007 is defined as

"start:application:microsoft:programl" and "start:service:s?p:dsr"(this is not on

the figure). This filter overrides all other proceeding filters with respect to

applications made by Microsoft and named "programl". It also overrides

services made by any company that begins with the character "s" and ends in

character "p" (and is three characters long) and is named "dsr". At this point, all

applications not made by Microsoft named "programl" are stopped; all services

named "dsr" not made by vendors complying with "s?p" are stopped; and every

other component is started.

[0104] The complete filter may be built during runtime. This allows for changes

to the filter to be updated "on-the-fly" to the system. This is advantageous if a

bug is discovered in a component and the component needs to be turned off for a

period of time without disrupting the rest of the system.

[0105] In an embodiment, the filter is constructed by building and evaluating a

graph. The graph is constructed by placing all components at a root level and

mapping dependencies. It is evaluated by walking (traversing) the hard

references between components (a hard reference indicating dependence) and

applying each rule to all components according to their dependencies.

[0106] Figure 11 illustrates an exemplary graph at a root level. This graph

includes four components: Comp_A 1101, Comp_B 1103, Comp__C 1105, and

Comp_D 1107. Comp_A 1101 has hard references to all of the other components

(it is dependent upon all of the components) and Comp_C 1105 has a hard

reference to Comp_D 1107 (Comp_C 1105 is dependent upon Comp_D 1007).

[0107] In this figure, if Comp_C 1105 is started by a filter, Comρ_D 1107 (and

only Comp_D 1107) must be started before (or at the same time as) Comp_C

1105. Because Comp_A 1101 depends on Comp_B 1103 and all others, each

component must start first (or at the same time) to start Comp_A 1101. Stopping

of individual components is done in a similar manner according to

dependencies.

System Information Abstraction

[0108] In prior systems, properties of software and hardware components in a

system were specifically crafted to a particular system and setup. For example, a

system configured with a Java VM for Microsoft XP Professional OS running on

a system with two CPUs and 1024 MB of memory would have properties crafted

for that exact configuration (and no other). This information would be stored at

a specific path in the system and would only be relevant for that particular

configuration. In other words, it was tied completely with that system. With an

abstract configuration model, this may not be efficient if the system configuration

could change or be ported to a different system.

[0109] Figure 12 illustrates an embodiment of configuration using abstract

system information. With this abstract system information configuration, an

individual component 1201 does not necessarily need to know that path

(location) of other components 1205 in the system. Instead, the components 1201,

1205 of the system use a system information module 1203 as an informational

proxy. This system information configuration allows for the location of a

particular property to be abstracted instead of hard coded to the system in each

node. For example "number of nodes" is not be taken directly found in each

instance, but instead is referenced from instances within the system to the system

information object.

[0110] For example, Component_l 1201 does not need to know where in the

structure that Component_2 1205 is located. It only needs to know that a value

that it needs may be obtained from system information 1203. Because dynamic

configuration is able to use parameterized settings instead of static values for

system dependent configuration, settings containing a link to other settings (for

example, a value link) may be used for cases where a setting is dependent upon

another setting which is stored somewhere else. During runtime the value link is

transparently resolved and substituted. With the parameterized value,

computed settings may be evaluated.

[0111] With the system informaiton object forward compatibility is easier to

achieve because all that need to be updated is the system information

configuration. For example, if the location or value of a property is changed only

the system information object 1203 needs to be changed and not each instance.

This will not affect all the components that refer the property, because they use

the value provided by system information instead of directly referencing the

component which the property belongs to.

[0112] The system information module 1203 may be a property sheet object (or

equivalent). A property sheet is a configuration that stores property like name-

value pairs such as system parameters, global constants, etc. A property sheet

may also include paths to specific components.

[0113] In one embodiment, a system information property sheet with initial

properties exposed in the system (like maximum heap size, number of nodes,

and number of threads) is created before all the components of the system

become functional. Additional properties can be exposed by template

deployment at runtime as described above.

File System Synchronization Using Bootstrap

[0114] The Cluster File System (CFS) is used for deploying a single file system

(FS) archive in multiple file systems in a cluster. The CFS serves as a repository

for the files deployed on the cluster. A bootstrap synchronizes the CFS

components in the FS of the cluster elements. Previous J2EE engine versions

stored the information in the FS archives only on the file systems of the cluster

nodes. Many times the data on the FS was deleted and it could be restored only

by redeployment. Additionally, the proper archive had to be found and

deployed. AU of this led to extended down-time for the system.

[0115] Figure 13 illustrates an exemplary file synchronization using bootstrap

configuration. Each system of the cluster 1337 (System_l 1301 and System_2

1335) contains a physical machine 1303, 1329 each having multiple instances

1305, 1307, 1317, and 1319; bootstraps per instance 1309, 1311, 1321, 1323; and

local file systems per instance 1313, 1315, 1325, and 1327. Of course it should be

understood that a system could have only one physical machine with varying

instance or bootstrap numbers, etc. In an embodiment, there is a single bootstrap

per physical machine. In another embodiment, there is a bootstrap per instance

and/ or file system.

[0116] Each local file system 1313, 1315, 1325, and 1327 includes a local

cache/ index that includes checksums and/ or version numbers of the archives

deployed locally.

[0117] A database 1333 includes a global cache/ index that includes checksums,

version numbers, and paths of the archives deployed in the system 1301. Of

course it should be understood that more than one database could store all or

part of this information. A CFS container 1331 includes a global counter that is

incremented each time an archive is deployed in the system 1301 and archives to

be deployed or already deployed.

[0118] Figure 14 illustrates an embodiment of a method for using a bootstrap to

synchronize a local file system with a CFS and database. At 1401, at least one

archive is deployed in a local system. In one embodiment, the file system

associated with that archive does not note the checksum and/ or version number

of this archive. In an alternative embodiment, the file system associated with

that archive notes the checksum and/ or version number of this archive. For

example, if an archive is deployed in system_l 1301, on physical machine 1303,

in instance 1309, the file system's 1313 local cache reflects this deployment.

[0119] At 1403, a database index is configured (or updated) to include the

checksums, version numbers, and/ or path of the archive deployed in the system.

The contents of the deployed CFS archive are also stored in the database. Upon a

change made in the system (database or CFS), the bootstrap associated with the

change compares the cache indexes its file system and the database for CFS

differences at 1405.

[0120] Depending on the results of the comparison, changes to the file system

are made at 1407 to synchronize the file system with the CFS and database. If the

bootstrap cannot read or process the data stored in the database, the CFS

component may not properly download into the file system. If there is new

component in the database and there is no information for this component on the

file system, then the component will be downloaded to the local file system and

the local cache/ index updated. If the CFS component was deleted from the

database, then it will also be deleted from the file system. If there is a component

in the database that has newer version or different content compared to the

component with the same name on the file system, the bootstrap will update the

content of the file system with this updated CFS. If the component on the

database is in different directory than the one on the file system, the bootstrap

will move the content of the CFS archive in the directory specified in the

database.

Closing Comments

[0121] Processes taught by the discussion above may be performed with

program code such as machine-executable instructions that cause a machine that

executes these instructions to perform certain functions. In this context, a

"machine" may be a machine that converts intermediate form (or "abstract")

instructions into processor specific instructions (e.g., an abstract execution

environment such as a "virtual machine" (e.g., a Java Virtual Machine), an

interpreter, a Common Language Runtime, a high-level language virtual

machine, etc.)), and/ or, electronic circuitry disposed on a semiconductor chip

(e.g., "logic circuitry" implemented with transistors) designed to execute

instructions such as a general-purpose processor and/ or a special-purpose

processor. Processes taught by the discussion above may also be performed by

(in the alternative to a machine or in combination with a machine) electronic

circuitry designed to perform the processes (or a portion thereof) without the

execution of program code.

[0122] It is believed that processes taught by the discussion above may also be

described in source level program code in various object-orientated or non-

object-orientated computer programming languages (e.g., Java, C#, VB, Python,

C, C++, J#, APL, Cobol, Fortran, Pascal, Perl, etc.) supported by various software

development frameworks (e.g., Microsoft Corporation's .NET, Mono, Java,

Oracle Corporation's Fusion etc.). The source level program code may be

converted into an intermediate form of program code (such as Java byte code,

Microsoft Intermediate Language, etc.) that is understandable to an abstract

execution environment (e.g., a Java Virtual Machine, a Common Language

Runtime, a high-level language virtual machine, an interpreter, etc.).

[0123] According to various approaches the abstract execution environment may

convert the intermediate form program code into processor specific code by, 1)

compiling the intermediate form program code (e.g., at run-time (e.g., a JIT

compiler)), 2) interpreting the intermediate form program code, or 3) a

combination of compiling the intermediate form program code at run-time and

interpreting the intermediate form program code. Abstract execution

environments may run on various operating systems (such as UNIX, LINUX,

Microsoft operating systems including the Windows family, Apple Computers

operating systems including MacOS X, Sun/Solaris, OS/2, Novell, etc.).

[0124] An article of manufacture may be used to store program code. An article

of manufacture that stores program code may be embodied as, but is not limited

to, one or more memories (e.g., one or more flash memories, random access

memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs,

EPROMs, EEPROMs, magnetic or optical cards or other type of machine-

readable media suitable for storing electronic instructions. Program code may

also be downloaded from a remote computer (e.g., a server) to a requesting

computer (e.g., a client) by way of data signals embodied in a propagation

medium (e.g., via a communication link (e.g., a network connection)).

[0125] Figure 15 shows an embodiment of a computing system (e.g., a

computer). The exemplary computing system of Figure 15 includes: 1) one or

more processors 1501; 2) a memory control hub (MCH) 1502; 3) a system memory

1503 (of which different types exist such as DDR RAM, EDO RAM, etc,); 4) a

cache 1504; 5) an I/O control hub (ICH) 1505; 6) a graphics processor 1506; 7) a

display/ screen 1507 (of which different types exist such as Cathode Ray Tube

(CRT), Thin Film Transistor (TFT), Liquid Crystal Display (LCD), DPL, etc.; 8)

one or more I/O devices 1508.

[0126] The one or more processors 1501 execute instructions in order to perform

whatever software routines the computing system implements. The instructions

frequently involve some sort of operation performed upon data. Both data and

instructions are stored in system memory 1503 and cache 1504. Cache 1504 is

typically designed to have shorter latency times than system memory 1503. For

example, cache 1504 might be integrated onto the same silicon chip(s) as the

processor(s) and/ or constructed with faster SRAM cells whilst system memory

1503 might be constructed with slower DRAM cells. By tending to store more

frequently used instructions and data in the cache 1504 as opposed to the system

memory 1503, the overall performance efficiency of the computing system

improves.

[0127] System memory 1503 is deliberately made available to other components

within the computing system. For example, the data received from various

interfaces to the computing system (e.g., keyboard and mouse, printer port, LAN

port, modem port, etc.) or retrieved from an internal storage element of the

computing system (e.g., hard disk drive) are often temporarily queued into

system memory 1503 prior to their being operated upon by the one or more

processor(s) 1501 in the implementation of a software program. Similarly, data

that a software program determines should be sent from the computing system

to an outside entity through one of the computing system interfaces, or stored

into an internal storage element, is often temporarily queued in system memory

1503 prior to its being transmitted or stored.

[0128] The ICH 1505 is responsible for ensuring that such data is properly

passed between the system memory 1503 and its appropriate corresponding

computing system interface (and internal storage device if the computing system

is so designed). The MCH 1502 is responsible for managing the various

contending requests for system memory 1503 access amongst the processor(s)

1501, interfaces and internal storage elements that may proximately arise in time

with respect to one another.

[0129] One or more I/O devices 1508 are also implemented in a typical

computing system. I/O devices generally are responsible for transferring data to

and/ or from the computing system (e.g., a networking adapter); or, for large

scale non-volatile storage within the computing system (e.g., hard disk drive).

ICH 1505 has bi-directional point-to-point links between itself and the observed

I/O devices 1508.

[0130] In the foregoing specification, the invention has been described with

reference to specific exemplary embodiments thereof. It will, however, be

evident that various modifications and changes may be made thereto without

departing from the broader spirit and scope of the invention as set forth in the

appended claims. The specification and drawings are, accordingly, to be

regarded in an illustrative rather than a restrictive sense.