Mobile Location Services: The Application Server

This chapter is from the book

Mobile Location Services: The Definitive Guide

Learn More Buy

This chapter is from the book

This chapter is from the book 

Mobile Location Services: The Definitive Guide

Learn More Buy

J2EE Application Server

There are several different approaches to integrating distributed enterprise applications. Typically they involve a high-speed network software bus operated by a transaction server such as BEA Tuxedo. A full discussion of transaction servers is beyond the scope of this book. To simplify our discussion, we focus on a mobile location service solution developed using Java 2 Enterprise Edition (J2EE).

Why Java on the Server?¹

There are many reasons to consider using Java on the server.

It's a Better Third-Generation Language (3GL)

Java is a simpler 3GL than C++, but still provides the necessary capability to scale to solve large problems. Programming in Java can be much faster than programming in C++. With improvements in computer processing power and distributing computing, it is better to take advantage of the reduced development time than the potentially faster run-time.

It's a Better Fourth-Generation Language (4GL)

Java has been designed to be very easy to extend to reusable, high-level business abstractions. Because Java is also object oriented, it can be better suited to encapsulating business logic than a traditional fourth-generation scripting language.

Ubiquitous

Java has a massive developer community and industry support. Java's portability is an additional advantage when it is necessary to support multiple operating environments.

Robust

Java is also very robust, and can considerably reduce time to market. Unlike C and C++, Java does not provide direct access to memory locations (pointers), so memory reference errors, which are hard to diagnose and debug, are rare. Memory leaks are also rare in Java applications, due to the language's automatic garbage collection feature.

Strong Network Support

Because Java grew and developed with the Internet, it is not surprising that it has very strong network support. Java's network facilities allow high-level business object abstractions to be passed by value, allow you to change an object's underlying representations without breaking remote applications, support the ability to load new functionality with standard bytecodes, and provide distributed garbage collection.

Component-Oriented Computing

Java's component-oriented computing model allows applications to be developed with data independent of business logic and business logic independent of presentation logic. This flexibility to reuse components makes development efforts with Java better able to support distributed development teams and long-term code changes.

It Is Fast

The performance of Java compared to native-compiled third-generation languages has improved significantly. It is important that in a distributed business application, only a small portion of the processing time is spent on business logic. The remainder is split between the database management system and the network.

What Is a J2EE Application Server?²

The J2EE specification states a set of minimum characteristics a J2EE application server must exhibit. These characteristics are delivered to your mobile location services infrastructure before you even begin to build. These minimum capabilities of any Java application server are described in the following sections.

Easy to Develop and Can Deploy Distributed Java Applications

A Java application server provides the structure and environment to facilitate building well-formed applications. In addition, the Java application server provides the systems infrastructure and management tools for deploying an enterprise application.

Scales to Permit Thousands of Cooperative Servers to Be Accessed by Tens of Thousands of Clients

Application servers are designed for scale. Preparing an application for deployment in an application server environment might be more complex and time consuming in the short run, but is well worth it in the long run. To deliver on scalability, an application server provides the following:

• It is fully multithreaded.

• It is parsimonious in consumption of network and other scarce resources.

• It has no architectural bottlenecks that prevent linear scaling.

Provides an Integrated Management Environment for Comprehensive View of Application Resources, Network Resources, System Resources, and Diagnostic Information

When substantial revenue and brand equity relies on consistent and high-quality service delivery, it is important to have instant access to robust monitoring and management tools. This suite of tools allows you to watch unchecked exceptions, logs, threads, sockets, network connections, and access control lists. You might want to supplement an application server's management environment with additional tools, but it is not efficient to develop your own suite of management tools. It is important that vendors for different components of your location services infrastructure (such as positioning and spatial analysis) provide systems feedback in accordance with standard monitoring tools such as Simple Network Management Protocol (SNMP) and Remote Monitoring (RMON). This data should be aggregated and monitored using a product such as HP Openview, CA Unicenter, or IBM Tivoli.

Transaction Semantics to Protect Integrity of Data Even as It Is Accessed by Distributed Business Components

Because the application server environment is built to scale, a facility needs to be available to allow data to be processed in a transaction processing model with commits and rollbacks. This prevents data from being corrupted and overwritten, and systems from getting out of sync.

Provides Secure Communications, Including SSL, Access Control Lists, HTTP, and IIOP Tunneling to Communicate Across Firewalls

Security is a key component of any application, and is especially important in an environment that will have thousands or millions of users. Poor security and security breaches shake confidence in your user base. A Java application server provides capabilities to operate from behind a firewall, support for various authentication systems including encrypted certificates, and encrypted communications such as SSL.

