Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Developer's Guide

> ## Chapter 1
> Designing Applications

> This chapter summarizes the Sun Java™ System Application Server 7, Enterprise Edition application design process.

> This chapter contains the following sections:

> - Application Requirements
> - About the J2EE Programming Model
> - Best Practices for Designing J2EE Applications

> ##

> Application Requirements

> When developing a Sun Java System Application Server application, start by identifying the application requirements. Typically, this means developing a widely deployable application that is fast and secure, and that can reliably handle additional requests as new users are added.

> The Sun Java System Application Server meets these needs because it supports the Java™ 2 Platform, Enterprise Edition (J2EE™ platform) APIs as well as a set of pre-existing high performance features. For example, for an online banking application, you can deliver:

> - Security
> - Rapid deployment of specific features; for example, account transfers, account reporting, online trades, special offers to qualified customers
> - Management and administration of different types of end users; for example, individuals, corporations, or internal users
> - Internal reporting
> - Enterprise Information System (EIS) connectivity for access to legacy databases

> ##

> About the J2EE Programming Model

> In the following figure, client machines are running web browser, web service, RMI/IIOP, or Java™ Message Service (JMS) clients; J2EE server machines are running the Sun Java System Application Server; and EIS server machines are running databases and legacy applications. JavaServer Pages™ (JSP™) pages and servlets provide the interface to the client tier, Enterprise JavaBeans™ (EJB™) components reside in the business tier, and connectors provide the interface to legacy applications.

> Figure 1-1 J2EE application layers

> A distributed application model allows different individual application layers to focus on different functional elements, thereby improving performance.

> These application layers are discussed in the following sections:

> - The Client Layer
> - The Presentation Layer
> - The Business Logic Layer
> - The Data Access Layer

> ### The Client Layer

> The client layer is where the user accesses the application. An application may require one of the following types of clients:

> - Browser Clients
> - Simple CORBA Clients
> - ACC Clients
> - Web Service Clients
> - JMS Clients

> For more information about components in the client layer, see the Sun Java System Application Server Developer’s Guide to Clients.

> #### Browser Clients

> In many cases, the client is simply a browser.

> #### Simple CORBA Clients

> You can use any client that is compliant with the Common Object Request Broker Architecture (CORBA) to access EJB components deployed to Sun Java System Application Server. The client can be written in any CORBA-supported language, such as Java, C, C++, Visual Basic, and so on. CORBA clients are typically used when a stand-alone program or another application server acts as a client to services available on the Sun Java System Application Server.

> Sun Java System Application Server supports access to EJB components using the IIOP protocol as specified in the Enterprise JavaBeans Specification, V2.0, and the Enterprise JavaBeans to CORBA Mapping specification.

> Simple CORBA clients that do not use the Application Client Container (ACC) have the following limitations:

> - The Java Naming and Directory Interface™ (JNDI) is not supported. However, you can build name translations and do lookups using standard COSNaming binding.
> - SSL over RMI/IIOP is not supported.
> - Features that are configurable in the sun-application-client.xml and sun-acc.xml files are not available.

> #### ACC Clients

> Sun Java System Application Server supports Application Client Container (ACC) CORBA clients that are written in Java and that use RMI/IIOP to communicate with the server.

> The Sun Java System Application Server provides system services that enable ACC client programs to execute. ACC clients use JNDI to locate services such as EJB components, Java™ Database Connectivity (JDBC™) resources, and JavaMail™ resources. You can configure special features using the application-client.xml and sun-application-client.xml deployment descriptor files.

> All CORBA clients described in this manual are also ACC clients unless otherwise specified.

> #### Web Service Clients

> Typically a business application sends a request to a web service at a given URL using the SOAP protocol over HTTP. The service receives the request, processes it, and returns a response. An often-cited example of a web service is that of a stock quote service, in which the request asks for the current price of a specified stock, and the response gives the stock price.

> Sun Java System Application Server supports Apache SOAP version 2.2 and JAX RPC 1.1. Apache SOAP web services support is also built into Sun ONE Studio 5.

> For more information about web services, see the Sun Java System Application Server Developer’s Guide to Web Services.

> #### JMS Clients

> Java applications that use Java Message Service (JMS) are called JMS clients. A JMS client can create, send, receive, and read messages. Clients that send messages are called producers, and those that receive messages are called consumers. For a detailed overview of JMS, see the Sun Java System Message Queue Developer’s Guide.

> ### The Presentation Layer

> The presentation layer is where the user interface is dynamically generated. An application may require the following J2EE components in the presentation layer:

> - Servlets
> - JSPs
> - Static Content

> In addition, an application may require the following non-J2EE, HTTP server-based components in the presentation layer:

> - SHTML
> - CGI

> For more information about components in the presentation layer, see the Sun Java System Application Server Developer’s Guide to Web Applications.

> #### Servlets

> Servlets handle the application’s presentation logic. Servlets are the page-to-page navigation dispatchers, and they also provide session management and simple input validation. Servlets tie business logic elements together.

