The Java EE Architect’s Handbook, 2nd Edition

The Java EE Architect’s Handbook, 2nd EditionReviews
Author: Derek C. Ashmore
Pub Date: 2014
ISBN: 978-0972954884
Pages: 268
Language: English
Size: 10 Mb


The Java EE Architect’s Handbook, Second Edition: How to be a successful application architect for Java EE applications

This handbook is a concise guide to assuming the role of application architect for Java EE applications. This handbook will guide the application architect through the entire Java EE project including identifying business requirements, performing use-case analysis, object and data modeling, and guiding a development team during construction. This handbook will provide tips and techniques for communicating with project managers and management. This handbook will provide strategies for making your application easier and less costly to support. Whether you are about to architect your first Java EE application or are looking for ways to keep your projects on-time and on-budget, you will refer to this handbook again and again.
You will discover how to:

  • Design Java EE applications so that they are robust, extensible, and easy to maintain.
  • Assume the role of application architect on Java EE projects.
  • Apply commonly used design patterns effectively.
  • Identify and address application architectural issues before they hinder the development team.
  • Document and communicate the application design so that the development team’s work is targeted.
  • Avoid common mistakes that derail project budgets and timelines.
  • Guide the development team through the design and construction process.
  • Setup effective procedures and guidelines that increase stability and decrease defect reports.
  • Avoid common mistakes that make Java EE applications overly complex and hard to support.
  • Effectively estimate needed resources and timelines.

Who this book is for:

  • Senior Java EE developers looking to assume an architect role.
  • Junior Java EE application architects looking to improve their skills.


Never put anything deployment specific in an object in the business logic layer. Business objects should be reusable in any context (e.g., web transaction, web service, or batch job) without changes. This insulates business logic from changes and developments in the deployment or presentation layers, which change more rapidly than anything else.

To keep business objects independent, business objects don’t reference presentation tier classes or make any assumptions (save for transaction management) about the context in which they will be called. They can assume that they are executed within the context of a transaction, as transaction management typically occurs at the point of deployment.

Many Java EE books guide you toward incorporating business logic directly into enterprise beans. I don’t subscribe to that view because of the rapid pace at which deployment methodologies have changed over the years. Secondly, enterprise bean usage has diminished over the past few years and is recognized as unneeded complexity in many cases.

All public methods should explicitly validate the arguments. If they don’t, you run a significant risk of generating a derivative exception, such as a NullPointerException, which can take longer to debug and fix. If you generate an IllegalArgumentException with a clear message, programming errors in the deployment layer or within business objects that call you will have a better chance at being caught in unit testing.


Objects in the presentation layer produce the pages or screens that users physically see and use. There are several aspects to the presentation side: static content, dynamic content, and navigation. For Java EE applications, HTML pages typically provide static content; and a combination of JSPs and servlets usually provide dynamic content. For applications that require special effects (e.g., mouse-overs), Javascript can be used in combination with either static or dynamically produced HTML. Users navigate pages using controls (e.g., push buttons) on the page.

I was tempted to call this layer the “service” layer, but that would lead to confusion as to why this layer contains enterprise beans. The deployment layer provides remote calling capability for other applications. For instance, it is not uncommon to support mobile applications by publishing Restful web services; those services would be part of the deployment layer.


Most architects leverage third-party frameworks to assist development for web services and user interfaces. Without such frameworks, the amount and complexity of code within these layers would be extremely high. Consequently, the largest deliverable for application architects with respect to these software layers is determining which frameworks will be used.

Some organizations make framework choices for these layers at an enterprise level. There are good reasons for doing this. Most frameworks have significant learning curves. Leveraging the same framework set across the organization optimizes the time spent learning these frameworks. It also makes transferring developers between applications easier and less costly. Furthermore, by consolidating the frameworks in use, it becomes easier to share common code across applications and get greater reuse.

Some organizations leave framework choice up to individual application teams. In these types of organizations, application architects either decide which frameworks will be used or they facilitate the decision. Examples of presentation frameworks commonly used include Spring MVC, Apache Struts (or Struts 2), Java Server Faces, Google Web Toolkit, Freemarker, Apache Velocity, and many others. Examples of web service frameworks commonly used include Apache Axis (2), Apache CXF, Glassfish Metro, and many others.

Once framework decisions are made, application architects usually provide usage guidance. This guidance should address cross-cutting concerns such as error handling, transaction logging, configuration, and build/deployment methodologies. Furthermore, I typically will provide a couple of working examples.

There are several considerations common to the deployment and presentation layers. One of the most important considerations is effectively reusing presentation code. Every website has graphics that are consistently reused throughout the site. Having an ability to reuse visual “components” can greatly optimize development time. The web framework choice for the application will largely dictate strategies for creating visual components and effectively reusing code in the presentation layer. Some web frameworks provide better support for creating and reusing visual components than others. The choice of web framework makes such an excellent example for illustrating a process for selecting a technical product that I use it as an example in the chapter entitled “Making Technology Product Selections.” Material on how to code using specific web frameworks, such as Spring-MVC, Java Server Faces, or Struts, is out of scope for this book.


Another important consideration is security. Most organizations will provide a security architecture for the enterprise along with processes for defining users and authorizing those users for specific web applications and assigning them security roles and security groups. Most developers can assume that users have already been authenticated and are authorized to use the application being called. Developers can assume that the Java EE container will provide them the identity of the authenticated user and the security roles to which they’ve been assigned.

The Java EE container will enforce security constraints defined within the web.xml configuration file for your application. Security constraints will specify secured URLs and indicate which roles are allowed access to them. For instance, if all URLs in your application require the assignment of the Manager role, you might add a security constraint like the following to the web.xml file of the application: