Designing Applications

This chapter summarizes the Sun ONE Application Server application design process and offers effective development guidelines.

Application Requirements

When developing a Sun ONE 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 ONE Application Server meets these needs because it supports the J2EE 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 that provides access to information stored in legacy databases

About the J2EE Programming Model

In the following figure, client machines are running web browser, web service, RMI/IIOP, or JMS clients; J2EE server machines are running the Sun ONE Application Server; and EIS server machines are running databases and legacy applications. JSPs and servlets provide the interface to the client tier, EJB components reside in the business tier, and connectors provide the interface to legacy applications.

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

The Client Layer

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

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

Browser Clients

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 ONE 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 ONE Application Server.

Sun ONE 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:

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 ONE 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 ONE Application Server provides system services that enable ACC client programs to execute. ACC clients use the Java Naming and Directory Interface (JNDI) to locate services such as EJB components, JDBC resources, and JavaMail. 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 ONE 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 4.

For more information about web services, see the Sun ONE 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 ONE 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:

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

For more information about components in the presentation layer, see the Sun ONE 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 ONE 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 ONE 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 ONE 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:

For more information about components in the business logic layer, see the Sun ONE 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.

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 ONE 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):

For more information about JDBC, see the Sun ONE Application Server Developer’s Guide to J2EE Features and Services.

For more information about connectors, see the Sun ONE 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 ONE 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.

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 ONE 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

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. The left column lists the type of development group, the middle column lists the teams in the group, and the right column lists the modularizing scheme.

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 ONE 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.

Session and Security Issues

If session sharing is a requirement, all the components that need to access a session should be contained in the same application.



Note	Session sharing across application boundaries is not supported in Sun ONE Application Server and is a violation of the J2EE specification.

If an HTTP session needs to be shared between two WAR files in an EAR file, the session should be marked “distributed” in the deployment descriptor.

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.

Chapter 1 Designing Applications