Relational Web DE

The goal of Relational Web is simple. It is to enable your organization to build and deploy:

• comprehensive
• reliable
• scalable
• high performance

web applications.

Actually, the scope is even larger. We propose the use of Relational Web for all interactive in-house database applications as well.

Relational Web may be used as an alternative to IBM 5250 "green screen" programming. For example, software developers may use it to provide a browser-based GUI for any business applications.

Relational Web can be recommended on the basis of:

• productivity - programmers spend less time developing more comprehensive applications.
• efficiency - resulting applications use much less CPU and other computing resources - especially in comparison to CGI, Net.Data, and Java Servlets. Hardware cost is ultimately reduced.
• functionality - both in terms of the services provided by Relational Web as well as what people create with it. It answers the need for both GUI and Web access.
• performance - resulting applications offer a highly-responsive, end-user experience.

Relational Web runs under the IBM i Operating System, which is exclusive to IBM Power Systems, eServer iSeries, and AS/400 platforms.

Our view is that it's the best platform for hosting a relational database, and multi-user database applications.

While Relational Web is targeted specifically at organizations that already own IBM i based servers, we invite every executive to consider owning this remarkable platform. For more details from IBM, see:

http://www-03.ibm.com/systems/i/

Relational Web enables web browsers and other clients to interact with programs hosted on your server.

Any device that is able to communicate with the IBM i Web server, can also be linked to Relational Web.

This includes hand-held devices such as personal digital assistants and cell phones, as well as desktop workstations, and even other servers.

Relational Web is an extension of the IBM i web server and runtime environment. As such, it can be used for just about any business application, both in-house, and over the internet.

It is typically used to deliver dynamic, database-specific HTML content to browsers, but is not limited to that. It can also deliver XML and WML, for example. Actually, it can easily deliver data in any format.

Relational Web provides functionality that is sometimes classified as a Web Application Server. Microsoft, IBM, and Oracle are but a few of the well-known vendors who offer functionally similar products.

Relational Web is targeted, more specifically, at the community of developers who use the native ILE language environment (RPG, COBOL, and C) of IBM i based servers.

For a more detailed look at Relational Web, we invite you read on to our Architectural Overview. It provides a lot of detail about how Relational Web works, and where it fits in the market.

Some may ask how Relational Web compares to scripting technologies like Microsoft's Active Server Pages, Sun's Java Server Pages, or Adobe's Cold Fusion. Or how how it compares architecturally with Java Web Application Servers like IBM's Websphere, or Oracle's Weblogic. Or how Relational Web Applications compare to Java Servlets, or CGI. This overview attempts to define the architecture of Relational Web. Topics also include include:

• application performance
• reliability
• scalability
• security
• flexibility
• programmer productivity

In dealing with these topics, we hope to illustrate advantages offered by Relational Web, as well as provide a view of where Relational Web fits in the web tools market.

Relational Web builds on the strengths of IBM i enabled systems. For those who may be unfamiliar with these remarkable systems, please see:

http://www-03.ibm.com/systems/i/

These systems offer unparalleled hardware, OS, database, and software integration. They are ideal for industrial-strength business applications. They offer true, time-tested value.

Many the same attributes that have made IBM i based systems such great platform for hosting 5250 applications, apply to the Web and other client-server scenarios as well.

One advantage of the Relational Web architecture is that your Web applications run on the same server as your database.

This is an often overlooked advantage in an industry that's saturated with the idea of dividing application components across multiple hardware and software platforms. The truth is, that these architectures often lead to bottlenecks, instability, complexity, extra deployment steps, and significant system overhead.

The lure of multi-tier hardware seems to be the ability to start out small, with low cost computers, and divide the work across multiple systems as demand for services increase. More often, the reality is a higher overall cost of ownership. As the number users, number of applications, number of developer skill sets, and number of ill-fitting software and database components increase, the more noticeable the weaknesses of this architecture become.

In contrast, Relational Web integrates perfectly with with IBM i supplied software components, hosted on a single computer:

This architecture leads to better performance and reliability, as well as lower cost of development, deployment, and maintenance.

Several protection mechanisms are enabled to ensure that your IBM i files and other resources are secure.

A firewall can block all unapproved network traffic from the Internet to your IBM i server.