Application Server Architecture

All application servers are divided into at least three logical layers: the presentation layer, business logic layer, and data access layer (see Figure 3.2). As discussed earlier, a good application server product also has a systems management and reporting interface. A code level discussion of how these components operate is beyond the scope of this book.

Figure 3.2 Simple J2EE Application Server Architecture.

Presentation Layer

The objective of the presentation layer is to decouple the actual user interface design and implementation from the specialized business logic of your mobile location services development process. For rapid development with minimum errors, it is most effective to have specialization.

Java Servlets and JSP

The Java servlet model is a special set of Java classes that excel in processing requests and creating responses. This model was developed with the generation of HTML Web pages transported across Hypertext Transfer Protocol (HTTP) in mind. Because HTML is related to the XML specifications, this process works equally well for applications that communicate using WML, VXML, GML, or any other proprietary XML specification. In addition, servlets are not limited to supporting the HTTP protocol—it just happens that it is the most common.

The team responsible for developing your user interface will often include people such as graphic designers, user interface specialists, and others. These people often do not have 3GL programming experience, and because servlets are 3GL Java code with graphic elements embedded in them, it can be difficult for your design team to work with. To solve this problem, Java server pages (JSPs) were developed. Java server pages are XML documents that contain tags that embed Java code in the document. When the servlet engine initializes, the JSPs are compiled into a servlet and behave exactly as a servlet from this point on. This allows your design team to operate independently on perfecting what the user will see while the presentation logic developers focus on piecing together business logic into an application and dynamically generating the user interface.

Business Logic Layer

Similar to the presentation logic layer, the objective of the business logic layer is to partition development work into manageable, reusable, and discrete components. Just as the standards used by the presentation logic team to deliver content to clients (WML for WAP phones, VXML for voice browsers, HTML for Web browsers, and specific XML formats for specific XML clients), it is necessary to have a framework and standards for the server-side business logic so the presentation logic team can use the business logic team's tools and services. Business logic should be concerned with application issues such as solving domain-specific problems and should not be concerned with system issues like managing transactions or security enforcement. Application servers provide you with a documented and proven infrastructure with a standard framework and interface for developing your business logic. This is the goal of the Enterprise JavaBeans (EJBs).

According to the EJB specification, the goals of the EJB architecture are:

• To define a component architecture for developing distributed business applications in Java

• To allow components from different vendors to be mixed to provide an enterprise-level solution

• To allow domain-specific developers to build business applications by leveraging a standard set of transaction, security, distribution, multithreading, and system-level facilities

• To address the entire software development lifecycle and provide specifications for using EJBs within interactive development environments (IDEs) during development

• To define methods for interoperability, which includes Common Object Request Broker Architecture (CORBA) and others

EJBs

Enterprise JavaBeans are Java components that implement business logic. EJBs reside within EJB containers that are stored within the EJB server of the application server. A sample EJB environment is shown in Figure 3.3.

Figure 3.3 Sample EJB Environment.

Leveraging standard components of a transaction server, the EJB server provides a number of immediate benefits to the EJB developer:

• Automatic handling of resource pooling for database connections and component instances.

• EJB components have memory and create and destroy methods efficiently managed by the EJB container.

• The EJB container handles concurrency problems of multiple clients accessing the same data or functionality.

• The EJB server implements security, transactional behavior, and persistence. These are configured when the application is deployed.

• EJBs are designed to work correctly in a clustered environment.

• EJB servers support high availability and hardware failover.

Because EJBs are based on a component model, they operate within a specific environment and its interactions are governed according to a specific set of rules. There are three types of EJBs: session beans, which implement a client/server conversation and are typically found managing business process or workflow; entity beans, which represent persistent business objects such as CustomerAccountInformation; and message-driven beans, which allow clients to asynchronously invoke server-side business logic.

In a mobile location services application, session beans might include the following:

• PositionUser: Attempts to update the user's current position

• Notifier: Sends SMS message

• GenerateRoute: Calculates a route between two locations

• CheckoutCounter: Responsible for totaling all the items a user put in a user's shopping cart, processing payment, and sending a message to an inventory system to ship the items to the user's address

Entity beans might include the following:

• Account: Customer's account information

• Inventory: List of items available for purchase

Data Access Layer

An application server's data access layer provides a number of facilities to connect legacy enterprise information systems (EIS), from a relational database to a mainframe transaction processing system. This provides better management and session support than a simple socket. Although some application servers have specially tuned interfaces for proprietary systems, most have also a generic connector for the integration of the proprietary interfaces more commonly found in positioning and spatial analysis products. This is known as the J2EE Connector Architecture (JCA).

