Since this is a site dependant architecture concept there is no examples but conceptual instructions are provided.
I am amazed at how many people think because an application has 2 pieces(client app and a server app) that it is a client/server application. Client/Server is a conceptual architecture not a physical design. A client/server application can run from one physical system.
The concept of client/server is to separate data from the display. In this way data can be received from disparate sources and merged into one view. The client layer controls all aspects of display and makes data requests to the server. The server layer controls access, business logic, and data. The server responds with data but does not tell the client how to display the results.
In most web architectures this separation does not happen. Each request for information from the server replaces the display in the client browser. This creates a lot of overhead since each time the layout of the page must be retransmitted and redrawn. It is much more noticeable when the application is forms based(most business apps). The whole form has to be redone even though just the form field data will change.
The Web/Server application modal(WSAM) creates an architecture that truly functions like a client/server application with separation of data but also provides all the benefits of web applications.
Currently anyone trying to make a WSAM application is using Java/ActiveX with very limited results... But you don't have too! Using DHTML and frames you can now create WSAM applications! Even better any server requests can run in background, dramatically reducing wait times.
Let's take a standard web form and compare what a user does...
- Current method - User requests form, completes form and presses save. Server sends user back confirmation page. Use clicks link to enter next entry which sends another request to server. Server sends new complete form to browser.
- New method - User requests form, completes form and presses save. Form clears, tells user system processing request and let's them add the next entry immediately. When process complete user is informed via message at top of page. The form never reloads.
The benefits of the new method are everywhere. The user is much more productive, the network processes much less data, the server can handle more requests and the server focuses more on data and not the presentation layer.
So how do you do it?
- Create a frames document with 2 frames. One named "process" the other named "main". Set process size to "0" and main size to "*" so process frame is hidden from view.
- Create your form and make sure it loads in the main frame. The form must have an area for messages at top. Very important - Make sure the target for the form is set to the process frame.
- Include a script with your form. Include variable to track processing status, a function that validates and submits the form, updates the message to "Now processing", clears the form fields, sets status variable to "processing" and sets timer to watch variable for completion. Timer function needs to monitor status variable and when "processing complete" it needs to check the process frame "result code" variable(see below) and act accordingly.
- The form results page is probably a server object(ASP, CGI, DLL...). In our example(an insert) the response from the server is a tiny script that includes 2 variables (result code and errormsg), plus code to set status variable in main frame to "processing complete". The result code is either 0(success) or any other number(failure). If there is a failure details are provided in errormsg otherwise errormsg is blank. Other examples might use script arrays to reflect a recordset. No HTML is required, just the data in "script tags".
With this architecture the web form functions as a client server application. The productivity benefits when doing forms processing easily pays for the architecture and your real cost per transaction savings is just gravy. It is important to note that client side validation is critical to avoid server errors.
You could make this concept have multiple concurrent processes. Even have client side queues. Once you understand the concept the possibilities are endless.
This architecture extends web applications and dramatically reduces potential limitations of applying web solutions to data intensive mission critical applications. I first presented this concept back in 1996 when using IE3 and was considered too advanced for the time. The concept can be minimized to support virtually any browser that supports frames and script.
Hope it helps those that want it.
P.S. The WSAM acronym is something I made up ;-)