Deployment Flow 

When an application is deployed to the portal, the following occurs:

·        The application is deployed to the Application Repository, as described in Deployment into Application Repository.

·        A copy of the application is written to each server node in the cluster, as described in Deployment to Local Servers.

Deployment into Application Repository

The following describes the steps the PRT takes when you deploy an application:

·        The application is placed in the PCD at par:/archives/<application_name>.

·        The deployment descriptor is extracted and placed in the PCD at par:/application/<application_name>.

·        Entries for the security zones defined in the application are created, if necessary, in the PCD at par:/security/<vendor>/<security area>/<safety level>.

·        Any resource bundles are stored at par:/resource_bundles/<application_name>.

·        The servers in the cluster are notified that a new application has been deployed.

Deployment to Local Servers

After an application is deployed to the Application Repository, all servers in the cluster are notified. The following lists the steps in deploying a copy of the application to each server:

·        If a previous version of the application is loaded, this instance is dropped. All instances of applications, components and services that depend on the new application are also dropped.

Applications can be marked as non-releasable in their deployment descriptor, but this only protects against dropping instances of the application’s components and services in case the VM runs low on memory.

No matter the setting of this flag, the components and services are dropped when the application is redeployed.

·        The application is unzipped and copied to the local server.

·        All portal applications that were dropped are restarted.

·        All services in the application that are marked to be started when the portal is started are restarted.

How Objects are Instantiated

...

       1.      When a component or a service of a portal application is accessed, The object broker checks whether the object is already available and returns it, if available.

       2.      If the object is not available, the broker tries to get it from the local deployment. The broker checks the revision number of the application to make sure the local deployment is up to date, and then loads the class and instantiates the object, if the local version is up to date.

       3.      If the local version is not up to date, the new version in the application repository is deployed on the local file system, and the object broker then loads the class and instantiates the object.

The portal application runs and remains in the memory unless a new version is deployed or an administrator decides to release the application. The system can also discard portal application instances when the Java VM needs to free up memory.

Deployment Policy (Enterprise Portal 5.0)

The DeploymentPolicyproperty of a component’s configuration determines whether the local deployment is deleted during deployment. The property’s value can be one of the following:

·         5.0: The deployment is backward compatible with Enterprise Portal 5.0. The old folder is not removed and the deployment process simply adds the new content to the folder.

·         Blank: A standard deployment is performed. The old deployment folder is removed and and replaced by the a new one with the new content.

The deployment assumes that the application stores configuration in the application repository, and not locally.