Introdução ao Java EE

Introduction to Java EE

1 WHY JAVA EE?

Java EE is the Component Container model for developing, deploy and managing N-Tier web enabled server centric applications. Java EE applications are made up of components.

A Java EE component is a self-contained functional software unit that is assembled into a Java EE application with its related classes and interfaces and its deployment information files and that communicates with other components.

2 WHY COMPONENT CONTAINER MODEL?

The idea behind the Component Container model is to reduce the effort of the enterprise application developer to concentrate on low level system services such as transactions, security, resource management, concurrency, etc.

Container: Handles most of the system level services.

Component: Handles presentation/business logic.

3 JAVA EE COMPONENTS - CATEGORIES

Java EE components are categorized by Presentation (Web Tier) and Business logic (EJB Tier).

EJB Tier:

Session Tier: Usually handles client business requests and it may be stateful. Number of instance equals to number of clients.

Message Tier: Similar to stateless session tier but handles asynchronous messages.

EJB Component Types:

Stateful Session Beans: Are business objects having state, that is, they keep track of which calling client they are dealing with throughout a session and thus access to the bean instance is strictly limited to only one client at a time.

Stateless Session Beans: Are business objects that do not have a state associated with them. However, access to a single bean instance is still limited to only one client at a time and thus concurrent access to the bean is prohibited.

Singleton Session Beans: Are business objects having a global shared state. Concurrent access to the one and only bean instance can be controlled by the container (Container-managed concurrency, CMC) or by the bean itself (Bean-managed concurrency, BMC).

Message Driven Beans: Are business objects whose execution is triggered by messages instead of method calls.

4 WHERE TO USE EJB?

EJB should be used in:

• A large scale deployment;

• To handle transactions;

• To implement fine-grained security. EJB has integrated support for declarative, fine-grained security;

• Business logic re-use (Supporting a variety of clients);

5 EJB LITE

EJB Lite is a lightweight subset of EJB 3.1, including the support for running EJB container embedded in the current java application. So one can run EJB without appserver.

For many applications, EJB technology offers a lot more functionality than those applications really need. The typical application that uses EJB only needs a subset of the features provided by the technology. EJB Lite meets the needs of these applications with a small subset of the features in EJB 3.1 centered on the session bean component model.

EJB Lite should simplify the use of EJB technology for many developers. Developers who use EJB Lite in their applications only need to learn to use a small set of features. In addition, applications developed with EJB Lite can run in application servers that implement either EJB Lite or the full EJB 3.1 API. Also, vendor implementations of EJB Lite should be simpler and more lightweight than full EJB implementations.

6 COMMON ARCHITECTURES

What is a Tier: Logical grouping of application components.

Presentation Tier: Login Screen, Search Screen, Account Screen, etc.

Business Logic Tier: LoginEvaluator, SearchProcessor, AccountManager.

Data: Login Table, Account Table.

Single Tier (Mainframe Based):

• Centralized model as opposed to distribute model.

• Presentation, Business, Logic and Data Access are intertwinded in one monolithic mainframe application.

• Dump terminals are directly connected to mainframe.

• No client side management is required.

• Difficult for updates, maintenance and code reuse because presentation, data model, business logic are intertwined.

Two Tier:

• Fat clients talking to back end database.

• SQL queries sent and raw data returned.

• Presentation, Business Logic and Data Model processing logic in client application.

• DB Product independence compared to single tier model.

• Difficult for updates and maintenance.

• Since data model is tightly coupled to every client if DB schema changes, all clients need to change the data access logic.

• Updates have to be deployed on all clients.

Three Tier (Introducing Browser Web Server):

• No need to maintain any logic on client machine.

• Presentation, Business Logic and Data Access logic are handled in common server.

• Server in turn connected with database.

• Zero Client Management.

7 N-TIER (INTRODUCTION JAVA EE ARCHITECTURE)

N-Tier