We all know you can’t just jump right in and start coding, so before you embark on your first real-world Java application, read this article to find out what Java architectures are available. This article summarizes the architectural considerations you need to make before you select a Java design strategy.

Once again, the AS/400 is the hot machine. IBM’s push into the Web server market brings to the AS/400 a wealth of new libraries, tools, and services. These new technologies allow you to build solutions on top of application architectures that were previously unavailable (or impractical). New technologies also bring new challenges because they fundamentally change the way you approach, develop, and deploy solutions on the AS/400. Using an order-entry application as an example, this article provides an overview for the problem analysis, building, and deployment steps for the three dominant application architectures offered on this new technological playing field.

Inside-out Design

Imagine a simple order-entry application. To operate it, the user enters a customer name, picks a product to purchase, enters a quantity, and then submits the order. For its part, the application provides a unique product list per customer and verifies the customer’s credit (based on the quantity requested) before processing the order. Typically, in procedural-based languages, you will model this problem in terms of the process the user follows (for example, entering a customer, selecting a product, and processing the order). In Java, however, you model the problem in terms of the objects involved. These objects will include such things as the customer, the customer-entry window, the order, and the order-entry window.

I have heard several procedural programmers describe this new design process as “inside-out” thinking. You do the same tasks in your analysis as you would for a procedural-based language. You model your data. You define your transactions. You define your displays. The whole modeling process, however, is from a different point of view. For the architectures presented in this article, you define your application in terms of the objects that are responsible for user interaction, business logic, and data interaction.

User-interaction objects are responsible for displaying data to the user, capturing data from the user, and performing syntactic validation (valid ranges, formats, and masks). User-interaction objects do not make any assumptions on the meaning of the data. They rely on business-logic objects for that. In the example, the fact that the product list is specific to each customer is a concern of the business-logic objects, not the user-interaction objects. You need only ensure that the user-interaction object passes the customer information to the appropriate business-logic object, such as the one that models a customer. Business-logic objects provide semantic validation, business-level behavior, and transactions. The credit check is an example of semantic validation because it must interpret some of the data. The customer-specific product list is an example of business-level behavior, and order processing is an example of transactions.

Business-level objects do not make assumptions of how the data is to be displayed. They need only provide an interface for the user-interaction objects. Business-level objects do not worry about how to read in the data or how to write it out. They use the interface provided by the data-interaction objects. Data-interaction objects connect to the database, request data, cache data, and write back to the database. There is very little difference between these objects and the DB2/400 logical files you use now. In many cases, they will be simple programming structures that provide a Java face to your existing logical files.

Building and Deploying Client/Server Applications

In Java, a client/server architecture consists of a Java Virtual Machine (JVM) running a Java application on a client machine. The client application uses the Java Database Connectivity protocol (JDBC) to communicate with a DB2 database on an AS/400. In this architecture, the user-interaction objects, the business-logic objects, and the data-interaction objects are deployed and executed on the client machine. The AS/400 is used only to run the database. (See Figure 1 for an illustration of a client/server architecture.)

In this architecture, the order-entry application has one user-interaction object: an order-entry screen. Java offers two APIs to build the screen: the Abstract Windowing Toolkit (AWT) for rudimentary GUI design, and the Swing API for advanced GUIs. (Note that Java’s Swing package was renamed the Java Foundation Classes (JFC) in Java 2 Platform.) In a client/server architecture, the order-entry screen object contains the definition for all the screen elements, such as the customer-entry field, a product pick list, a field to enter quantity, and a submit order button. In such an architecture, you will also define the quantity field with a mask such as 999. You will define methods (the Java version of procedures) that use a customer object to set the product pick list based on the entered customer. You will also define methods that cause the submit order button to invoke methods of an order object that verifies the customer’s credit and processes the order.

While you could hand code the user-interaction objects, most Integrated Development Environments (IDEs) come with tools that facilitate the development of user- interaction objects (see “Java IDEs: From Toy Box to Toolbox” by Joe Pluta for more information on Java IDEs). Because of these tools, you do not need a lot of Java, or even programming, experience to build user-interaction objects.

