Client/server computing

The J2EE platform is an implementation of the concept of client/server computing. So before we go into detail about the J2EE platform first an introduction to client/server computing in general.

There are many ways to create advanced distributed applications. This tutorial is about one such technology: the J2EE Platform. Other technologies that can do the same, like CORBA, DCOM or .NET, are beyond the scope of this tutorial.

Client/Server definitions

Client/server computing is an area in which there are as many definitions of terms as there are people working in that area. This tutorial also has its own definitions. In discussing client/server computing we have the following starting-points:

• Client/server is a distributed software architecture in which systems are divided into autonomous processes [TODO: we need a distinction between a business process and an OS process], where a client sends requests to a server and that server sends responses as an answer to the request to that client.
• Client/server is a concept that will distribute the autonomous processes over clients and servers, based on the suitability for the task of those clients and servers.

As can be seen clearly from the figure above, it is possible that a server can be the client of another server. In general there is no clear distinction between clients and server besides a concrete request. In a large distributed system almost every client is a server and every server is also a client.

Client/Server logical layering

To understand client/server computing it is important to understand that software can be divided in logical layers. All logical layers together form the application. Each layer in the software is responsible for a specific task in the application. The logical layering of an application does not need to be the same as the physical layering of an application ( see for the physical layering the next paragraph).

In theory we distinguish 6 layers in sofware, as shown in figure below. The layering as shown here is a reference model: in practise the layering will not be so clear as shown here.

Presentation manager

A presentation manager displays the user interface. The presentation manager is responsible for the look and feel of an application: it defines how something is displayed to the user. It is also responsible for the infrastructure of user interface elements that are possible in an application. The user interface elements are not limited to text and controls , but also include things as grafics, sound, animation and movies. A presentation manager is not application dependent. All applications can use the same presentation manager.

In some operating systems there is a clean distinction between a presentation manager and the operating system itself (e.g. Linux/Unix with X-Windows) and a user can choose which presentation manager (s)he will use for the application (this choice is of course limited by the required user interface elements). Other operating systems only offer one presentation manager which is integrated with the operating system (e.g. Microsoft Windows).

Presentation logic

The presentation logic layer is responsible for what is displayed to the user. It defines which screens are displayed, when they are displayed, which navigation paths exist between screens, which fields to display etc.. The presentation logic layer is application dependent.

Application logic

The application logic layer contains the actual application logic. This is the layer where the application functionality is defined. The application logic layer is application dependent.

Business logic

The business logic layer contains the business rules of an organization. All the business rules should be shared between all the applications of the organization. This will ensure that changes in business rules will propagate through all the organization's applications. This layer is not application dependent but organization dependent.

Database logic

The database logic layer contains the data dictionary of the application (or even organization). It describes the tables, their columns, datatypes, primary and secondary keys. This layer is application (or even organization) dependent.

Database manager

This layer is responsible for the actual storage of data. This layer can be application/organization dependent but most of the time it is not. Most of the time the database manager is a commercial off-the-shelve application, which is able to manage many applications. For very simple applications the database manager and the operating file system are the same (persistence).

In practice, the database logic layer and the database manager layer are almost always one layer. Most database managers generate the physical storage facilities of the data on the basis of a database logic written in SQL. Whenever we speak of "database" in this tutorial we mean the integrated database logic / database manager layer.

Client/Server physical layering

When creating a distributed client/server system there are several strategies on can use to divide the logical layers over processes, ranging from all layers on their own process to all layers in one process (which of course is not distributed anymore). One can even choose to implement one layer in multiple processes. A physical layer is called a tier. A tier is for all practical purposes and considerations the same as a process.

In the past, several strategies were implemented with different degrees of success. In the next paragraphs several tier-models are introduced. Note that different books may use some different definitions, although they are always similar.

1-Tier

A 1-tier application is an application in which all 6 logical layers are in 1 physical layer as shown in the picture below.

A 1-tier application is of course not a distributed application but it is mentioned here for completeness only. Most applications known to end users are 1-tier applications. Examples of 1-tier applications are Microsoft Word, Open Office Writer and games like Sim City. But other applications which fall in this category are all kinds of databases that use file sharing mechanismes to achieve multi-user databases like Microsoft Access. They look like multi-tier applications but are in fact 1-tier applications.

