3.1. Introduction

The two previous chapters covered more the Java Object Oriented Programming (OOP) conventions and guidelines.

The Design chapter on the other hand will focus on Enterprise Java Object Oriented Design (OOD) using, in a first phase, the more lightweight and pragmatic approach for enterprise Java projects that need to be delivered today using main-stream Java technologies like the Spring Framework, Struts (yes Struts is still used a lot) and Hibernate.

Eventually a second part will get added to this chapter where Java Enterprise Edition 5 (JEE5) will get covered and API's like Java Server Faces (JSF), Enterprise Java Beans (EJB), Java Persistence API (JPA) and even Java Web Beans (JSR-299) will get positioned.

Today and Tomorrow

The above table shows in a very simplistic way the different main-stream frameworks/API's available for our multi-layered Java enterprise project. In this chapter we'll drill-down on the multi-layered design and show you with some code examples and related UML diagram how this all fits together.

I know there are over 100+ web frameworks out there but you'll agree that Struts has been a dominate player for many years, even more with WebWork joining.
Because JEE5 has embraced JSF as the standard API for web applications this is of course an important direction that many of you will follow which also enjoys full-force vendor support. I'm expecting a lot from Java Web Beans (JSR-299), final release around March 2008, which will close the artificial gab between JSF and EJB3 and opening the door to work-flow and process engines. Add the Data-binding API (JSR-227) to the story and the JEE5 future is looking very bright and interesting!

In the middle-tier many people have today embraced the Spring Framework using declarative Remoting strategies, powerful Inversion Of Control (IoC) techniques and even (sometimes without knowing) Aspect Oriented Programming (AOP). Some projects only use the Spring Framework to improve the Data Access Object (DAO) implementation through extending the different templates that Spring supports for Hibernate, JDBC, JDO and even JPA. It goes without saying, but I'll say it anyway, if possible start using JPA today however if this is not possible use the latest Hibernate release with annotations making your potential migration to JPA painless! If you're still on JDK 1.4 (or lower) use Hibernate with XDoclet so at least you start getting a feel for annotation based programming

Java Enterprise Edition Architectures

So before we can drill-down in the design of each layer lets have an overview of the types of Java enterprse architectures we can configure.

Web-based architecture with remote EJB invocation (A1)

The above deployment diagram shows the classical full-blown multi-layered web-based architecture. Each layer/container runs in its own instance of the Java virtual machine (JVM) and communicates with the other containers using either HTTP (client between web container), IIOP (web between EJB container) or JDBC (EJB between database). This kind of architecture is also the classical J2EE setup for which the J2EE patterns have been designed, more on that later.

In the different UML deployment diagrams the database is located in its own container/server. You can of course also choose to include the database on the machine of the EJB container, reducing another network communication bottleneck.

Depending on the skills at hand, some companies prefer to move data business logic into stored procedures instead of centralizing them in Data Access Objects (DAOs). This approach will reduce the complexity of the DAO's and will allow you to leverage your database investment, which is good. The only challenge is how to include your stored procedures in your test plan... your input is welcome

Web-based architecture with local EJB invocation (A2)

In practice often the EJB container runs on the same JVM (Figure 3) as the web container allowing the components to communicate over inter-process communication (IPC) instead of remote procedure calls (RPC). It almost goes without saying that this approach will be faster and is also the kind of setup Spring-based architecture will follow, of course replacing EJB with POJO's (using either Hibernate or JPA, see Figure 4) and JSP/Serlvets with a higher level web framework.

Web-based architecture with local JPA invocation (A3)

With the introduction of JEE5 we now have finally a consolidated Object Relational Mapping (ORM) API called the Java Persistence API (JPA). This standard API will eventually replace Hibernate within the Data Access Objects (DAO). JPA has the same benefits as Hibernate, the founder of Hibernate (Gavin King) was also involved in the JPA specification, where we can easily write unit tests running outside of the container and use annotations (or if you wish an xml file) where you describe the object/relational mappings. 

Fat client architecture with remote EJB invocation (A4)

The next non-browser architecture uses a 'fat' Java swing client that calls a remote EJB over either IIOP (often used in an intranet setup) or HTTP web services (often used in an internet setup).

Fat client architecture with local JPA invocation (A5)

A stand alone Java application using JPA to access the local database using either a Type 1 or 4 JDBC driver or remote database using Type 2 or 3 JDBC driver.
JPA does require JSE5 (or higher) because of its dependency on annotations, if this is not possible you can always consider to use Hibernate instead.

Web service client architecture (A6)

Since EJB 2.1 stateless session beans can implement a Web service endpoint allowing your J2EE application to get triggered by web services. Service Oriented Architectures exist in different flavors some based on the standards SOAP approach or more lightweight strategies like REST and Plain Object XML (POX).

Check out the Parleys.com related SOA talks for more detailed info on REST, POX etc.

Business Process architecture (A7)

The next deployment is a very interesting and promising one.  Here we introduce the Business Process Execution Language (BPEL) API in the UML diagram allowing the business analysts to get introduced within our technical environment.  A simple and straight forward setup is shown in Figure 8 where a remote BPEL process calls a stateless session bean.  Lets have a look at some more advanced configurations... 

Business Process architecture within SCA environment (A8)

The Open Service Oriented Architecture group (OSAO.org) released in November 2005 a first version of their Service Component Architecture (SCA) specification.  This specification is *not* a JSR because SCA is language-neutral programming model.  

"Service Component Architecture aims to provide a model for the creation of service components in a wide range of languages and a model for assembling service components into a business solution - activities which are at the heart of building applications using a service-oriented architecture."

You can see SCA as a new abstraction layer on top of Java EE, allowing business processes to be declared using BPEL and getting wired (using webservices, jms or even CORBA IIOP) to other components such as POJO's, Rule Engines, human interactions and other BPEL components.  The reference implementation is hosted at Apache and is called tuSCAny, both BEA and if I'm not mistaken IBM are using this implementation for their next SOA/SCA compliant products.

You can view an SCA presentation by Michael Rowley on Parleys.com

The main vendors such as IBM, BEA, Oracle, SAP, Sybase, TIBCO, Interface21 (= Spring framework ) and yes even Sun Microsystems (joined in June 2006) have endorsed this specification making it a very promising API for our SOA initiatives!

Lightweight Java Architectures

Our lightweight architecture only needs a web container and will use the Struts framework for the presentation layer, Spring-enabled POJO's for the service implementations and Hibernate for the DAO components. This configuration reflects many main stream enterprise Java projects that have or will get implemented today. Many IT projects out there are still not in a situation where JEE5 can be used, this is why JEE5 design will get introduced in a later phase within this chapter.

So the next sections will drill-down on the lightweight architecture.