J2EE Connector Architecture (JCA)

The JCA architecture enables an EIS vendor to provide a resource adapter that can be plugged in to an application server to provide the underlying infrastructure necessary to integrate with the EIS. The application server and EIS resource adapter collaborate to keep all the systems level components transparent from the application components.

JCA defines a set of system and application contracts. The application contract defines the client interface that the application uses to communicate with the EIS. The most commonly used client interface is the Common Client Interface (CCI), but a proprietary interface could also be used. The system contract is specified in the EIS vendor's resource adapter.

In many ways, a JCA resource adapter operates in a similar way to a Java Database Connectivity (JDBC) driver. In fact a JDBC driver is one example of a resource adapter. The difference is that the adapter is not limited to connecting a database using SQL. The adapter can connect to any type of EIS and use any protocol to communicate with the EIS.

Commercial Application Servers

Commercially available application servers appropriate for mobile location services include the IBM Websphere Everyplace Server (http://www.ibm.com), BEA Weblogic Server (http://www.bea.com), Oracle 9iAS (http://www.oracle.com), Microsoft Mobile Information Server (http://www.microsoft.com), and the freeware Jakarta Tomcat from Apache (http://www.apache.com).

A Scalable J2EE Web Application Network Architecture³

This section presents a scalable and robust network architecture for J2EE-based applications. The architecture spreads the presentation, business logic, and database layers across different sets of physical machines. This technique provides many advantages over other J2EE application architectures, in which the application server executes both presentation and business logic.

The Architecture

A sample of this architecture is shown in Figure 3.4.

Figure 3.4 A Sample Scalable J2EE Web Application Network Architecture.

Load Balancer Cluster

The load balancer cluster contains at least one load balancer that distributes requests evenly across the Web server cluster.

Web Server Cluster

The Web server cluster contains at least one Web server machine. Each Web server should have the following software installed on it:

• HTTP server: For responding to HTTP requests and serving static content

• Servlet/JSP container: For executing servlet and JSP code to generate client output (HTML, XML, WML, etc.)

• EJB container: For communicating with the application server cluster

Application Server Cluster

The application server cluster contains one or more J2EE-compliant application server machines. Each application server is responsible for executing the business logic, which is contained in EJBs.

Database Server Cluster

The database server cluster contains one or more database server machines for storing and retrieving data.

Advantages

This architecture provides many advantages in terms of scalability and robustness.

No Single Point of Failure

Clustering ensures that if any one machine crashes, the application will still run, although performance might degrade. Clustering also provides greater scalability. For example, if a Web server is running at or near capacity, adding additional Web server boxes helps distribute the load.

Reducing Load on the Application Server(s)

With this architecture, all the presentation logic sits in the Web server cluster. This frees up application server resources to execute more business logic, requiring fewer hardware resources for the application server cluster (i.e., new machines or additional CPUs and memory for existing machines). Application servers are generally expensive and licenses tend to be based on the number of CPUs. Thus, offloading presentation-layer work onto cheaper Web server boxes can save a significant amount of money.

Higher Throughput

Because this architecture includes clustering and separates work across multiple network layers, there will be fewer bottlenecks than architectures with less clustering and no separation of the presentation and business logic layers.

Disadvantages

This architecture does have disadvantages, however. Those presented in the following section should be considered when designing systems.

Increased System Management Complexity

This increased complexity comes from two places. First, there are more machines to configure and maintain, which will stress information technology resources. Second, clustering can be complex. Although clustering Web servers is relatively simple, clustering application and database servers is difficult and requires highly skilled personnel.

Increased Software Deployment Complexity

With this architecture, different pieces of the application are spread across different machines. Servlets, JSPs, and static content reside within the Web server cluster, whereas EJBs and other business logic sit inside the application server cluster. Spreading the application across many different physical machines can make maintaining the production environment trickier. For example, when an updated version of your application is released, it can be challenging to verify that all the pieces successfully deploy to the various machines.

Increased Network Traffic and Latency

Because the presentation layer and business logic layer reside on different machines, there will be more traffic across the network than if those two layers were on a single machine. This separation might also slow individual response times slightly.

Additional Techniques

Bypass the Application Server

For nontransactional operations (e.g., reports), one can access the database layer directly from the presentation layer via JDBC. This reduces the response time for these operations, as well as the load on the application server cluster.

Cache Static or Nearly Static Data in the Presentation Layer

If there is data that rarely or never changes, caching it inside the servlet/JSP code reduces the load on the application server cluster and access times for that data.