J2EE

The Java 2 Platform, Enterprise Edition (J2EE), now known as Jakarta EE, defines a
standard for developing multi-tier, distributed enterprise applications. This architecture
separates the application's functionality into distinct tiers, which can be deployed on different
machines to enhance scalability, modularity, and security.

J2EE applications are typically structured as a Four-Tier Architecture (which is an

extension of the common three-tier model):

J2EE Enterprise Tiers and Components

The J2EE platform breaks down the application into four logical tiers, with the middle tier
(Business Logic) often split into the Web Tier and the EJB/Business Tier.

1. Client Tier (Presentation)

This is the client-side layer where the end-user interacts with the application.

 Function: Handles user input and displays application output. It primarily

communicates with the Web Tier.
 Components:
o Web Clients: A standard web browser running static HTML pages and
dynamic content generated by the Web Tier (Servlets/JSPs). These are
typically thin clients.
o Application Clients: Standalone Java applications (like rich desktop
clients) that run on the client machine and can directly access the Business
Tier components.
o Applets: (Historically common) Small programs embedded in HTML pages,
running within a Java Plug-in.

2. Web Tier (Server-Side Presentation)

This is the first tier on the server side, primarily handling client requests and managing the
flow of data between the client and the business logic.

 Function: Processes HTTP requests, controls navigation, generates dynamic web

pages, and acts as a controller in the MVC pattern.
 Container: Web Container (e.g., in Tomcat, WebLogic, JBoss) manages the
execution of Servlets and JSPs.
 Components:
o Java Servlets: Java classes that dynamically process requests and construct
responses.
o JavaServer Pages (JSP): Text-based documents that contain static template
data and dynamic content logic (often used for the "View").
o JavaServer Faces (JSF): A component-based UI framework built on top of
the Servlet API.
3. Business Tier (EJB Tier / Middle Tier)

This layer contains the core logic that defines the application's purpose and functionality.
This logic is decoupled from both the client presentation and the data storage mechanisms.

 Function: Implements the Business Logic, handles complex transactions, enforces

business rules, and manages access to the Enterprise Information System (EIS) Tier.
 Container: EJB Container (part of the J2EE Application Server) manages the
lifecycle of Enterprise JavaBeans, providing services like security, transaction
management, and resource pooling.
 Components (Enterprise JavaBeans - EJBs):
o Session Beans: Implement business processes and logic. They can be Stateful
(for conversations with a specific client) or Stateless (for general, non-client-
specific tasks).
o Message-Driven Beans (MDBs): Used for asynchronous business logic
execution, typically listening for and processing messages from a Java
Message Service (JMS) queue or topic.

4. Enterprise Information System (EIS) Tier (Data Tier)

This is the back-end layer where enterprise data resides and persists.

 Function: Provides connectivity and storage for data sources. The Business Tier is
the only tier that directly interacts with this layer.
 Components:
o Databases: Relational (Oracle, MySQL, PostgreSQL) and NoSQL databases.
o Legacy Systems: Older systems and mainframes containing critical business
data.
o APIs/Technologies: Java Database Connectivity (JDBC) and Java
Connector Architecture (JCA) are used by the Business Tier components to
communicate with the resources in this tier.

J2EE Clients
In the J2EE (Java 2 Platform, Enterprise Edition) multi-tier architecture, the Client Tier
is the end-user interface through which users access and interact with the enterprise
application.

J2EE applications support several types of clients, which are generally categorized based on
whether they are thin (rely heavily on the server for processing) or thick/rich (perform more
processing locally).

1. Web Clients (Thin Clients)

These are the most common clients and represent the thin-client approach, relying on
standard web protocols.

 Description: A standard web browser running on the client machine. These clients
are generally the simplest to deploy and maintain.
 Interaction: They communicate with the Web Tier of the J2EE application using
HTTP/HTTPS and receive content generated by Servlets and JavaServer Pages
(JSPs).
 Technologies:
o HTML, CSS, JavaScript: Used for presentation and dynamic client-side
behavior.
o AJAX/Fetch: Used for asynchronous communication with the server to
update parts of the page without a full reload.