2-Tier

A 2-tier application is an application in which the 6 layers are divided over 2 processes. As you can see, below are the three most used variants of that division. The first (left column) one is called 2-tier with a thin client. The client is called thin because the only thing the client manages is the presentation of the application. Everything else is done at the server tier. The third (right column) one is called 2-tier with a thick client. It is called thick because it includes the presentation logic and the application logic as part of its client tier. The second variant (middle column) is just the intermediate form of the two extremes.

A 2-tier application is quite common. Most database driven application built in the 1980's are 2-tier applications. Typical examples of a thin or intermediate client application are all application that use dumb terminals or X-Windows terminals. Typical examples of thick client applications are those applications written in C++ or Visual Basic that require the installation of a JDBC or ODBC driver/datasource which connects directly to a database.

3-Tier

A 3-tier application is an application in which the 6 layers are divided over 3 processes. The figure just shows the 2 most common variants, although other variants do exist. The first (left column) one is the thin client. The second (right column) is the thick client version. The distinction of the tiers is the same as with the 2-tier application.

A 3-tie application is also common as the technology matured enough in the 1990's. Typical examples of a thin client 3-tier application are most web based applications. They consist of a client tier that uses a web browser, a server tier with a webserver and some CGI based technology (or something very similar) and a data tier with a relational database. Typical examples of thick client applications are applications that use technologies as CORBA and DCOM.

3-Tier applications

n-Tier

As the name implies an n-tier application is an application in which the 6 layers are divided over an unknown number of tiers. Practise has shown that not every combination is successful. The figure below shows the 2 most common variants. The first (left column) has a thin client tier and a thin presentation tier (this can be seen in X-Window applications, where the actual output and the presentation logic can live on different machines), a thick business tier and a data tier. The second (right column) has a thin client tier, a thick presentation tier and a data tier.

n-Tier applications started in the late 1990's to appear. Typical examples of the thick presentation n-tier applications are application build based on component technologies as DCOM and J2EE. It is the J2EE variant which we will be discussing in the remainder of the tutorial.

The J2EE Platform

The J2EE platform is first of all a specification of an n-tier distributed application environment. The J2EE specification contains all the APIs and full descriptions of all the runtime components and services a J2EE application can use. Perhaps the most important feature of the specification is the clear distiction between the APIs that together form an application programming model for J2EE applications and the server side runtime environment formed by the components and services.

The second part of the J2EE platform is the reference implementation, which is a complete implementation of the J2EE specification provided by Sun Microsystems. It available both in binary and in source form. The reference implementation can be used to determine the portability of your own J2EE application. It can also be used to compare with your implementation of choice.

The third part of the J2EE platform is the J2EE Compatibility Test Suite. This suite will validate the compliance to the specification of a particular implementation. This suite must be used in conjunction with the Java Conformance Kit (JCK), as this suite starts where the JCK stops.

The fourth part of the J2EE platform is the J2EE SDK. The J2EE SDK includes the reference implementation, application verification and deployment tools and documentation.

The last part, which is not really part of the J2EE platform, is the PetShop Store, which is a J2EE demo application. Because it is a working J2EE demo application available in source code form, it provides the developer with valuable information on the architecture and working of a J2EE application.

The J2EE APIs

The following APIs are defined for the J2EE platform. For the exact version of the API in question please look at the specification itself. During the tutorial we will see some of these APIs in more detail, in the context in which they are used. The APIs can be divided into four types of technologies, according to use. For completeness we also includede some technologies that are actually J2SE technologies, but as the J2EE platform heavily depends on or even extends these technologies they are mentioned here. Notice that in most cases the version numbers of the API specifications are left out. For the most current version numbers of the APIs, please see the specification itself.

Component technologies

The component technologies are the technologies that application developer will actualy extend and implement. It are the component technlogies that implement the presentation, application and business logic layers.

• Java Servlets
  The Java Servlets provides object oriented abstractions for building dynamic web applications. Servlets are server side components that are a platform independent high performance replacement for CGI. Like CGI, Servlets dynamically generate HTML as a result of a HTTP request.