Any network traffic that is approved to pass between the firewall and the Web server is subject to several layers of protection, which includes:

• Web server is subject to a fairly limited protocol
• Any access to IBM i files or other resources must be explicitly configured (Web server has a default "fail" rule)
• The Web server supports several explicit protection settings (User ID and Password validation, and Access Control Lists, for example)
• Web server runs under a user profile that has limited access to IBM i resources
• IBM i provides explicit protection settings for all IBM i objects
• Relational Web application runs under a user profile that is separate from that of the Web server which offers further control
• Relational Web applications are subject to a limited proprietary protocol
• Web application designers can implement additional protection mechanisms into the applications themselves

Relational Web applications may also be deployed only within an internal network if so desired.

IBM i is largely an implementation of the Integrated Language Environment (ILE), and ILE languages are usually the most efficient way to access IBM i resources. RPG, COBOL, and C programming languages, combined with native record-level access, provide the best performing database applications.

Relational Web applications are ILE based. They take advantage of the simplicity, reliability, security, and scalability of the IBM i platform. They support record-level database access - which is the most efficient.

This is a significant contrast to ODBC and JDBC connections employed under n-tier architectures. Generic database interfaces required by n-tier architectures are comparatively resource intensive, lead to bottlenecks, and offer security loopholes.

Relational Web is a framework of servers and ILE components that offer a set of functions common to most Web applications. Its components are implemented as ILE service programs. The service programs export a comprehensive set of procedures for building Web applications.

Your ILE Applications link to Relational Web components in order to respond to requests from Web browsers, as well as other client software, and devices.

Relational Web's remarkable performance paired with it's message-based design, often leads to more comprehensive, highly functional user interfaces. Developers can easily add functionality without fear of performance constraints.

The message architecture implemented by Relational Web also offers a contrast to the dynamic program call architecture implemented by CGI. Messages provide significant performance advantages. Your Relational Web applications run as server jobs in parallel with the IBM Web Server. Your programs may open files and allocate other resources, prior to entering a message-based, request-response cycle.

Your Relational Web applications use an API to receive a request from the HTTP server. If no requests are pending, then your program remains in a data queue wait state. Since files and other resources are allocated only once, at start-up, dynamic program call related overhead is eliminated.

This frees the application developer to concentrate on functionality instead of performance. The results are more robust applications, delivered in less time, that provide better scalability, with quicker runtime response.

Loading a program is fairly resource expensive. It takes less work to pass a message to a program that's already running - waiting on a queue. So, Web applications that are based on a message architecture offer the best possible performance, and scalability.

In addition to performance, a message architecture enables developers to properly scope their programs. Take the example of a file maintenance application, which might implement function such as browse, display, add, modify, delete, find, and filter. Where all those functions apply to a single file.

In the absence of a message architecture, the application would probably be divided into perhaps a dozen or more called programs or scripts. For example, one program to build the "modify" screen, another program to post the changes to the record.

Under a message architecture, the programmer would likely write a single program, scoped to handle all functions pertaining to the file. Therefore, all functions pertaining to the file would be kept in proper context. The file would be opened only once, as opposed to being opened for each request.

Java Servlets, CGI programs, and runtime scripts are implemented through a load and execute (callable) interface - in contrast to a message interface. A message interface is more efficient when servicing multiple concurrent clients - no additional threads or processes are activated as the load increases. Outstanding requests are simply queued. Since most requests are handled in a matter of a few milliseconds, a single instance of a single server can support many concurrent clients. However, additional instances of Relational Web applications can be started to handle heavy load scenarios.

A message architecture facilitates the tracking of client state. Some complex operations may involve a dialog that spans multiple pages. The answers on one form may determine the content on a subsequent one. It's easier to track state from one request to the next if a single "server" handles the entire operation, as opposed to dividing the operation across multiple programs or scripts.

We certainly propose that you use Relational Web to modernize your existing applications. It's great for providing a browser based GUI for your users. However, Relational Web is much different from most tools that compete in the modernization market.

Relational Web is not a tool for converting DDS to HTML. Nor is it a server that converts the 5250 data stream to HTML. It does not offer a quick and easy way to replace legacy "green screen" applications with a Web interface.