2. Application Clients (Thick/Rich Clients)

These are standalone Java applications that run on the client's machine. They are
considered thick because they contain presentation logic and often directly interact with the
Business Tier.

 Description: A custom-developed Java application that typically uses a graphical user

interface (GUI) framework.
 Interaction: They can communicate directly with the Business Tier using the
Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP) to call
methods on Enterprise JavaBeans (EJBs).
 Technologies:
o Swing or JavaFX: Used for developing rich GUIs.
o Java Naming and Directory Interface (JNDI): Used to look up and obtain
references to EJB components on the server.

3. Applets (Historical)

Applets were small Java programs downloaded from a web server and executed within a web
browser using the Java Plug-in.

 Description: They provided the benefit of a rich Java interface but were deployed
easily via the web.
 Current Status: Applets have been largely deprecated and are no longer commonly
used due to security concerns and the rise of modern web technologies like HTML5
and JavaScript frameworks.

🔗 Client Interaction in J2EE

The J2EE client typically performs the following steps:

1. Initiates a Request: The user interacts with the client interface (e.g., clicks a button).
 2. Accesses the Web Tier: The Web Client sends an HTTP request to a Servlet or JSP
in the Web Tier.
3. Invokes Business Logic: The Servlet/JSP acts as a controller, often delegating the
core processing to a Session Bean in the Business Tier.
4. Receives Response: The Business Tier executes the logic, potentially interacts with
the Data Tier, and returns the result back to the Web Tier.
5. Presents Data: The Web Tier formats the result (e.g., as HTML) and sends it back to
the client browser for display.

Session Management in J2EE

In J2EE (Java 2 Platform, Enterprise Edition), Session Management is the process by
which a server keeps track of a specific user's interaction and state across multiple,
consecutive HTTP requests. Since HTTP is a stateless protocol (meaning each request is
independent), the server needs a mechanism to remember who the user is and what actions
they have taken during their visit to the application.

The HttpSession Object

The core mechanism for session management in the J2EE Web Tier is the HttpSession
object, which is managed by the Web Container (e.g., Tomcat, Jetty).

How It Works:

1. Creation: When a client (browser) makes its first request to a servlet or JSP, and the
server needs to store state for that user, the Web Container creates a new
HttpSession object.
2. Session ID: A unique identifier, the Session ID, is assigned to this new session.
3. Communication: The container then sends the Session ID back to the client, usually
embedded in a Cookie or rewritten into the URL.
4. Subsequent Requests: On all subsequent requests from the same client, the client
sends this Session ID back to the server.
5. State Retrieval: The container uses the received Session ID to locate the
corresponding HttpSession object and makes it available to the Servlets/JSPs
handling the request.
6. Data Storage: Developers use the HttpSession object to store and retrieve user-
specific data as key-value pairs (attributes) using methods like setAttribute() and
getAttribute().

Example: Storing a user's logged-in status or items added to a shopping cart.

🔑 Session Tracking Techniques

The Web Container uses various techniques to maintain the link between the client and the
HttpSession object:

1. Cookies (Most Common)

 The container sends the session ID back to the client in a special cookie, often named
JSESSIONID.
 The browser automatically includes this cookie in all subsequent requests to the
server, allowing the container to identify the session.
 Pros: Seamless, efficient, and standard practice.
 Cons: Requires the client browser to have cookies enabled.

2. URL Rewriting

 If cookies are disabled on the client, the container can append the session ID directly
to the URL of every link generated by the server.
 The format usually looks like: .../[Link];jsessionid=ABCD12345
 Pros: Works even when cookies are disabled.
 Cons: Clutters the URL, requires server-side code to rewrite all links, and can be
exposed if the user bookmarks a page with the session ID.

3. Hidden Form Fields

 In specific scenarios (e.g., submitting a sequence of forms), the session ID can be

stored in a hidden form field (<input type="hidden">).
 The ID is sent back to the server as a parameter when the form is submitted.
 Pros: No reliance on cookies or URL rewriting.
 Cons: Only works when a form is submitted, limiting its general use for navigation.

