As a system, the J2EE Engine consists of three logical layers:
1. Java Enterprise Runtime – comprised of low-level subsystems that provide functions such as class Loading, cluster communication, persistent configuration data management, etc.
2. J2EE Engine components – consists of interfaces, libraries and services components that provide various runtime functions and programming APIs
3. Applications – refers to the applications that are deployed and run on the J2EE Engine
The J2EE Engine architecture is based on the following general rule: components from the higher level can use components from lower level; whereas components from the lower level are not aware of the APIs of the components from the higher level and therefore cannot use them.
This rule is reflected by the starting order of the system modules: runtime is first, then services (libraries) are loaded, and interfaces resolved at this phase), and lastly, applications. The system is considered functional when all runtime managers and core services components are started in the proper order.
Components from the higher level use a set of defined APIs to utilize the functions of the components from the lower level. The J2EE Engine components use the Framework APIs to connect to the SAP Java Enterprise Runtime. Applications use the J2EE Engine components by the APIs that are defined by J2EE 1.3 Specification (and supporting specifications) and SAP-proprietary APIs.
SAP J2EE Engine Architecture
The J2EE Engine components build the second level of the system. Built on top of the runtime and able to communicate and use each other, these components form the complete system infrastructure to run both J2EE and SAP proprietary applications.
Three types of J2EE Engine components are defined:
1. Interfaces – “contracts” that define how different components of the system work together. These components do not provide any runtime functions. At runtime, they provide the system with their name and classes (no objects). They are used by services components that provide their implementation. Interface components can also be implemented directly by applications.
2. Libraries – 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. Other library components or services components typically access those using static methods.
3. Services – more powerful than the other two types of components. They provide the system with their name, classes and runtime objects. The runtime objects are registered on the system once the components classes have been loaded. Service components can access and utilize functions of the runtime through the Framework API.
Service Manager Architecture
A Java cluster installation consists of:
• One or more instances of the AS Java
• The Central Services, which also form an instance
• One or more databases
The dispatchers and servers can be split up among different physical servers. The Central Services (Message Service and enqueue service) are installed on a host that meets the requirements for high availability.
Java Instance
A Java instance is a unit in the AS Java cluster which can be individually started, stopped, and monitored. The cluster elements that form an instance run on one physical machine. It is also possible to run several instances on one physical machine. An instance is identified by the system ID (SID) and the instance number. Central Services are a special example of a Java instance.
Another special instance is one that runs the SDM (Software Deployment Manager). This instance usually runs with the database and Central Services on the same machine, and is then indicated as the central instance.
A Java instance normally is comprised of one Java Dispatcher and several server processes. A Java instance is started and stopped by the Java Startup and Control Framework. An HTTP request to execute a servlet runs through several layers in the J2EE engine. The Java dispatcher receives the request, selects a server process for the processing and establishes the connection from the client to the server.
Minimum Cluster Installation
The following graphic shows the simplest installation of usage type AS Java. A system installed in this way can only process requests to Java applications.
This minimal AS Java installation consists of:
• A Java central instance with a dispatcher, a server process, and Software Deployment Manager (SDM)
• The Central Services instance
• The Database
A Java Instance consists of (with the exception of Central Services):
• A Java Dispatcher
• One or several server processes
Minimum Cluster Installation
The SAP J2EE Engine provides the following basic administration options:
Offline – enables the configuration and administration of J2EE Engine cluster elements when the server is not running
Online – enables the administration of J2EE Engine cluster elements at runtime
Remote – enables configuration of the J2EE Engine from a distance; that is, the administration tool runs on one machine and the server that must be managed is running on a different machine.
These options are implemented in the administration tools for the J2EE Engine: Visual Administrator, Shell Console Administrator, Config Tool and SAP Netweaver Administrator.
Visual Administrator
SAP J2EE Engine Visual Administrator is a graphical user interface (GUI) that enables administration of the entire cluster, cluster elements, and modules running on them. It provides remote monitoring and management of managers, services, libraries, and interfaces working on each element in a single GUI.
Visual Administrator enables:
- Obtaining general information about a service, manager, interface or library (for example, its
name, group, and so on)
- Logging on to the SAP J2EE Engine via the Visual Administrator tool
- Administrating and changing common properties or those specific to a service or manager
- Runtime administration and control
- Configuring the global properties
To start the Visual Administrator, enter the following command:
“/usr/sap/<SID>/<Instance Name>/j2ee/admin/go.sh”
Shell Console Administrator
The J2EE Engine Console Administrator is an alternative to the Visual Administrator. Unlike the Visual Administrator, it is not a GUI and the runtime control and administration is done using specific commands in the shell language. The commands are entered on the command line of the console where the cluster element is running. This tool enables monitoring of the processes started on the different elements of the cluster and provides an opportunity for prompt and adequate reaction whenever problems occur. The Console Administrator enables remote administration through Telnet clients or applets that simulate a Telnet client, as well as continuous deployment of applications and additional libraries.
By default, the Telnet shell is opened on the dispatcher. Once connected, the user can access and use all shell commands available on the different J2EE Engine cluster elements. Use the LSC command to display all server components with their ID, component name, host, port, and type. The first component displayed is the current one. To pass over from one component to another, use the JUMP command and specify the ID of the target element. For example, executing jump 4001 enables the remote administration of a cluster element with ID 4001.The JUMP command is available for Telnet administration only. To close the Telnet connection type exit on the command line.
To connect to the J2EE dispatcher, enter the following command:
“telnet hostname telnet_provider_service_port” or, as an example: “telnet ibm_node_01 50008”.
ConfigTool
The Config Tool enables offline configuration of the J2EE Engine cluster elements. It is XML-based and allows the user to export for later use. When working offline, it is not required to have a SAP J2EE Engine running, as the Config Tool connects directly to database and applies the changes. When running the J2EE Engine Config Tool via a GUI or text-only interface, it connects to the database and scans the server configuration. The information provided is passed to the corresponding interface that is used for configuration.
The J2EE Engine GUI Config Tool enables configuration of J2EE Engine cluster elements concerning
properties, adding new elements, and exporting the system configuration to an XML file.
After installing the J2EE Engine a configtool directory is created, containing a Config tool script file.
To start the GUI ConfigTool enter the following command:
“/usr/sap/<SID>/<Instance Name>/j2ee/configtool/configtool.sh”
SAP Netweaver Administrator
SAP NetWeaver Administrator (NWA) is a new Web Dynpro-based tool for administration and monitoring, offering a central point of entry point into the SAP NetWeaver system landscape. The SAP NetWeaver Administrator can be used in a central scenario, where it is capable of operating an entire system landscape containing ABAP and Java systems as the application platform of SAP NetWeaver. The NWA unifies the most important administration and monitoring tools both for Java and ABAP systems. The most important advantages of the NWA are:
• No longer need to switch between different tools for administration, troubleshooting and problem analysis of SAP NetWeaver system landscape
• Central administration tool available landscape-wide for both Java and ABAP systems, for starting
and stopping instances, checking configuration settings and logs, and monitoring error-free functioning of components
• Interface follows the current guidelines for interface design, is easy-to-use, task-oriented and complete. Web Dynpro runs in a normal web browser
• Interface allows seamless navigation to other SAP NetWeaver administration tools (User Management Engine, System Landscape Directory)
• For Java, the NWA represents a crossover from various expert tools to an integrated, simple and clear solution. The NWA also completes the integration of the data sources for monitoring
• For ABAP, the NWA represents a crossover from many different expert transactions, which are difficult to use and integrate
To connect to the Web Administrator, open a following http page:
“http://<fully qualified hostname>:50000+(100 * instance number)/nwa”
The Software Deployment Manager (SDM) is a tool to deploy and manage software packages from SAP. SDM resides in the SAP Web Application Server. The SDM is responsible for installing and updating software components into the SAP J2EE Engine. It also provides modification support on demand. Each time a new component version is deployed, the CBS consults the SDM on the target system. This process can be initiated via the SAP NetWeaver Developer Studio.
Software Deployment Archive (SDA)
The Software Deployment Archive (SDA) is the delivery format for SAP applications in programming
languages other than ABAP. It is a ZIP-compatible archive format that can be used as a container for other archives. The SDA contains the manifest information - that is, package-related data - of its archives (such as jar, war) and an SAP manifest, which contains additional software logistics information.
The EAR archive is a special case in the J2EE context. If an EAR archive contains a SAP manifest, it is
also a SDA. The SDM recognizes the EAR archive as a SDA, but does not rename the archive extension as <archive_name>.sda. SDA is the smallest unit that can be deployed. Furthermore, the SDA is the smallest unit for which patches can be created and delivered.
Software Component Archive (SCA)
A Software Component Archive (SCA) is the physical representation of a version of software
component. It contains a specific number of SDAs, whose quantity describes a precisely-defined version level. A SCA update always results in a new version level of the software component.
Deployment
The deployment is the final step in the software delivery process; it involves the deployment of available software packages - SDAs or SCAs - in the runtime environment of the SAP Systems.
When deploying SDAs/SCAs, the Software Deployment Manager stores the data in the SDM Repository, from where it then manages the installed archives. The SDM recognizes dependencies between archives and provides support when installing and maintaining shared applications.
The SDM uses the Deployment Manager to control the deployment of SDAs/SCAs for the following –
· J2EE applications
· File system content
· Database content
· SAP J2EE Engine Additional Libs
To start the SDM GUI tool, enter the following commands:
“/usr/sap/<SID>/<Instance Name>/SDM/program/StartServer.sh” (if server not started),
“/usr/sap/<SID>/<Instance Name>/SDM/program/sdm.sh remotegui”.