In this architecture, the order-entry application has two business-level objects: a customer object and an order object. As just stated, the order-entry screen uses the customer object to obtain the customer-specific product list. The customer object uses data- interaction objects to read in the product list. The data-interaction objects, in turn, will use JDBC to connect to the DB2/400 database and submit database requests. You will need a fair amount of programming and Java experience to develop the business-level objects. VisualAge for Java comes with tools that help you generate shells for these objects. These same tools also generate the data-interaction objects (eliminating the need for any programming).

Client/Server Caveats

Java contains many performance “gotchas.” These misfeatures are of particular concern in a client/server architecture because the client executes the entire program. To catch bottlenecks, I recommend using, from day one, a Java profiler such as JProbe from the KL Group (www.klg.com). Java profiling, however, requires a good understanding of the Java environment.

Your business-level objects will need to use Java exceptions to handle database failures. Exceptions are the built-in error handling mechanism provided by Java. By using exceptions, you can gracefully handle broken connections and database shutdowns. (For more information see “Java Error Handling for CL Programmers” in AS/400 NetJava Expert, December/January 1998.)

To deploy the client/server order-entry application, you must install a JVM on the client machine. You must also install all the order-entry class files on the client machine. A class file is the compiled form of the order-entry objects. You must also configure the client machine for data access. This last step varies based on the connection method you chose when you programmed. Currently, you can choose between using TCP/IP to connect to the database and ODBC.

Building and Deploying Servlets

A servlet-based architecture consists of the application running as a Java servlet inside a Web server on the AS/400. This servlet uses the Java Servlet API to communicate with a Web browser running on a client machine. The servlet uses either SQL (using Java’s JDBC driver) or record-level access (using IBM’s Java Toolbox for the AS/400) to send data requests to DB2/400. (See Figure 2 for an illustration of a servlet architecture.)

In this architecture, the business-level objects and data-interaction objects are deployed and executed on the AS/400. The servlet will generate the user-interaction objects as HTML files that it sends to the Web browser. The generated user-interaction objects are then executed on the client browser.

In this servlet architecture example, you will need to write Java objects that generate the HTML user-interaction objects. You will probably need to generate two user-interaction objects. The first will be a customer-entry form. The second will be an order-entry form. The user enters the customer in the customer-entry form and presses a submit button. The servlet processes the form and generates the order-entry form with the customer-specific product list. The user selects the product, enters a quantity, and presses a submit button. The Java servlet validates the customer’s credit, processes the order, and sends an HTML page back to the user’s browser, indicating the success or failure of the processed order.

Servlet Caveats

The user-interaction objects are limited in this architecture because HTML lacks many standard interface features. Syntactic validation, for example, is more difficult to achieve because HTML does not support field masks. Typically, writing the user- interaction object generators requires knowledge of HTML, the Java language, and the Java Servlet API. The Enterprise version of VisualAge for Java, however, comes with the Servlet Builder, a tool that allows you to build the Java generator objects visually, thus removing the requirements for HTML and the Java Servlet API.

You will still need to know some Java. Also, visual programming in VisualAge takes some getting used to. For tasks like these, however, it is well worth the effort. You will also need to write methods that process the user-interaction objects when the user submits them. These methods interact with the business-level objects. The business-level objects in this architecture are similar in form and structure to those in the client/server architecture. The same is true for the data-interaction objects.

In a client/server application, for instance, you will need to use Java exceptions to handle database failures. You will also need to handle failures on the client side. When the client first connects, the Java Servlet API starts a client-specific “session.” You can use this session to store state information, such as the selected customer or orders processed. There is no way to know if the client has gone down, so the session data remains. Fortunately,

servlet engines allow you to configure time-out lengths for session data. As a result, when the client submits data, you cannot always assume that the session data is still present. You should handle this condition by sending back a time-out error message.

Deploying for this architecture is simple on the client side. The client must have a Web browser. The client machine must also be configured for TCP/IP access. Your Web server must be configured for servlet support. Achieving these configurations means loading all the current PTFs for WebSphere on the AS/400. You will also need to deploy all order-entry class files on the AS/400.

Building and Deploying Object Server-based Applications

An object server-based architecture consists of a client-side application communicating with a server-side application. The server-side application, in turn, sends database requests to DB2. The server-side application is the object server. It contains and activates the business-level objects and data-interaction objects. (See Figure 3 for an illustration of an object server architecture.)

