Table of Contents
This chapter describes the components of JEUS and the services they provide.
The following are the key components of JEUS.
A domain consists of a single domain administrator server (hereafter DAS) and one or more managed servers (hereafter MS).
-
Domain
Domain is a group that manages servers and clusters. Refer to "JEUS Domain Guide" for more information about domains.
-
Multiple MSs can exist in a domain. An MS runs user-deployed applications, and provides services required by the applications.
The following are the main services of MS.
-
EJB, WEB, JMS engine service
-
JNDI service
-
Management service
-
Security service
-
HTTP session clustering service
-
Transaction service
-
Database (hereafter DB) or EIS (Enterprise Information System) connection service
-
Scheduler and other services
-
Note
For more information, refer to JEUS Domain Guide. "2.2. Domain Composition".
DAS is a server that manages a domain. Only one DAS can exist in a domain. It manages domain configurations, and manages and controls applications running in the domain. It also manages MSs in the domain.
Note
For more information, refer to JEUS Domain Guide. "1.3.1. Domain Administration Server(DAS)".
The following services are the major services that can only be used in DAS. These services can only be executed on DAS because they have to be managed in domain units. The following services can be used through WebAdmin or the console tool (jeusadmin) by connecting to DAS.
-
WebAdmin is a web-based management console that the users can use to manage servers and applications more easily. For more information about WebAdmin, refer to "JEUS WebAdmin Guide".
WebAdmin is deployed to DAS as a web application. Even if WebAdmin is not deployed, DAS can start up normally and jeusadmin can be used to control and provide services.
-
Dynamic configuration reloading service
DAS supports dynamic reloading of domain configurations on all servers in the domain. Domain configurations can only be changed by DAS.
WebAdmin or the console tool can be used to execute commands. A lock must be obtained from the dynamic configuration reloading service to change the domain configurations. After the configurations have been changed, the changes are applied to the domain. Some configuration changes can be applied dynamically, while others can only be applied after rebooting the server. This is the role of the dynamic configuration reloading service.
For more information about the service that manages the domain configuration changes, refer to JEUS Domain Guide. "Chapter 3. Configuring a Domain".
-
Domain application management service
DAS manages all applications running in a domain by using the domain application management service. To run applications on MSs, the applications must be registered in the domain. Then, in DAS, execute the deploy command by specifying the targets to deploy. The domain application management service synchronizes the applications' states between DAS and MSs. If an application file is changed on DAS, the service allows MSs to retrieve the changed file to sync with DAS.
For more information about application management in the domain, refer to JEUS Applications & Deployment Guide. "Chapter 1. Application Management in a Domain Environment" .
-
Domain data source management service
In DAS, the domain data source management service manages all data sources that are registered in a domain. MSs must use the data sources that are registered in the domain. For more information about how to register and manage data sources in the domain, refer to "Chapter 6. DB Connection Pool and JDBC".
-
In DAS, the cluster management service manages clusters. A cluster is a collection of multiple servers running the same services, and it supports load balancing and failover. For more information about clusters, refer to JEUS Domain Guide. "Chapter 5. JEUS Clustering".
-
DAS can provide all services that are provided by MSs. In an environment where only one server is running services like in a small-sized production environment or a development environment, DAS can also be used to service applications like an MS. For more information about MS services, refer to "1.3. Managed Server (MS)".
Note
DAS can be configured to run like an MS, but it is not recommended to do so. Except in an environment where only one server is required like in a small-sized production environment or a development environment, it is common to dedicate DAS only for management and MSs for application services.
A Managed Server is a server instance that manages engines and services that are required to run the actual applications.
Multiple MSs can be in a domain. MSs run user-deployed applications, and provide services and resources required by the applications.
The following are the key MS services.
-
MS provides servlet, EJB, and Java Message Service (JMS) engines. For information about other engine services, refer to "1.3.1. Engine Service".
-
JNDI service provides the JNDI standard mechanism defined by Java EE. It provides methods that find various objects registered in JEUS by name.
JEUS server calls the object that provides such service as JNDI naming server. In a clustered environment, JNDI servers on each MS exchange information and work together like a single JNDI naming server. For more information about JNDI services, refer to "Chapter 4. JNDI Naming Server".
-
Management service manages and monitors services, components, and applications by using Java Management Extensions (JMX).
It configures the management objects of the JEUS Manager, such as JMX Remote API Connector(RMI Connector/JMXMP Connector), HTML adapter, and SNMP adapter that are defined in JMX. The management objects provide the methods for accessing JEUS management and monitoring information. For more information about management service configurations and management objects, refer to "JEUS JMX Guide".
-
Security service responds to and authenticates security requests from applications and internal components.
For more information about security services, refer to "JEUS Security Guide".
-
HTTP session clustering service
HTTP session clustering service maintains HTTP sessions between servlet engines.
JEUS supports distributed HTTP session clustering. The service maintains HTTP sessions even if an error occurs to a servlet engine. Distributed HTTP session clustering is a memory efficient distribution method for server operation. For more information about HTTP session clustering services, refer to JEUS Session Management Guide. "Chapter 2. Distributed Session Servers".
The previously described service is automatically provided in a cluster. For the servers that are not in a cluster, a limited service with constraints is provided that maintains sessions on all the servers in a domain. For more information, refer toJEUS Session Management Guide. "2.9.3. JEUS 6 Central Session Server Support".
-
In EJB 2.x, RMI stub classes are required to call an EJB from a remote client. But the required classes can be obtained through the FTP Class service without packaging the RMI stub classes on the remote client.
If FTP Class service is not used, the RMI stub classes must be in the classpath of the remote client. For more examples, refer to JEUS EJB Guide. "Chapter 11. EJB Client".
Note
The protocol that actually sends the class files is the HTTP protocol, not FTP protocol.
EJB 3.x does not use this service because it uses dynamic proxy. EJB 2.x also uses dynamic proxy by default, but it can be configured to use the RMI stub method.
-
Scheduler service executes certain jobs at a specified time set by the user. For more information about scheduler services, refer to "JEUS Scheduler Guide".
-
Logging service records events and errors that occur on the servers to a file. The logger level or the handler that are supported by Java Logging Technology can be configured in JEUS. For more information about logging services, refer to "Chapter 8. Logging".
-
Server provides support for applications to access databases using JDBC connection pools. For more information, refer to "Chapter 6. DB Connection Pool and JDBC".
-
Server provides support for applications to use transactions through a transaction manager. For more information about transaction managers, refer to"Chapter 7. Transaction Manager".
-
Server provides applications with connections to various types of external resources.
Users can add the connection information for external resources. The information will be registered on a JNDI naming server and applications can use it for JNDI lookup operation. Although external resources are configured in the domain, this service is classified as a server service since it is used by all servers in the domain.
In a cluster environment, all servers in a cluster share the same resources by using the JNDI naming server. For more information about resource configurations, refer to "Chapter 5. External Resources".
-
Enterprise Information System (EIS) connection service
EIS can be accessed by using the registration information of the JCA resources or external resources where the application is deployed. For more information about the JCA resource adapter, refer to "JEUS JCA Guide".
An engine corresponds to an EJB container or a web container that is defined in Java EE, and it manages and runs user-deployed components. An engine is included as a service on the server and even without any configuration it automatically starts up using the default settings when the server starts up.
The engine configurations can be changed using WebAdmin or the console tool while the server is running. Refer to the relevant manual for information about the default and dynamic configurations of each engine.
The following are the three types of service engines provided by each server.
| Engine | Description |
|---|---|
| EJB engine | Acts as an EJB container that manages and executes EJB components. Refer to "JEUS EJB Guide" for more information. |
| Web engine (or servlet engine) | Acts as a web container that receives requests from web clients or web servers and creates dynamic web contents through user-deployed servlets (or JSP, JSF). Refer to "JEUS Web Engine Guide" for more information. |
| JMS engine | Provides Java Message Service (JMS). Refer to "JEUS MQ Guide" for more information. |
Note
Up to JEUS 6, engines could not run if the engine is not configured in the engine container, and this prevented applications from running services. If the web engine was not configured, the engine had to be added and JEUS had to be restarted to run web applications.
But starting from JEUS 7, the engines automatically starts up when MSs start up. This way, any type of applications can be deployed and serviced even if the user does not configure the engine.
This section describes the Isolated Class Loader supported in JEUS.
Note
By default, the Shared Class Loader (hereafter Shared) is used in JEUS 5.0, and it is also supported in JEUS 7.0 for backward compatibility. However, it needs to be manually configured, otherwise the Isolated method is used by default. It is not recommended to use the Shared method.
This guide does not cover the Shared class loader.
Applications use a separate class loader to prevent duplicate classes in JEUS. This is called Isolated Class Loader (hereafter Isolated). JEUS complies with the Java EE standards that recommend to use the Isolated Class Loader.
The following is the Isolated Class Loader hierarchy.
Each web module class loader of an application exists under an EJB class loader of the application. A class loader of an application does not request a class from a class loader of another application. When an application needs to use the interfaces of another application, it cannot reference the class loader of the application because JAVA EE standards require that the interfaces be packaged together.
Since the classes are not shared, when deploying an application other applications do not need to be redeployed. The proper use of this class loader requires the binding of related applications into an EAR file to create a single application.
Each server has its own directory under the DOMAIN_HOME folder. They exist in the servers directory under DOMAIN_HOME. Each server has a directory with its server name and stores information that is required to start and operate the server. This directory is called SERVER_HOME.
The following is the directory structure of SERVER_HOME.
- .workspace
-
Space used by each server in JEUS. Must not be modified by the user.
The following table describes each sub-directories.
Directory Description deployed Contains the unzipped image files of the applications deployed on the server and the files that were created when the applications were deployed. In this directory, directories are created by using application IDs to store the application files received from DAS. Archived applications will be unzipped by using the application ID (deploy image).
Under the deployed directory, a directory named "_generated_" is created to store the files created when the applications are deployed. In this directory, directories are created by using application IDs to store the files required for deployment.
ejbtimerdb Directory that is used for Apache Derby (a file-based database that is embedded in JEUS) when the timer services of the EJB engine does not have database configuration. For more information about timer services, refer toJEUS EJB Guide. "Chapter 10. EJB Timer Service". session Path of the file DB used in distributed session server. Distributed session server stores passivated sessions and backup sessions received from the primary session to this file DB. For more information, refer to JEUS Session Management Guide. "2.3. Server Structure". tmlog Directory that contains transaction logs required for transaction recovery.
A sub directory is created with the name "_serverName_LOCATION_type_port_ipaddress_virtualport name". The following values are set for the type and virtualhost of the created directory name.
-
type : 0 for IPv4 and 1 for IPv6
-
virtualport : hash value of the server name
For more information, refer to "7.5.2. Recovery Related Log File".
tmp Directory that is used when temporarily saving files during server operation. There is no particular reason for users to access this directory. -
- bin
-
Contains the scripts for starting and stopping the server. The scripts execute the same functions as the scripts in 'JEUS_HOME/bin', but they don't require the configuration of the domain name and server name. The 'startDomainAdminServer/stopserver' script is used for DAS, and 'startManagedServer/stopserver' script is used for MS.
- lib/application
-
Contains application libraries that are applied to the server. The files in this directory is used when a library conflicts with a domain_level library in the 'DOMAIN_HOME/lib/application' directory. A warning that there is a library conflict appears and the domin_level library is ignored on the server. For more information about 'lib/application', refer to JEUS Applications & Deployment Guide. "3.3.1. The lib/application Directory".
- logs
-
Contains the launcher log, server log, and access log files. According to the rotation rule, each log file is created as "logname_date.log00000" where "00000" represents a number between 1 and 99999. For more information, refer to "Chapter 8. Logging".
- nodemanager
-
Contains configurations and logs. For more information, refer to "JEUS Node Manager User Guide".
Starting from JEUS 7, DAS and MS are started by a launcher. A launcher process is executed when starting a server by using a script or starting MS from DAS. The launcher prepares to start and run the servers.
The launcher performs the following tasks.
-
Receive domain configuration files from DAS.
-
Start the server.
First, the launcher receives the domain configuration files from DAS. The files are domain.xml and security configuration files. When the launcher receives the files, it uses them to start the server JVM. When starting up the server, it reads JVM options and classpaths from the files and uses the options to create the server JVM.
If the launcher process fails to receive the configuration files but there are domain configuration files that are cached on the machine, the launcher will use them to start the server JVM. If the launcher fails to receive the configuration files and there are no cached files, the server cannot be started.
Besides the 2 aforementioned tasks, the launcher process acts as a logger for the server boot logs.
The logs that are generated when the server starts up are logged in the launcher logs. The launcher process starts the server JVM and waits for the server to complete the boot process and records logs that have been generated when the server finishes starting up. If the server fails to boot before the server resets the logger, the launcher logs can be used to check for the cause of the failure.
Generally, the launcher process starts the server JVM and terminates when the server starts up successfully. Note that the server process started by the launcher operates as a background process. Since the server process is started as a child process of the launcher process, it does not have its own console screen.
Hence, to print the server logs on a console screen, the '-verbose' option should be used to start a server. If the '-verbose' option is used, the launcher process does not terminate and it outputs the logs on the screen until the server is terminated. For more information, refer to "8.2.2. JEUS Launcher Logger".
In the INDEPENDENT mode, MSs boot up and operate without using DAS. The INDEPENDENT mode is used when the URL information of DAS doesn't exist during startup or when DAS is in a failed state.
The URL of DAS must be provided as a option when starting an MS. The launcher uses this URL to access the configuration files on DAS. If the URL information is omitted, the launcher cannot receive configuration files from DAS. In this case, the launcher uses the cached configuration files on the server machine, if they exist, and starts up the server in the INDEPENDENT mode. If they don't exist, the server cannot boot.
Even if the configuration files exist on the server machine, the files may be outdated and out of sync with DAS. Therefore, the DAS URL should always be used to start a server.
The DAS URL is not required when DAS and MS are on the same machine, and the domain configuration files do not need to be sent to the MS. If the DAS URL is not used to start a server, the server will run in the INDEPENDENT mode, but once the group management starts on the MS, it can communicate with DAS and switches back to the DEPENDENT mode.
The INDEPENDENT mode is triggered more often due to an error on DAS rather than due to missing URL. When starting an MS, if an error occurs on DAS, the launcher cannot receive the configuration files. After failback, the MSs that are in the INDEPENDENT mode are switched back to the DEPENDENT mode. Their configuration files are synchronized with DAS, and the applications that have failed to deploy are redeployed.
Note
Even if DAS is recovered and the configurations are synchronized, MS should be restarted if the non-dynamic configurations or running applications have been modified.
The following are the logs generated when MS starts in the INDEPENDENT mode.
JEUS_HOME/bin$ ./startManagedServer -domain domain1 -server server1 -u administrator -p adminadmin - dasurl 61.77.153.160:9736 *************************************************************** - JEUS Home : /home/test/jeus - JEUS Base Port : - Added Java Option : - Java Vendor : Sun *************************************************************** ================ JEUS LICENSE INFORMATION ================ === VERSION : JEUS 7.0 (Fix#1) (7.0.0.0-b71) === EDITION: Enterprise (Trial License) === NOTICE: This license restricts the number of allowed clients. === Max. Number of Clients: 5 ========================================================== [2012.05.13 23:05:06][0] [launcher-1] [Launcher-0052] Receiving the configuration failed. Attempting to start as INDEPENDENT. <<__Exception__>> java.io.IOException: Connection failed. host:61.77.153.160, port:9736, virtual id:FileTransfer at jeus.net.SocketProxy.getConnection(SocketProxy.java:107) at jeus.net.SocketProxy.getConnection(SocketProxy.java:42) at jeus.server.filetransfer.ConfigurationSynchronizer.connect( ConfigurationSynchronizer.java:106) at jeus.server.filetransfer.ConfigurationSynchronizer.checkConnection( ConfigurationSynchronizer.java:131) at jeus.server.filetransfer.ConfigurationSynchronizer.downloadConfigFileFromDAS( ConfigurationSynchronizer.java:170) at jeus.launcher.ManagedServerLauncher.receiveConfigurationFromDas( ManagedServerLauncher.java:179) at jeus.launcher.ManagedServerLauncher.updateXmls(ManagedServerLauncher.java:59) at jeus.launcher.ManagedServerLauncher.readDescriptor(ManagedServerLauncher.java:39) at jeus.launcher.Launcher.start(Launcher.java:145) at jeus.launcher.ManagedServerLauncher.main(ManagedServerLauncher.java:35) <<__!Exception__>> [2012.05.13 23:05:08][0] [launcher-1] [Launcher-0054] Starting the server using the local configuration. ... [2012.05.13 23:05:26][0] [server1-1] [SERVER-0249] Successfully started the server INDEPENDENTLY [2012.05.13 23:05:26][2] [server1-1] [SERVER-0248] The JEUS server is RUNNING [2012.05.13 23:05:26][2] [server1-1] [SERVER-0401] The elapsed time to start: 17672 ms [2012.05.13 23:05:26][2] [launcher-10] [Launcher-0034] The server[server1] initialization completed successfully[pid : 3388]. [2012.05.13 23:05:26][0] [launcher-1] [Launcher-0040] Successfully started the server. The server state is now RUNNING. JEUS_HOME/bin$
Once DAS is restored, MS synchronizes the configurations with DAS, and redeploys any applications that have failed to deploy.
[2012.05.13 23:08:28][2] [server1-66] [Domain-0101] Domain Administration Serverrecovered. server1 is running in DEPENDENT mode now. [2012.05.13 23:08:28][2] [server1-66] [SERVER-0201] Successfully connected to Domain Administration Server(61.77.153.160:9736) [2012.05.13 23:08:28][2] [server1-66] [SERVER-0308] Resynchronized the configuration with Domain Administration Server.