Step into the J2EE architecture and process

Develop complete J2EE solutions with an eight-step cycle

In the commercial world, we use Java 2 Enterprise Edition (J2EE) to solve business problems, to develop commercial software, or to provide contract services to other businesses' projects. If a company wants to build an e-business Website using a multitiered architecture, it usually involves managers, architects, designers, programmers, testers, and database experts throughout the development lifecycle.

For different parties to work efficiently and effectively, they often need a software development process. Some classic development processes include the waterfall model, rapid application development (RAD), and extreme programming. In this article, we will focus on a popular software engineering process, the Rational Unified Process (RUP). RUP provides a disciplined approach to assigning tasks and responsibilities to different roles. Its goal ensures we produce high-quality software that meets user needs within a predictable schedule and budget.

I like to use RUP for J2EE development for three reasons. First, RUP is architecture-centric; it develops an executable architecture prototype before committing resources for full-scale development. Second, RUP is iterative and component-based. The architecture baseline often includes a framework or infrastructure to facilitate adding components through iterations to customize and extend a system's functionality without affecting the rest of the system. Third, RUP employs an industry-standard language, UML, to visually model a system's architecture and components. RUP has four different development phases: inception, elaboration, construction, and transition. This article, however, covers eight essential activities involved in J2EE development from a technical perspective in a manner that maintains the architectural focus.

I. Requirements analysis

The requirements analysis describes what the system should or should not do so that developers and customers can create an initial business contract. You can document functional requirements in business concepts, domain glossaries, use cases, and user interface (UI) mockups. Nonfunctional requirements, such as performance and transactions, you specify in a supplementary requirements document. You can create the high-level UI mockup on paper or in HTML, depending on how deeply you are involved in the project.

Figure 1 shows two sample use cases of a typical e-business system. The viewOrder use case tells us that a user logs into a system through a Web interface, sees an order list, and clicks a link to view order details of a specific purchase order. The addLineItems use case tells us that the user browses a product catalog, selects interesting products, and adds them to a purchase order.

Figure 1. Order use cases

II. Object-oriented analysis

Analysts generate problem domain models: classes, objects, and interactions. Your analysis should be free from any technical or implementation details and should contain an ideal model. Object analysis helps you understand the problem and acquire knowledge about the problem domain. You must maintain a pure domain model without technical details because a business process changes much more slowly than information technologies.

These first two steps -- requirements analysis and object-oriented analysis -- are not J2EE-specific; they are quite generic for many object-oriented methodologies. Figure 2 shows a high-level object analysis model of a pet store sample application. It illustrates the major concepts we identified from requirements analysis use cases. We model these concepts into objects and identify their relationships.

Figure 2. Higher-level analysis model: The pet store domain

The result of requirements and object analyses is the entry point for J2EE architecture development. To develop an architecture, you select a vertical piece -- often a critical part, such as the order domain object model -- for object design, implementation, testing, and deployment. (A vertical piece, an RUP concept, is a small portion of a system. The starting point is a subset of use cases, as shown in Figure 1, and domain analysis models, as shown in Figure 3. The implementation of a vertical piece results in a fully functional mini-system including all the tiers, such as UI-tier JavaServer Pages (JSPs), middle-tier business objects such as Enterprise JavaBeans (EJBs), and often backend databases.) You can apply experience gained from the prototype to domain objects, and let that knowledge serve as a design guideline for the object design stage.

Figure 3. Detailed object analysis model: Order

III. Architecture specification

After the first two steps, the business domain problems and requirements should be clear. Now we'll focus the effort on the technical strategies and architecture. An architecture is a blueprint of all the parts that together define the system: the structure, interfaces, and communication mechanisms. We can further divide an architecture into enterprise and application architectures.

Enterprise system architecture

Enterprise-wide system architecture covers hardware and software infrastructure, network topology, development, testing, production environment, and so forth. These reflect an enterprise's long-term investment. Before development, you want to evaluate your existing software and hardware infrastructure and possibly add new components and upgrade your existing system if it cannot fully support J2EE. You need to thoroughly evaluate hardware, including computers, routers, network switches, and network topology, as they all impact system performance and reliability. Figure 4 shows a possible multitiered network topology.

Figure 4. Enterprise architecture: Network topology

A possible multitiered enterprise architecture shown in Figure 4 has the following major components:

  • A Web browser client may or may not sit behind the client-side organization's firewall
  • An HTTP server is the Web server known to the public. It usually sits in a subnet known as the DMZ
  • Web containers host presentation and possibly business logic components
  • Application containers host business logic components
  • Relational Database Managements Systems (RDBMS) and databases host data and data logic

