WebSphere Application Server provides services (database connectivity, threading, workload management, and so forth) that can be used by the business applications. The main element is the application server, a java process that encapsulates many services, including the containers, where business logic executes. If you are familiar with J2EE, you will recognize the Web Container and the EJB container. The Web container executes Servlets and JavaServer Pages(JSPs), both of which are java classes that generate markup to be viewed by a Web browser. Traffic into and out of the Web Container travels through the embedded HTTP Server. While Servlets and JSPs can act independently, they most commonly make calls to Enterprise Java Beans (EJBs) to executes business logic or access data. EJBs, which run in the EJB container, are easily reusable java classes. They most commonly communicate with a relational database or other external source of application data, either returning that data to the Web container or making changes to the data on behalf of the servlet or JSP.
The JMS messaging engine is built into the application server. This is a pure-java messaging engine. JMS destinations, known as queues and topics provide asynchronous messaging services to the code running inside the containers, JMS will be covered in more depth later in this course.
As you will see in more detail later on, the web services engine enables application components to be exposed as web services, which can be accessed using Simple Object Access Protocol (SOAP).
Several other services run within the application server, including the dynamic cache, data replication, security, and others. These will be covered later in this course.
There are also some important components outside of the application server process.
WebSphere Application Server also provides a plug-in for HTTP servers that determines what HTTP traffic is intended to be handled by WebSphere, and routes the requests to the appropriate server. The plug-in is also a critical player in workload management of HTTP requests, as it can distribute the load to multiple application server, as well as steer traffic away from unavailable servers. It too roads its configuration from a special XML file.
One of the servervices provided within the application server is the admin service. This service allows for the ability to configure the application server. This files necessary for configuration are stored outside of the actual application server in a set of XML configuration files. There is an application that runs within the Web application-the admin console.
WebSphere Architecture Administration
There are two main tools used to administer WebSphere Application Server:1) The Administrative console, and 2) wsadmin command line tool.
The Server's Configuration is stored in a set of XML files, often referred to as the configuration repository. These files define the server itself, as well as resources and services that it provides. One of the services provided within the application server is the admin service. This service allows for the ability to configure the application server. The files necessary for configuration are stored outside of the actual application server in a set of XML configuration files. There is an application that runs within the Web container that provides user the ability to administer the application server via a Web application- the admin console. Here you see the communication from the browser all the way back to the XML configuration files. Wsadmin can be used to administer the application server in two ways. 1) Via SOAP by communicating with the embedded HTTP server. 2) By using RMI (the default) to communicate directly with the admin service.
One of the services provided within the application server is the admin service. This service allows for the ability to configure the application server. The files necessary for configuration are stored outside of the actual application server in a set of XML configuration files. There is an application that runs within the Web container that provides users the ability to administer the application server via a Web application-the admin console.
Websphere Support, Websphere Outsourcing:
WebSphere profiles overview
Profiles are the way that you are allowed to run more than one application server on a single installation of WebSphere product files.
Profiles are sets of files that represent a WebSphere Application Server configuration. WebSphere Application Server files are split into two categories. 1) Product files Set of shared read-only static files or product binaries shared by any instances of the WebSphere Application Server product. 2) Configuration files (profiles) Set of user-customizable data files. Files include: WebSphere configuration, installed applications, resource adapters, properties, log files, and so forth. Each profile uses the same product files, Simpler than multiple WebSphere installations, Less disk space, Simplifies application of product updates.
Under the WebSphere installation directory <was_root> there are subdirectories for each profile. In the example above there are two application servers running that are each configure by the files that exist within their own profile directory.
Network deployment runtime flow
The main theme with network deployment is distributed applications. While the "flow" of an application remains the same, there are significant additions to runtime of an application. Note the "Load balancer" this allows for multiple HTTP servers, users point there browsers to the load balancer and their request will be work load managed to an HTTP Server. Once the request hits one of these HTTP Servers, the HTTP Server plug-in will load balance the request between the application servers that it is configured to serve. Once the request enters the application server, the flow is identical to how it was in Express and Base. The Java clients requests to EJBs can also be work load managed so that the requests do not all hit one application server.
Network Deployment Administration Flow.
Each managed process, node agent, deployment manager starts with it's own set of configuration files. Deployment manager contains the MASTER configuration and application files. Any changes made at node agent or server level are local and will be overridden by the MASTER configuration at the next synchronization. The administrative console and wsadmin are still the two ways that the environment is administered. However, take note that these tools now talk to the deployment manager and NOT to the application servers directly. The communication of these commands flows from the tools to the deployment manager to the node agents, to the application servers. This allows administration of multiple nodes (each possibly containing multiple application servers) from a single focal point (the deployment manager).
There is ONE main repository for the configuration files within a cell, and those are associated with the deployment manager. All updates to the configuration files should go through the deployment manager. You will see in a moment how this process works. You should be very careful in connecting to an application server directly with wsadmin or the administrative console as any changes that are made to the configuration files are only temporary, they will be overwritten with the configuration files from the MASTER files.
Web Server custom plugin-cfg.xml
Web server definitions are created to allow the mapping of J2EE enterprise applications to specific Web servers. Can be done through the administrative console. Alternatively use the script generated during the installation of the plug-in which can automate the mapping of all the applications to the Web server configure <Web_server_name>.bat in <plugin_root> bin. Mapping the applications to specific Web Servers will cause the custom plugin-cfg.xml files for only those Web servers to include the information for those applications. Web servers target specific applications running in a cell. Automatically generated by the deployment manager. Just as modules for an enterprises application need to be mapped to one or more application servers, they also need to be mapped to one or more Web servers.
J2EE Packaging
A J2EE application is packaged in an Enterprise Archive, a file with a.EAR extension. The application has a deployment descriptor, shown here as DD, allowing configuration to a specific container's environment when deployed. The application can include one or more modules. J2EE components are grouped in modules, and each module has its own deployment descriptor. EJB modules group related EJBs in a single module, and are packaged in Java Archive (JAR) files. Note that there is only deployment descriptor for all of the EJBs in the module. Web modules group servlet class files, JSPs, HTML files and images. They are packaged in Web Application Archive (WAR) files. Application client modules are packaged in Java Archive (JAR) files. Resource Adapters may be packaged to the application server or within an application .EAR file.
Assembling an enterprise application
When working with a workspace handed over by development, no assembly is required (already done automatically by tool). If your developers use IBM tools you may receive an existing, working workspace folder for final configuration and deployment. In this case the individual WAR and JAR files are not required as they already exist as part of the workspace. When working with workspaces all you need to do when starting AST, is point to the root directory of the workspace. If you receive the individual WAR and JAR files, which are the modules for the application, you will need to point AST to an empty workspace which will hold the Enterprise application's workspace. You only do this the first time, thereafter you just point AST to this newly created workspace directory. In this last scenario, assembly is just the action of importing the files containing the modules and associating them with the Enterprise Application. The end result is an EAR file, which contains all the modules and their deployment descriptors. The EAR file can then be installed (or deployed) to an application server.
Creating a data source
Installed applications that must interact with relational databases use JDBC providers for data access. Together, the JDBC provider and data source objects are functionally equivalent to the J2EE Connector architecture (JCA) connection factory (which provides access to non-relational databases). Installed applications use a data source to access the data from the database. A data source is associated with a JDBC provider that supplies the specific JDBC driver implementation class. The data source represents the J2EE Connector Architecture (JCA) connection factory for the relational adapter. Application components use the data source to access connection instances to a specific database; a connection pool is associated with each data source. You can create multiple data sources with different settings, and associate them with the same JDBC provider. (One reason to do this is to provide access to different databases.) JDBC providers that are supported by WebSphere Application Server are required to implement one or both of the following data source interfaces, which are defined by Sun Microsystems. The interfaces enable the application to run in a single-phase or two-phase transaction protocol.
You can also find out more at the Software Outsourcing Company website: Symbyo.com
WebSphere Application Server logs
Java virtual machine (JVM) Logs
The JVM logs are created by redirecting the System.out and System.err streams of the JVM to independent log files. WebSphere Application Server writes formatted messages to the System.out stream. In addition, applications and other code can write to these streams using the print() and printIn() methods defined by the streams. In the case of a WebSphere Application Server Network Deployment configuration, JVM logs are also created for the deployment manager and each node agent because they also represent JVMs.
Process Logs
WebSphere Application Server processes contain two output streams that are accessible to native code running in the process. These streams are the stdout and stderr streams. Native code, including Java virtual machines (JVM), might write data to these process streams. In addition, JVM provided System.out and System.err streams can be configured to write their data to these streams also. As with JVM logs, there is a set of process logs for each application server, since each JVM is an operating system process, and in the case of a WebSphere Application Server Network Deployment configuration, a set of process logs for the deployment manager and each node agent.
IBM Service Logs
The IBM Service log contains both the WebSphere Application Server messages that are written to the System.out stream and some special messages that contain extended service information that is normally not 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. The IBM Service log is maintained in a binary format and requires a special tool to view. This viewer, the AST Log and Trace Analyzer, provides additional diagnostic capabilities. In addition, the binary format provides capabilities that are utilized by IBM support organizations. The HTTP server plug-in log will be covered later in this presentation.
Wsadmin Introduction
Wsadmin provides scripting capabilities and command-line administration. Common operational and configuration tasks can be performed from scripts and the command line instead of through the administrative console. The WebSphere Application Server wsadmin tool provides the ability to execute scripts. You can use the wsadmin tool to manage a WebSphere Application Server V6.1 installation. This tool uses the Bean Scripting Framework (BSF), which supports a variety of scripting languages to configure and control your WebSphere Application Server installation. The wsadmin launcher makes administrative objects available through language specific interfaces. Scripts use these objects for application management, configuration, operational control, and for communication with MBeans running in WebSphere server process. Wsadmin acts as an interface to Java objects for access by scripts. Wsadmin uses the same interface (through JMX) as the administrative console to make configuration changes and control servers
There a many levels that are involed in security an environment. WebSphere only provides part of the total security that needs to be applied. Things like file system security still need to be taken into account to protect things like your configuration files and keyrings. Operating System Security - The security infrastructure of the underlying operating system provides certain security service to the WebSphere Security Application. This includes the file system security support to secure sensitive files in WebSphere product installation. The WebSphere system administrator can configure the product to obtain authentication information directly from the operating system user registry, for example the NT Security Access Manager.
No comments:
Post a Comment