> A servlet developer must understand programming issues related to HTTP requests, security, internationalization, and web statelessness (such as sessions, cookies, and time-outs). For a Sun Java System Application Server application, servlets must be written in Java. Servlets are likely to call JSPs, EJB components, and JDBC objects. Therefore, a servlet developer works closely with the application element developers.

> #### JSPs

> JSPs handle most application display tasks, and they work in conjunction with servlets to define the application’s presentation screens and page navigation. JSPs are likely to call EJB components and JDBC objects. The EJB components typically encapsulate business logic functionality. As such, they carry out calculations and other repetitively requested tasks. JDBC objects are used to connect to databases, make queries, and return query results.

> #### Static Content

> You can also provide static content, such as images and HTML pages. Properly designed HTML pages provide:

> - Uniform appearance across different browsers
> - Efficient HTML loading across slow modem connections
> - Dynamically generated page appearances that are servlet or JSP dispatched

> #### SHTML

> SHTML (Server-parsed HTML) files are HTML files that contain tags that are executed on the server. In addition to supporting the standard server-side tags, or SSIs, Sun Java System Application Server 7 allows you to embed servlets and define your own server-side tags.

> #### CGI

> Common Gateway Interface (CGI) programs run on the server and generate a response to return to the requesting client. CGI programs can be written in various languages, including C, C++, Java, Perl, and as shell scripts. CGI programs are invoked through URL invocation. Sun Java System Application Server complies with the version 1.1 CGI specification.

> ### The Business Logic Layer

> The business logic layer typically contains deployed EJB components that encapsulate business rules and other business functions in:

> - Session Beans
> - Entity Beans
> - Message-Driven Beans

> For more information about components in the business logic layer, see the Sun Java System Application Server Developer’s Guide to Enterprise JavaBeans Technology.

> #### Session Beans

> Session beans encapsulate the business processes and rules logic. For example, a session bean could calculate taxes for a billing invoice. When there are complex business rules that change frequently (for example, due to new business practices or new government regulations), an application typically uses more session beans than entity beans, and session beans may need continual revision.

> Session beans are likely to call a full range of JDBC interfaces, as well as other EJB components. Applications perform better when session beans are stateless, although session beans can be stateful. A stateful session bean is needed when a user-specific state, such as a shopping cart, must be maintained on the server.

> #### Entity Beans

> Entity beans represent persistent objects, such as a database row. Entity beans are likely to call a full range of JDBC interfaces. However, entity beans typically do not call other EJB components. The entity bean developer’s role is to design an object-oriented view of an organization’s business data. Creating this object-oriented view often means mapping database tables into entity beans. For example, the developer might translate a customer table, invoice table, and order table into corresponding customer, invoice, and order objects.

> An entity bean developer works with session bean and servlet developers to ensure that the application provides fast, scalable access to persistent business data.

> There are two types of entity bean persistence:

> - Container managed persistence (CMP) - The EJB container is responsible for maintaining the interactions between the business logic and the database.
> - Bean managed persistence (BMP) - The developer is responsible for writing the code that controls interaction with the database.

> #### Message-Driven Beans

> Message-driven beans are persistent objects that are likely to call a full range of JDBC interfaces, much like entity beans. However, message-driven beans have no local or remote interfaces as do other EJB components, and they differ from entity beans in how they are accessed.

> A message-driven bean is a message listener that can reliably consume messages from a queue or a durable subscription. The messages may be sent by any J2EE component—from an application client, another EJB component, or a Web component—or from an application or a system that does not use J2EE technology.

> For example, an inventory entity bean may send a message to a stock ordering message-driven bean when the amount of an item is below a set lower limit.

> ### The Data Access Layer

> In the data access layer, JDBC (Java database connectivity) is used to connect to databases, make queries, and return query results, and custom connectors work with the Sun Java System Application Server to enable communication with legacy EIS systems, such as IBM’s CICS.

> Developers are likely to integrate access to the following systems using J2EE CA (connector architecture):

> - Enterprise resource management systems
> - Mainframe systems
> - Third-party security systems

> For more information about JDBC, see the Sun Java System Application Server Developer’s Guide to J2EE Services and APIs.

> For more information about connectors, see the Sun Java System J2EE CA Service Provider Implementation Administrator’s Guide and the corresponding release notes.

> ##

> Best Practices for Designing J2EE Applications

> This section lists guidelines to consider when designing and developing an Sun Java System Application Server application, and is merely a summary. For more details, you may want to consult Core J2EE Patterns: Best Practices and Design Strategies by Deepak Alur, John Crupi, and Dan Malks.

> The guidelines are grouped into the following goals:

> - Presenting Data with Servlets and JSPs
> - Creating Reusable Application Code
> - Modularizing Applications

> ### Presenting Data with Servlets and JSPs

> Servlets are often used for presentation logic and serve as central dispatchers of user input and data presentation. JSPs are used to dynamically generate the presentation layout. Both servlets and JSPs can be used to conditionally generate different pages.

