Most business applications present information and also collect new information. Occasionally, this new information is simply stored or recorded. Many times this new information also causes another action or some coordinated information update, called a transaction. In some cases, these updates are irreversible¾for example, if the transaction controls an industrial process such as drilling a hole in a piece of metal or pouring uncured thermo-setting plastic into a mold.
Frequently, these applications are client/server applications. That is, the action is initiated at one computer¾the client, and the recording, update or process takes place at, or is controlled by, another computer¾the server. Increasingly, in multitiered or networked implementations more than just two computers are involved.
You can implement the client portion of these applications as a set of one or more components and scripts that execute within an Internet Web browser. Because the browser has become the client, we call the new implementation a server/browser application. Here are some ways you can create server/browser applications from existing applications:
Use the Windows NTÒ Internet Information Server (IIS) Internet Database Connector (IDC) to retrieve and update information stored in any ODBC-accessible data repository.
User input is through the standard HTTP POST/GET forms technology. Output is standard HTML, including HTML tables, frames, and even ActiveX Controls.
Technology: The Internet Information Server IDC and any ODBC data source.
Add client-side ActiveX Controls to the IDC application.
These controls could send HTTP POST/GET requests to the HTTP server creating a more capable layer between the user interface and "plain" HTTP.
Technology: The Internet Information Server IDC and ActiveX Controls.
Implement the above application in server side scripts/controls.
Technology: Internet Information Server 3.0 Server Side Scripting and server side ActiveX Controls.
Create a server side ISAPI application that delivers ActiveX Web pages.
In addition to normal Web interaction through the HTTP connection between the client and the browser, the ActiveX Document Application and the ISAPI Application can directly interact through Sockets, RPC or Distributed COM (DCOM).
Technology: Internet Server ISAPI and ActiveX Document technologies, optionally DCOM.
Create a server side ISAPI "connector" application that uses the services of a server application running on the same server (Windows NT) or a different (Windows NT or other platform) server through RPC or Distributed COM.
Technology: ISAPI application and RPC or DCOM. NT Service.
Modify an existing desktop application or stand-alone workstation application to run on an HTTP server, and to interact through Web pages instead of its current graphical user interface.
This creates a Web Server application from the current desktop application and makes it available to many users. One way to create this modification is for the application to offer its user interface functionality through Window Automation (IDispatch:: interface commands) that is used from Active Server Page (Denali) scripts.
Technology: ISAPI application, or NT Service, or Windows Automation component. Active Server Page (Denali) scripting in Visual Basic Script, JScriptÔ, or any ActiveX scripting language.
Modify the client side of an existing client/server application to run on an HTTP server, and to interact through Web pages instead of its current user interface.
This creates a multitiered application in which the current desktop application becomes an intermediate tier between the previous server (or set of servers) and the users.
Technology: Same as for the previous option, but as a multitiered client/server application set, thus offering greater flexibility.
In either of the two previous scenarios, stand-alone application or client/server client, implement the "new" client as a single ActiveX control on a static "heading text only" Web page delivered to the client
Maintain a state-based conversation between this control and the server portion of the application. In the extreme case, this control could even be an ActiveX Document viewer. The server portion of the application could be on the same server or a different server machine from where the page was delivered, and there could be multiple server components on one or more server machines. The client control and the server components of this application could communicate by any means workable over a TCP/IP connection. Distributed COM is probably the most flexible and has the lowest implementation effort.
Technology: Same as for the previous options with the additional use of ActiveX Controls and client server communications through Windows Sockets, RPC, or Distributed COM.
In either of the two previous desktop application or client-server client scenarios, implement a set of ActiveX Controls within a Web page.
Orchestrate the behavior of these controls with a script delivered with the page to the client. As above, maintain a state-based conversation between these controls as a set and the server portion(s) of the application. Each control could have one or more server component interactions, but more likely the server interaction would be "centralized" and controlled by the script and/or a single server interface control.
Technology: Same as for the previous options with the additional use client-side scripting to orchestrate interaction and "integrate" many controls into a single application.