WebSphere Application Server is a platform on which Java-based business applications run. WebSphere Application Server Is an implementation of the Java 2 Enterprise Edition(J2ee) Specification.
WebSphere Application Server provides services (database connectivity, threading, workload management, and so forth) that the business applications can use. 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, the 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. The most commonly communicate with a relational database or another 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, etc. These will be covered later in this course.
More Articles :
- Apps tap into snow sports
- Tiger Woods
- IOS Application Development – A Complete Guide
- Jagmohan Dalmiya
- Features and Functions of the New Pajero Sport
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. It can distribute the load to multiple application servers and steer traffic away from unavailable servers. It too roads its configuration from a special XML file.
One of the services provided within the application server is the admin service. This service allows for the ability to configure the application server. These files necessary for configuration are stored outside of the actual application server in XML configuration files. In addition, 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) the wsadmin command-line tool.
The Server’s Configuration is stored in XML files, often referred to as the configuration repository. These files define the server itself, as well as the 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 the actual application server in XML configuration files. An application runs within the Web container that provides users 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 the actual application server in XML configuration files. In addition, 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 profiles overview
Profiles are how 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 the application of product updates.
Under the WebSphere installation directory
<was_root></was_root>
there are subdirectories for each profile. In the example above, two application servers running are configured 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 an application’s runtime. Note the “load balancer” allows for multiple HTTP servers; users point their browsers to the load balancer, and their request will be workload 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 configured to serve. Once the request enters the application server, the flow is identical to how it was in Express and Base. The Java client requests to EJBs can also be workload managed so that the requests do not require all to hit one 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 overridden by the MASTER configuration at the next synchronization. The administrative console and admin are still the two ways that the environment is administered. However, 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 the 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. Therefore, all updates to the configuration files should go through the deployment manager. You will see in a moment how this process works. It would be best if you were very careful in connecting to an application server directly with wsadmin or the administrative console. Any changes 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. It 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></plugin_root></web_server_name>
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 enterprise 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 into modules, and each module has its own deployment descriptor. For example, EJB modules group-related EJBs in a single module and are packaged in Java Archive (JAR) files. Note that there is only a 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.