The client-side application consists of the user-interaction objects. The order-entry application, in this architecture, functions very much like the client/server application. As in the client/server application, there is one user-interaction object that contains a field to enter the customer, a customer-specific product pick list, a field to enter quantity, and a submit order button. In the client/server version, you wrote methods that directly called the business-logic objects. In the object server version, the methods must now first “connect” to the business-logic objects. The business-logic objects are then invoked through a remote protocol such as Remote Method Invocation (RMI) or Common Object Request Broker Architecture (CORBA).

The business-logic objects are similar in function to the client/server version. Your choice of object server impacts the specifics of how you develop these objects. Each object server has slightly different rules you must follow. The basic process for each server is the same. You write your business-logic object as before. You then use a utility packaged with the object server to generate client- and server-side “wrapper” objects. These wrapper objects ensure compliance with the object server you are using. IBM is currently naming BEA Weblogic (www.weblogic.com), formerly known as Tengah, as its recommended object server for the AS/400.

BEA WebLogic supports the Enterprise JavaBeans (EJB) specification. EJB is an object server protocol meant to simplify object server programming (see “Enterprise JavaBeans and AS/400e” by Keith Rutledge for more information on EJB). EJB support for IBM’s AS/400 version of its WebSphere Application Server will be available in the summer. Programming these objects requires an understanding of the Java language, the remote protocol API (CORBA, RMI), and, possibly, object server-specific APIs (see “R.I.P. 5250” by Don Denoncourt for more information on RMI, CORBA, and EJB). Again, the enterprise version of VisualAge for Java comes with a tool that automatically generates EJB-compliant versions of your business-logic objects.

Object Distribution Caveats

For performance reasons, you may need to program the user-interaction object differently in the object server version than in a client/server version. For example, in the client/server application it may be more efficient to load the product list one product at time. When using an object server, however, this would cause a high volume of remote calls for a small amount of data. Instead, you would have an API that requests the data one page at a time. You also need to handle object server and connection failures. Like servlets, object servers keep track of client sessions. In an object server architecture, handling time-out failure is a client-side responsibility.

To deploy the client side of the application, you must install a JVM on the client platform (unless you deploy the client as a Java applet). You must install the user- interaction class files and the client-side wrapper class files for the business-level objects. On the server side, you need to install the server-side wrapper class files, the business-level

object class files, and the data-interaction class files. The specific installation steps vary, depending on the chosen object server.

So, What’s the Right Approach?

The right approach depends largely on the type of application you are writing, the environment you deploy into, your user base, and your style of application management. Client/server applications are the easiest ones to develop, but they have high maintenance costs. For Java, this architecture is applicable only in a controlled deployment environment. Java is still young and JVM compatibility is not at the advertised levels. Currently, I would not consider Java for large-scale deployment of a client/server application. If you are committed to client/server, I would stick to one of the more mature solutions available.

If your user base is accustomed to interacting with applications over the 5250, then I would strongly consider the servlet-based architecture. Users interact with servlet-based applications almost identically to how they interact with the 5250-based applications. Data entry and reporting applications are good candidates for this architecture. You also need to deploy the application only on the Web server, although you will need to manage and tune the Web server.

Consider using object servers for applications that are transaction-oriented. Object servers provide many fault-tolerant safeties not offered by the other architectures. Be aware, however, that this architecture is by far the hardest to build. Also, as in a client/server application, you have the issue of deploying on all the clients and the same problem with incompatible JVMs.

Whatever architecture you choose to use, however (client/server, servlets, or objects), what remains constant is this: The “Black Box” is hot. And, while the stream of new technologies offers us opportunities and choices at a frightening pace, one thing is certain—it is an exciting time to develop on the AS/400.

User-interaction Objects

Business-level Objects

Data-interaction Objects

Client Workstation

JDBC

Figure 1: Here’s an overview of the client/server architecture.

DB2

AS/400

User-interaction Objects

Web Browser
HTTP

Figure 2: Check out this overview of the servlet architecture.

AS/400

User-interaction Objects Generator

Business-level Objects

Data-interaction Objects

Servlet

Client Workstation

DB2 DB2

JDBC

Web Server

AS/400

User-interaction Objects

Client Workstation

IIOP or RMI

Figure 3: This is an overview of the object server-based architecture.

Business-level Objects

Data-interaction Objects

Object Server

JDBC