Instead of connecting a Web interface to existing 5250 applications, Relational Web offers a true client-server architecture. One advantage of this approach is that there are no contrived restrictions on Web browsers and other desktop clients that would be forced into following a 5250 model, which is a considerable handicap to a Web browser. While such tools may offer an interim GUI solution, Relational Web offers a long-term solution.

Relational Web does not use any IBM i based "interactive" features. Therefore, it is not affected by the interactive CPW limits placed on IBM's systems.

Relational Web is not a code generator. Code generators often follow rather rigid models that produce inflexible programs with inefficient code. The upside of course, is the ability to create extensive applications in a short timeframe. The more sophisticated code generators may implement a high-level language of their own, which helps alleviate the rigidity problem, but at the cost of simplicity.

Since Relational Web is an extension of the Integrated Language Environment, existing legacy code can be used in the implementation of new Web interfaces. Not only does this offer a performance and reliability advantage, it leads to more timely deployment than solutions based on new languages and code.

Relational Web addresses the issue of programmer productivity through a set of APIs that are common across all Web applications. Modularity and a comprehensive set of generic services are keys to productivity.

In addition, ILE programmers tend to come up with program templates of their own; when applied across multiple applications, it is a technique that is nearly as fast as a code generator.

Relational Web both encourages and facilitates the design of modular applications. The API is itself a good example of modularity. Modularity is another key to programmer productivity.

Relational Web offers a comprehensive framework that enables developers to focus on application requirements - instead of infrastructure.

Relational Web is not a runtime script interpreter. While that may be a popular architecture (Microsoft ASP, Cold Fusion, Net.Data, Java JSP), it also suffers some drawbacks.

A mixture of HTML and server-side script in a single file is incongruent with good architecture and the goal of separating user interface from control logic.

Runtime script interpretation is CPU intensive and slow. A robust script language is an unnecessary complexity to learn and manage.

Relational Web supports an application architecture known formally as Model-View-Controller. It is a classic architecture recommended for change-resilient applications. It is promoted by IBM, and we absolutely agree!

Model-View-Controller is a technique for designing modular code. It divides an application similar to the way a normalized database divides files according to subject. One key is to separate code into files according to its purpose, and to not mix different types of code.

Too few modules leads to code mix and redundancy, while too many components leads to discontinuity (harder to manage). Relational Web supports the right level of modularity, which leads to more maintainable, and more reusable code.

The basic idea of M-V-C is to divide an application into three major components. The Model represents database I/O and business logic. The View represents user interface elements handled by client applications - Web browsers, for example. The Controller represents logic that provides an interface between Model and View.

When the application is properly separated, a change to one component requires little or no change to the others. Hence the adage, change resilient.

For Web browsers, the View is usually implemented as HTML, Style Sheets, Java Script, and possibly XML. These are all text-based components that may include references to image, sound, and other binary files. Any favorite editor can be used to create these components and store them as text and binary files in the Integrated File System.

Relational Web supplies an API to load text files into memory, automatically parse them into fragments, merge them with data supplied by your program and database at runtime, then send the results to the user. It provides a complete separation of user interface, from presentation and business logic.

This is a big contrast to Active Server Pages, Java Server Pages, and Net.Data macros in which you'll nearly always find varying amounts of server-side logic mixed with user interface elements, in a single file. In our opinion, this code mixture is not the ideal level of modularity.

Another significant advantage to the Relational Web approach is the separation of skill sets. Professionals who design page content never stumble over program (or script) logic.

The opposite is also true, there is generally no HTML included in native language program files. The application program simply loads and transforms the content produced by the user interface designer prior to sending it to the client.

Project team members who have different expertise, can work independently (within reason) of one another.

The Model is usually implemented as a separate ILE module or service program. It encapsulates database I/O, record and field validation, business rules, and application specific procedures. Several sources have become available recently that teach this technique. It's being deployed in 5250 applications as well as web applications.

The database I/O - business rules module may export one or more single or multiple occurring data structures that encapsulate records. It may also export procedures to add, update, delete, process transactions, and perform business logic.

This form of encapsulation makes software much easier to maintain over time. Also, a single module may be used in several applications. The same database module may be used, for example, with a browser interface, a hand-held device interface, and a 5250 interface. Only the Presentation Controller would be different. A change in the database structure, or business rules may have little or no affect on the presentation logic. The opposite is also true.

