Java Enterprise Development — The Complete Expert Guide

Written by Gizem Arslan Altınbaş, Senior Backend Developer with 15+ years of Java enterprise experience, including nearly eight years building banking applications at TEB Bank (BNP Paribas) using Java EE, JSF, Spring, and Oracle PL/SQL.

Java has been the backbone of enterprise software for over two decades. If you are building financial systems, corporate applications, or high-availability backends — or if you are hiring a Java developer who knows the platform deeply — this guide is for you.

---

What is Java Enterprise Edition (Java EE / Jakarta EE)?

Java EE (now called Jakarta EE) is the set of specifications and APIs that extend standard Java SE for large-scale, distributed, multi-tier enterprise applications. It defines a runtime environment (the application server) and a collection of APIs covering web services, persistence, messaging, security, and more.

Java EE powers:

• Internet banking and financial trading systems
• Enterprise resource planning (ERP) platforms
• Telecommunications back-office systems
• Insurance and healthcare information systems
• Government and public sector applications

Key facts:

• Originally developed by Sun Microsystems, now governed by the Eclipse Foundation as Jakarta EE
• Runs on application servers: JBoss/WildFly, WebLogic, WebSphere, GlassFish, Payara
• Specification-driven — implementations are interchangeable
• Battle-tested at massive scale in regulated industries (banking, insurance, telecoms)

---

Core Java EE Technologies

Servlets and JSP

The foundation of Java web applications. Java Servlets handle HTTP requests and produce responses. JSP (JavaServer Pages) embed Java logic in HTML templates — the predecessor to JSF and modern view frameworks.

Servlets remain relevant for:

• Building lightweight REST endpoints without a full framework
• Custom filter chains for authentication and logging
• Low-level HTTP handling where framework overhead matters

JSF — JavaServer Faces

JSF is the standard Java EE component-based UI framework for server-rendered web applications. It provides:

• A reusable UI component model (similar to React components, but server-side)
• Managed beans for backing UI state
• Built-in validation and conversion
• Navigation model for page flows
• AJAX support via f:ajax

JSF was the UI technology of choice for Java EE enterprise applications throughout the 2010s. Banking portals, corporate intranets, and financial dashboards were commonly built with JSF + PrimeFaces or RichFaces.

<!-- JSF component example -->
<h:form id="loginForm">
  <h:inputText id="username" value="#{loginBean.username}" required="true" />
  <h:inputSecret id="password" value="#{loginBean.password}" required="true" />
  <h:commandButton value="Login" action="#{loginBean.login}" />
</h:form>

JAX-RS — RESTful Web Services

JAX-RS is the Java EE specification for building REST APIs. It uses annotations to map Java classes and methods to HTTP endpoints.

@Path("/accounts")
@Produces(MediaType.APPLICATION_JSON)
public class AccountResource {

    @GET
    @Path("/{id}")
    public Response getAccount(@PathParam("id") Long id) {
        Account account = accountService.findById(id);
        return Response.ok(account).build();
    }

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    public Response createAccount(AccountDTO dto) {
        Account created = accountService.create(dto);
        return Response.status(201).entity(created).build();
    }
}

Implementations: RESTEasy (JBoss), Jersey (reference implementation), Apache CXF.

WebSocket (JSR 356)

Java EE includes a native WebSocket API for real-time bidirectional communication. Banking applications use WebSocket for:

• Live currency exchange rate feeds
• Real-time balance updates
• Trading system order status
• Notification delivery to browser clients

@ServerEndpoint("/rates/{currency}")
public class ExchangeRateEndpoint {

    @OnOpen
    public void onOpen(Session session, @PathParam("currency") String currency) {
        RateSubscriptionManager.subscribe(session, currency);
    }

    @OnClose
    public void onClose(Session session) {
        RateSubscriptionManager.unsubscribe(session);
    }
}

JDBC and JPA

JDBC is the low-level Java API for relational database access — direct SQL execution, connection management, and result set processing. For high-performance banking applications where SQL control matters, JDBC is preferred over ORM.

JPA (Java Persistence API) provides an object-relational mapping (ORM) layer, allowing Java objects to be persisted to relational databases without writing SQL. Hibernate is the dominant JPA implementation.

For financial applications, experienced developers often choose JDBC + stored procedures over JPA when:

• Queries are complex and performance-critical
• The DBA team owns the data model and SQL
• PL/SQL business logic already exists in the database layer

