“3 billion devices run Java” – so claims Oracle’s Java advertising slogan, and it would seem they don’t exaggerate. A Java Runtime Environment (JRE) is installed on virtually every PC. But although Java is undoubtedly ubiquitous, it’s pertinent to consider whether it really is the dominant platform in every single case.
There’s no denying that in many specific cases (desktops, servers, mobile devices, blu-ray players and more), the dominance (or otherwise) of the Java platform remains a subject of controversial discussion. For critical business applications, meanwhile, there can be little doubt that Java has asserted itself as the dominant platform.
A contributing factor to this success is Java’s long-time reliance on future-oriented concepts such as object orientation and platform independence, which simplify the maintenance and distribution of applications. In addition, the inclusion of extensive class libraries (e.g. for threads, remote method invocation, data structures, graphical user interfaces and I/O) in earlier versions of Java made the implementation of complex functionalities possible from a relatively early point in time.
The foundations laid in earlier Java versions were quickly extended to cover other aspects of business applications, such as transaction management, security mechanisms and web technologies, paving the way for the standardization and establishment of the Java platform in the enterprise computing field – even if, in recent years, the road has not always been straightforward.
I.1.1 Structure of an Enterprise Java Application
In contrast to ordinary Java programs, Enterprise Java applications are developed for distributed, multi-tier architectures. This means that different parts of the application are typically performed on different computers. Java EE applications for these architectures are divided logically in up to four different layers: client, web, business and persistence.
The client layer contains those parts of the application that require the user to interact with the application. For web applications, the client is a browser. The implementation of the control flow and the generation of web pages is the responsibility of the web layer. This makes it possible for the user to make indirect use of the business logic in the business layer.
If no web application is implemented, the web layer is not needed. Instead, an application client – such as a desktop Java application with a graphical user interface – is used. An application client realizes the control flow of the application itself and makes use of the business logic provided, either directly (though direct use of the business layer) or indirectly (by invoking web services that encapsulate the business logic of the business layer).
Data to be processed for implementation of business logic in the business layer is permanently stored in the persistence layer. In general, database systems (including their abstractions) are used for this storage, so that they can easily be incorporated in the business layer. However, the data can also be stored in other external systems, which can then be integrated via a range of methods, including message communication.
Enterprise Java applications are managed and made available by a Java application server. In addition to providing appropriate runtime environments – or containers – for different parts of the application, it provides horizontal services that can be used by all applications. These include transaction management, authentication, authorization and naming and directory services as well as standardized access to data banks, message queues and other external systems.
Important properties of business applications such as synchronization, load balancing and availability are also guaranteed by the application server and are thus decoupled from the application logic. In this way, the application server facilitates the development of business applications, since programmers are able to concentrate fully on the functional design of the application itself.
An application is built from components that meet a clearly defined purpose within the application and are assigned to a specific layer thereof. The aim of the component model is clear structures, which mean higher transparency, better intelligibility and easier maintainability and extensibility of the application.
I.1.2 The Java Enterprise Edition (Java EE)
The Java standard for multi-tier business applications operates under the name Java Platform Enterprise Edition 7 (Java EE 7) and is defined by specification JSR-342 of the Java Community Process (JCP) – for details, see the PDF of the specification.
The standard is based on the Java Platform Standard Edition (Java SE) and on additional APIs that either implement the component model (e.g. Enterprise JavaBeans) or address specific aspects of a business application (e.g. transactions with the Java Transaction API). These APIs, like all official Java APIs, are standardized by the JCP and published under a separate JSR (Java Specification Request) number.
This is an important process, since it provides a standard for the work of developers and for the work of companies providing application servers or libraries. Makers of servers or libraries know exactly what is required of their product, and developers know what they can assume to be true about the libraries and application servers when programming their application. This enables application servers to be certified for Java EE versions. All specifications are publicly available on the Internet (http://jcp.org).
There have been several ups and downs in the history of Java EE standards. Initial excitement at the beginning of the new millennium quickly gave way to disillusionment, as the standard itself (known in short at the time as J2EE) turned out to be too cumbersome and complex for programmers to master.
This resulted in the development of many (successful) frameworks such as Spring, Seam, Hibernate and Struts, which came into being as “competitors” to parts of the standard or to the standard as a whole. This did not, of course, lead to simplification of the Java landscape, but was the inevitable consequence of a number of practical issues arising from its use.
Given the above, it still holds true today that not every enterprise Java application is based on Java EE. Ultimately, at the time of these competitors being released, the very existence of the Java EE standard was at stake. The turning point came with Java EE 5 in 2006, whose motto was “Ease of Development” and which pursued the goal of simplifying standards and returning the work of the developer to the forefront.
It was with this guiding principal in mind that many ideas and best practices from the various Java frameworks were adopted in Java EE 6 (2009) and in the current version, Java EE 7 (2013). Thanks to these actions, the standard once again came to be recognized as competitive and future-oriented.
I.1.3 Anatomy of a Java EE Application
Java EE applications are different from ordinary Java programs. Although they are mostly created using the Java programming language, programmers base their work on a component model defined by the specification.
Java EE defines components that are responsible, within Java EE web applications, for generating web pages for the browser. The standard technologies Java Servlets, Java Server Pages (JSP) and Java Server Faces (JSF) are provided for the implementation of Web layer components.
Java EE also defines a component technology called Enterprise Java Beans (EJBs) for the business layer. EJBs are dedicated to implementing the business logic, allowing the programmer to draw on the transactional behavior and security mechanisms they supply as standard. The features of a newer technology called Contexts and Dependency Injection (CDI) enables a highly flexible software architecture to be constructed for the application. A brief overview of these technologies can be found in the Cloud Tutorial Java EE in a Day.
A component can consist of different technical artifacts (e.g. XML files, interfaces or classes). Each type of component has its own container within the application server, with the container’s responsibility being to monitor the life cycle of components. Fig I-1 represents this this situation visually. The following chapter will discuss the illustrated Java EE component architecture in more detail.
Fig. I-1 Diagram showing the execution environment of Java EE applications
Discussion
Use the message board below to give the authors your feedback or to discuss this page’s topic with other readers (in English please!). Please don’t expect the authors to answer directly, but they might update the content of this site according to your feedback.