If the AS/400 has suffered from one thing, it would be its own success. For years, it has provided a solid platform for the development and deployment of crucial business applications. The AS/400 has made it easy to bypass the waves upon waves of Internet technologies, each one promising to do something that is already done robustly on the AS/400 platform. The Internet, however, is rapidly maturing. It is fundamentally changing the model of business and the applications that automate that business. And while this new model, named e-business, does resemble the one that has enabled the AS/400 to be so successful, the differences and impact are such that we need to rethink how and what we are developing.

The E-business Runtime Environment

Key to any e-business application is the set of components that make up the application runtime environment. No longer is an application simply an RPG (or COBOL) program sending display files to a 5250 terminal and reading and writing logical files. An e-business application is a set of static Web pages, dynamic scripts, business objects, and, perhaps, even workflow documents collectively working together to provide the business functionality that a user would perceive as a single application. Each piece of the application executes on one or more of the components in the runtime environment.

One of the main things that distinguish an e-business application from traditional applications is that the user interacts with an e-business application via a Web client. The Web client displays screens to the user, who, in turn, uses the screens to view information, enter information, navigate through the application, and invoke application functionality. The Web client is usually a standard Web browser but can be any client-side application that communicates with a Web server using standard Internet protocols. Unlike a 5250 terminal, a Web client actually has the ability to perform some client-side processing, though that processing is limited to simple user-interface functionality such as field validation.

The Web client interacts with a Web server, which feeds the Web client screens and data. The Web client sends the Web server information that is entered by the user as well as requests for application screens and for application functionality. The client and server typically communicate using the HTTP or HTTPS (SSL-encrypted HTTP) protocol. While other protocols are acceptable, such as the Internet Inter-ORB Protocol (IIOP), for

example, HTTP is easier to deal with when the Web server requires a firewall. When HTTP is being used, the Web server sends the Web client HTML pages. As the standards mature, HTML pages will be replaced by Extensible Markup Language (XML) pages.

Next in the complex process behind an e-business application, the Web server passes requests for application functionality through either Common Gateway Interface (CGI) or servlets to either an application server or a workflow server. (For more information on these two technologies, see the article “Understanding CGI and Servlets” at www.midrangecomputing.com/mc/.) Which one of these two servers is used depends on the task being performed. Application functionality that is best modeled with objects or functionality that is transactional in nature—such as entering customer information, taking orders, or viewing a build list—belongs in an application server. Application functions that are message- or document-based belong on a workflow server; administering a newsgroup and tracking an order approval process are good examples. Finally, modules implemented to execute on either the workflow server or the application server may, in turn, invoke functions on an existing system. For example, a module on the application server may process orders. That module, in turn, could tie back into an existing inventory system and order-fulfillment system.

E-business applications are well suited for an object-oriented architecture known as Model- View-Controller (MVC). With MVC, the modeling of the external world, the visual feedback to the user, and the handling of user interaction are explicitly separated and handled by three types of modules, each one of which is specialized for its task. The view manages the graphical and textual output of the application. The controller interprets the user input, commanding the model and the view to change as appropriate. Finally, the model manages the behavior and data of the application, responds to requests for information, and executes requested commands.

To see the MVC architecture at work, go to your favorite portal site on the Web. The total functionality of such a Web site is the application. It may let you search for sites and find out about local weather, television, and movies. Each HTML page executed by your browser is a view. When you click on a link or enter information that is sent to the Web server, whatever system responds acts as the controller. Sometimes, the Web server itself is the controller, as it is when a static page is requested. For more complicated requests, such as a search or request for local television listings, either a CGI program or a servlet acts as the controller. The CGI program or servlet interprets the posted data and then determines which application functionality to invoke. The code that implements the application functionality acts as the model.

Application Domains

Applications can be organized into either vertical domains or horizontal domains. Vertical domains are based on an industry, such as retailing, banking, or manufacturing. Horizontal application domains are grouped by the functionality they deliver. E-business requirements vary based on the horizontal and vertical domains of an application. Vertical domains have a rich history and support. Many applications already exist that satisfy vertical-domain requirements. The Internet has introduced several new horizontal categories. The five most common, for the sake of discussion, I will call storefront, marketplace, self-service, information distribution, and transaction service.

Storefront

