Step into
the J2EE architecture and process
Tutorial Details:
Step into the J2EE architecture and process
Step into the J2EE architecture and process
By: By Jian Zhong
Develop complete J2EE solutions with an eight-step cycle
n 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. Wi
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Step into
the J2EE architecture and process
View Tutorial: Step into
the J2EE architecture and process
Related
Tutorials:
 Get the app out - JavaWorld January 2001
Get the app out - JavaWorld January 2001
|
Add the power of asynchronous processing to your JSPs - JavaWorld February 2001
Create custom JSP tags to use with JMS ost JavaServer Pages (JSP) developers that
|
Master Java with these introductory books - JavaWorld May 2001
Master Java with these introductory books - JavaWorld May 2001
|
Connect the
enterprise with the JCA, Part 1
Connect the
enterprise with the JCA, Part 1
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
US Department of Energy signs on to J2EE
US Department of Energy signs on to J2EE
|
Reinvented
wheel
Reinvented
wheel
|
Design patterns make for
better J2EE apps
Design patterns make for
better J2EE apps
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
Business process
automation
made easy with
Java, Part 2
Business process
automation
made easy with
Java, Part 2
|
Get the inside
track on J2EE architect certification
Get the inside
track on J2EE architect certification
|
J2EE 1.4 eases Web service development
J2EE 1.4 eases Web service development
|
The J2EE 1.4 Tutorial
The J2EE 1.4 Tutorial is a guide to developing enterprise applications for the Java 2 Platform, Enterprise Edition (J2EE) version 1.4. Here we cover all the things you need to know to make the best use of this tutorial.
|
Add concurrent processing with message-driven beans
Add concurrent processing with message-driven beans
|
Using a JMS Provider with MDBs via the J2EE Connector Architecture
Using a JMS Provider with MDBs via the J2EE Connector Architecture
In this article I will provide a brief introduction to MDB and the J2EE Connector Architecture (JCA), examining how MDBs can be deployed with the JCA 1.5 resource adapter to use a JMS pro
|
Using Timers in J2EE Applications
Using Timers in J2EE Applications
Job scheduling is nothing new--most enterprise applications require the scheduling of tasks and activities. For example, your application may need a timer service to run a business process once a day, or to clean up a te
|
J2EE pathfinder: Implement JSP custom tags in five easy steps
JSP custom tags provide a standardized mechanism for separating presentation and business logic in a dynamic Web page, allowing page designers to focus on presentation while application developers code the back end. In this installment of J2EE pathfinder,
|
Service Orchestration - Cornerstone for Building Service-Oriented Architecture
This Web Cast explains the Service-Oriented Architecture (SOA). Service-oriented architecture is rapidly becoming the cornerstone for enterprise infrastructure, bringing cost reductions and increasing IT and business responsiveness.
|
Struts, JavaServer Faces, and Java Studio Creator:
The Evolution of Web Application Frameworks Sun Microsystems' Craig McClanahan, the creator of the Apache Struts Framework, co-specification lead for JavaServer Faces 1.0, and prime architect for Sun Java Studio Creator's new release, explains all three.
|
The J2EE Architecture allows the programmers to divide their work into two major categories Business Logic Presentation
The J2EE Architecture allows the programmers to divide their work into two major categories Business Logic Presentation Logic
J2EE Architecture
The J2EE Architecture allows the programmers to divide their work into two major categories:
Business
|
|
|
|