---

Spring Framework

Spring is the dominant Java application framework — not a Java EE implementation, but a complementary ecosystem that provides:

• Spring Core / IoC — Dependency injection container
• Spring MVC — Web MVC framework (alternative to JSF for REST-first apps)
• Spring Boot — Opinionated, auto-configured starter for rapid application development
• Spring Security — Authentication and authorisation framework
• Spring Data — Repository abstraction over JPA, JDBC, MongoDB, and more
• Spring Integration — Enterprise integration patterns (messaging, adapters)

Spring vs Java EE

	Java EE / Jakarta EE	Spring
Container	Application server	Embedded (Tomcat/Jetty) or standalone
Configuration	XML + annotations (standard)	Annotations + Java config
Boot time	Slower (full app server)	Fast (Spring Boot)
Microservices	Possible but complex	Native (Spring Boot + Spring Cloud)
Standards	JSR specifications	De-facto industry standard
Banking legacy	Very common	Growing adoption

In practice, many enterprise applications use both: Spring for the application layer, running inside a Java EE application server, using Java EE APIs (JTA transactions, JMS, JNDI) where needed.

---

Oracle PL/SQL in Enterprise Java Applications

PL/SQL is Oracle's procedural extension to SQL. In large-scale banking applications, a significant portion of business logic lives in the database layer as stored procedures, functions, and packages.

Why PL/SQL in Banking?

• Performance — Procedures execute within the database, eliminating network round-trips for complex multi-step operations
• Data integrity — Business rules enforced at the database layer cannot be bypassed by application bugs
• Legacy — Decades of accumulated business logic in stored procedures that pre-dates the Java layer
• DBA ownership — Database teams maintain PL/SQL independently of application release cycles

Calling PL/SQL from Java

// Calling a stored procedure via JDBC CallableStatement
public BigDecimal calculateInterest(Long accountId, LocalDate fromDate, LocalDate toDate) {
    String sql = "{ ? = call PKG_INTEREST.CALCULATE(?, ?, ?) }";
    try (CallableStatement cs = connection.prepareCall(sql)) {
        cs.registerOutParameter(1, Types.NUMERIC);
        cs.setLong(2, accountId);
        cs.setDate(3, Date.valueOf(fromDate));
        cs.setDate(4, Date.valueOf(toDate));
        cs.execute();
        return cs.getBigDecimal(1);
    }
}

Common PL/SQL Patterns in Banking

• Packages — Group related procedures and functions; maintain state via package variables
• Cursors — Process large result sets row-by-row
• Triggers — Enforce audit trails and referential integrity automatically
• Bulk operations — BULK COLLECT and FORALL for high-performance batch processing
• Dynamic SQL — EXECUTE IMMEDIATE for runtime query construction

---

Internet Banking Architecture

Internet banking systems are among the most demanding Java enterprise applications. They require:

Three-Tier Architecture

[Browser / Mobile App]
        ↓ HTTPS
[Web Tier — JSF / REST / Node.js]
        ↓ EJB / Service layer
[Business Logic Tier — Java EE / Spring]
        ↓ JDBC / JPA
[Data Tier — Oracle + PL/SQL]

The three tiers may run on separate servers with load balancers, providing horizontal scalability and fault isolation.

Headless Banking — React + Node.js + Java EE Backend

Modern banking portals decouple the frontend entirely:

• Frontend: React / Redux SPA, served from a Node.js BFF (Backend for Frontend)
• Backend: Java EE REST APIs (JAX-RS) consumed by the Node.js BFF
• Authentication: OAuth 2.0 / OpenID Connect
• Real-time: WebSocket for live rate feeds and notifications

This architecture was implemented at TEB Bank for the Corporate Internet Banking replatform — moving from a server-rendered JSF portal to a fully headless React/Node.js frontend backed by Java EE REST APIs.

Security in Banking Applications

Banking applications implement multiple security layers:

• Transport security: TLS 1.2+ enforced on all connections
• Authentication: Multi-factor authentication (OTP via SMS, hardware token, mobile app)
• Session management: Short-lived tokens, server-side session invalidation
• Authorisation: Role-based access control (RBAC) with fine-grained permissions per banking function
• Audit logging: Every user action logged with timestamp, IP, user ID, and request payload
• Input validation: Server-side validation of all inputs — amounts, account numbers, dates

---

