Java Applications in the VM Container 

Concept

The task of the VMC application server is to receive requests from clients and to send responses back. A request is processed by a handler, which is part of an application.

A component is a Java application with required libraries, saved in the database or file system. The component consists of Java classes and files that are integrated in modules.

A module is a deployable unit.  As a set of files it corresponds to a Java archive (.jar-file) or directory.

An activation is a running component that uses resources (for instance, the cache), and has a life time limited by the deployment of a new version of the application.  Once the lifetime has expired, resources are freed up again. An activation can be used by all the VMs belonging to the same instance. Each request is always processed by one handler only in one VM, and for this reason is called a local VM object.

The deployment of a component into the database can be performed asynchronously from any application server. If the same component is deployed again, it is saved in the database as the new version with a timestamp. The old version remains supported for as long as it is needed by activations that are still in use.

The application administration in the VM Container fulfills the following requirements:

●     Applications are deployed asynchronously and non-destructively into the database.

●     Application servers can load and delete applications. You can identify recently deployed applications and find out the latest status of the database.

●     Separated class loaders guarantee that activated applications run in isolation, which means that Java classes belonging to different versions of an application cannot be mixed up.

●     Application code runs in a Java VM context. The specific VM in which the application is running is not important for the application in the VM Container. For the application the VMC behaves almost like one single Java VM.

●     An application itself determines which objects it wants to share with other applications. The VM Container has no specifications.

Design

Component

A component is a named unit consisting of modules. The name is in the form: /namespace/name, whereby the namespace can be a maximum of eight characters long, and the name a maximum of 30 characters long (case-insensitive). The standard namespace /0CUST/ is valid for names beginning with Y or Z, and /0SAP/ is valid for all other names.

Module

A module is a deployable unit containing resources and bindings. The modules are seen as development units in the system, and can be transported separately. For this reason modules across the system (beyond component boundaries) must be assigned unique names. The format of the module name is the same as it is for components.

Resources are standard files with names of any length (for instance, Java class files).

A module is a collection of resources corresponding to a jar-file or directory.

Binding

Bindings are used for finding the correct request for a handler. The name identifies the request (for example, the name of the function module called), and the value of the binding normally identifies the Java class name of the handler.  

A binding is a name/value pair, whereby the name is a seven bit ASCII string and the value is a multiple string (one or more strings separated by commas). Bindings are located in text property files, which are the resources of a module.

Data Flow

Database Organization

The components are kept in various database tables. Runtime tables are used for loading classes and looking up bindings. Transport tables are used for importing from, and exporting to, other systems.

Runtime Tables

Components are stored in database tables.

Since each module has a timestamp, the database can be displayed in layers. Each timestamp forms one layer.

There are two versions of module A=/0SAP/TEST (including all resources and bindings). The first has been saved with timestamp T1, the second with T2.

The application server knows the timestamp of the component it wants to activate. It can see all the latest modules that have an older (or the same) timestamp.

So the database always contains the latest version of each module for a timestamp. This example shows modules A, B, and C belonging to a component.

Time Stamp	Module A	Module B	Module C
T1	v.1		v.1
T2	v.2
T3	v.3	v.1	v.2
T4		v.2
...	...	...	...

The application server knows the timestamp t of the component it wants to activate. It can see all the current modules whose time stamps are smaller (older) or equal to t. In this example, if t =T2, the application server would activate version 2 of module A and version 1 of module C. The component does not have module B.

Transport Tables

Transport tables are needed for importing modules from, and exporting modules to, other SAP systems. They are not used for loading classes and are not integrated in the time stamp layer model.

Transport tables are modified during deployment together with runtime tables. When modules are transferred from other systems, they are written to transport tables, which are then used as the data source for integrating the modules into runtime tables.

Operations

The following database operations are used for components:

●     Deployment, including the import of patches and deletion of applications.

●     Integration

●     Compaction

These operations are implemented as SQL transactions.

Deployment

Deployment is then used for installing modules directly into the system (in contrast to importing a transported module).

The deployment transaction enables the following actions:

●     Deployment of entire components

●     Patches from individual modules of a component

●     Deletion of components and modules

The deployment transaction changes runtime and transport tables. With transport tables, for all operations the existing modules are physically deleted from the table, and new components or patches are inserted where required.

With runtime tables modification is non-destructive. No data records are deleted because other application servers may need to access them if the associated application is still running. Only data records with new timestamps can be added. Deletion is simulated by adding “empty" modules. Modification works as follows:

●     When a component is deployed, all existing non-empty modules except for those to be deployed are hidden. A new timestamp is added to the modules to be deployed.

●     To add a patch, a new timestamp is simply inserted into the module.

●     When a component is deleted, all of its non-empty modules are hidden. 

Integration

Integration is used for importing transports into the system.

The integration transaction copies imported modules from the transport table into the runtime tables.

Compaction

Due to the non-destructive procedure in the runtime tables, these increase in size. Compaction removes old modules no longer used by any application server.

Further Information

Life Cycle of Running Applications

VMC system administration (SM53): Displaying Applications