Explain the architecture of the application flow in WAS Environments?

The basic flow of the application starts when the user’s request to a URL.The URL is a combination of the Hostname, port no and context root of the specific application. The URL has a valid hostname/IPAddress of the application installed machine.

In most general, A HTTP Server/Webserver can handle the HTTP requests. Webserver maintains and serve the static pages to the users and for dynamic pages it will direct the requests to the Application Server.

The Webserver plug-in uses a XML configuration file to determine whether a request is for WAS and identifies the request as addressing a Java servlet and utilizes its configuration data to pass the request on to the servlet runtime engine code. The appropriate servlet is invoked via HTTP.

Next, the servlet understands which method or call it needs to make to obtain the information to satisfy the client request.

The third step involves business logic written as part of the Enterprise JavaBeans, which connects to the back-tier database and performs the transaction.

When the query results are sent back to the WebSphere middle-tier environment, the Java servlet regains control and manages the response page generation which needs to be served back to the client making the original request. To do that, an appropriate Java Server Page can be selected to help generate the dynamic content. The computed Web page with the results of the query is then served back to the Web client via the HTTP server.

WebSphere Application Server Important Files

WebSphere stores its configuration to set of XML files. When we use the Admin console to configure WebSphere, certain XML files are updated internally.

CELL-scope

• Admin-authz.xml: contains the roles set for administration of the Admin console.
                  <Profile root>/appsrv01/config/cells/<cell name>/

• profileRegistry.xml: Contains a list of profiles and profile configuration data

• resources.xml :Defines operating cell scope environmental resources, including JDBC, JMS, JavaMail, URL end point configuration, and so on.

• security.xml: Contains security data , including all user ID and password information.

• virtualhosts.xml: Contains virtual host and Multipurpose Internet Mail Extensions (MIME)-type configurations.

• variables.xml: Contains cell level WebSphere variables

• wimconfig.xml: Contains the federated repository configurations for global security
            <profile_root>/config/cells/<cell_name>/wim/config/

NODE-scope

• namestore.xml: Provides persistent JNDI namespace binding data

• resources.xml :Defines node scope environmental resources, including JDBC, JMS, JavaMail, URL end point configuration, and so on

• serverindex.xml: Specifies all the ports used by servers on this node

• variables.xml: Contains node level WebSphere variables

SERVER-scope

• resources.xml: Contains the configuration of resources, such as, JDBC, JMS, JavaMail, and URL end points at server scope

• server.xml: Contains application server configuration data

• variables.xml: Contains server level variables

properties files

If the global security is enabled WebSphere Application Server cell, you need to manually enter the username and password every time you run the wsadmin tool. By editing the sas.client.props and the soap.client.props files, you can specify the username and password you have configured for global security so you are not prompted to enter the username and password every time you run administrative scripts.

soap.client.props file
com.ibm.SOAP.securityEnabled=<true>
com.ibm.SOAP.loginUserid=<username>
com.ibm.SOAP.loginPassword=<password>
Optionally, set the following property:
com.ibm.SOAP.loginSource=none

sas.client.props file
com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginPassword=
Also, set the following property:
com.ibm.CORBA.loginSource=properties

Log Files

JVM logs
native_stderr.log,native_stdout.log
stdout and stderr streams are redirected to log files at application server startup, which contain text written to the stdout and stderr streams by native modules, that is, Linux Modules, and so on. In normal error-free operations, these logs files are typically empty.

startServer.log
It is created in your logs directory when the server starts up. This log is very useful to determine JVM parameters used in the start-up process, the server’s process id, and also the date and time in which the server was started. If there are errors experienced during the start-up (for example, security configuration errors where the application server cannot start), then log information will exist for problem determination.

stopServer.log
when server was stopped via a command line, the log will be written to this. If the server has trouble stopping, then Java stack traces will be written to the log which can be used in determining why a given application server failed to stop.

SystemErr.log
contains Java exceptions and stack traces. An empty SystemErr.log file does not necessarily indicate a successfully running application server JVM. You may need to consult the other logs in this directory.

SystemOut.log
This log file contains messages as generated by the JVM during runtime. Some messages are informational, some are warnings or status updates. Applications can be configured to write to the log and so it is very common for the SystemOut.log to be your first port of call in application debugging.

<server_name>.pid
contains the process id of the server. In Linux, this is the actual process id assigned to the JVM process.

FFDC logs
FFDC directory contains detailed logs of exceptions found during the runtime of the WebSphere Application Server. Can be found at WAS_ROOT/profiles/logs/ffdc