Java Build and CI/CD Tools

Maven

Maven is the dominant Java build tool for enterprise applications. It manages:

• Dependency resolution via a central repository (Maven Central)
• Project lifecycle (compile, test, package, deploy)
• Multi-module project builds (common in large banking systems)
• Plugin ecosystem for code generation, static analysis, and reporting

<!-- Maven dependency example -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>6.1.0</version>
</dependency>

Jenkins

Jenkins is the most widely deployed CI/CD tool for Java enterprise projects. A typical Java banking pipeline:

1. Developer pushes to Git / TFS
2. Jenkins detects the change and triggers a build
3. Maven compiles, runs unit tests, produces a WAR/EAR
4. Static analysis (SonarQube, FindBugs/SpotBugs)
5. Deploy to test environment
6. Integration tests
7. Manual approval gate for production deployment

---

Java in Financial Applications — Lessons from TEB Bank

Nearly eight years of Java EE development in a banking environment (TEB Bank, BNP Paribas joint venture) taught several practical lessons:

Transaction Management

Banking operations require ACID transactions. Java EE provides JTA (Java Transaction API) for distributed transactions spanning multiple resources (database + message queue). For most operations, container-managed transactions (CMT) are sufficient:

@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class MoneyTransferService {

    public void transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) {
        accountDao.debit(fromAccountId, amount);
        accountDao.credit(toAccountId, amount);
        auditLog.record(fromAccountId, toAccountId, amount);
        // If any step throws, the entire transaction rolls back
    }
}

Connection Pool Management

Database connections are expensive. Banking applications configure connection pools (Oracle UCP, HikariCP, c3p0) carefully:

• Pool size tuned to database capacity
• Connection validation on borrow
• Statement caching for frequently executed SQL
• Idle connection timeout to release resources

Logging and Audit

Financial applications require comprehensive logging:

• Every API call logged with correlation ID, user, timestamp
• All data modifications logged to an audit table (who changed what, when)
• Error logs with full stack trace and request context
• Log levels configurable at runtime without restart (Log4j2, SLF4J)

---

Java Certifications

Oracle Certified Professional: Java SE 17 Developer

The standard Java certification. Tests:

• Core language features (OOP, generics, collections, streams, lambdas)
• Concurrency (threads, locks, concurrent collections)
• I/O and NIO
• JDBC fundamentals
• Modules (Java 9+)

Oracle Certified Professional: Java EE 7 Application Developer

Tests Java EE platform knowledge:

• Servlets, JSF, JAX-RS, WebSocket
• JPA and bean validation
• EJB (Enterprise JavaBeans)
• CDI (Contexts and Dependency Injection)
• JMS (Java Message Service)

---

Java vs Other Backend Languages

Criterion	Java	Node.js	Python	Go
Enterprise adoption	Very high	High	Moderate	Growing
Banking / finance	Dominant	Growing	Limited	Limited
Performance	High (JVM JIT)	Moderate	Lower	Very high
Ecosystem	Massive (Maven Central)	Large (npm)	Large (PyPI)	Growing
Type safety	Strong (compile-time)	Optional (TypeScript)	Optional (type hints)	Strong
Learning curve	Moderate-high	Low-moderate	Low	Moderate
Legacy codebases	Enormous	Limited	Moderate	Very limited
Concurrency model	Threads + virtual threads	Event loop	GIL-limited	Goroutines

Java's greatest strength in enterprise is its proven track record at scale in regulated industries. A Java EE banking system built in 2010 is still running — and still maintainable — today. That longevity and stability is a core reason banks continue to invest in Java.

---

About the Author: Gizem Arslan Altınbaş

Gizem Arslan Altınbaş is a Senior Backend Developer based in İzmir, Turkey, with 15+ years of software engineering experience. Her career spans Java EE banking systems at TEB Bank (BNP Paribas) and SFCC backend development at OSF Digital.

At TEB Bank she built:

• Corporate Internet Banking — replatformed from Java EE / JSF to headless React/Node.js
• TEB FX — real-time currency exchange system using WebSocket
• PUSULA — internal banking application with Java EE, JSF, Oracle PL/SQL

Her Java expertise covers Java EE, JSF, Spring, JAX-RS, WebSocket, JDBC, Oracle PL/SQL, Maven, Jenkins, and Git — across internet banking, credit, and treasury application domains.

View full career history · View services · Contact Gizem

---