The system architecture type you use depends on your requirements for security, performance, and reliability, as well as your organization's financial situation. At the least sophisticated end, you can reasonably run a simple second-hand computer in a garage with a phone line. There are many open source operating systems, Web servers, application servers, and database management systems available through the Internet. This system type's cost would be a few hundred dollars and a few sleepless nights.

High-end customers, such as many Wall Street financial institutions, might require a system that continually supports security, high throughput transactions, and unpredictable network traffic. In this situation, you commonly need an n-tier architecture with Web servers and application servers configured as clusters for fault tolerance.

You also need to evaluate the software infrastructure, including the Web server, security management software, application server, domain name management server, database management system, and third-party software components. If you have not purchased your application server yet, selecting a J2EE vendor is an important aspect of this evaluation process. I should note that different vendors implement J2EE quite differently, and some vendors only support old J2EE versions. Additionally, some Web containers or application containers might be faster than others. Other than implementing the J2EE specification, many vendors might also sell J2EE infrastructure components or frameworks. Selecting a stable J2EE vendor who provides support is also critical. Common functionalities that you can purchase or develop at the system infrastructure level include:

  • Transaction
  • Internationalization and localization
  • Clustering and object distribution
  • Session management
  • Application performance measuring and profiling
  • Messaging
  • Workflow management
  • Portal and personalization management
  • Tier-to-tier communication protocols
  • Security and firewalls

Application architecture

Application architecture, built on top of an enterprise-wide system architecture, refers to a specific project or application. After the infrastructure is complete, the architect studies how to build a specific application. If your enterprise architecture only partially supports an old J2EE version, you might first upgrade your system. If you cannot upgrade due to budget or timing concerns, then you may have to work within the technical constraints associated with older versions. While it's important to build enterprise-wide reusable components, you first must be able to use in order to reuse. The ultimate goal here is to satisfy customer requirements -- one project at a time.

An architect is not a designer; architecture and design are two different things. An application architecture's scope is the system's major structure, its architectural design patterns, and the frameworks upon which you can add components. The architecture's major concern realizes nonfunctionality, whereas design is concerned with the business use cases you apply to convert the domain object model into a technical object model. Application architecture is the project's structure, a particular application. Common application architecture decisions you must make through application architecture development include:

  • Functionality partition between tiers
  • Model domain objects
  • What legacy system to save
  • What software components to buy
  • What components to build
  • How to integrate third-party components

The order domain objects in Figure 3 demonstrate how you can model domain objects. With current Java technology, you could distribute domain objects among Web containers as developer-managed persistent objects, EJBs in the application server, or as RDBMS-hosted Java stored procedures.

In the BluePrint pet store, we design the order object as an entity bean, a detail object, and a data access object as shown in Figure 5 and later in Figure 6. When you see this, you should realize its architectural significance. Ask why a domain object in an analysis model maps into so many objects. Ask what would happen if you change the design. You might have heard good things about EJBs, but be aware that the performance of different vendor implementations varies. When a new technology comes along, you need to research and perform hands-on work before plunging into a full-scale design effort. You can often apply the lessons learned about designing and implementing the domain object model's vertical pieces to the design of many other domain objects. This is what architecture development is about.

Figure 5. Order object design model

In the early J2EE days, some object-oriented designers tried to map domain objects into entity beans and pass them across tiers. They obtained nice UML diagrams, but the result was a slow system due to unnecessary network traffic. To go from object analysis directly to object design without architecture development, without clearly understanding a new technology, almost always leads to project failure.

Architectural deliverables

As J2EE architecture is a relatively new topic, the deliverables for a J2EE architect are not well defined. From the pet store sample application, it is difficult to see where architecture stops and design begins. The document begins with a high-level examination of the application architecture, a discussion of the Model-View-Controller design pattern, and an architecture overview. The low-level documentation is available in the source code. There are no UML diagrams. The assignment part of Sun's J2EE Enterprise Architect certification requires all deliverables to be in UML. However, the marks only distribute into one class diagram, one component diagram, and a few object interaction diagrams. These are far from sufficient for real-world J2EE applications. To get started, the architecture specification and process requires at least the following:

  • A system architecture document to describe your existing hardware, software, network topology, and other components
  • An application architecture document to describe the application's major structure, including a logical view of all architecturally significant components, use case components, and legacy components
  • A new components design guideline to describe all design guidelines and architectural decisions, explain all those decisions, and describe possible consequences if an alternative option is used. These guidelines should capture all important base determinants that the new component design must respect to maintain the system's architectural integrity
  • A working architectural prototype to evaluate new technologies; gain experience developing and deploying J2EE applications; build architectural frameworks; address risks by measuring performance, scalability, and ease; as well as prove to project stakeholders that your approach works

After you develop several J2EE solutions and gain more experience, the prototype becomes less important and a few UML diagrams and some design guidelines may be sufficient.

1 2 3 Page
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more