Java Enterprise Edition (Java EE) is a collection of abstract specifications that together form a complete solution for commonly faced challenges during software development.
Words that are typically heard while studying Java EE includes:
Application Server : It is a concrete implementation of the Java EE abstract specifications. Examples include Payara Server (Glassfish), IBM OpenLiberty, and JBoss Wildfly.
Java Specification Request (JSR) : It is a formal request to the Java community process for addition and enhancements to technologies. It is a body that standardizes APIs on the Java Technology platform and is used to group APIs into silos, e.g. JAX-RS (Java API for RESTful Web Services). For every JSR, there is always a default reference implementation.
Reference Implementation : It is the concrete realization/implementation of an abstract JSR. For instance, the reference implementation for JAX-RS is called Jersey. Java EE in itself is a JSR. Thus, an application server is a collection of the various reference implementations for the Java EE JSR. Java EE is JSR 366, and one of its reference implementation is Glassfish 5.
Jakarta EE : It is Java EE going forward. Oracle moved the Java platform to be hosted by the Eclipse Foundation.
Java EE Basics
There are three key APIs in Java EE.
- Java Persistence API (JPA) . It is responsible for storing and retrieving information from relational databases, which can be extended to handle NoSQL databases. It is the data layer of an application.
- Context and Dependency Injection (CDI API) . It is a standardized way to create highly decoupled applications. It manages various interactions of different components to allow loose decoupling.
- Java API for RESTful Web Services (JAX-RS) . It exposes resources over HTTP protocol as webservices.
Context and Dependency Injection API
Dependency Injection is a specific form of inversion control (software strategy where individual components have their dependencies supplied to them). This externalizes dependency in the application to create loosely coupled components.
- Dependency Injection (Typesafe) : Allows declaration of dependency on types, so that the compiler catches error during runtime.
- Lifecycle contexts : The ability to bind the lifecycle and interaction of stateful components to well-defined but extensible lifecycle components.
- Interceptors : This allows interception of requests to access a certain method.
- Events : A way to develop highly decoupled applications. Events can be fired while observers listen for the fired events.
- Service Provider Interface (SPI) : A set of hooks and API and interfaces that can be used as extensions, e.g. Apache libraries.
Some concepts under the CDI API,
- CDI Bean Discovery : A mechanism where the dependency injection runtime analyzes and discovers beans for it to manage default bean discovery mode, i.e. beans that are annotated, e.g @Annotated. There are three types of bean discovery mode, ALL (includes those beans that are not annotated), ANNOTATED, and NONE.
- CDI Container : A factory in which Java classes comes in and goes out with their functionality and features. It is an application that manages beans.
- Bean and Contextual Instance : A bean is a template which a developer creates. A contextual instance is an instance of a bean created by the CDI container and is managed by it.
Java Persistence API
JPA is used to map objects to relational database tables. The Java Persistence API meets the ORM manifesto tenets.
ORM Manifesto (Object Relational Mapping Manifesto)
- Objects not Tables : Developers write objects not table.
- Convenience, Not Ignorance : An ORM should be convenient. Developers should at least have minimum knowledge on relational databases. ORM is not a way to mask ignorance but convenience.
- Unobtrusive not transparent : An ORM should make it so that developers are able to control what is in the database and have complete control on what is being persisted.
- Legacy Data, New Objects : Expect ORM to allow creation of new objects from legacy data, i.e. reverse engineer legacy database to Java objects.
- Just Enough, not too much : Expect ORM to give us all the tools to solve generally encountered problems due to impedance mismatch (term used to refer to problems that occur due to difference between database model and programming language). An ORM should not be excessively heavy weight.
- Local but mobile : The data is local but there should be an ability that enables the persistent state of the application to travel to different parts of the application.
- Standard API, pluggable implementation : Rely on a standard API but can be swapped implementations if needed.
Some important concepts under JPA,
- The most unit component of JPA entities is a plain old java object (POJO). Every entity must have a unique identifier.
- There are commonly used annotations on JPA entities such as @MappedSuperClass annotation which enables the use of superclasses containing the common fields of entities. @AttributeOverride annotation is used to override entities od the superclass. @Column is used to customize database mappings. @Transient annotation can be used for fields in the entity class that should not be mapped to the database.
- Access type : The process by which the persistence provider accesses states in the entity. Field access happens when the provider accesses class fields directly through reflection. Property access happens when the java bean property methods are used to access states, i.e. use of getter and setter methods. To use property access, the getter method must be annotated with @ Id. Mixed access type uses both field and property access in the same entity class using @Access annotation.
Java API for RESTful Web services
REST Architecture Constraints
- Client and server is independent of each other.
- Stateless : Every single request that comes to the server is a self-contained unique request. The server does not make any assumption from the previous request.
- Cacheable : The system should support caching at different levels to improve performance and scalability.
- Uniform Interface : Means that the client should have general uniform interface for accessing resources on the server and also for interacting with the resources on the server.
- Layered System : The server can be implemented in different layers in a way such that a client need not to worry about a layer system, e.g. a server that supports load balancing.
Some common concepts related to JAX-RS
- HTTP GET method : A request for a resource or resources. A GET request method is idempotent, meaning that making the same request to a method over and over again should not and must not change the state of a resource or data on the server.
- HTTP POST method : A POST request is used to create new resources on the server. It causes a change on the dataset in the server. The POST normally has a body where payload or whatever we want to create on the server is posted or attached.
- HTTP PUT method : This is used semantically to update resources on the server.
- HTTP DELETE method : It is used to delete resources on the server.
- Content types: There are several content types that can be consumed and is produced by request methods, (1) XML, (2) CSV, (3) EXCEL (4) TEXT (5) JSON.
- JAX-RS has a concept of message body writer. They are API constructs used to convert the Java types to relevant type the client expects. @Produces annotation can be used to specify the type to which the Java object response is converted.
- The @Consumes annotation tells the JAX-RS runtime the type of content a given resource method consumes. The JAX-RS runtime will then convert the JSON content passed as a payload to a Java object of type similar to the method parameter.
- JAX-RS Exception Mapper : API construct used to map exceptions to HTTP responses. The @ Provider annotation is used to register an exception mapper to the JAX-RS runtime programmatically.
This is just a very basic introduction to Java EE. Each key API needs more delving to be able to create web application using Java EE.
Thank you for reading!!
Top comments (2)
Will you want to share opinion regarding the change Oracle does to Java EE, esp renaming the packages from javax.* to jakarta.* ?
If so, then you will want to visit the post by Thomas Bowyer : dev.to/tbroyer/the-javax-to-jakart...
No mention of Servlet ?