Home > Articles > Programming > Java

Layered Architecture Defined

The primary motivation for layering is to create and to preserve an enterprise-reusable domain model that spans application boundaries. Of course, this can be accomplished with three layers, but introducing two additional layers between the presentation and data source layers further decouples the domain from application presentation and data source requirements (Figure 3.5).

Figure 3.5 Five-Layer Architecture

Let's now take a closer look at the roles and responsibilities of the layers in this proposed five-layer architecture.

Presentation Layer

The presentation layer consists of objects defined to accept user input and to display application outputs. Presentation technologies that can be used with J2EE include

  • HTML/JSP, with servlets acting as Controllers, as we see in the next section

  • Applets, using Abstract Windowing Toolkit (AWT) or Swing

  • Applications, using AWT or Swing

We will focus on the first option, the most common for supporting thin clients and the one that uses the most J2EE technologies, but we will at times bring up issues related to the other two.

Controller/Mediator Layer

Whatever the presentation technology happens to be, requests for domain state and behavior are done through a Controller object defined for the particular presentation requirements. This Controller object implements the Mediator design pattern from [Gamma]. An important design requisite involves making sure that domain-specific logic is not defined in presentation object methods but rather is obtained from a Mediator-referenced domain object. Application navigation topology also is defined within this layer.

Servlets control a client request for dynamic HTML content. Servlets produce HTML by either delegating to a JSP page or simply putting raw HTML tags onto the available PrintWriter. The JSP approach naturally separates the servlet from HTML presentation logic, as JSPs are physical documents, independent of the servlet. However, for producing raw HTML tags, the developer might be tempted to accomplish this with a method defined in a servlet. A better design involves creating a separate HTML-generating class, effectively isolating this functionality (Figure 3.6).

Figure 3.6 A Servlet as a Controller

Servlets don't generate HTML but rather facilitate the production of dynamic HTML content by providing an entry point into a server-side JVM through a Web server. This entry point, known as a servlet, enables the developer to resolve session objects for individual users, access HTML form parameters, and respond with dynamically generated HTML. For a more detailed explanation of the Servlet API, refer to Chapter 4.

Application presentation objects interact with a domain model in generalized ways, regardless of the presentation technology. For instance, a GUI presents a list of choices, a collection of domain model objects; the same collection can be used to populate an HTML list. For that matter, the same collection could be used to provide a list of choices in a voice-response unit interface (Figure 3.7).

Figure 3.7 Mediators Used by Various Presentation Technologies

Mediators capture and decouple application-specific functionality from presentation technology by performing domain model requests for presentation or Controller objects that drive a specific application use case. Mediator classes are defined to satisfy a specific application user interface function or use case; therefore, they are less granular than controllers that usually exist at a component level. Mediators implement behavior that would usually end up in presentation classes as methods/scripts. Moreover, consistently applying mediator objects offers more than just loose coupling a domain model from presentation technologies. Mediators provide a convenient and consistent way to transfer application state between user interfaces, eliminating the typical highly parameterized approach. Additionally, transaction behavior finds an appropriate location in mediator objects, as constraints of navigation and units of work are tied to application-specific functionality.

Mediators also play a role supporting scalability using distributed object technologies, such as EJBs or CORBA. In the case of mediators in a GUI application, making the mediator a distributed object makes for a thin client, and Web-based applications using servlets can keep sessions lightweight by referencing distributed mediator proxies (Figure 3.8).

Figure 3.8 Distributed Mediator Topology

The key to mediators' presentation independence is the enforcement of strict layering, meaning that mediators should not contain any references to presentation objects. However, mediators are free to reference domain object public state and behavior. Care must also be taken not to define domain logic in mediators. This pitfall can be avoided by asking yourself, "Can I still perform or obtain the requested domain operation by using only existing domain objects?" If the answer is, "No, I need a mediator object," the mediator is implementing behavior that belongs in the domain.

Mediators implement the same design intent as controllers. But instead of loosely coupling presentation objects, such as GUI components, mediators help decouple and capture the application presentation requirements of a domain model.

Mediator objects are application specific and possess intimate knowledge of the domain they are mediating on behalf of. So, typically they define methods that quickly delegate requests through to the domain. A common mediator operation involves producing a vector of objects that will be displayed in a drop-down selection list. A developer implementing a JSP page to display this list does not have to write domain-specific code to obtain this list but instead can simply obtain it from a mediator instance. Likewise, a selection will be made from this list and ultimately will result in a "selected" domain instance that an operation will be performed against. Again, instead of defining this application-specific behavior in presentation-specific code, such as a JSP page, the behavior can be captured in methods defined in a mediator class.

