AS JAVA Architecture & Start - Stop Process

AS Java Cluster Architecture

An AS Java cluster consists of several types of instances, each one of which has an instance number and can be started, stopped and monitored separately. They are

1.        Central services instance

The central services instance consists of a Message Service and Enqueue Service. They are responsible for lock administration, message exchange and load balancing within the Java cluster.

2.        One or more Java instances

A Java instance consists of an Internet Communication Manager (ICM) and one or several server processes. The ICM handles requests coming from clients and dispatches them to the available server processes, which actually process the requests.

3.        Database

The database stores system and application data. There is one central database. It is also possible to have several application databases.

Minimum AS Java Cluster Installation:

Large AS Java Cluster Installation:

Java Instance:

A Java instance is a unit in the AS Java cluster which is identified by its instance number. The elements that form an instance run on one physical machine. Also, it is possible to run several instances on one physical machine, but it is recommended that you split the different instances among different physical machines.

 

A Java Instance consists of:

1.Internet Communication Manager (ICM)

2.One or several server processes

Internet Communication Manager:

The ICM is an element of the Java instance which handles requests coming from clients and dispatches them to the available server processes. Data is transferred from the ICM to the server processes and vice versa using the Fast Channel Architecture (FCA), which allows fast and reliable communication between them.

 

The ICM reads the request from the TCP/IP stack into the FCA, decides which server process should handle the request (load balancing), and then sends the requests directly to the individual process. The required information for load balancing is retrieved by the ICM from the Message Service.

 Server Process:

The server processes of AS Java actually execute the Java application. They are responsible for processing incoming requests which are assigned to them by the ICM.

Each server process is multi-threaded and can therefore process a large number of requests simultaneously.

 

Server processes in an instance have a shared memory which enables much faster interaction. In the shared memory, server processes and the ICM store all their monitoring information, which can be used for detailed analysis of the current internal status of each Java instance.

 

SAP Java Virtual Machine (SAP JVM):

 

Java Virtual Machine (JVM) 

Java Virtual Machine (JVM) is a hypothetical machine over which Java code runs. It provides an interpreter used for execution of the compiled Java code (Java byte code). Java Byte code is special kind of machine language which could be run on any platform provided a JVM compatible to that platform is installed on that. It also makes Java platform independent (Write Once Run Everywhere).

SAP JVM

SAP delivers its own Java Virtual Machine (JVM) with SAP NetWeaver 7.1 release and is called SAP JVM. It is developed for robust, scalable and high performing SAP NetWeaver Application Servers and It offers a very strong and reliable foundation for the whole SAP NetWeaver Java stack. For the features of new Java EE 5 environment refer weblog

Central Services Instance:

Central services form the basis of communication and synchronization for the AS Java cluster. They are responsible for lock administration, message exchange, and load balancing within the cluster.

Central services run on one physical machine and constitute a separate instance. This SAP Central Services Instance (SCS) comprises the message server and the enqueue server.

Message Server The message server keeps a list of all server processes in the AS Java cluster and provides information about their availability to Internet Communication Manager (ICM). It also represents the infrastructure for data exchange between the participating server processes.

The message server is responsible for the following tasks in the AS Java cluster:

Notification of events that arise in the cluster, for example when a server process is started or stopped Communication between different server processes Forwarding of messages and requests to all participants

 

Note

The central services are always required when an AS Java cluster is installed. The central services instance has its own instance number.

The SAP start service ( sapstartsrv(.exe))starts the SCS instance first. When the central services are running, the other Java instances are started.

 

Message Server

The message server keeps a list of all server processes in the AS Java cluster and provides information about their availability to Internet Communication Manager (ICM). It also represents the infrastructure for data exchange between the participating server processes.

 

Enqueue Server

The enqueue server manages logical locks. The enqueue server runs on the Central Services instance of the Java cluster. It manages the lock table in the main memory and receives requests for setting or releasing locks. It maps the logical locks to the database.

 The enqueue server has the following tasks:

• Internal synchronization within the AS Java cluster.
• The applications can lock objects and release locks again. The enqueue server processes these requests  and manages the lock table with the existing locks.

Locking in AS Java: Architecture:

Each server process of the AS Java is controlled by the Startup Framework, which is started by the start service. As far as locking is concerned, an AS Java server process contains the following layered components:

·         JENQUEUE library

This library is the basic layer which holds a TCP/IP connection to the enqueue server and contains the functions used to operate the enqueue server.

·         Locking Manager

The Locking Manager is one of the basic managers of AS Java and provides the Java classes and methods to set,

release, and manage locks.

·         Application Locking Service

The Application Locking Service is based on the Locking Manager and implements the interfaces which are used by JEE applications running on AS Java.

·         Locking Service

The Locking Service is based on the Locking Manager and provides administration functions to the SAP NetWeaver Administrator. The functions can also be executed using shell commands.

    Startup Framework, SAP start service and SAP Management Console

The start service starts the SCS instance and the Startup Framework for AS Java, which itself starts the server processes. The start service provides a Web service interface for the SAP Management Console / SAP MMC to provide monitoring and administration functions.

In addition, the Startup Framework can remove dangling locks after an uncontrolled shutdown of the server process. To do this, the jstart process connects directly to the enqueue server

Cluster Communication in AS Java: Architecture

Communication within the Java cluster is triggered by the Cluster Manager. If a server process wants to send a message or data, this is arranged by the Cluster Manager, which connects to the Message Server.

The Message Info Service is the administration interface which enables the administrator to manage message server functions and cluster communication with the SAP NetWeaver administrator.

 Cluster Manager - manages communication between elements in the AS Java cluster. It updates the information about the status of each cluster element and the services running on it.

AS Java System Architecture

The AS Java system consists of three logical layers:

Java Enterprise Runtime - comprises low-level subsystems that provide functions such as class loading, cluster communication, persistent configuration data management, and so on.

 
AS Java System Components - consists of facades, interfaces, libraries and services components that provide various runtime functions and programming APIs.

Applications - refers to the applications that are deployed and run-on AS Java.

 

 

Order of starting the system modules:

The runtime is started first, then the services (the libraries are loaded, the interfaces resolved at this phase), and the applications are started last. The system is considered as started when all runtime managers and core services components are started properly.

 Java Enterprise Runtime 

The Java enterprise runtime provides the core functions of the system. It is made up of several low-level subsystems containing manager components which provide the infrastructure and runtime to support the upper layer of the AS Java system components.

The Java enterprise runtime provides a number of key concepts which significantly enhance the robustness, stability and supportability of the AS Java, such as central cache management and session management.

 Cluster Communication

AS Java cluster elements communicate via cluster messages. The system is able to send messages to one cluster element, to a group of elements, or to all elements in the cluster. Cluster elements use messages to broadcast notification events. The Cluster Manager is responsible for managing this communication.

 Cache Management

The AS Java uses a central cache management to better control the memory consumption of the components' caches. It provides a complete cache framework - the Cache Management Library (CML) - which drastically reduces the overall memory footprint of the system. This lower memory footprint results in the capability of running more VMs.

 Session Management

AS Java has a central session management which provides the following features:

• Enhanced control of the sessions in the server
• Enables a session failover safety mechanism

In general, sessions are used to keep the state of a user accessing an application between several requests. The AS Java architecture provides a reduced number of sessions per VM, which is achieved through separating the inactive user sessions from the active user sessions and reducing the number of sessions stored in a VM.

 Thread Management

The AS Java thread management system provides common handling, maintenance, configuration, error processing, and monitoring for the thread resources used for execution of parallel system and application requests. The thread management system comprises two thread managers which handle the system and application operations separately. The Thread Manager supplies threads for the AS Java system operations such as framework tasks, system events handling, and services management, while the Application Thread Manager supplies threads for application requests processing.

 

AS Java System Components

Facades - they simplify the relationships between SAP NetWeaver layers and client applications. Facades are the only

official way for clients to access the AS Java API.

 

Interfaces - they define how different components of the system work together. At runtime, they provide the system with

their name and classes (no objects). They are used by services components that provide their implementation.

 

Libraries - they provide name, classes and objects to the system. These objects are created by the system when it loads the library, or when an object is first requested. Libraries are not active components - they have no definite life cycle, do not allocate resources themselves and do not keep any kind of configuration information in the system. Other library components or services components usually access them using static methods.

 Services - they provide the system with their name, classes, and runtime objects. Services are active components with a definite life cycle. They can allocate resources at their startup time and are responsible for releasing them at shutdown time. There are core services which provide the core functionality and should always be running, otherwise the system will stop. The rest of the services provide additional functionalities and are not required for the operation of the system.

  

