WebSphere Application Server Features : WebSphere Application Server is a platform that runs Java-based business applications. WebSphere Application Server Implementation of the Java 2 Enterprise Edition (J2ee) Specification.
WebSphere Application Server provides services (database connectivity, threading, workload management, and so on) that business applications can use. Its main element is the application server, a java process that encapsulates many services, including containers, on which the business logic is executed. If you are familiar with J2EE, you will recognize Web Containers and EJB Containers.
Web Containers execute Servlets and JavaServer Pages (JSP), both of which are java classes that generate markup for Web browsers to view. Traffic in and out of the Web Container passes through the embedded HTTP Server. While Servlets and JSPs can act independently, they most often make calls to Enterprise Java Beans (EJB) to execute business logic or access data.
EJB, which runs in an EJB container, is an easy-to-use java class. They most often communicate with relational databases or other external application data sources, either returning that data to a Web container or making changes to the data on behalf of a servlet or JSP.
The JMS messaging engine is built into the application server. This is a pure java messaging engine. The purpose of JMS, known as queuing and the topic of providing asynchronous messaging services for code running in containers, will be covered in more depth later in this course.
As you’ll see in more detail later, the web service engine allows application components to be exposed as web services, which can be accessed using the Simple Object Access Protocol (SOAP).
Several other services run on the application server, including dynamic caching, data replication, security, and more. This will be discussed later in this course.
There are also some important components outside the application server process.
The WebSphere Application Server also provides plug-ins for HTTP servers that determine what HTTP traffic WebSphere is intended to handle, and directs requests to the appropriate server.
Plug-ins are also important players in HTTP request workload management, as they can distribute the load across multiple application servers, as well as redirect traffic from servers that are not available. It also runs its configuration from a custom XML file.
One of the server services provided in the application server is the admin service. This service allows the ability to configure the application server. The files required for this configuration are stored from the actual application server in a set of XML configuration files. There is an application running within the Web application admin console.
WebSphere Architecture Administration
There are two main tools used to manage the WebSphere Application
Server: 1) the Administrative Console, and
2) the wsadmin command line tool.
Server configurations are stored in a set of XML files, often referred to as a configuration repository. These files define the server itself, as well as the resources and services it provides. One of the services provided in the application server is the admin service. This service allows the ability to configure the application server. Files required for configuration are stored from the actual application server in a set of XML configuration files.
There are applications that run in Web containers that give users the ability to manage the application server through the Web application – admin console. Here you see the communication from the browser all the way to the XML configuration file. Wsadmin can be used to manage application servers in two ways.
1) Through SOAP by communicating with the embedded HTTP server.
2) By using RMI (default) to communicate directly with admin services.
One of the services provided in the application server is the admin service. This service allows the ability to configure the application server. Files required for configuration are stored off the actual application server in a set of XML configuration files. There are applications that run in Web containers that give users the ability to manage the application server via the Web-application admin console.
WebSphere profile overview
Profiles are how you are allowed to run more than one application server on a single installation of WebSphere product files.
A profile is a collection of files that represent the WebSphere Application Server configuration. WebSphere Application Server Files are divided into two categories.
1) Product file A collection of read-only static files or product binaries that are shared by all WebSphere Application Server product instances.
2) Configuration file (profile) A user-customizable collection of data files. Files include: WebSphere configuration, installed applications, resource adapters, properties, log files, and so on. Each profile uses the same product file, Simpler than multiple WebSphere installations, Less disk space, Simplifies product update application.
Under the WebSphere installation directory
there is a subdirectory for each profile. In the example above there are two application servers running which are each configured by files in their respective profile directories.
Network deployment runtime flow
The main theme with network deployment is distributed applications. While the application “flow” remains the same, there is a significant increase in application runtime. Note this “Load balancer” allows for multiple HTTP servers, users point the browser to the load balancer and their requests for managed workloads to the HTTP Server.
After a request hits one of these HTTP Servers, the HTTP Server plug-in will load a balance of requests between the application servers it is configured to serve. Once the request goes to the application server, the flow is identical to the way in Express and Base. Java client requests to EJBs can also be workload-managed so that requests don’t all hit a single application server.
Network Deployment Administration Flow.
Each managed process, node agent, deployment manager starts with its own set of configuration files. The deployment manager contains the MASTER configuration and application files. Any changes made at the node agent or server level are local and will be overwritten by the MASTER configuration on the next sync. The administrative console and wsadmin are still two ways of managing the environment.
However, note that this tool now talks to the deployment manager and NOT to the application server directly. This command communication flows from the tool to the deployment manager to the node agent, to the application server. This allows the administration of multiple nodes (each may contain multiple application servers) from a single focal point (deployment manager).
There is ONE main repository for configuration files in cells, and that is related to the deployment manager. All updates to the configuration file must go through the deployment manager. You will soon see how this process works.
You should be very careful about connecting to the application server directly with wsadmin or the administrative console because any changes made to the configuration file are only temporary, they will be overwritten with the configuration file from the MASTER file.
Web Server-specific plugin-cfg.xml
The web server definition was created to allow mapping of J2EE enterprise applications to a specific Web server. Can be done via the administrative console. Or use the script generated during plug-in installation that can automate the mapping of all applications to the Web server configuration <web_server_name>.bat in <plugin_root </plugin_root></web_server_name>
Mapping an application to a specific Web Server will cause a custom plugin-cfg.xml file for only that Web server to include information for that application. The web server targets specific applications running in cells. Generated automatically by the deployment manager. Just as modules for enterprise applications need to be mapped to one or more application servers, they also need to be mapped to one or more Web servers.
J2EE applications are packaged in the Enterprise Archive, a file with the a.EAR extension. Applications have deployment descriptors, shown here as DD, that allow configuration to a specific container environment when deployed. Applications may include one or more modules. J2EE components are grouped into modules, and each module has its own implementation descriptor.
The EJB module groups related EJBs in a single module, and is packaged in a Java Archive (JAR) file. Note that there are only deployment descriptors for all EJBs in the module. The web module groups servlet class files, JSPs, HTML files, and images. They are packaged in a Web Application Archive (WAR) file.
The application client module is packaged in a Java Archive (JAR) file. Resource Adapters can be packaged to the application server or in the application’s .EAR file.
Assembling enterprise applications
When working with development-delivered workspaces, no assembly is required (already done automatically by the tool). If your developer uses IBM tools, you may receive an existing, working workspace folder for configuration and final deployment. In this case the individual WAR and JAR files are not needed as they already exist as part of the workspace.
When working with workspaces, all you need to do when starting the AST, is point to the root directory of the workspace. If you receive individual WAR and JAR files, which are modules for the application, you must point the AST to an empty workspace that will house the Enterprise application workspace. You only do this the first time, after that you just point the AST to this newly created workspace directory.
In this latter scenario, assembly is simply the act of importing the file containing the module and associating it with the Enterprise Application. The end result is an EAR file, which contains all the modules and their implementation descriptors. The EAR file can then be installed (or deployed) to the application server.
Create a data source
Installed applications that must interact with a relational database use a JDBC provider for data access. Together, the JDBC provider and the data source object are functionally equivalent to the J2EE Connector (JCA) architecture connection factory (which provides access to non-relational databases). Installed applications use data sources to access data from the database.
The data source is associated with a JDBC provider that supplies a specific JDBC driver implementation class. The data source represents the J2EE Connector Architecture (JCA) connection factory for the relational adapter. Application components use data sources to access connection instances to specific databases; a collection of connections associated with each data source.
You can create multiple data sources with different settings, and associate them with the same JDBC provider. (One reason for doing this is to provide access to a different database.) JDBC providers supported by the WebSphere Application Server are required to implement one or both of the following data source interfaces, as specified by Sun Microsystems. Interfaces allow applications to run in single-phase or two-phase transaction protocols.
WebSphere Application Server Logs
Java virtual machine (JVM) logs
JVM logs are created by redirecting the System.out and System.err streams from the JVM to independent log files. The WebSphere Application Server writes formatted messages to the System.out stream. Additionally, applications and other code can write to this stream using the print() and printIn() methods defined by the stream.
In the case of the WebSphere Application Server Network Deployment configuration, JVM logs are also generated for the deployment manager and each node agent because they also represent the JVM.
The WebSphere Application Server process contains two output streams that can be accessed by native code running in the process. These streams are stdout and stderr streams. Native code, including the Java virtual machine (JVM), may write data to this process flow. Additionally, the JVM-provided System.out and System.err streams can be configured to write their data to these streams as well.
Like JVM logs, there is a set of process logs for each application server, because each JVM is an operating system process, and in the case of the WebSphere Application Server Network Deployment configuration, a set of process logs for the deployment manager and each agent node.
IBM Service Log
The IBM Service Log contains WebSphere Application Server messages written to the System.out stream and several special messages containing additional service information that is not usually of interest, but can be important when analyzing problems. There is one service log for all WebSphere Application Server JVMs on a node, including all application servers.
IBM Service Logs are stored in binary format and require special tools to view them. This viewer, AST Log and Trace Analyzer, provides additional diagnostic capabilities. In addition, the binary format provides the capabilities used by IBM support organizations. HTTP server plug-in logs will be discussed later in this presentation.
Introduction to wsadmin
Wsadmin provides scripting and command line administration capabilities. Common operational and configuration tasks can be performed from scripts and the command line instead of via the administrative console. The WebSphere Application Server wsadmin tool provides the ability to execute scripts. You can use the wsadmin tool to manage the installation of WebSphere Application Server V6.1.
This tool uses the Bean Scripting Framework (BSF), which supports multiple scripting languages to configure and control your WebSphere Application Server installation. The wsadmin launcher makes administrative objects available through a language-specific interface. The script uses these objects for application management, configuration, operational control, and for communication with MBeans running in WebSphere server processes.
Wsadmin acts as an interface to Java objects for scripts to access. Wsadmin uses the same interface (via JMX) as the administrative console to make configuration changes and control the server
There are many levels involved in environmental safety. WebSphere only provides a portion of the total security that needs to be implemented. Things like filesystem security still need to be taken into account to protect things like your configuration files and keychains. Operating System Security – The security infrastructure of the underlying operating system provides certain security services for WebSphere Security Applications.
This includes file system security support for securing sensitive files in WebSphere product installations. WebSphere system administrators can configure the product to obtain authentication information directly from the operating system user registry, for example NT Security Access Manager.