🛑 Session Lifecycle Management

A session does not last indefinitely. The container manages its lifecycle using the following
events and methods:

Action Description Method/Event

If the session remains inactive for a period defined

Timeout in the deployment descriptor ([Link]), the [Link] timeout setting
container automatically invalidates it.

The application code explicitly ends the session,

Invalidation usually when the user logs out. All session attributes [Link]()
are lost.
Action Description Method/Event

HttpSessionBindingListener can be
valueBound(),
Binding implemented by objects to be notified when they are valueUnbound()
added to or removed from the session.

The J2EE (Java 2 Platform, Enterprise Edition) multi-tier architecture is centrally defined by
its Web Tier (server-side presentation) and EJB Tier (business logic), with J2EE Web
Services providing a standardized way for them to communicate with external systems.

1. Web Tier vs. EJB Tier: Components & Technologies

The Web and EJB Tiers are the two primary server-side layers, each running within its own
specialized container that provides essential services (like security, transaction management,
and lifecycle management).

Feature Web Tier EJB Tier (Business Tier)

Handles client interaction,

Implements the core business logic, handles
controls application flow, and
Primary Role complex transactions, and manages data
generates dynamic web
access.
content.

J2EE Web Container (e.g., in EJB Container (part of the J2EE Application
Container Tomcat, Jetty) Server)

Servlets, JavaServer Pages Enterprise JavaBeans (EJBs): Session Beans

Key
(JSPs), Filters, Tag Libraries, (Stateless/Stateful), Message-Driven Beans
Components
Web Event Listeners. (MDBs).

Primarily accessed by the Web Tier

Accessed by Web Clients
components or Application Clients using
Client Access (browsers) using
RMI-IIOP (Remote Method Invocation over
HTTP/HTTPS.
Internet Inter-Orb Protocol).

Servlet API, JSP API, JSTL

Key EJB API, JTA (Java Transaction API), JMS
(JSP Standard Tag Library),
Technologies (Java Message Service) for MDBs.
JSF (JavaServer Faces).
2. J2EE Web Services
J2EE Web Services allow the application's functionality (typically defined in the EJB Tier)
to be exposed to external, often non-Java, systems over standard network protocols. This is a
key requirement for enterprise interoperability.

Technologies and Components:

 Endpoint Implementation: Web Services in J2EE are often implemented by

exposing a Stateless Session Bean or a Servlet.
 Protocols and Formats:
o SOAP (Simple Object Access Protocol): Used for exchanging structured,
XML-based information between applications.
o WSDL (Web Services Description Language): An XML format used to
describe the service's interface (what methods it offers, how to call them, and
where it is located).
o UDDI (Universal Description, Discovery, and Integration): A registry for
publishing and discovering web services (less common now).
 J2EE APIs for Web Services:
o JAX-RPC (Java API for XML-based RPC) / JAX-WS (Java API for XML
Web Services): APIs used to define and consume SOAP-based web services.
o SAAJ (SOAP with Attachments API for Java): Used for manipulating SOAP
messages and attachments.
o JAXB (Java Architecture for XML Binding): Used for mapping Java objects
to and from XML documents.

3. The .NET Framework in J2EE

The .NET Framework is Microsoft's platform for developing and running applications,
acting as a competitive counterpart to the J2EE/Java EE platform. It is not a component or
technology within the J2EE specification itself.

In a typical enterprise environment with both platforms, the relationship is one of

interoperability (the ability of systems built on different platforms to work together).

Interoperability Mechanisms:

 XML Web Services: This is the most common and standardized way to connect