Simply put, a storefront Web application is one that lets a user purchase products. If you have purchased books, movies, or flowers over the Internet, then you have used a Web application that fits into the storefront application domain. Amazon.com is probably the most famous storefront application. Storefront applications support transactions between a

MVC

buyer and a seller where the application host is always the seller and the application user is always the buyer. The application user may be an individual consumer, or the user may act as a purchasing agent for a business. The application host uses the application primarily as an order-entry system and interfaces the application into an order-fulfillment process.

Storefront applications allow a user to browse a catalog of products, search for products by attribute, order products, pay for orders, and track orders. The payment process may be as simple as accepting credit card information and connecting to a payment gateway. If the user is a purchasing agent for a company, then the payment process may need to tie into a workflow process if quantities or order values exceed certain limits. Storefront applications may also use a workflow server to provide messaging services that keep users updated on order progress and allow users to send questions on their orders.

Storefront applications also interface with vertical legacy applications. The applications typically service the vertical domains of retailing and manufacturing. Storefront applications use these vertical applications for order fulfillment, inventory management, merchandising, and accounting.

As shown in Figure 1, a storefront application’s ordering process maps onto an e- business architecture. In this example, the user presses a button labeled Add to shopping cart on the view object, which is an HTML form. The view object executes in the user’s Web browser. When the user presses the button, the browser sends the application request to the Web server. The Web server is configured to pass all requests of this nature to the application server. The application server, in turn, invokes a controller object that accepts the function request. The controller looks up the model object that handles shopping-cart functionality. The controller then invokes a function that will add the requested product to the shopping cart. The model object may use a legacy connector to check available inventory in an existing inventory system. Once the model adds the product to the shopping cart, it returns a success code to the controller. The controller looks up or generates the success view, and that view is returned and displayed in the user’s browser.

The storefront application domain is the most mature of the domains discussed. Many off-the-shelf commerce servers provide the functionality to satisfy the needs of most storefront applications. These off-the-shelf packages provide model and controller objects that you use to build your application. Many even provide templates that you can use as a starting point for your view objects.

Marketplace

A marketplace application provides an environment for buyers and sellers of products to find each other. E*TRADE and eBay are examples of this type of application. As with storefront applications, marketplace applications support transactions between buyers and sellers. However, the application host need not be a buyer nor a seller. Instead, the application host acts as a clearinghouse for all the transactions. Users of the application act as buyers, sellers, or both. The application host may charge a subscription fee or a percentage of each transaction.

Online auctioning is the most common, but not the only, form of this application domain. One marketplace application host, for example, markets itself as a consulting agency. It provides application functionality that consultants use to enter information about themselves and their companies. It also provides functionality that companies use to find consulting services. The application host charges the consultants both an entry fee and a percentage on the consulting engagements. Online trading is yet another example of a marketplace application.

A marketplace application allows sellers to register products or services and allows buyers to find the sellers that have the products they wish to purchase. Because neither the buyer nor the seller may know much about each other, a marketplace usually authenticates the buyer and the seller or the transaction between them. Depending on the level of service

offered by an application host, the authentication process may be served best by a workflow server.

There are some off-the-shelf packages that can be used to build auctioning functionality. These packages, however, are still new in their development cycle and not yet proven. Because of this, if you need to build a marketplace application, you have to build the model, view, and controller objects from the ground up. The whole concept of a marketplace is one of the new concepts made possible by the Internet. Because of this, except for accounting needs, marketplace applications tend not to interface with existing systems.

Self-service

The primary goal of a self-service application is to use the Internet to reduce support costs while increasing the level of support available. Shipping companies such as Fed Ex and UPS provide good examples. A self-service application allows users to find out information that they would otherwise find out from a person knowledgeable in the area of inquiry. An FAQ page is the simplest example of this type of application; shipment tracking is another example.

A self-service application allows users to enter an item of inquiry and submit searches. It may use a workflow server to track and satisfy the inquiries. Self-service applications are typically based on existing in-house legacy and workflow applications used by support staff. As is the case with a marketplace application, if you need to build a self- service application, you have to build the model, view, and controller objects from the ground up. The difference is that the controller and model objects are thin wrappers over the existing systems.

Information Distribution

An information distribution application collects data in a particular area and allows a user to find the information. Web portals, such as Yahoo.com, are an example of this type of application; market-research sites and online magazines are other examples. Using the application, the host collects information on a subject and repackages it in a more meaningful way. The host may charge a subscription fee for the service or a fee for each information request or, as in the case of portals, charge partners or advertisers.