It is also worth mentioning that the mediator design is not specific to an HTML/servlet-based application. Mediators are coupled to the domain in an application-specific fashion; however, they do not reference a specific application technology, making them reusable by various presentation technologies. It is realistic to think that a single mediator type can "mediate" for both servlet and GUI-based applications (Figure 3.9).

Figure 3.9 Mediator Servicing Various Presentation Types

In the context of servlet-based applications, mediators provide a convenient and consistent way to store user-specific application session objects. Several servlets are typically defined to support a single Web-based application function. Of course, the Servlet API provides a mechanism to associate domain object state with a user session; however, multiple domain objects could be involved in the function, and having to "get" and "put" multiple objects from the session requires extra bookkeeping. For a detailed discussion on how mediators can be used to help session management, see Chapter 8.

Domain Layer

The domain layer is possibly both the most difficult part of a layered system to understand and the most challenging to implement. To understand what a domain object is, we have to go back to the basic roots of object-oriented programming. When we learn Java programming or OO design, the first examples seen are usually in terms of concrete objects. This might be an example of a control system as in Booch, in which the objects modeled, such as temperature sensors and air conditioners, are physical, or through a simple game in which objects, such as playing cards, are modeled.

Unfortunately, when starting to look at their own day-to-day problems, many programmers instead see more abstract things, such as windows and database tables, not the nice concrete things seen in the books and tutorials. This is unfortunate, as modeling the aspects of a business in software can be one of the most powerful tools that a programmer can bring to bear on solving the most difficult problems in software development. Capturing business abstractions in objects can make a system much more powerful by making it more flexible and can also create a critical distinction between the parts of a system that represent the business problem being solved—its essence—and the "accidents" of implementation resulting from choices in technology that might be transitory.

Domain objects are usually implemented as standard Java classes, which may or may not implement or follow the JavaBeans specification. If domain objects are implemented as JavaBeans, later users of these classes will have more options of how they can be manipulated in visual programming tools, such as VisualAge for Java. Correspondingly, there will be extra features required by the JavaBean specification that must be implemented for these options to be available.

As we have already discussed, J2EE provides another option for implementing domain objects. A programmer can choose to implement domain objects as EJBs, which offers some benefits in distribution, transaction capabilities, and persistence. Even when EJBs are used, a mix of standard Java classes and EJBs can be used, as we will examine in greater detail in the chapters on EJB architecture (Chapters 13 and 22).

Data Mapping Layer

One consequence of building a domain layer as we have described is that if we take a more abstract view of a domain object, it should not be concerned with purely implementation-specific details. For instance, one of the most common questions in enterprise programming is how to extract data from or update data in a database. Rather than making this behavior part of the domain object, a second set of objects is required to perform this function. Separating the behavior out in this way has a number of benefits, including making it possible to change implementation details, such as database vendor or database schema, without changing the domain implementation.

A design like this requires a separate layer, often called a mapping, or persistence, layer, that can move data from domain objects to back-end data sources and vice versa. Several commercial products, such as the VisualAge Persistence Builder, JavaBlend, and TOPLink, can add this behavior. However, for a programmer using J2EE, this behavior will commonly be used through the APIs provided by the EJB container. The EJB container in WebSphere provides a simple and consistent interface for data persistence for entity EJBs. However, we may still need to implement some mapping functions even in designs using EJBs when we need to move data between JavaBeans and EJBs. We cover this topic in depth in a later chapter.

From an architecture design perspective, how mapping operations are engaged from a JavaBean domain should be vendor neutral. Domain models should be implemented as JavaBeans that inherit from a common base class. Methods defined in this class allow an extended class to consistently issue persistent operations for retrieving, saving, and deleting of objects from underlying, "mapped" data sources. A discussion of the Mapper design and implementation details that appear in this book's case study are discussed in Appendix A.

Data Source Access Layer

Relational databases, such as DB2, Oracle, and Informix, are arguably the most common way IT organizations store and query enterprise data. Recognizing this profound market share, Sun delivered the JDBC (Java Database Connectivity) API, which allows the production and execution of vendor-neutral SQL.[1] Developers can use standard ANSI SQL against any JDBC-compliant driver. The specific API and types of available JDBC drivers are beyond the scope of this discussion; refer to the JDBC specification, available on Sun's Java Web site, for more information.

How does this fit into the J2EE architecture? Data source access exists within the EJB portion of the architecture. EJB containers perform mapping and specific persistent operations on behalf of entity objects. Containers accomplish this by using data source access frameworks and such APIs as JDBC. Other objects like servlets and JavaBeans may also use JDBC directly to access enterprise data as well.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020