• Java ServerPages (JSP)
  The Java ServerPages are an extension of the Servlet API that simplifies the generation of dynamic web pages by providing template driven web application development. It uses XML/HTML-like tags and Java scriptlets to encapsulate the logic required to generate pages in a platform independent way.

• Enterprise JavaBeans (EJB)
  Enterprise JavaBeans are a distributed component based framework. It provides a standard means of defining server-side components, and specifies a run-time environment for hosting the components on the server side. Theer are 3 main types of EJBs: session beans, entity beans and message driven beans.

Service technologies

The services technologies provide a technical infrastructure the application components can use. As such, they are supportive technologies and most of the application developers will only use these technologies and not extend or implement them.

• JDBC
  JDBC provides platform and vendor independent access to SQL compliant databases. Basic JDBC (version 2.0) is J2SE. The J2EE platform requires, besides the basic APIs, also the JDBC 2.0 Optional Package. JDBC allows transactional querying, retrieval and manipulation of data in a JDBC compliant database. JDBC compliant databases provide either native JDBC drivers or you can use a ODBC-to-JDBC bridge. This means that almost every relational database available can be used on the JsEE platform.

• Java Message Service (JMS)
  JMS provides a Java API for message queuing, and publish and subscribe types of message oriented middleware (MOM). This API is to used if applications in a distributed environment are not able to be connected all the time and the handling of the communication shpould be a-synchronous.

• Java Transaction API (JTA)
  This API is for distributed transaction management. It contains three parts:
  1. A high level application interface that allows transactional applications to begin, commit and commit transactions.
  2. A Java mapping of the X\Open XA protocol which is an industry standard that allows a transactional resource manager to participate in a global transaction controlled by an external transaction manager.
  3. A high level transaction manager interface that allows an application server to control transaction boundary demarcation for an applciation being managed by the application server.

• JavaMail
  This API provides a platform independent and protocol independent framework to build Java based email applications. Although platform independent, JavaMail depends on an underlying email server like Sendmail or MS Exchange Server for the actual sending of an email. It uses IMAP4, POP3 and SMTP as it's underlying transport mechanisms.

• JavaBeans Activation Framework (JAF)
  The JavaBeans Activation Framework is required for JavaMail. JavaMail uses JAF to determine the contents of a MIME message and what appropriate actions can be done accordingly.

• Java Authentication an Authorization Service (JAAS)
  JAAS provides authentication and authorization mechanisms to J2EE applications using concepts like users, realms and groups. JAAS relies on underlying implementations of other authenticating and authorization services like Kerberos through the PAM framework. It can be used to grant permission to execute code based on which user is trying to run the code.

• Java Naming and Directory Interface API (JNDI)
  JNDI standardizes acces to different types of naming services. The API is designed to be independent of any specific naming or directory service implemntation. J2SE also specifies a JNDI service provider interface (SPI) for naming and directory service providers to implement. JNDI is not a J2EE API but a J2SE API.

  The use of JNDI is twofold. Firstly, it provides an interface to provide access to directory service resources like LDAP or NDS. Secondly, it is used by a J2EE application to lookup interfaces used to create e.g. EJBs and JDBC connections.

Integration technologies

The integration technologies help the application developer to integrate the J2EE platform with other platform that may exist in the enterprise.

• Java API for XML (JAXP)
  This API provides abstractions for XML parsers and transformation APIs. JAXP helps to isolate specific XML parsers, or XML Document Object Model (DOM) implementations, or XSTLT transformation APIs from J2EE applicatiopn code.

• Java Connector Architecture (JCA)
  JCA provides a means to integrate J2EE application components to legacy information systems. The JCA specifies a simple architecture that results in components that an application developer can use to access a legacy appplication, typically ERP systems as SAP or Baan, without needing to know much specific about how to work with it.

• Java Interface Definition Language API (IDL)
  IDL allows J2EE application components to communicate with CORBA objects through IIOP (see below). These CORBA objects do not need to written in Java but than be written in every language for which there is a CORBA language binding (e.g. C, C++, COBOL).

Communication technologies

These technologies are mostly transparent for the applciation developer but they are invaluable for any distributed application

• RMI-IIOP API
  This API provides an implementation of RMI over IIOP. This bridges the gap between RMI and CORBA applications. This is the standard communication prototcol to be used between J2EE containers. RMI over IIOP allows the application developer to define a remote interface to any remote object that can be implemented in every language for which there is a CORBA language binding (e.g. C, C++, COBOL).