With Relational Web, the Controller (referring to M-V-C architecture) is implemented as an ILE program. Presentation Controller is a more descriptive term. This program includes the logic to receive client requests, manage client state across multiple requests, make calls to database routines and business logic, and return dynamic content to the client.

Much of the Relational Web API is devoted to making the presentation process easier. It is comparable to the API exported by Java and corresponding Web Application Servers. IBM may specifically promote the use of Java Servlets, Java Beans, and Java Server Pages for this purpose. But we offer Relational Web as a simpler, native, better performing alternative.

We're aware of one web development tool from a competing vendor that goes one step further. It divides the Presentation Controller into two parts. The part that controls the presentation is a generic server. The goal presumably was to shield native language programmers entirely from any specifics of HTML, etc. The interface between the two components is a simple array which is further divided into data segments.

One problem with the above design, is the rigidity of the interface. For example, it doesn't provide the means to dynamically change HTML attributes based on data values (i.e. display negative balances in bold red, positive balances in black). A script file must be deployed to map array elements to HTML tags. The size of the array, and the script syntax impose limits that negatively affect some applications (i.e. a lengthy report). It doesn't support the concept of "session" to track client state from one request to the next.

With Relational Web, the application programmer has complete control over user interface. The length of the output stream is only limited by disk space, and possibly memory. A web programmer may need to have a basic understanding of HTML, just as a 5250 programmer should have a basic understanding of DDS for screen files. The advantage is a more flexible user interface.

Relational Web offers a simple development environment. The only additional tools needed for browser interfaces are your favorite HTML editor, and the familiar options provided by IBM's Program Development Manager (PDM) or Code/400. This may sound counter-intuitive, even boring to some developers. After all, IBM and it's competitors have been making huge investments in powerful web oriented development tools.

The reason those tools are so complicated is because the language, database, and system interfaces they support are complicated. While the tools themselves are fascinating, they're also unnecessary unless you have a requirement for cross-platform implementations. Otherwise, they're counter-productive.

By choosing native IBM i languages for Web development you gain a large bundle of benefits, one of which is a simplified development, testing, and deployment environment. It would be impractical to delineate the steps required to produce a Web application using Relational Web vs. some of the more complex developer tools. The difference is vast.

Some tools duplicate the runtime deployment environment of your server - to your PC. That's redundant. One indicator of complexity is often the size and speed of the PC required to host some tools. Another is the number of professional disciplines that must be learned, managed, and maintained in order to implement an application. Yet in irony, the simpler native-IBM i development environment often yields more reliable, more robust applications.

Relational Web supports the development of client-server applications where the control logic, business logic, database I/O, and user interface can be handled by the server. Yet, each component is separate from the others in a modular, easily-maintainable design. End-users are provided with a web browser, or thin-client user interface, while major application components are deployed to a single server. It's a winning combination.

Relational Web, offers a high-performance alternative to Java Web Application Servers, such as IBM's Websphere and Oracle's Weblogic. ILE languages offer significant performance advantages over Java, and Relational Web offers vast performance advantages over comparable Java Web Application Servers. With Relational Web, it is realistic to expect a CPU performance improvement of at least five times, over similar Java based applications.

Relational Web, however, is an excellent means of accessing IBM i data and other resources from Java clients - which might also be IBM i based. It provides an efficient and highly scalable message service for any HTTP client that might need the services of an ILE program. Having an ILE application supply data and services to a Java program through Relational Web is an effective strategy.

For example, IBM i based Java programs can send requests to to the HTTP server that are routed to ILE applications through Relational Web. This offers a solution that is more efficient and scalable than the dynamic program calls that are implemented under the Java Toolbox and corresponding IBM i Host Servers. The same services can be provided to Java and other clients that might be hosted on non-IBM i server or workstation platforms.

ILE solutions are definitely strategic to IBM i! Indeed, much of IBM i is based on ILE components. And many future IBM i enhancements will likely be built from ILE components.

There is no question that legacy languages offer time-tested, and long-lasting value. The real question is whether people will only pay attention to IBM's current marketing campaign, or will they also consider a logical and historical perspective in determining their own strategy?