On the surface, information distribution applications and self-service applications appear similar. The primary difference is that the source of a self-service application tends to be an in-house system; the data is generated from within the application host. An information distribution application instead uses sources outside the application host. Its primary function is to collect information, package it, and present it for use.

The part of the information distribution application that collects information may be as simple as a screen that a source provider uses to enter information, or it may be a module that runs outside the application host and sends information about the source. Once the information is collected, the application packages the collected information. A portal site may index a database of Web sites and organize them into categories. In other types of sites, data may be dumped into a business-intelligence system where the users can find the information. The type of information distribution application being designed will determine how users access information. The access method could be anything from a search function to a push system that emails periodic reports to subscribers, and it might use a workflow server as a means of distributing the information.

Transaction Service

A transaction service application allows a user to request that a transaction (such as online banking, airline reservations and ticketing, and hotel reservations) be executed by the application host on the user’s behalf. Travelocity.com is a good example. The application

host may execute the transaction yet may not always be the provider of the items or services purchased in the transaction.

Transaction service applications allow users to specify transaction parameters. These parameters may include a date when the user wishes to execute the transaction, a price that the user wishes to execute the transaction at, and a specification of what the user wishes to purchase. The application may allow a user to schedule recurring transactions. It may also help users find products and services that match their search criteria. The application may attempt to execute the transaction immediately or at some scheduled time. If the application executes the transaction at a later time, it may send a message to inform the user of the transaction’s status. It may also provide online reports on the transaction.

Organizations that offer a transaction service application typically have older reservation or ticketing systems that implement the core functionality. As a result, the model objects are usually thin wrappers over these existing systems. The view and controller objects simply map user interaction to the thin model objects.

As shown in Figure 2, an airline-ticketing e-business application could check for ticket availability. In this example, the user is presented with a view object that allows the user to enter information such as departure and destination cities, dates of travel, preferred airlines, seating preferences, and ticketing-class preferences. Once the user enters the information, he presses a check for availability button. The submitted form makes its way to a controller that finds the model object that can handle the request, and the model object takes the information entered by the user and packages it into a transaction request. That information is sent to an external airline reservation system such as Sabre. The model object caches the results of the transaction and returns a success value to the controller. The controller then uses a JavaServer Page (JSP), in conjunction with the model object, to generate an HTML form that lists available flights. The document, or view, is returned and displayed in a user’s browser.

Building an E-business Application

Although based on similar architectures, the processes of writing a traditional AS/400 program and writing an e-business application are quite different. In a traditional program, you specify the display files and the logical files. Then, you implement algorithms in RPG or COBOL that send display files to the terminal and use the logical files as a data store. A single engineer or a team of engineers who share a common set of skills perform these tasks. The same is not true for an e-business application.

An e-business application is a collection of model objects, controller objects, and view objects working together to provide a cohesive set of functionality. Model objects are typically implemented in RPG, COBOL, C++, or Java, depending on the application server used. If the application server is CGI-based, then the model objects are implemented in RPG, COBOL, or C++. If the application server supports servlets, then the model objects are implemented in Java. The same logic holds true for the implementation choice concerning controller objects.

View objects are typically generated by either the application server or a CGI process using some scripting language. (For more information, see the article “Making Use of Net.Data and JavaServer Pages” on the Web at www.midrangecomputing.com/mc/.) On the AS/400, the scripting language used will be either Net.Data for CGI-based application servers or JSP for servlet-based application servers. The programmer responsible for view objects needs to understand both the HTML generated by the scripts and the scripting language itself.

Ready for E-business?

The question remaining, then, is, “How does e-business fit into your organization?” The AS/400 has always been a successful, robust platform. Supporting e-business may require upgrades to the hardware, operating systems, and software executing on the box. There is

always a risk when undertaking a change such as this. Moving to e-business architecture does mean training staff on technologies such as HTML, XML, JSP, Java, CGI, and servlets. Is it worth it, especially when the existing solutions satisfy current business needs? The answer depends on your business objectives. How important is Web enablement? Does the Internet offer new opportunities for your business? Does the Internet open competitive channels? In the end, most companies will need some sort of e-business solution. Fortunately for us, the AS/400, always a robust platform, provides the support that will allow us to take our solutions into the next generation of applications.