The J2EE architecture

Containers

The J2EE architecture is a multi-tiered architecture. Depending on the type of client it is a 3-tier or 4-tier architecture. Besides the division of the logical layer into 3 or 4 physical layers, it also specifies the technical infrastructure which must be present in a specific layer. The tier together with the corresponding technical infrastructure is called a "container". A J2EE container is a runtime to manage application components developed according to the API specifications, and to provide access to the J2EE APIs. It provides life cycle management, security, deployment and runtime services to its contained (hence container) application components.

The concept of containers is the most important feauture of the J2EE platform. It seperates the technical infrastructure (the containers) from the J2EE application. This separation, which is achieved through the specification of the J2EE platform, has some interesting consequenses.

First, you only have to develop or buy the infrastructure software once and reuse it for all J2EE applications you develop. In fact, because the infrastructure is defined in the J2EE platform, all implementations of the infrastructure behave the same and therefore they are interchangeable. This means that there is no vendor lock-in, which, in practice, is very handy, because still, some implementations are created more equal than others (sorry George).

Second, because the containers provide all the infrastructural plumbing, the application developer can concentrate on the important part of his work, the actual J2EE application. When the application component is ready it will be deployed in the container.

In the figure below the containers and the division of the logical client/server layers over the physical client/server layers are depicted. The architecture shows 4 containers:

• An application client container for hosting standard Java client applications.
• An applet container for hosting Java applets.
• A web container for hosting Servlets and JSP pages.
• An EJB container for hosting Enterprise JavaBeans.

Figure 7: The J2EE Containers

It also shows some non-container components in the architecture, especially the web browser and the database. Although they are standardized software components, they are not standardized by the J2EE platform. The web browser (actually the HTML etc. it displays) is standardized by the World Wide Web Consortium, the databases (in case of SQL databases) by stardard bodies as ISO, ANSI and X/Open.

As can be deducted from the figure, the J2EE platform offers a very versatile architecture, offering sollutions ranging from thin client (with the web browser as a client), to medium range client (with an applet container as a client) and to thick client (with an application client container as a client).

Container architecture

As seen before, a container is a runtime environment for application components. In the figure below the architecture of a container is shown.

Figure 8: The container architecture

The architecture contains two elements, the container itself and the components that someone put in. The glue between the two is the so called "deployment descriptor". The deployment descriptor is application dependent and therefore the responsibilty of the people that create and deploy the application component. We will describe the creation and deployment of application components later.

The container itself is divided into four parts:

• Container contract

• A set of APIs and protocols specified by the container, that the application components are required to extend or implement. The container uses these APIs and protocls to manage the componenents. Whenever a container needs to create, initialize and invoke methods on application componenents, they are required to implement or extend certain Java interfaces or classes.

• Container services API

• Services provided by the container, which can be used by all application componnents. In general, the services here are the actual implemention of the J2EE APIs mentioned before (JAAS,JNDI,JTS etc.).

• Declarative services

• Services that a container interposes on the application components, based on the deployment description provided for each application component, such as security, transactions etc.

• Other container services

• Other runtime services, related to component lifecycle, resource pooling, garbadge collection, clustering etc.

Containers have to communicate with each other. If the containers are in the same JVM local procedure calls can be used, just as with every other Java program. If the containers run in different JVMs or do not run in a JVM at all, other communication means have to be used. There is no restriction in the specification on which ways of communication have to used. For communication between the browser based clients and the web tier most likely HTTP or HTTPS (HTTP over a secure connection) will be used. RMI-IIOP is the most likely choise for all other communications. But it is also possible to use Java sockets or JNI based software to communicate with third party software.

The client tier

The client tier is responsible for displaying the user interface. Depending on the actual program, it is a program, written in Java or anyother language or a web browser.

As stated earlier, the J2EE platform is a 3/4-tier client/server system. Whether it is a 3 or 4-tier system depends on the client being used (see figure 7). The thin client, with the web browse, typicaly is a 4-tier system, while the thick client, with the standalone Java program running in a application client container, typicaly is a 3-tier system. The intermediate client, with the applet container (which in fact is most of the time a web browser) can be both a 3 and a 4-tier system, although most implementations will be a 4-tier system.

