There are two main ways that a browser may interact with an Omnis application server - using the proprietary WebClient plug-in or using plain HTML.
The WebClient has the advantage of allowing you to easily create a sophisticated graphical interface to your web application, using Omnis remote forms. But it also means that users must download the plug-in in order to use your application, and that there is a limit to the number of users who may connect at one time.
You can also call Omnis methods directly from a normal web page without using the WebClient. Your page is limited to normal HTML elements, such as text, images and standard HTML form components.
With the WebClient, your application can dynamically respond to many different user events, such as clicking a pushbutton or selecting an item from a list. It does not need to redraw the whole page, and only needs to request limited data, to update the relevant portion of the form.
Using a pure HTML approach, the application usually responds to only one event on the page (typically a form Submit button). It can either redirect the users browser to a new location (which may be a page created on the server by the application, such as a report), or it can return the HTML contents of a page directly. In the latter case, Omnis Studio 2.4 has some limits on page length, but there are ways to get around this, which we will look at later.
WebClient applications are good when you have a targetted user base, who require Internet access to sophisticated database functionality. They allows you to provide an interface almost like that of a standard Omnis desktop application via the web, without the investment in development that, say, a Java solution would require.
A pure HTML interface would be useful on a site where you do not expect visitors to use an application regularly, in which case they may hesitate at downloading a plug-in, or where the required functionality is fairly simple, and can be handled using a page-based approach. Any number of users can interact with HTML applications at once, the server queues the requests and services them in order, so concurrent usage is less of an issue.
Issues such as expected load (application traffic) and the complexity of your business processes may influence your decision.
Document prepared 15 AUG 2000 by Tim Stewart