ETECTURE offers the complete spectrum of an Enterprise Java application
- Functional website with JSF, classic JSPs, or as a lean AngularJS application
- Flexible and lightweight EJB-based micro-services for your business logic
- High-performance persistence with a classic-relational database but also NoSQL databases, such as MongoDB or Neo4j
- Scalable integration of your existing information systems (e.g. SAP, Oracle, etc.)
- Resource-oriented (ReST) or service-oriented (SOA) interfaces for communicating with third-party systems
- Adaptation for operation in a cloud (e.g. Amazon WebServices)
Enterprise Java applications have changed significantly over the last 10 years. While J2EE involved a high level of effort and expense for the selection and adaptation of the appropriate technology, JEE—as it is now called—is a pool of constructive and lightweight standards (JSRs — Java Specification Requests).
The standards consolidated in the JEE specification are developed in a process executed by Oracle and the Java Community and they therefore represent the highest common denominator of all interests. Anyone—regardless of whether they are a company or a private person—can take part in this process and bring in their ideas and interests. The acceptance of JEE within the Java developer community is thus constantly increasing. This is decisive progress compared to the proprietary competition, behind which there is usually one single company.
JEE also defines two compliance profiles with which manufacturers of JEE-compliant application servers can decide how many individual technologies their products actually support. This allows web application servers (referred to as “web profiles”, e.g. Tomcat) to distinguish themselves from fully-equipped application servers (referred to as “full profiles”, such as Glassfish or Wildfly).
For the last three evolution stages (starting with Java EE 5 to the current Java EE 7), there were two primary objectives: simple development and clear specification. There are now hardly any inconsistencies in how application servers should behave in certain scenarios; instead, there are a number of guidelines and rules that the manufacturers have to take into consideration in their products. A conformity check has also been introduced to ensure that a JEE application can be executed with all available application servers.
However, it was the simplification of development that was the decisive breakthrough for the success of JEE. Above all, this was achieved by a consistent definition of conventions. You only create a configuration when you have to deviate from these conventions — for example, because you need a different form of transaction handling, or to change a database schema from a test system to a live system. The business logic already developed remains largely the same, and is thus independent of the technology to be used.
A simple motto could be as follows: “The application server delivers the technology, the developer concentrates on the business logic”. This has a positive effect on the project budget, as expensive integration tests are no longer required; prototypes can be created quickly, allowing the requirements for the business logic to be validated at an early stage.
JEE is therefore ideally suited to the agile method: the properly prepared specification of how a developer should build the application and the great advantage that the technology is only a cross-sectional aspect mean that the “technical debt” (a measure of the accuracy of the existing solution and of how much it deviates from the ideal solution) can be kept low from the very beginning of the project.
But the architecture of JEE applications has also changed. Previously, the focus was on the functional distribution of an application in dedicated hardware systems (tiers), e.g. a separate server was used for data maintenance, business logic, and presentation logic respectively. In JEE today, development is based on layers and thus no longer encapsulates the functionality through hardware but rather by a division of programs into components. Today, a JEE application can run perfectly on one single server.
But this development goes even further: using micro-services, you no longer “cut” the application into horizontal layers, but rather into vertical modules. Each lightweight, flexible module then fulfills a specific functional purpose and can be exchanged. The modules can run on a server completely independently of one another or can be distributed with one server per module. Communication between the modules is easily resolved using ReST via HTTP so that the infrastructure requirements remain reasonable. The advantages of a cloud can therefore also be used for JEE applications. In addition to many small and large simplifications and improvements, the latter is the focus of the specification work that began in September for the next version: Java EE 8.
JEE has no need to fear comparison with other solutions, such as the Spring framework. The great thing about JEE is that application servers bring with them almost everything needed to operate an Enterprise application “out-of-the-box”. The artifacts to be deployed are small and are delivered and installed quickly. The application is configured via the administration consoles of the application servers and therefore does not require recompilation and recomposition of the application.
At ETECTURE, we have been using JEE in many of our projects since we founded the company and we therefore have access to a great wealth of experience. We have a lot of ideas and solutions not only with regard to development, but also for the design phase. We are also involved in the further development of the specification.
In particular, we see the following trend: increasingly, projects are no longer just about creating a pure website but rather an integrative overall solution. In addition to coordinating the execution of the business logic, this “middleware” coordinates the flow of data between the website and the various systems that exist within a company. For example, a content management system or portal is no longer seen as one single system in which the business and adaptation logic has to be integrated; rather, it is seen simply as one component of a complete enterprise application that has to be integrated in the interaction of the other components of the application. The magic phrase is “separation of concerns” — each component fulfills one specific purpose. In the case of the CMS or portal, this is the presentation and not the execution of the business logic or connection to existing Enterprise information systems, such as SAP Accounts Receivable Management or a CRM system from Oracle.
ETECTURE offers the complete spectrum of an Enterprise Java application: from the functional website, through EJB-based micro-services, to adaptation for operation in a cloud. We will be happy to advise you!
[Technical article by Robert Herschke, Software Engineer, ETECTURE 2014]