Web servers are computers on the internet that host websites, serving pages to viewers upon request. This service is referred to as web hosting.
Every web server has a unique address so that other computers connected to the internet know where to find it on the vast network. The IP (Internet Protocol) address looks something like this: 69.93.141.146. This address maps to a more human friendly address, such as CloverInfotech.
For example, apache tomcat , JBoss, HTTP Server, IIS, IBM Http Server etc.
An Application server is a server program in a computer in a distributed network that provides the business logic for an application program. The application server is frequently viewed as part of a three-tier application, consisting of a graphical user interface (GUI) server, an application (business logic) server, and a database and transaction server. More descriptively, it can be viewed as dividing an application into:
- A first-tier, front-end, Web browser-based graphical user interface, usually at a personal computer or workstation
- A middle-tier business logic application or set of applications, possibly on a local area network or intranet server
- A third-tier, back-end, database and transaction server, sometimes on a mainframe or large server
For example, IBM WebSphere Application , oracle application server, oracle weblogic etc.
What is the difference between an application server and a Web server?
Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:
A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.
Let's examine each in more detail.
The Web server
A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.
Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.
While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.
The application server
As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).
Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.
In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.
How do Web and application servers fit into the enterprise?
An example
As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.
Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
To summarize, a Web server simply processes HTTP requests by responding with HTML pages.
Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.
In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.
By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.
Oracle Application Server :
Oracle Application Server Components:
Up to this point, we've introduced a lot of features available in different versions of Oracle Application Server without providing much explanation of what they do. The following subsections group the main components of Oracle Application Server into three basic categories—core components, application components, and additional components—and describe briefly what these components do.
Core Components
The components that make up the core of Oracle Application Server are the Oracle HTTP Server, Oracle Application Server Containers for J2EE, and OracleAS Web Cache.
Oracle HTTP Server
The Oracle HTTP Server, which is based on the Apache Web Server, provides the services needed to handle incoming HTTP requests and can serve as a proxy server. Developers can program in languages such as Perl, C, C++, PL/SQL, and Java, and can leverage libraries and frameworks such as BC4J, the XML Developer's Kit, Java Naming and Directory Interface (JNDI), and JDBC. The Oracle HTTP Server supports Server Side Includes for adding content (such as header or footer information) across all of a web site's pages. Servers can be clustered in high-availability configurations, and Oracle HTTP Server also supports load balancing, which can couple high availability with scalability. Security support includes OracleAS Single Sign-On and encryption with the Secure Sockets Layer (SSL).
Oracle Application Server Containers for J2EE
Oracle Application Server Containers for J2EE (OC4J) is a set of J2EE-certified containers executed using any standard Java Virtual Machine (JVM). OC4J provides a JSP translator, a servlet engine, and an EJB container. It also provides other J2EE services to the containers, such as JNDI, JDBC, Java Message Service (JMS), Java Authentication and Authorization Service (JAAS), and Java Transaction API (JTA). OC4J supports clustering, load balancing, and application state replication for web and EJB applications, thus enabling highly available and scalable configurations. OC4J can use Java Object Cache in the OC4J containers.
OracleAS Web Cache
OracleAS Web Cache is a memory cache that speeds the delivery of content to requesters. OracleAS Web Cache can store both static and dynamic pages, as well as parts of pages that are marked with Edge Side Include (ESI) tags. This cache also provides other types of functionality, such as balancing request loads between multiple instances of the Oracle HTTP Server and monitoring the speed at which content is returned to users.
Application Components
The components of Oracle Application Server described in the following subsections provide capabilities that can create and deploy applications.
Web Services
Web Services are extensively supported in Oracle Application Server. The product includes support for the following:
· Java classes (either stateful or stateless) as remote procedure call (RPC) or document-style Web Services
· Stateless EJBs as Web Services
· PL/SQL stored procedures as Web Services
· JMS topics and queues as document-style Web Services
Clients can invoke these either dynamically or statically.
Other standards supported include publishing and query with UDDI and typed and untyped SOAP messages with SOAP header access via an application programming interface (API). A dynamic WSDL tester allows you to create web-based clients and simplify the testing of Web Services during development.
Oracle Application Server TopLink
OracleAS TopLink is an object-relational persistence tool used to store Java objects and EJBs in relational database tables. The visual mapping interface allows developers to define how Java classes are mapped to database schema. Thus, a Java developer using OracleAS TopLink doesn't need to write SQL calls. Using the visual mapping tool, the developer can usually handle database schema changes without needing to recode the Java applications. The mapping tool provides graphical views of relationships, queries, locking, caching, sequencing, and other areas of interest that enable performance tuning.
Oracle JDeveloper
Oracle JDeveloper is a part of Oracle Developer Suite, rather than of Oracle Application Server itself, but it can create the Java applications that are deployed on an Oracle Application Server platform. Oracle JDeveloper was introduced by Oracle in 1998 to enable the development of basic Java applications without the need to write large amounts of code. At the core of Oracle JDeveloper is an advanced application development framework. Oracle JDeveloper provides numerous wizards that create Java and J2EE objects and project types. Some wizards in Oracle JDeveloper include:
· A Beans wizard for creating Java Beans and BeanInfo classes
· A Deployment wizard providing "one-click" deployment of J2EE applications to OC4J
Database development features include various Oracle drivers, a Connection Editor to hide the complexity of using the JDBC API to establish connections, database components to bind visual controls, and a SQLJ precompiler for embedding SQL in Java code (which you can then use with the Oracle database).
Oracle Application Server comes with a limited-use license for Oracle JDeveloper. The development tool is packaged in the Oracle Developer Suite.
OracleAS Forms Services
Oracle Application Server Forms Services provide data handling, navigation, database access, and database validation for Oracle Forms applications. These services allow Oracle Forms to run in an N-tier web environment.
Forms deployed to Oracle Application Server are developed using the Oracle Forms Developer, an interactive development tool that is part of the Oracle Developer Suite. Oracle Developer allows you to define applications by defining values for properties, rather than by writing procedural code. Oracle Developer supports a variety of clients, including traditional client-server PCs and Java-based clients. The Forms Builder includes a built-in JVM for previewing web applications.
OracleAS Reports Services
Oracle Application Server Reports Services enable the rapid deployment and publishing of web-based reports. Reports can also leverage the Oracle Application Server Single Sign-On capabilities and can be embedded as portlets in OracleAS Portal.
Reports are created using the Oracle Reports Developer, a part of the Oracle Developer Suite. Data can be formatted in tables, matrixes, group reports, graphs, and combinations. You can achieve high-quality presentation using Cascading Style Sheets (CSS), an HTML extension. Using OracleAS Reports Services, XML-based reports can be exchanged via HTTP, and paper-based layouts can be deployed over the Internet using PDF format.
Additional Components
The components described in the following subsections provide extended functionality that is an important part of Oracle Application Server. These components relate to specific areas of IT, such as business intelligence and integration, or provide capabilities that can be used by developers, such as OracleAS Portal or the Oracle Internet Directory.
OracleAS Portal
OracleAS Portal, packaged with Oracle Application Server, provides an HTML-based tool for developing web-enabled application interfaces and content-driven web sites. Portal applications can be developed using wizards in a WYSIWYG portal development environment. Using this environment, you can create and deploy static and dynamic portal content. Users can be granted access to the environment to create their own customization. For example, you can grant an OracleAS Portal user permission to choose which content areas and links appear in his portal pages.
Java or PL/SQL developers may wish to leverage the functionality of OracleAS Portal without having to use the Portal Development environment. For such power developers, Oracle also provides a Java and PL/SQL Portal Development Kit for custom portlet development or application integration.
Portals are deployed as an integrated service in Oracle Application Server and can use directory services, the OracleAS Web Cache, J2EE services, and business intelligence services provided by OracleAS Reports Services and OracleAS Discoverer.
OracleAS Discoverer
OracleAS Discoverer is a business intelligence tool used for ad hoc queries and user-generated reports. OracleAS Discoverer also provides an interface to relational online analytical processing (ROLAP) by leveraging analytic features present in the Oracle database and as of 2004, also provides an interface to the Oracle OLAP Option. Included in Oracle Application Server are:
Discoverer Plus
A Java-based browser client that can be used to generate ad hoc queries, reports, and graphs
Discoverer Viewer
An HTML-based browser client that can execute reports or graphs created in Discoverer Plus or the Desktop version of Discoverer
Discoverer Portlet Provider
A package used for lists of workbooks and worksheets
OracleAS Discoverer can leverage the Oracle Application Server Single Sign-On capabilities and can also export workbooks to Oracle Reports Developer for deployment in OracleAS Reports Services.
OracleAS Discoverer has an End User Layer (EUL) that is metadata-driven, enabling business definitions to hide and map to underlying technical descriptions. The EUL is set up and maintained via Oracle Discoverer Administration Edition, a part of the Oracle Developer Suite. Wizards guide the administrator through the process of building the EUL. In addition to managing the EUL, administrators can put limits on resources available to analysts monitored by the OracleAS Discoverer query governor.
Oracle Internet Directory
The Oracle Internet Directory provides users a means of connecting to an Oracle server without requiring a client-side configuration file. The Oracle Internet Directory is a Lightweight Directory Access Protocol (LDAP) directory that supports the Single Sign-On capability of Oracle Application Server.
Oracle Workflow provides a graphical workflow builder that facilitates the modeling of business processes. A rules-based engine and business event system is stored in an Oracle database. Messages can be transmitted via Advanced Queuing (AQ), Oracle Net, HTTP, or HTTP using SSL (HTTPS). Oracle Workflow provides key capabilities needed to deploy Oracle Application Server InterConnect, described in the next section.
Oracle Application Server InterConnect
Oracle Application Server InterConnect provides a heterogeneous application integration platform through logic and services. Deployed in a "hub-and-spoke" manner, Oracle Application Server leverages Oracle Workflow and Oracle AQ to provide a message broker infrastructure. AQ enables asynchronous messages between Oracle databases with adapters available to extend support to other message types and applications. Content-based publish-and-subscribe solutions can be deployed using a rules engine to determine relevant subscribing applications. As new content is published to a subscriber list, the rules on the list determine which subscribers should receive the content, thus efficiently serving the needs of different subscriber communities.
OracleAS InterConnect includes a design-time Integrated Development Environment (IDE), adapters, a metadata repository, a management infrastructure (used with Oracle Enterprise Manager), and SDKs (for writing custom adapters, transformations, and IDE extensions). Adapters are available for HTTP, HTTPS, AQ, Oracle database, FTP, MQSeries, CICS, SAP, PeopleSoft, Siebel, JDEdwards, and CICS.
Oracle Application Server ProcessConnect
Oracle Application Server ProcessConnect is new to Oracle Application Server 10g. Using wizards to create a hub-and-spoke deployment model, it's designed to make business process integration feasible. OracleAS ProcessConnect includes a modeling tool, a metadata repository, and adapters. These adapters are based on the JCA specification and enable connections to technology (such as Web Services), packaged applications (e.g., JD Edwards, PeopleSoft, SAP, and Siebel), and legacy systems.
Oracle Weblogic Server :
Oracle WebLogic Server Application Components :
Oracle WebLogic Server applications can include the following components:
- Web components-HTML pages, servlets, JavaServer Pages, and related files
- EJB components-entity beans, session beans, and message-driven beans
- WebLogic components-startup and shutdown classes
Web designers, application developers, and application assemblers create components by using J2EE technologies such as JavaServer Pages, servlets, and Enterprise JavaBeans.
Components are packaged in Java ARchive (JAR) files-archives created with the Java jar utility. JAR files bundle all component files in a directory into a single file, maintaining the directory structure. JAR files include XML descriptors that instruct WebLogic Server how to deploy the components.
Web Applications are packaged in a JAR file with a .war extension. Enterprise beans, WebLogic components, and client applications are packaged in JAR files with .jar extensions.
An Enterprise Application, consisting of assembled components, is a JAR file with an .ear extension. An .ear file contains all of the .jar and .war component archive files for an application and an XML descriptor that describes the bundled components.
To deploy a component or an application, you use the Administration Console or the weblogic.deploy command-line utility to upload JAR files to the target WebLogic Servers.
Client applications (when the client is not a Web browser) are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI). A Java client can access Enterprise JavaBeans, JDBC connections, JMS messaging, and other services by using RMI.
A Web archive contains all of the files that make up a Web application. A .war file is deployed as a unit on one or more WebLogic Servers. A Web archive can include the following:
- Servlets, JSP pages, and their helper classes.
- HTML/XML pages with supporting files such as images and multimedia files.
- A web.xml deployment descriptor, a J2EE standard XML document that describes the contents of a .war file.
- A weblogic.xml deployment descriptor, an XML document containing WebLogic Server-specific elements for Web applications.
Servlets are Java classes that execute in WebLogic Server, accept a request from a client, process it, and optionally return a response to the client. A GenericServlet is protocol independent and can be used in J2EE applications to implement services accessed from other Java classes. An HttpServlet extends GenericServlet with support for the HTTP protocol. An HttpServlet is most often used to generate dynamic Web pages in response to Web browser requests.
JSP pages are Web pages coded with an extended HTML that makes it possible to embed Java code in a Web page. JSP pages can call custom Java classes, called taglibs, using HTML-like tags. The WebLogic JSP compiler, weblogic.jspc, translates JSP pages into servlets. WebLogic Server automatically compiles JSP pages if the servlet class file is not present or is older than the JSP source file.
You can also precompile JSP pages and package the servlet class in the Web Archive to avoid compiling in the server. Servlets and JSP pages may depend upon additional helper classes that must also be deployed with the Web application.
Web Application Directory Structure
Web application components are assembled in a directory in order to stage the .war file for the jar command. HTML pages, JSP pages, and the non-Java class files they reference are accessed beginning in the top level of the staging directory.
The XML descriptors, compiled Java classes and JSP taglibs are stored in a WEB-INF subdirectory at the top level of the staging directory. Java classes include servlets, helper classes and, if desired, precompiled JSP pages.
The entire directory, once staged, is bundled into a .war file using the jar command. The .war file can be deployed alone or packaged in an Enterprise Archive (.ear file) with other application components, including other Web Applications, EJB components, and WebLogic components.
Enterprise JavaBean Components
Enterprise JavaBeans (EJBs) beans are server-side Java components written according to the EJB specification. There are three types of enterprise beans: session beans, entity beans, and message-driven beans.
Session beans represent a single client within WebLogic Server. They can be stateful or stateless, but are not persistent; when a client finishes with a session bean, the bean goes away.
Entity beans represent business objects in a data store, usually a relational database system. Persistence-loading and saving data-can be bean-managed or container-managed. More than just an in-memory representation of a data object, entity beans have methods that model the behaviors of the business objects they represent. Entity beans can be shared by multiple clients and they are persistent by definition.
A message-driven bean is an enterprise bean that runs in the EJB container and handles asynchronous messages from a JMS Queue. When a message is received on the JMS Queue, the message-driven bean assigns an instance of itself from a pool to process the message. Message-driven beans are not associated with any client. They simply handle messages as they arrive. A JMS ServerSessionPool provides a similar capability, but without the advantages of running in the EJB container.
Enterprise beans are bundled into a JAR file that contains their compiled classes and XML deployment descriptors.
Entity beans and session beans have remote interfaces, home interfaces, and implementation classes provided by the bean developer. (Message-driven beans do not require home or remote interfaces, because they are not accessible outside of the EJB container.)
The remote interface defines the methods a client can call on an entity bean or session bean. The implementation class is the server-side implementation of the remote interface. The home interface provides methods for creating, destroying, and finding enterprise beans. The client accesses instances of an enterprise bean through the bean's home interface.
EJB home and remote interfaces and implementation classes are portable to any EJB container that implements the EJB specification. An EJB developer can supply a JAR file containing just the compiled EJB interfaces and classes and a deployment descriptor.
J2EE cleanly separates the development and deployment roles to ensure that components are portable between EJB servers that support the EJB specification. Deploying an enterprise bean in WebLogic Server requires running the WebLogic EJB compiler, weblogic.ejbc, to generate the stub and skeleton classes that allow an enterprise bean to be executed remotely.
WebLogic stubs and skeletons can also contain support for WebLogic clusters, which enable load-balancing and failover for enterprise beans. You can run weblogic.ejbc to generate the stub and skeleton classes and add them to the EJB JAR file, or WebLogic Server can create them by running the compiler at deployment time.
The J2EE-specified deployment descriptor, ejb-jar.xml, describes the enterprise beans packaged in an EJB JAR file. It defines the beans' types, names, and the names of their home and remote interfaces and implementation classes. The ejb-jar.xml deployment descriptor defines security roles for the beans, and transactional behaviors for the beans' methods.
Additional deployment descriptors provide WebLogic-specific deployment information. A weblogic-cmp-rdbms-jar.xml deployment descriptor for container-managed entity beans maps a bean to tables in a database. The weblogic-ejb-jar.xml deployment descriptor supplies additional information specific to the WebLogic Server environment, such as clustering and cache configuration.
The WebLogic Server components are startup and shutdown classes, Java classes that execute when deployed or at shutdown time, respectively.
Startup classes can be RMI classes that register themselves in the WebLogic Server naming tree or any other Java class that can be executed in WebLogic Server. Startup classes can be used to implement new services in WebLogic Server. You could create a startup class that provides access to a legacy application or a real-time feed, for example.
Shutdown classes execute when WebLogic Server shuts down and are usually used to free resources obtained by startup classes.
Startup and shutdown classes can be configured in WebLogic Server from the Administration Console. The Java class must be in the server's classpath.
An Enterprise Archive (.ear) file contains the Web archives and EJB archives that constitute a J2EE application. The META-INF/application.xml deployment descriptor contains an entry for each Web and EJB module, and additional entries to describe security roles and application resources such as databases.
You use the Administration Console or the weblogic.deploy command line utility to deploy an .ear file on one or more WebLogic Servers in the domain managed by the Administration Server.
Client-side applications written in Java have access to WebLogic Server services via RMI. Client applications range from simple command line utilities that use standard I/O to highly interactive GUI applications built using the Java Swing/AWT classes.
Client applications use WebLogic Server components indirectly, using HTTP requests or RMI requests. The components actually execute in WebLogic Server, not in the client.
To execute a WebLogic Server Java client, the client computer needs the weblogic_sp.jar file, the weblogic.jar file, the remote interfaces for any RMI classes and enterprise beans on WebLogic Server, and the client application classes.
The application developer packages client-side applications so they can be deployed on client computers. To simplify maintenance and deployment, it is a good idea to package a client-side application in a JAR file that can be added to the client's classpath along with the weblogic.jar and weblogic_sp.jar files.
WebLogic Server also supports J2EE client applications, packaged in a JAR file with a standard XML deployment descriptor. The weblogic.ClientDeployer command line utility is executed on the client computer to run a client application packaged to this specification.
No comments:
Post a Comment