Executive Summary
In England, in the early part of 1720, the investment world was taken by storm with people investing money in projects simply because they were based in the South Seas and the speculation was, for many reasons, that these projects were going to be highly profitable.
This came to be known as the South Seas Bubble. Many of the projects being invested in were totally vacuous ('vaporware' in modern terminology) and most were unsuccessful. Eventually, the Bubble burst, few investors saw a return on their investment and most people involved lost all of their money.
Today, the Worldwide Web is taking the computing world by storm. Everyone wants to get on the web - everyone seems to have a web solution of some kind.
Before investing in a web enabling solution, you should carefully consider the true business benefits of the proposed solutions as well as how this will fit into your existing, and probably quite extensive, client-server environment.
Using the web for running applications offers a number of opportunities, including solving two of the main headaches of today's client-server systems. The web greatly reduces the costs of administration and maintenance of your applications. The web also allows for a very thin, very low cost client.
At the same time, you probably already have client-server applications running today and have expectations for the applications you intend to run on the Web.
You still want to run mission critical applications which are scalable to large numbers of users. Your applications should also be open to all of your environments and they should support, and often drive, your business practices.
In fact, as you use the web to open up new markets and to get access to even more geographically dispersed users and customers, the traditional benefits of client-server (scalable, reliable, open applications) will become even more important.
It's therefore critical that any web solution you adopt also provide you with the benefits of client-server based applications in conjunction with the new benefits of the web.
Rushing blind into the first solution which seems to provide some or other web enablement is almost guaranteed to fail and your own web bubble will be burst.
The solutions provided with Developer/2000 for the Web will allow you to leverage everything which is good about the web whilst maintaining the strengths of client-server in a proven, robust and scalable environment.Introduction
The web solution provided by Developer/2000 for the Web is a pure web approach, leveraging everything which is good about the web using Java for interactive database applications and HTML or PDF for web publishing.
This approach has several key benefits :
1. Thin Client - Low Administration and Maintenance Costs
As you'll see later in this paper, the Developer/2000 for the Web Java solution requires nothing to be installed on the client. This means you have minimal client side requirements - the Java applet, for instance, is around 60K ! It also means that administration and maintenance is all done on the server rather than the client.
2. Complete Platform Support (including the Network Computer)
Deploying applications on the Web provides a number of advantages. In particular, the central administration and low cost of hardware are very attractive benefits.
However, Web deployment is not a panacea to every IS problem and other deployment options such as running natively on Windows, Mac, Motif and character mode all have their own benefits. It's fairly unlikely that the Web will ever be the only deployment platform.
It's therefore important that your application development tool allows you to deploy applications into multiple environments with minimum effort. You also don't want to be locked into a particular platform for your web applications by ActiveX or a Plug-In.
Using Developer/2000 for the Web you will be able to deploy the same application on Windows, Motif, Mac, Character Mode and the Web with no changes required to the application. It also means that your applications will run unchanged on a Network Computer.
3. Zero Migration Costs
Any Developer/2000 application you have today will run on the Web, unchanged. The only caveat to this is if you have taken advance of any OS specific facilities which perform UI functions.
This means you can take all of you existing Developer/2000 applications and move them to the web unchanged. It also means that you can use the mature and productive environment of Developer/2000 to build any new applications you wish to deploy on the web.
You can use the world's leading development tool to build your web applications and leverage our extensive experience and expertise in the application development world for your web applications.
Banking Your Business On Developer/2000 for the Web
Oracle Applications division is targeted to make almost $1 billion revenue in FY97. This is a fifth of Oracle's entire revenue. In addition to this revenue, we also run our entire $5 billion business using these tools - all our Order Entry, Payroll, HR etc. are run using Oracle Applications.
All of the Oracle Applications are built using Developer/2000. We bank our business on the success of our Development Tools. Oracle Applications will also be using the Web capabilities of Developer/2000 as their solution for deploying applications on the Web.
This clearly demonstrates the commitment Oracle has to our tools and our Developer/2000 for the Web solutions.
Developer/2000 for the Web provides a solution which uses our existing technology to provide Web application deployment for our customers. One key benefit of this approach is that it will allow our customers to deploy their existing applications on the web using the same skills and tools they use today, without needing to change a single line of code in their applications.
For new application development, customers will be able to use Developer/2000 to build their applications in the same manner they do today and then deploy these on the Web unchanged.
Developer/2000 for the Web does not attempt to create a development platform based upon Java although we may, in future releases, deliver an environment in which Java development can be fostered.
This document outlines the requirements for the Client and Server components of Forms in Developer/2000 for the Web and some of the technical issues relating to their implementation.
The Server component for Developer/2000 for the Web Forms applications will be a modified version of the existing runtime engine. In this document, this component will be referred to as the Application Server (App Server).
The Client component for the Developer/2000 for the Web project will be a Java Applet, which will be created and managed by the product itself - the application developer will not need to write a single line of code to enable this.
The Java Applet will be executed within a Java compatible Browser. In this document, this applet will be referred to as the FormsClient. The terms FormsClient and Java Applet are used interchangeably in this document. The viewing mechanism that contains the FormsClient shall be referred to as the Browser.
The currently shipping release of Developer/2000 has the following well established capabilities:
Scalable and robust application deployment
Handling complex logic and tight database integration
Handling complex declarative and programmatic validation
Handling Client-Server partitioning through stored procedures
Managing large volumes of fetched data through record management facilities capable of buffering many thousands of records in memory and on disk
Using the PL/SQL programming language
User interface portability to Motif, Windows, Macintosh and character mode
These capabilities have been developed and fine tuned over many years of experience with database technology.
The current Developer/2000 runtime model looks as follows:
Forms
| User Interface Elements
Fields, pushbuttons, scrollbars, dialogs |
| Application LogicNavigation sequence, declarative and programmatic field & record validation, general UI event processing, UI related trigger processing.(Key-xxx, When-Mouse-xxx, When-Validate-xxx). |
| Data Management
Record management, database interaction, trigger processing. (On-xxx, Pre/Post-xxx, When-New-xxx)
|
The current Developer/2000 runtime architecture
Developer/2000 for the Web separates the handling of the User Interface elements from Runform and run them within the Java Applet on the FormsClient. We will talk a bit later on how the Java applet is created and managed, but for now, let's just assume that it has already been automatically created (which is, in fact, how it works).
User interface interactions, such as changing a checkbox, inter-field navigation or choosing a menu option will be performed by the user in the FormsClient with the potential involvement of the Application Server.
As you can see from the diagram below, the Application Server is still executing the standard .FMX file which has a number of advantages, but more about this later.
User actions which operate solely within the User Interface, such as typing a series of characters into a Text Field, will be handled purely within the FormsClient.
Other user actions, such as changing a checkbox or inter field navigation, will require the Application Server to be notified of the relevant changes so that appropriate trigger processing may occur.
Some aspects of the existing system, such as the operation of the dialogs, will be able to operate completely within the FormsClient until the user performs a high level operation such as Accepting or Canceling a dialog.
In these cases, navigation around the dialog will be handled completely without the involvement of the Application Server. Examples include the Logon Dialog, Show Keys window, and the List of Values window.
Other more complicated processing, such as Trigger and Commit time processing, Record management and general database interaction will occur within the Application Server.
FormsClient (Java Applet)
| User Interface ElementsFields, pushbuttons, scrollbars, dialogs |
|---|
| Network Interface |
Application Server (& .FMX file)
| Network Interface |
| Application LogicNavigation sequence, declarative and programmatic field & record validation, general UI event processing, UI related trigger processing.(Key-xxx, When-Mouse-xxx, When-Validate-xxx). |
| Data ManagementRecord management, database interaction, trigger processing.(On-xxx, Pre/Post-xxx, When-New-xxx) |
The FormsClient/Application Server Architecture
You will also be able to configure your applications depending on whether you plan on running within an Intranet or over the Internet.
Within an Intranet, you can make certain assumptions on the level of equipment that people will be using and the bandwidth of the network they are running on. In this scenario you will probably run your applications with Field Level Validation, so that the users get immediate feedback on any changes they make.
Over the Internet, you cannot make any assumptions, other than perhaps that you know the network will probably be slow. In this scenario you probably want to run in a Block or Form Level Validation mode. This will minimize the amount of communication between the FormsClient and Application Server, but will mean that your users will not get immediate validation of any data they enter. This is, in fact, how most internet applications run today.
This change of validation mode is a simple declarative setting in the product with no code changes required to your application. You should ensure you are aware, however, of what the implications might be of your users interacting with their applications with validation being performed at the block or form level.
The interaction between the FormsClient and the Application Server is a series of Requests and Responses.
Requests from the FormsClient typically take the form of Events, although requests for specific data will also be supported. Responses from the Application Server typically take the form of a series of changes to the User Interface such as value changes, adding and removing components.
The FormsClient will receive User Interface commands such as "create a green text-field on canvas my_canvas1", and translate them into actual User Interface objects in the Java Applet.
The Application Server will bundle a set of these events and the FormsClient will create the associated display.
As mentioned before, the Application Server will be a modified version of the Forms runtime engine. All interactions, such as creating, modifying properties and deletion of User Interface items will be buffered into memory. Once Runform Returns for Input these buffered interactions will be synchronized with the FormsClient by returning a bundled set of User Interface commands.
The following examples illustrate the exchanges between the FormsClient and the Application Server when a user changes an employee bonus to "5000.00", in the form called 'Bonus', and then clicks in the EMP.ENAME field.
In this form there is a When-Validate-Item trigger that displays an alert, each time the Bonus amount is raised above $2000.00, asking if the operator really wants to make the change:
At this point the field value has changed from the unformatted value "5000.00" to the formatted value "$5000.00", using the Format mask in the Application Server, and an Alert has appeared asking if the user wishes to do this. A "Yes" response to the alert presented by the FormsClient would start the following sequence of requests/responses:
As you can see in the above description, the only network interaction between the Client and Application Server portions is the client indicating events and the server passing back the user interface diffs.
These UI diffs are likely to be of a textual nature (e.g. user wants to see another row or a calculation changes the value of an item) which will be very small amount of data and of a type which could be very easily compressed.
In fact for some applications, the amount of network traffic between the client and application server will actually be less than in a traditional client server environment.
We've mentioned a number of times the Java Applet which is downloaded onto the client. You'll now see how this applet gets created and managed for an application.:
A generic Java applet interprets each form on the fly at runtime. Let's take a look at what this means and why it makes sense.
First of all, the applet isn't interpreting the entire form, but only the UI aspects of the form. The compiled .FMX file is still running on the same machine as the Application Server, and the applet is only receiving responses which relate to changes in the UI.
The first time the user attempts to execute a form from the Web browser, the Java applet is downloaded into the browser from the Web Server. The Web Server then establishes communication between the applet and the Application Server (see below for more details on this communication).
Using this approach, if a particular screen is never visited, we never have to download its state which improves the performance and memory use of the application.
Secondly, this means that application startup should be fast, because the Java applet will be thin, and only the data relating to the first screen is downloaded. Thirdly, it also means that the administrative and maintenance overhead will be lower as you will not need a different Java applet for every form that you would like to run on the web.
Just like calling any HTML page or Java applet, a URL in the client would point to the FormsClient Java applet on the Web Server, passing the forms file name as a parameter.
The Java applet would then be downloaded onto the client (the Web browser). At the same time, the Web Server would call the Application Server to initiate communication between the FormsClient and the Application Server and to run the appropriate .FMX file.
There will be two modes of communication between the FormsClient and the Application Server depending on whether the application is being run over an Intranet or Internet. This communication is handled automatically by the FormsClient and Application Server without the need for any manual coding.
Intranet
Running an application within an Intranet, you most likely do not have to go through a firewall. This will allow us to use a more direct communication method. In this mode of operation, the Web Server will initially be used to establish a connection between the FormsClient and the Application Server :
Once the connection has been established, the Web Server is no longer required and the FormsClient and Application Server will communicate directly with each other using an RPC mechanism possibly based on Sun's RMI protocol or on IIOP :
Internet
In an Internet environment, the FormsClient is most likely running outside a firewall with the Application Server running inside. In this mode of operation we will use standard HTTP or IIOP protocols for communication :
For Web Servers which support the cartridge mechanism (e.g. the Oracle Web Server), we will supply a cartridge program which performs the communication between the Web Server and the Application Server. For other Web Servers, we will supply CGI scripts which perform this communication.
The Application Server will be based upon a modified and simplified version of the Forms runtime engine (runform). This will allow your existing .FMX files to be run with no code changes - all of the communication between the Application Server and FormsClient will be handled automatically via the methods discussed above.
In the initial release, the Application Server will reside upon the same host as the WebServer. This is due to limitations in the security model for a Java Applet which prohibit communications between the applet and any host other than the one from which the applet was downloaded.
In a general situation, customers may want to run different applications from different hosts. This would require the FormsClient applet to establish a network connection with multiple hosts.
Due to security restrictions in the Java environment it is not currently permitted for an embedded Java Applet to establish a network connection to any host except the one from which the Applet was downloaded [the WebServer host].
In general, messages sent and received should have provision for Client and Server authentication of some sort. Since, in the Internet case, the connections are not going to be maintained, and instead are going to be established on demand we will need to ensure that no-one can attack this interface and so cause a security violation.
We will leverage all the security features that the RMI or IIOP protocols provide.
The network performance between the FormsClient and the Application is expected to be better than a character mode terminal environment.
In fact, character mode has some of the same central administration and maintenance characteristics of the web and is how some of our largest customers (including many Oracle Applications sites) run today. These customers count their user bases into the thousands and many of them are looking to Developer/2000 for the Web to provide a better UI solution while at the same time leveraging very similar benefits to character mode.
We therefore already have a demonstrated and proven ability to scale applications to vast numbers of users. An ability we will continue to leverage with Developer/2000 for the Web.
Clearly this is an important issue and we will be benchmarking the performance and scalability of Developer/2000 for the Web at every stage. We fully understand that good performance and scalability is critical for the success of this product.
It is likely that in the initial release of Developer/2000 for the Web we will have limitations on what is and is not supported. These limitations will be caused mainly by the youth of the Java programming language. Depending on the development of Java over the next few months, these limitations may include not supporting the following in the first release:
OLE
OCX
VBX
Developer/2000 for the Web leverages all the benefits you are looking for from a web solution, including the major wins of low client costs and central administration. It does this within an architecture that allows you to reap the rewards of the web whilst maintaining the strengths of a traditional client-server environment.
Your web based applications run in a scalable, robust and mature environment - key attributes of any second generation client-server system. Your applications are build with mature, proven and highly productive tools, allowing low cost development and rapid time to market - significant benefits when you are competing in the fast changing world of the Web.
Oracle's billion dollar revenue from Oracle Application is testament to the commitment that Oracle has for Developer/2000, with solutions for client-server and the Web. With such an investment in technology you can be guaranteed that Oracle will provide you with the solutions you need for today and well into the next century.
Developer/2000 for the Web truly provides you with the best of the web and the best of client-server in a single product.