Our view is that a platform independent strategy is more myth than reality. It also leads to unnecessary complexity and performance concerns.

Relational Web is for people who consider IBM i to be strategic to their organizations. If so, then an IBM i specific framework makes sense.

If the terms used in this overview are unfamiliar, don't worry. It won't be hard to learn to use Relational Web, if you've worked with an ILE language (RPG, COBOL, or C). Relational Web applications have many characteristics similar to 5250 programs. We'll show you how.

• Supports Web applications
• Strategic application modernization
• Close coupling with IBM i and ILE
• Message-based communication
• True client-server architecture
• Powerful, high-level API
• Best performing
• Highly productive
• Simple development & deployment
• Not a code generator
• Not a script processor
• Not a 5250 conversion tool, per se
• Supports Model-View-Controller design guidelines

Let's take a closer look at the components that define a web application. It will lead to a better understanding of how Relational Web works, what you can do with it, and what it can do for you.

All web applications involve a Web Client, a Web Server, and a standard protocol. Relational Web extends that basic architecture with a Message Service, and a powerful API used by ILE Application Servers.

Application Servers provide dynamic content, information, and services to Web Clients.

Web browsers are the most common Web Client. Mobile devices are another type of client. Some organizations may even build their own client applications to connect and interact with an Application Server.

A Web Server/Message Server handles the communication between Web Client and Application Server.

The Application Server is an ILE program you'd write (with the aid of the Relational Web API). The Application Server may actually link to other service programs in order to achieve the level of modularity you might desire.

The response from the Application Server (typically HTML, XML, WML, and Java Script) supplies both dynamic content, and in the case of HTML - how to display it. It's a powerful means of providing a user interface that's easy to deploy across a network of any size, and involving any number of users.

The Web client makes a socket connection to the web server, sends a request, and waits for either a response, or a timeout event to occur. The request always includes an address known formally as a Universal Resource Locator (or URL). It's part of the HTTP specification.

For example:

http://www.example.com/myProgram/myTopic.isp

could be a hyperlink that a user might enter into the browser's address line. Let's say that it references a resource on your computer.. In this case a program you've written (myProgram), and a specific topic (myTopic) that your program is able to respond to.

The basics of the HTTP protocol are actually very simple. It's a message protocol. Relational Web supplies a higher-level API that shields the programmer from much of this detail, but a basic understanding of HTTP leads to a better understanding of all web development tools, including Relational Web.

After connecting to the HTTP server, the browser sends a message in the following format:

1. One Request Line.
2. Zero or More Header Lines.
3. One Blank Line (CRLF).
4. Optional Message Body.

For example:

Note that the request line includes the GET keyword, the requested resource (your program and topic), and the browser supported protocol (HTTP 1.1).

If the browser were sending HTML form fields to the host, then the "POST" keyword would likely be used instead of GET, and the message body would be a potentially lengthy string of field name and value pairs.

Note that the format for request headers is an HTTP keyword, a colon, and a string.

If you're writing your own HTTP client, rather than using a Web browser, you'll probably choose to use fewer headers. The only line that's absolutely required by the Web Server is the one with the GET or POST keyword.

You'll also need to be able to connect to the Web Server over a TCP/IP socket. MS Windows programmers often use a socket ActiveX control, while Java programmers use high-level socket classes. The optional message body can be any text of your choosing and would be application specific.

Relational Web provides an automatic logging feature that can be enabled or disabled for any application. The log delineates all input received from the browser. It can be very useful during development for debug and testing purposes.

The response from the HTTP server has a format that is very similar to the request:

1. One Response Status Line.
2. One or More Header Lines.
3. One Blank Line (CRLF).
4. Optional Message Body.

For example:

In this example, an HTML document is returned to the browser. Again, if you're writing your own HTTP client, rather than using a browser, you might not be interested in the HTTP headers. If so, you can simply scan the response stream for the double carriage-return + line-feed that marks the end of the headers. All subsequent data would be the application specific message.

The automatic logging feature noted previously can be enabled or disabled, by application, for either input received, output sent, or both.

The World Wide Web Consortium at:

http://www.w3.org

has a great deal of information on Web protocols such as HTTP and HTML. The actual specification documents may be tedious to read for most people.