> If the page layout is its main feature and there is minimal processing involved to generate the page, it may be easier to use a JSP for the interaction.

> For example, after an online bookstore application authenticates a user, it provides a boilerplate portal front page for the user to choose one of several tasks, including a book search, purchase selected items, and so on. Since this portal conducts very little processing, it can be implemented as a JSP.

> Think of JSPs and servlets as opposite sides of the same coin. Each can perform all the tasks of the other, but each is designed to excel at one task at the expense of the other. The strength of servlets is in processing and adaptability. However, performing HTML output from them involves many cumbersome println statements. Conversely, JSPs excel at layout tasks because they are simply HTML files and can be edited with HTML editors, though performing complex computational or processing tasks with them can be awkward. You can use JSPs and servlets together to get the benefits of both.

> For more information on servlets and JSPs, see the Sun Java System Application Server Developer’s Guide to Web Applications.

> ### Creating Reusable Application Code

> Aside from using good object-oriented design principles, there are several things to consider when developing an application to maximize reusability, including the following tips:

> - Use relative paths and URLs so links remain valid if the code tree moves.
> - Minimize Java in JSPs; instead, put Java in servlets and helper classes. JSP designers can revise JSPs without being Java experts.
> - Use property files or global classes to store hard-coded strings such as the data source names, tables, columns, JNDI objects, or other application properties.
> - Use session beans, rather than servlets and JSPs, to store business rules that are domain-specific or likely to change often, such as input validation.
> - Use entity beans for persistent objects; using entity beans allows management of multiple beans per user.
> - For maximum flexibility, use Java interfaces rather than Java classes.
> - Use J2EE CA to access legacy data.

> ### Modularizing Applications

> The major factors to keep in mind when designing your J2EE Applications are:

> - Functional Isolation
> - Reusable Code
> - Prepackaged Components
> - Shared Framework Classes
> - Security Issues

> For more information about assembling modules and applications, see Chapter 4, “Assembling and Deploying J2EE Applications.”

> #### Functional Isolation

> Each component should do one thing and one thing only. For example, in a payroll system, one EJB component should access the 401k accounts while a separate bean accesses the salary database. This functional isolation of tasks leads to the physical isolation of business logic into two separate beans. If separate development teams create these beans, each team should develop its own EJB JAR package.

> ##### Scenario 1

> Assume that the user interface development team works with both of the bean development teams. In this case, the UI development team should assemble its servlets, JSPs, and static files into one WAR file. For example:

> payroll system EAR file = payroll EJB jar
> + 401k EJB JAR
> + 1 common war from the UI team

> This isolation of functionality within an EAR file does not mean that components cannot interact with each other. The beans (in separate EJB JAR files) can call business methods from each other.

> ##### Scenario 2

> Assume that each bean development team has its own UI development team. If this is the case, then each web development team should assemble its servlets, JSPs, and static files into separate WAR files. For example:

> payroll system EAR file = payroll EJB jar
> + 401k EJB JAR
> + 1 payroll UI team's war + 1 401k UI team's war

> With this setup, the components in each WAR file can access components from the other WAR file.

> ##### Assembly Formulas

> Some general formulas should be followed when assembling modules and applications. The following table outlines assembly formulas.

> Table 1-1 Assembly Formulas

> Type of Development Group | Teams in Group | Modularizing Scheme
> --- | --- | ---
> Small workgroup | 1 web team + 1 EJB team | 1 EAR = 1 EJB + 1 WAR
> Enterprise workgroup | 2 EJB teams + 1 web team + 1 component | 1 EAR = 2 EJB + 1 WAR + 1 individual component

> #### Reusable Code

> Reusable components are the primary reason for assembling and deploying individual modules rather than applications. If the code developed by one team of developers is a reusable component that may be accessed by several applications (different EAR files), then that code should be deployed as an individual module. For more information, see Chapter 4, “Assembling and Deploying J2EE Applications.”

> #### Prepackaged Components

> If you do not want to create your application from scratch, you can use prepackaged components. Today's leading J2EE component vendors offer many prepackaged components that provide a whole host of services. Their goal is to provide up to 60% of the standard components needed for an application. With Sun Java System Application Server, you can easily assemble applications that make use of these readily available components.

> #### Shared Framework Classes

> Sometimes several applications need to access a single modular library. In such cases, including the library in each J2EE application is not a good idea for these reasons:

> - Library size: Most framework libraries are large, so including them in an application increases the size of the assembled application.
> - Different versions: Because a separate classloader loads each application, several copies of the framework classes exist during runtime.

> For tips on how to set up a library so multiple applications can share it, see Chapter 4, “Assembling and Deploying J2EE Applications.”

> #### Security Issues

> You should not allow unauthorized runtime access to classes, EJB components, and other resources. A component should only contain classes that are permitted to access other resources included in the component. In addition, you should use the standard J2EE declarative security (see Chapter 3, “Securing J2EE Applications”) for sensitive tasks.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.