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) Server Pulsa Murah.
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 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
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.