However, your favorite Web search engine can help you track down easy to read tutorials, if you have further interest.

As noted previously, a web URL may reference a resource on your system. It may be a static file located in the IFS. But in the example above, it's a Relational Web program (that you might write) called "myProgram" and a program topic called "myTopic".

The ".isp" extension simply tells the HTTP server to forward the request to the Relational Web Message Server, which in turn forwards the request to one of the currently running instances of "myProgram". If myProgram is not currently active, then the Message Server will return a generic message file that you define when you add an entry for your program in a Relational Web configuration file. The response might simply state that your server is unavailable at that moment.

myProgram would be an ILE program that you might write (with the help of our API) to handle the myTopic request. Actually, you'd probably scope "myProgram" to handle a dozen or more different "topics". myProgram would be an implementation of a Presentation Controller discussed briefly in the the Architectural Overview.

A "Service" directive in the HTTP server configuration file tells the HTTP Server to send all requests ending with the ".isp" extension to the specified Service procedure of the Relational Web Message Server. The necessary directives are added to the HTTP server configuration file when Relational Web is installed.

What is the significance of the ".isp" extension? Nothing, really. And you can change it to anything you want. We coined the extension after considering that a Web page might be returned from an ILE Server. In other words, ILE Server Page. Web tools and application servers from other vendors use the same technique to route requests. Microsoft uses .asp, while Java Application Servers use .jsp, for example.

The Relational Web Message Server is a small ILE Service Program that exports a single procedure to handle all new requests from all browsers. It has the potential of simultaneously handling thousands of concurrent user requests, for hundreds of different applications hosted on your server.

The Message Server operates as an IBM i HTTP server "plug-in". It is initialized when the HTTP server starts. It runs in the same address space as the HTTP server. It supports the HTTP server's multi-threaded architecture. In effect, it becomes part of the HTTP server.

Instead of starting more BCI Servers to handle peak loads (as with CGI), the HTTP Server uses threads that are started from it's main BCH program for our Message Server interface. Therefore, efficiency is maximized. IBM's Websphere Application Server uses the same technique to interface with the HTTP Server. This underscores Relational Web's close coupling with IBM i. We're aware of web tools from other vendors that supply their own HTTP server, for example.

TCP/IP and the HTTP protocol are, in essence, a client-server message service. Relational Web's Message Server is an extension of that service. Rather than making a dynamic program call, as in the case of a CGI application, messages are passed along a short chain of concurrently running servers. It's a high-performance architecture that eliminates call-level initialization and overhead.

A message service, such as that provided by Relational Web, is most appropriate in applications that experience frequent, high-volume interaction, or need to keep track of client state from one request to the next, or need to provide the highest level of performance, or must provide a real-time interface with external systems at the same time they handle web requests.

Complex applications may require hundreds of active servers to support client requests. Relational Web's message service is designed to quickly and efficiently pass messages between potentially hundreds of active server programs and thousands of concurrent clients. It's a multi-threaded architecture that is designed to scale with the hardware. The number of active threads is determined by your HTTP server configuration files. Relational Web enables you to launch multiple instances of your application servers in order to handle high-demand usage scenarios. We balance loads across all instances. Applications use zero CPU time while in a data queue wait state.

CGI programs have always had a reputation of being slow and unable to scale. The major reason for this is the way they are loaded. CGI programs get loaded at each invocation in a process separate from the web server. This obviously requires a relatively large amount of resource, both in the web server and the operating system.

Scalability usually refers to the ability to accommodate more users. But what about scalability in terms of functionality? CGI programmers tend to scale back the number and type of resources allocated by their programs in order to improve performance.

For example, a simple CGI based database maintenance application may be divided into 10 or more programs, each called separately from the HTTP Server. Some may say that's modularity. But, the individual components are not reused in other applications, so perhaps it's modularity only for the sake of performance. While the individual programs are simple to write, they often overlap in terms of resources used (I.E. same files), and cause a lack of continuity in the overall application. A message service eliminates that problem. CGI is most appropriate for occasional queries or reports.

Some programmers will use persistent CGI to keep their web applications active, and avoid call-level overhead. But the main problem with persistent CGI is the one-to-one correlation between end-user and server. The server remains active, but only for one user - one session. If you have 1000 active users, then you need 1000 active servers. If you have 1000 users needing 10 applications, then you need 10,000 active servers.

