Changing Components States 

Purpose

The starting point of the process is the state missing, that is, the component classes are not deployed on the SAP J2EE Engine. Changing the state of components is related to the system performing certain actions, in order to ensure the consistency of the components in the next state.

The deployment process is performed by the deployment utilities that the SAP J2EE Engine provides. Transition between states beyond “deployed” state is managed exclusively by the Service Manager.

Process Flow

Starting Components

       1.      Deploy

The system checks if the name of the component is unique. Components of the same type must have unique names. Components of different types can have the same name. To be deployed, the component must be packaged correctly, as described in Developing Services. After deployment, the system registers the component in the persistent registry.

       2.      Resolve

In this step, the system checks if all components that are referenced by a particular component are available. The algorithm is as follows:

                            a.      For each component, the system checks whether all referenced components are deployed. If true, the current component is marked as “temporarily resolved”. If not true, its status becomes “not resolved”.

                            b.      For each component with the state “not resolved”, the system checks if it is referenced by a component that is marked as “temporarily resolved”. If it finds any components, it changes their state from “temporarily resolved” to “not resolved”, and applies the same check to them.

                            c.      The system finds all components marked as “temporarily resolved” and changes their state to “resolved”.

       3.      Load

In this step, the system registers the components class loaders and loads all components that were resolved in the previous step. For library components, this immediately means they are in “active” state.

       4.      Start

This step applies to services only. The system starts them asynchronously using the following algorithm:

                            a.      For each service, it checks whether all services and interfaces that are referenced by strong references are “active”. If true, the system calls the startmethod of the service. If the startmethod executes successfully, then the service is marked as “active”. If the service implements any interface components, they are marked as “active” too. If the start method fails, the system marks the service and any interface components that it implements as “not active”.

                            b.      If the service has a strong reference to a service or interface that are “not active”, then the current service and all interfaces it implements are marked as “not active”.

Stopping Components

This process aims at changing the state of a component from “active” to “deployed” (or “missing”).

...

       1.      Stop

This step refers to services only. The system checks if there are any services that have a strong reference to the current service, or any of the interfaces that it provides. If it finds any, it first attempts to stop them (by applying the same algorithm to them).

The system sends a beginServiceStop synchronous event. The idea behind this event is that it informs other components with a weak reference to the current service to release their references.

At the end, the system calls the stopmethod of the service and marks its state as “loaded”.

       2.      Unload

In this step, the system must first unload all other components that have a weak reference to the current one. If the referencing component happens to be a service, it must be stopped before it is unloaded. It is stopped using the algorithm of the previous step.

The system sends a beginComponentUnload synchronous event. This event is important for components that have a notify reference to the current one.

After the event is processed, the system unregisters the component class loader.

       3.      Unresolve

In this step, the system checks if there are any components that have a strong or weak reference to the current one. If it finds any, it first marks them as “not resolved”, and then sets the “not resolved” state to the current component.

       4.      Undeploy

The system first sends a beginComponentUndeploy synchronous event. When the event is processed, the system removes the component classes from the persistent storage.