In case of the application client container 3-tier system, the client tier connects directly to the business logic tier. In this case the communication between the client tier and the business tier will be RMI-IIOP based. In case of a web browser based 4-tier system, the client tier connects to the web tier using HTTP or HTTPS.

[TODO: enter here something about when to use web based clients and when to use application container bases client (B2B integration)]

The web tier

The web tier is responsible for the presentation and application logic. The web container contains Servlets and JSP pages that generate the appropriate HTML that can be displayed by the browser based clients. Because of the nature of web tier the components will be highly application dependent, although it is possible that presentation or application logic is shared betweeen applications.

The web tier is loosly coupled with the business logic tier and can either communicate through local procedure calls if they run in the same JVM or RMI-IIOP if they run in defferent JVMs. It is even possible for a web tier to connect to different business logis tiers. This can be used for additional functionality, load balancing or redundancy. Much of these features are hiden by the container from the components and are declarative by nature: to use these feautures you will not have to addapt your components, just the deployment descriptors. This results in a scalable system as far as the web tier is concerned.

The business logic tier

The business logic tier is responsible, as its name indicates, for the business logic. The architecture of the J2EE platform makes it possible to reuse business logic between applications. Because of the loose coupling between the containers and their ability to use remote communications there is no need to run the web tier and the business logic tier on the same machine. Is is even possible to connect to a different business tier from a business tier, providing additional functionality, load balancing or redundancy, just as with the web tier. Thsi is one also by adjusting the deployment descriptors, leaving alone the components themselves. This result in a very scalable system as far as the business logic tier is concerned.

The enterprise information system (EIS) tier

The enterprise information tier consists of databases, ERP system and other legancy applications. Part of the functionality of the J2EE platform is to be able to provide an unified and integrated view on all applications and their data in the EIS tier. The J2EE platform is an excelent platform for enterprise application integration.

The J2EE application development

The J2EE platform distinguishes several roles in the development and deployment lifecycle of EJBs. The usage of roles does not mean that all roles should be played by different people. In most organisations multiple roles will be combined in one employee. But if your project is large it may even be possible that one role is played by many people. The EJB specification speaks of the following roles:

• Enterprise bean provider.
  The role that develops EJB components.
• The application assembler.
  The role that combines EJB components with other softeware (e.g. web components) in order to make a complete application.
• Deployer.
  The role that takes the application and install it on an application server, resolving any references to existing resources in the target environment.
• Application server /EJB container vendor.
  The role that provides the application server on which the application is deployed.
• System administrator
  The role that manages the application after it has been deployed in a target environment.

Althought the specification distinguishes between these roles and we will introduce the roles here, we will assume in the tutorial that you will play all the roles. We consider it essential that people who develop EJBs have a knowledge of all other roles beacause the implementation of an EJB will have an impact on the other roles.

Developing J2EE applications

The EJB specification provides a component architecture, which in this case means that the data and business logic of an application is organized in discrete components that are separated through well defined boundaries (interfaces) and all provide a well defined functionality. The EJB provider is responsible for implementing those components. The boundaries and functionality are not so much technical by nature but are taken from business itself. All components are defined by the domain of the application. All components should be as independent of other components (or communicate through well defined interfaces). A succesfull component can be treated as a black box and can be obtained through a third party vendor.

Deploying J2EE applications

Deploying J2EE application involves the installation of the EJBs and fine tunig the environment in which the EJBs run by adapting the deployment descriptors.

The J2EE application server

A J2EE application server is an application that implements the web- and the EJB-container from the J2EE specification. In general it is not a monolythical application but a suite of integrated applications. Sometimes the suite of applications is of one vender but most of the time the suite is of different vendors or creators. For a list of possible application servers, see here. The fact that a lot of application server providers choose to use applications of different origin proves that the specification of the J2EE platform is a strong and usable one.

Figure 9: The J2EE Application Server

The Askesis J2EE "Hello world!" tutorial is tested on the Askesis Application Server Development Distribution. At this moment is based on JBoss with Tomcat as its web container and Apache as the webserver. For more information on this distribution, see here.

Copyright © 2002-2010 Askesis - Opmerkingen/Comments: webmaster@Askesis.nl