There's the question about how long a CGI server instance should remain active, and dedicated to a single session, and how to terminate it? Also, when and how to call RCLACTGRP to free the resources of the entire activation group?

Having a message server in the middle, is much more resource friendly than persistent CGI, and a better architecture for interactive applications that experience frequent use. If an average user submits a new request every 10 seconds, and it takes the application server 10msec of CPU time to handle that request, then a single instance of a single application server can handle 1000 concurrent users.

One of the main ideas behind the Relational Web API is programmer productivity - to make the the programmer's job easier.

Another benefit of a high-level modular API is fewer bugs during development. By making it easier for the programmer to respond to web requests, he or she is able to devote more time to the requirements of the application. Much less time is spent to implement changes that crop up during development. And less time is spent on program maintenance.

The value and use of the Relational Web API is delineated much more extensively in our Developers Guide and API Reference. Additionally, you'll only truly understand it's value after implementing it in a few applications. The ideas we introduce in this section are extremely summarized.

Web browsers send several types of input to a Web server. These include HTTP headers, query-string parameters, form variables, file attachments, and cookies. Relational Web receives all the input, automatically parses it, and places it into components where it can be easily referenced by either name or index number. The API is comprehensive and clear. The distinctively web portion of the API is divided into a set of ILE service programs, namely:

Input received from the browser is combined with HTTP server status and environment variables to provide complete information to your applications, that may be needed to provide the best response. This is a big contrast to the CGI API supplied by IBM which leaves a lot of work to the programmer to handle user input.

Relational Web supplies an API to support the concept of sessions. Sessions provide a means of tracking and managing client-state across multiple requests. One attribute of the web is that a single instance of a host program may need to handle many different types of requests from many concurrent users.

Applications are often designed in which a sequence of interactions leads to a final conclusion, or transaction. This type of process is often called a "dialog". The host application must be able to reference input received from previous requests in order to complete the current request, or perhaps finalize an order. Sessions have an expiration value. If the user abandons an activity prior to completion, and the session expires, then any previously stored session data should be cleared. Sessions facilitate the deployment of more cohesive, robust applications. They can be a key to application security. For example, a sensitive banking application may use the expiration property to help prevent unauthorized use if a "logged in" user leaves his workstation for a period of time. That's the idea in a nutshell. Relational Web is the only ILE specific Web tool we're familiar with, that supplies a session API.

It is possible, though uncommon to find any HTML imbedded in ILE Web applications that use the Relational Web API. And that's a good thing. Our API enables the user interface to be developed and maintained independently of the program logic - perhaps by different experts. A change to the HTML doesn't necessarily affect the program. The opposite is also true.

The HTML author divides the file into sections, and inserts markers to identify the location where program data is to be placed. The file is loaded into memory and parsed into fragments during program initialization. This maximizes the performance and efficiency of merging program data with HTML during the request-response cycle.

While HTML applies to a Web browser interface, the concept of "text" templates applies as well to any formatted data stream. You might use it with pre-formatted XML, for example. Or, it can be used with any proprietary message formats.

We hope you'll use Relational Web to provide a GUI for your users, and web interaction with your database. But lots of tools can do that. Where Relational Web really shines is when performance is important.

For example, some developers avoid using HTML frames to reduce the number of calls to their application. But our message based architecture handles multiple frame pages easily.

What about applications that require the user interface to be refreshed frequently - for multiple concurrent users, such as a chat room? Relational Web is the right choice for that too.

When isn't performance important? Perhaps for asynchronous reports. But, for multi-user interaction with your database, and for on-line transaction processing, Relational Web offers a unique advantage.

Relational Web applications are deployed by:

• Using our API in your application server.
• Adding a reference to your application server in our deployment file.
• Using our commands to start and stop your application servers.

We also supply a menu.

Relational Web implements message-based communication between Web Clients and ILE Application Servers.

It frees programmers to focus on application specific requirements by providing a high-level, high-performance, full-featured API especially suited to Web browsers and other thin clients.

We invite you to peruse our User's Guide to discover precisely how to build and deploy Relational Web applications.