J2EE and .NET applications.
o A J2EE EJB can be exposed as a Web Service, which a .NET client (using
C# or [Link]) can consume using its built-in SOAP support.
o Conversely, a .NET Web Service can be consumed by a J2EE component
(Servlet or EJB) using JAX-WS.
 Runtime Bridges (Third-Party Tools): Specialized third-party software (like
JNBridgePro) allows Java and .NET code to directly invoke methods on components
from the other platform, bridging the gap between the Java Virtual Machine (JVM)
and the Common Language Runtime (CLR).
  Messaging and Shared Databases: Asynchronous communication is achieved using
standard protocols like JMS (Java Message Service) on the J2EE side and MSMQ
(Microsoft Message Queue) or a shared relational database accessed via JDBC
(J2EE) and [Link] (.NET).

The J2EE (Java 2 Platform, Enterprise Edition) architecture is built upon a set of fundamental
design principles and the application of proven Design Patterns to address the complexities
inherent in building large-scale, distributed enterprise systems. The core goal is to achieve
applications that are scalable, reliable, maintainable, and secure.

Core Architectural Principles

The J2EE platform enforces several principles through its structure and APIs:

1. Multi-Tier Architecture and Separation of Concerns

This is the most critical principle. The application is logically and often physically separated
into distinct layers.

 Principle: Decoupling the various parts of the application (presentation, business

logic, data access) so that changes in one area have minimal impact on others.
 Implementation in J2EE: The Web Tier (Servlets/JSPs) handles the UI
(Presentation), the EJB Tier (Session Beans) handles the core business rules (Logic),
and the EIS Tier (Databases) handles data persistence.

2. Component-Based Development

J2EE applications are constructed from reusable, self-contained components.

 Principle: Use well-defined, modular components to encapsulate specific

functionality, promoting reuse and simplifying development.
 Implementation in J2EE: Servlets, JSPs, and Enterprise JavaBeans (EJBs) are
the primary component models, each with a specific role and lifecycle managed by its
container.

3. Container-Managed Services

The J2EE server environment (the Application Server) provides essential infrastructure
services, freeing developers to focus on business logic.

 Principle: Delegation of cross-cutting concerns (like security, transaction

management, and resource pooling) to the container.
 Implementation in J2EE: The Web Container and EJB Container automatically
handle:
o Transaction Management (JTA): Ensuring data integrity across multiple
operations.
o Security: Authentication and authorization checks.
o Lifecycle Management: Creating and destroying components (like EJBs) as
needed.
4. Loose Coupling and Abstraction

Components should minimize their direct dependency on each other, often communicating
through interfaces or standardized mechanisms.

 Principle: Reduces the complexity and makes the system more flexible and easier to
test.
 Implementation in J2EE: Use of Remote Interfaces for EJBs and APIs like JNDI
(Java Naming and Directory Interface) to look up resources and services, abstracting
the physical location.

📐 Key Design Patterns (Core J2EE Patterns)

J2EE design principles are often implemented using proven design patterns, which are
reusable solutions to common problems in enterprise development.

Presentation Tier Patterns

These patterns manage client requests and view generation:

 Model-View-Controller (MVC): Separates the application into three parts:

o Model: Business logic and data (often handled by the EJB Tier or POJOs).
o View: Presentation/UI (JSPs, HTML).
o Controller: Handles requests, calls the Model, and selects the View (Servlets,
Front Controller pattern).
 Front Controller: A single handler (Servlet) centralizes request processing and
controls workflow for the Web Tier, standardizing the application's entry point.

Business Tier Patterns

These patterns manage the business logic and client interaction with EJBs:

 Session Facade: Provides a unified, coarse-grained interface to the Business Tier.

It bundles related business logic calls into a single method on a Session Bean,
reducing network overhead (remote calls) and simplifying the client's view of the
system.
 Business Delegate: Reduces coupling between the Presentation Tier (Web) and the
Business Tier (EJB). It hides the complexity of looking up (via JNDI) and accessing
the EJB remote interfaces.

Integration Tier Patterns

These patterns handle communication with the data and legacy systems:

 Data Access Object (DAO): Abstract and encapsulate all access to the data source
(database). The business logic components use the DAO interface without knowing
the specific database technology (e.g., JDBC, Hibernate) being used, allowing the
underlying persistence mechanism to change easily.
 Transfer Object (or Data Transfer Object - DTO): An object used to transfer data
efficiently between tiers. Instead of making multiple remote calls to get individual
fields, a single DTO object containing all necessary data is passed, significantly
reducing network traffic.

Alternative Implementations Networking