Architecture of the Java Startup Framework

This section contains a detailed description of the components of the Java Startup Framework, their interaction and communication, and the architecture of the Java Startup Framework. You can follow the steps when starting, monitoring, or stopping an AS Java instance.

Structure

The Java Startup Framework is implemented in the JSTART program.

The JSTART program has two roles:

• When running as the Java instance controller, JSTART starts, stops, and monitors the processes of a Java instance (the ICM process and several Java server processes). In this role, JSTART provides a local port for command communication and implements the SAP signal handling to stop the instance.
• In the role of a server process, JSTART connects to the Java instance controller before loading the Java VM into its address space. It then starts the AS Java code and represents the Java server process. The program can receive commands from the Java instance controller and reports the status of the Java server to the instance controller. A Java server process stops immediately when it detects that the Java instance controller has terminated unexpectedly.

Administration and monitoring of Java Startup Framework with the command line program jsmon

jsmon pf=<path to profile> from the command line

Startup, Operation and Shutdown of an AS Java Instance

With the Java Startup Framework you can start, monitor, and stop a Java instance and its processes. This means you can:

• Start, stop or restart processes
• Stop or restart the whole instance
• Terminate hanging processes

The JSTART program is part of the standard delivery.

Process

Startup of the Java Instance

The following steps are involved in starting the Java instance:

1.    JSTART is started (in Windows by the SAP Start Service; on UNIX platforms by the startsap script). It takes the role of the Java instance controller.

2.    The Java instance controller analyzes its configuration (from the instance profile) and examines the details of the Java SDK defined there.

3.    The Java instance controller initializes SAP signal handling to be able to receive signals and opens the control port.

4.    The Java instance controller reads the instance description (from the list of files specified by the jstart/startupNodeFiles and jstart/instanceNodeFiles profile parameters) for the first time, searching for nodes with a runLevel=1 property. The OFFLINE DEPLOYMENT node in the startup.properties file matches this criterion.

5.    The Java instance controller starts another JSTART process with the parameters from the OFFLINE DEPLOYMENT node and waits for the child process to terminate.

6.    The child process acts as a Java process. It loads the Java Virtual Machine (JVM) into its own process, initializes the JVM and starts the OFFLINE DEPLOYMENT program, which performs the deployment steps in the Java database.

7.    The Java instance controller reads the instance description again, searching for nodes with a runLevel=2 property. The BOOTSTRAP node in the startup.properties file meets this condition.

8.    The Java instance controller starts another JSTART process with the parameters from the BOOTSTRAP node and waits for the child process to terminate.

9.    The child process loads and initializes the JVM and starts the BOOTSTRAP program. BOOTSTRAP synchronizes the binary data in the Java database with the local file system, reads the Java instance description from the Java database and updates the instance.properties file.

10. The Java instance controller reads the instance description from the startup.properties and instance.properties files once more, this time focusing on nodes with a runLevel=3 property or without a runLevel property at all. These nodes form the productive instance.

11. The Java instance controller starts the processes for infrastructure nodes, such as ICM or DEBUGPROXY.

12. When all infrastructure processes are started, the Java instance controller starts the processes for the server nodes.

13. The JSTART child processes act as Java processes and execute a similar sequence as described before. They become the Java server processes.

The following figure shows the sequence of actions that the Java Startup Framework executes.

Operation of the Java Instance

The Java instance controller monitors the Java instance. It receives the status update messages and catches termination signals from the child processes. When a process terminates unexpectedly, the Java instance controller starts the process again.

Shutdown of the Java Instance

Signals and commands sent to the control port trigger a Java instance to stop. The Java instance controller ensures that the order of shutdown is obeyed and forces termination if a process does not stop within the shutdown timeout period.

The figure below shows the sequence of the actions.

An instance is stopped as follows:

1.    A process (for example, the ABAP dispatcher, a start script or SAP Start Service) sends a SIGINT signal or an appropriate command to the Java instance controller.

2.    The Java instance controller updates the instance state and sends STOP commands to the server processes.

3.    When the server processes are finished, the Java instance controller sends STOP commands to the infrastructure processes.

4.    Once all child processes have exited, the Java instance controller terminates