Chapter 4. Architecture. Table of Contents. J2EE Technology Application Servers. Application Models

(1)

J2EE Technology Application Servers

J2EE technology application servers promote the distinction between various portions of applications. This distinc-tion enables developers to design a pordistinc-tion of an applicadistinc-tion with a level of abstracdistinc-tion from the other contributing parts.

Application Models

An application model is the conceptual division of an application into functional components. The Sun ONE Appli-cation Server appliAppli-cation model is component-oriented. This appliAppli-cation model promotes code reusability and faster application deployment.

(2)

The Sun ONE Application Server application model divides an application into these layers:

• Server-side presentation • Business logic

• Data and legacy access

Note

It is not necessary to always have a web server in front of the application server. This situation arises if the application server is behind a firewall.

Architectural Overview

Sun ONE Application Server is based on a new architecture and is a significant enhancement to the Sun ONE appli-cation server products. Implemented largely in Java, except for performance-critical communiappli-cation and security layers, Sun ONE Application Server offers a server platform to rapidly deliver implementations of new and forth-coming J2EE specifications.

(3)

The Sun ONE Application Server architecture is derives the functionality by using proven technologies. The Sun ONE Application Server architecture uses the following technologies:

• Sun ONE Web Server

(4)

Server Process Interactions

Sun ONE Application Server 7 process interaction is very similar to what is currently available in the Sun ONE Web Server 6.0. The administration server is a distinguished Sun ONE Application Server 7 instance. It can administer one more server process instances, on the same machine. Appropriate authentication is performed to grant adminis-trative privileges to a user.

The administration server can be configured to start automatically or can be started manually, by the administrator. The Application Server instance process can be started from the administration server, or can be manually started by the user. In all cases, a watchdog process monitors and restarts the watched process, if it dies.

(Animation: Admin Server desc - see admin guide chap1-p32)

JDBC Support and Connection Pooling

Chapter 4. Architecture

(5)

To access a database, you require to register and configure the JDBC data source. Sun ONE Application Server 7 administration tools provide ways to register and configure JDBC data source. Next, you create and manage named JDBC connection pools using the administrative interface. Each named pool is initialized at server start up and con-figured as per the attributes. If more than one registered JDBC data sources point to the same connection pool they share the same physical pool of connections.

Connection pooling is a mechanism that enables recycling of a connection when it is closed. The connection is not destroyed. The establishment of connections is an resource extensive operation that consumes hardware computing cycles. Therefore, reusing connections can improve performance dramatically by reducing the number of new nections that need to be created and torn down. A data source provides access to connection pools for database con-nectivity. Configuration of connection pools and drivers is done in the server.xml file. This will covered in detail in the Database and Transactions module.

(6)

The code required to implement CMP for a bean can be classified as follows:

• Code to instantiate a persistence manager factory

• Code to specify the database connection the persistence manager uses • Code to create the persistence manager

Bundled PersistenceManager

The persistence manager is implemented as a pluggable API. It is responsible for the transparent persistence of con-tainer-managed beans installed in the EJB technology container and has the following characteristics:

• Uses the datasource registration capabilities provided by the container to register and use the required data-sources

• Can use the Object-to-Relational (O/R) mappings generated by the Sun ONE Studio (formerly called Forte for Java) integrated development environment (IDE) during the creation of containermanaged beans

JMS Support

Sun ONE Application Server provides support for applications that use the Java Message Service (JMS) application programming interface (API) for messaging operations. JMS is a set of programming interfaces that provide a com-mon way for Java applications to create, send, receive, and read messages in a distributed environment.

In particular, JMS is the standards-based way that Java 2 Enterprise Edition (J2EE) applications perform asyn-chronous messaging. Accordingly, J2EE components—Web components or Enterprise JavaBeans (EJB) compo-nents—can use the JMS API to send messages that can be consumed asynchronously by a specialized EJB, called a message-driven bean (MDB).

Sun ONE Application Server support for JMS messaging, in general, and for MDBs, in particular, requires messag-ing middleware that implements the JMS specification — a JMS provider. Sun ONE Application Server uses Sun ONE Message Queue (formerly known iPlanet Message Queue), Version 3.0, as its native JMS provider. Detailed information about JMS support in Sun ONE Application server is covered in JMS Supoort module.

CORBA ORB Support

(7)

Common Object Request Broker Architecture (CORBA) is a standard architecture that is used for distributed object systems. CORBA defines a client request for the services of a distributed object. These services are located by an object reference. The services are defined by an interface.

When a client requests for a service, the Object Request Broker (ORB) locates the object and delivers the request to the object. In addition, ORB delivers any results from the object to the client.

In the Sun ONE architecture, the application client container uses the ORB service to communicate EJB. The ORB supports the following CORBA 2.3.1 specification requirements:

• Transport using RMI-IIOP

(8)

Web Services Support

A web service enables a transaction between two entities using the Web. For example, a web service enabling busi-ness to busibusi-ness transactions and credit card authorizations. A web service can use other web services to offer en-hanced functionality. Multiple web services join together to form a web application.

A web service uses Universal Description Discovery and Integration (UDDI) protocol to locate another web service. Two web services interact with each other by using the Simple Object Access Protocol (SOAP) protocol.

SOAP is a transport mechanism serializes and deserializes java objects as XML/HTTP). Web services runtime relies on SOAP runtime to deliver JAXM, JAX-RPC, JARXR, and other Web Services.