A new emphasis has emerged as the need for Internet services and applications have become prevalent, and has become critical to business operations. Implementing effective enterprise applications requires the development of these capabilities into the design process of large-scale higher-performance architectures. In many cases, the phrase “Quality of Service” (QoS) is synonymous with term “systemic qualities”; such as reliability, availability, “securability”, flexibility, accessibility, manageability, interoperability, portability, reusability etc. These QoS qualities are required at each tier and are not the specific responsibility of any given layer – instead, these layers must complement and co-operate in providing each quality within a given tier. For these reasons, the Java EE (Oracle 2013) application model represents one of the best available design models on which to base the design of your enterprise application. Additionally, Java EE is a set of standard specifications, thus it is truly vendor-independent, as several implementations exist for a specification. Java truly is the number 1 most popular language (Tiobe, 2016) and as such an abundance of available people is joining the ranks of the existing legions of Java developers. Java EE as a framework represents both an abstraction notion of a software architecture as well as a description of development artefacts, making the effort for transcribing between design and implementation much less that of competing application architecture frameworks.

Like all frameworks, the Java EE model is not without some negative aspects, for example; the Java EE specification is a robust one, and as such if your application grows in complexity, you might end up refactoring most of the application code to meet ever-changing requirements. Furthermore, in many production systems, database-related performance problems are very common. Since most database transactions are typically executed via JDBC Datasources (including for APIs such as JPA and Hibernate), performance problems will initially manifest as stuck threads from the Java EE container thread manager (for example, isolated long running SQL statements due to lack of indexes, non-optimal execution plans and returned datasets being too large). Additionally, many programmers complain about the “bloated” nature of the Java APIs – which, can be seen as both a pro and a con, as most of the “plumbing” has already been encapsulated, but this also means that a lot of code and configuration has to be done in order to implement something really simple.

Conclusion: I will use Java EE in most new enterprise application projects, with one caveat; JSF, in my opinion, is flawed because it tries to abstract away HTML, CSS, and HTTP, exactly the reverse of what modern web frameworks do. JSF, like ASP.net, attempts to create statefulness on top of the stateless protocol HTTP and ends up causing a whole host of problems involving shared server-side state. While there are improvements in JSF 2.3 (J Burns, E. and Riem, M, 2015), I think that the model is fundamentally broken. I will instead recommend teams to use simple frameworks such as Spring.io over JSF and embrace web technologies such as HTTP, HTML, CSS, and JavaScript instead.

REFERENCES:

Burns, E. and Riem, M. (2015) ‘JSR 372: JavaServer Faces (JSF2.3) Specification’ [Online], Available at https://jcp.org/en/jsr/detail?id=372 (Accessed September 2016).

Oracle (2013) ‘Java(tm) Platform, Enterprise Edition (Java EE) Specification, v7’ [Online], Available at http://www.oracle.com/technetwork/java/javaee/overview/index.html (Accessed September 2016).

Tiobe (2016) ‘Tiobe Index for September 2016’ [Online], Available at http://www.tiobe.com/tiobe-index/ (Accessed September 2016).