The mainstay of application deployment, 5250 data streams, is dead or, at least, dying. In the late ’80s and early ’90s, there was a strong attempt to replace green-screen apps with client/server. Perhaps what bungled this attempt was the indecision over what client/server language to use. Should it have been Visual Basic, C++, Visual RPG, or one of the other languages that were available at the time? Whatever the reason, client/server never became as big as expected. Today, the hype about client/server has been replaced with Web-based thin-client hype. Perhaps the HTML front-end of thin clients doesn’t provide as sophisticated a GUI as client/server, but “thin is in” because it puts control of information systems back where it belongs—on the host.
HTML may be what I call a “pseudo-GUI,” but it does provide an easy-to-develop, consistent, browser-based user interface. When it began, the Web—the infrastructure of networked computers that disseminates HTML via HTTP to Web browsers—was made mostly of static HTML. However, entrepreneurs quickly saw the business potential for dynamic HTML. Scripting languages such as IBM’s Net.Data, Microsoft’s Active Server Pages (ASP), and Netscape’s server-side JavaScript were developed to construct Web pages “on the fly.” Soon thereafter, to support legacy languages, Common Gateway Interface (CGI) was introduced, and programmers began to develop Web pages with their favorite languages. Each of these various strategies for developing dynamic content has weaknesses such as speed limitations or platform dependence. The technologies that are emerging as the cross-platform strategy of choice for deploying Web applications are Java servlets and JavaServer Pages (JSP).
By themselves, servlets and JSP are missing some features that are required for business applications: transaction control, work management, and Java class interoperability with relational databases. This is where Enterprise JavaBeans (EJB) comes in. The new model of application design uses a combination of JSP, servlets, and EJB. I’d like to give you an overview of each of these technologies and then introduce you to the design strategy that combines JSP, servlets, and EJB in the development of the next generation of world-class business applications.
Server-side Java
You use Java servlets to dynamically generate Web content on the host machine (hence, the term server-side Java). Learning and using object-oriented programming with Java can be complex, but programming with Java servlets is actually quite simple. Figure 1 shows a basic Java servlet that has two methods: a doGet and a doPost (note that a method is essentially a subroutine or function). When a Web browser user keys a URL (or clicks a hyperlink) that qualifies the Java servlet on a host, the doGet method of that Java servlet is invoked by the Web server. The doGet method in my example “dynamically” generates a Web page, which the server subsequently sends back down to the requesting browser. (For simplicity, my example does not retrieve dynamic information from an application database.)
After the user fills in the HTML form and clicks the Submit button, the request is passed back to the server. The server then invokes the doPost method of the servlet that was qualified in the Action option of the HTML form tag, passing to this method the values from the HTML form’s input fields. My trivial servlet reads only the parameter values and echoes them back to the user, but I’m sure you can envision building far more complex applications using the simple input/output mechanism of HTML forms and Java servlets. (For more on Java servlets, see Sonjaya Tandon’s article “Servlets: What’s Old Is New” in the December 1998 issue of MC and my article “Serving Up Host-based Java Apps” in the August 1999 issue of MC.)
Here’s a little info about the performance advantages of Java servlets over RPG CGI and good old client/server: Only one instance of a Java servlet is required to handle all remote browser requests. As a result, Java servlets require fewer database connections, file opens, and job starts compared to CGI or client/server applications. Java servlets run in the Web server’s job space, not in a separate job as do RPG CGI or the database connection jobs required for client/server applications. Java servlets seamlessly handle multiple users with threads and efficiently manage memory with their garbage collection facilities. The Web application server that provides the engine that manages servlets also supports the clustering of host servers, which, when used with data mirroring, support load balancing and greater fault tolerance. In short, Java servlets allow your Web applications to be scalable and cross-platform.
JavaServer Pages
In my article “Reconcilable Differences” (November 1999 issue of MC), I explained that a servlet “embeds the HTML code required for the user presentation (UI)” and that “RPG programmers haven’t embedded UI code since externally defined files became available.” (Kevin Vandever, in his article “The First Degree of Separation,” somewhat disagrees. Vandever points out that RPG programs still embed UI code—the F-specs and all the C- specs used to control the UI. Vandever also points out that externally described files provide only a modicum of user interface and business logic separation.) JavaServer Pages is a technology that cleanly separates the user interface from the business logic. JSP effectively separates the role of Web page designer from that of business programmer. Take a look at the JSP source shown in Figure 2. It is immediately obvious that the code is HTML. However, if you look more closely, you can see some embedded Java code (specifically, the invocation of the Items class’s getItem method). You also see some nonstandard HTML tags:
Going back to the JSP source in Figure 2, notice that its form tag specifies the Java servlet (in the Action option) shown in Figure 1. The JSP takes over the responsibility for the construction of the HTML form previously handled by the doGet method of the PanelServlet. Now, realize what I’ve done—I’ve pulled out the user interface from the programming logic and put it in a JSP source. As shown in Figure 3, the user interface was also improved: The JSP builds a drop-down list from which users can easily select the items they wish to purchase. Notice that the bean tag of the JSP in Figure 2 references a JavaBean called ItemsBean. Figure 4 shows the source code for ItemsBean. The JSP retrieves item descriptions from the getItem method of the ItemsBean and places them into an HTML drop-down selection box. The resulting Web page is very basic. But remember: The idea is that a Web page designer (which I am not) will make it “look pretty.” (For more on JSP, see my article “Reconcilable Differences.”)
Back Office
There is a big piece of the application design puzzle that I left out of my simple JSP and servlet example: real business logic. For instance, where is the interaction with the complex databases typical of AS/400 applications? If you follow the application redeployment strategies as explained in Joe Pluta’s “Revitalization—Put on a GUI Face” and Kevin Vandever’s “The First Degree of Separation,” your servlets will interact with legacy RPG application code retrofitted for Internet deployment. Joe’s redeployment strategy makes great use of two important corporate assets: legacy code and the talents of RPG applications programmers. However, applications really start to fulfill the promise of cross-platform code and object-oriented programming (OOP) only when they are developed with 100% Pure Java.
OOP in a Nutshell
Before I explain where to plug in your business logic, I’d like to give you my “nickel description” of object-oriented programming. Think about one of your standard 5,000-to- 10,000-line RPG programs. Think of it in terms of its business processes. Now, think of all the file accessing that occurs in this program. Take each file and, in your head, encapsulate (encapsulation is the process of creating a simplified interface that is easy to use and hard to break) its data access to a service program with modules that add, retrieve, update, and delete the business entities stored in the file. These service programs might also contain modules that perform more complex manipulations of these business entities. Some of the modules might even use modules from other service programs to encapsulate access to the business entities stored in the files. For instance, a purchase order aggregates purchase order line items, so the modules of the purchase order service program might use the modules of the line-item detail service program. The purchase order service program, therefore, might contain modules that add and remove purchase order line items.
Now, look again at the original application program. This program no longer opens files. All data access is encapsulated into service programs. And because so many of the standard routines for manipulating business entities have been isolated to service programs, the main program has shrunk to what is now a very manageable size; it coordinates the use of the service programs to perform only some business processes. The program is now smaller and more maintainable, and code reuse is enabled. This style of programming is known as component-based programming. Although you can do much with the modular programming capabilities of RPG IV, object-oriented languages such as Java allow you to take full advantage of the capabilities of component-based programming.
Persistence Engines
In the object-oriented (OO) world, the mechanism that is used to encapsulate access to business entities is known as a persistence engine. Java-based persistence engines provide classes that encapsulate access to entities stored in relational databases using a process
called object-to-relational wrappering (or, as IBM calls it, “fluffing and stuffing”). In Joe Pluta’s redeployment strategy, there are no wrappering requirements; your legacy RPG programs provide the back office. But with the 100% Pure Java strategy, you need to select some mechanism that maps your relational data to Java objects. There are all kinds of software products available that will generate the Java classes for you, such as IBM’s Access Builder and Persistence Builder (both of which ship with VisualAge for Java Enterprise Edition) and The Object People’s (www.objectpeople.com) TOPLink for Java.
But, alas, there are problems with using object-to-relational wrappers. They work fairly well, but they have only basic support for transactions, don’t pool database connections, and, most importantly, don’t scale well.
Enterprise JavaBeans
The best solution for a persistence engine is Enterprise JavaBeans. The use of Enterprise JavaBeans technology is the best solution because an EJB engine does the object-to- relational wrappering for you in addition to being accessible remotely. The EJB engine handles transaction control, and, further, the EJB engine efficiently handles high volumes of those transactions. In short, the use of EJB technology allows business programmers to do their job by relieving them of the complex tasks of coding object distribution, transaction control, managing system resources, and object-to-relational wrappering. To ensure the database integrity, the EJB engine uses a sophisticated transaction control strategy that requires little or no programming on the business programmer’s part. To efficiently manage system resources, EJB engines use a sophisticated strategy that I call work management for Java. I call this strategy work management for Java because the EJB engine uses least recently used (LRU) algorithms, just as your basic AS/400 work management does, to allow your high-volume, transaction-based Web applications to scale well. Finally, you can deploy EJBs in an n-tier application scenario where the EJB engine can reside on one system, the database on another system, and the clients on virtually any number of other systems. An example of an EJB client might be a Java applet running in a Web browser, but another example would be a servlet running in a Web server using the MVC strategy extolled in this article. For more on EJB, refer to my articles “Enterprise JavaBeans: Show Me the Code!” (MC, July 1999) and “E-business by Design with EJB” (MC, August 1999).
MVC—The New Architecture for Business Applications
Having identified JSP, servlets, and EJB as the technologies that you are to use for your host-based applications, I’ll explain how these three technologies collaborate. JSP, servlets, and EJB each have an area of responsibility. They collaborate using a design architecture known as the Model-View-Controller (MVC), shown in Figure 5. The Model is the persistence engine, which, in my perfect world, is EJB. The View is JSP, coded by Web page designers, not business programmers. And the Controller portion of the MVC architecture is implemented with Java servlets.
The only way I can understand a new technology is to use, as an analogy, a technology that I already know. To best explain the controller responsibility of Java servlets in the MVC architecture, I’ll use the analogy of a CL driver. Think about one of those monster CL drivers from some application’s menu system. It is driven by one display file, and its job is to set things up and then pass control to RPG or other CL programs. CL, of course, has its problems: Until recently, it was not a modular programming language; rather, it was a monolithic nightmare proliferating “gotos” and labels. Anyway, the CL controller mediates between the user interface (the display file) and the application code.
Java servlets in the MVC architecture also mediate between the user interface and the application code. The difference is that a servlet can handle the user input from any
Mediator
number of input sources; the input source for your application’s servlet controller is a JSP or HTML file. Also, the Java servlet not only is modular in design but also allows you to completely submerge yourself in and subsequently benefit from object-oriented programming.
In a typical application scenario, the servlet controller manages user input from numerous views. These views are HTML forms generated from JSP files. The servlet differentiates among the various views with a hidden HTML field:
VALUE=”orderView”>
The servlet, after retrieving the hidden field’s value with the getParameter() method, invokes a method that is coded to handle this HTML input (or delegates this responsibility to another Java class that encapsulates this process). The servlet’s method then interacts with the persistence engine to perform the business processing required to handle the user request. The response to that request is not built by the servlet; it is built by a JSP. The servlet instances a “smart parameter” bean that encapsulates access to the information required to build the HTML response from.
The view beans are basically “domain firewalls” to the business entities of the persistence engine. “Domain” refers to the business entities encapsulated with Java classes, and “firewall” refers to disabling the Web page designer’s access to the complex API of these business objects. Thus, the users of the view beans, the Web designers, cannot violate database integrity because they do not have direct access to that data. The Web designer has controlled access only to information pertaining to the business entities stored in your relational database through the view beans, which you, as a business programmer, provide for the Web designer.
Once the view bean is created by the servlet, it then uses the servlet API’s set- Attribute method to add the newly created view bean to the list of HTTP request attributes. (Alternatively, you could use an HttpSession object and the putValue method.) The servlet then passes control to the appropriate JSP by invoking it with the callPage method. The following three statements show how a servlet would create a view bean that contains order summary information, then associate that bean with the HTTP request, and finally pass control to a JSP to build the user interface:
OrderSumBean orderSum =
new Order(orderNo);
req.setAttribute(“OrderSumBean”,
orderSum);
resp.callPage(“OrderPage.jsp”, req);
There are a number of other flow-control strategies available for servlets and JSP. For instance, JSPs are able to invoke servlets with a special
Application Nirvana?
Nirvana, in Buddhist terms, means a release from the cycle of reincarnation as the result of an extinction of individual passion, hatred, and delusion. If you believe in the mantra of the sun gods (Sun Microsystems) and Big Blue (IBM Corporation), the cycle of reincarnation is the reuse of old technology in the development of new applications; the extinction of individual passion is freeing yourself from platform-specific technologies (RPG); hatred is what you feel for something you don’t know or understand (Java); and delusion is that Java and the Web are passing fads.
Perhaps this view of technological nirvana is a little “out there,” so let me try it again. This time, I’ll relate it to a more commonly understood meaning of nirvana: a state of freedom from pain and worry. The pain is maintaining monolithic applications; the worry is concern about not using the Web to your company’s and your career’s advantage; and the freedom is using cross-platform, nonproprietary technologies that are scalable and maintainable.
Or maybe the MVC architecture of JSP, servlets, and EJB is just a great strategy for developing the business applications of tomorrow. JSP separates presentation from programming; EJB handles the processing of business entities in a scalable, transaction- oriented manner; and servlets mediate the user interface of JSP and the business logic of EJB.
References and Related Materials
• “E-business by Design with EJB,” Don Denoncourt, MC, August 1999
• “Enterprise JavaBeans: Show Me the Code!” Don Denoncourt, MC, July 1999
• “Reconcilable Differences,” Don Denoncourt, MC, November 1999
• “Serving Up Host-based Java Apps,” Don Denoncourt, MC, August 1999
• “Servlets: What’s Old Is New,” Sonjaya Tandon, MC, December 1998
• The Object People home page: www.objectpeople.com
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class PanelServlet extends HttpServlet
{
public void doGet(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException
{
resp.setContentType("text/html");
PrintWriter out = new PrintWriter(resp.getOutputStream());
out.println("");
out.println("
out.println("item number:");
out.println("");
out.println("");
out.println("");
out.println("");
out.close();
}
public void doPost(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException
{
resp.setContentType("text/html");
PrintWriter out = new PrintWriter(resp.getOutputStream());
String itemDesc = req.getParameter("item");
out.println("");
out.println("Item Selected: "+itemDesc+"
");
out.println("");
out.close();
}
}
create="yes" scope="session" introspect="no">
Figure 1: The doGet and doPost methods are the “mainlines” of a Java servlet.
public class ItemsBean {
String items[] = {
"Midrange Computing",
"AS/400 Technology SHOWCASE",
"AS/400 Network Expert",
"AS/400 NetJava Expert"};
public String getItem(int i) {
return items[i];
}
}
Figure 4: Application programmers use their talents to pull business information out of the database and build view beans for the Web page designer to use in a JSP source.
Figure 2. JSP syntax is HTML with embedded Java code and JSP-specific HTML tags such as
Figure 3: Web page designers use their talents to create a sophisticated user interface with a JSP.
JSPs Servlets EJB Smart Parameters/View Beans
Input Handled by Servlet Build HTML from View Bean Info
Application Controllers for DB2 Access
HTML
Generate User Interface
Forward
Control to JSP
Create View Beans
Figure 5: The Model-View-Controller (MVC) design pattern works well with Web application design.
Don Denoncourt is a freelance consultant. He can be reached at
MC Press books written by Don Denoncourt available now on the MC Press Bookstore.
 |
||
 |
|
Java Application Strategies for iSeries and AS/400 Explore the realities of using Java to develop real-world OS/400 applications. List Price $89.00 Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online