Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework


United States Patent		5987245
Gish		November 16, 1999

	*Title*

Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework

	*Abstract*

An interprise computing manager in which an application is composed of a client (front end) program which communicates utilizing a network with a server (back end) program. The client and server programs are loosely coupled and exchange information using the network. The client program is composed of a User Interface (UI) and an object-oriented framework (Presentation Engine (PE) framework). The UI exchanges data messages with the framework. The framework is designed to handle two types of messages: (1) from the UI, and (2) from the server (back end) program via the network. The framework includes a component, the mediator which manages messages coming into and going out of the framework. The system includes software for a client computer, a server computer and a network for connecting the client computer to the server computer which utilize an execution framework code segment configured to couple the server computer and the client computer via the network, by a plurality of client computer code segments resident on the server, each for transmission over the network to a client computer to initiate coupling; and a plurality of server computer code segments resident on the server which execute on the server in response to initiation of coupling via the network with a particular client utilizing the transmitted client computer code segment for communicating via a particular communication protocol.



Inventors:	Gish; Sheri L. (Mountain View, CA)
Assignee:	Sun Microsystems, Inc. (Palo Alto, CA)
Appl. No.:	675267
Filed:	July 1, 1996

Current U.S. Class:			719/310 709/203
Field of Search:			395/680,682,683,685,200.32,200.33,200.31

	U.S. Patent Documents
3946503	March 1976	Buchan et al.
4200867	April 1980	Hill
4588074	May 1986	Strong et al.
4682957	July 1987	Young
4739477	April 1988	Barker et al.
4779187	October 1988	Letwin
4798543	January 1989	Spiece
4800488	January 1989	Agrawal et al.
4803643	February 1989	Hickey
4825358	April 1989	Letwin
4829468	May 1989	Nonaka et al.
4837487	June 1989	Kurakake et al.
4866602	September 1989	Hall
4897781	January 1990	Chang et al.
4933880	June 1990	Borgendale et al.
4954818	September 1990	Nakane et al.
4955066	September 1990	Notenboom
4967378	October 1990	Rupel et al.
4974159	November 1990	Hargrove et al.
4990907	February 1991	Jikihara et al.
5021974	June 1991	Pisculli et al.
5027273	June 1991	Letwin
5109433	April 1992	Notenboom
5113341	May 1992	Kozol et al.
5124989	June 1992	Padawer et al.
5125077	June 1992	Hall
5125087	June 1992	Randell
5138303	August 1992	Rupel
5146580	September 1992	Naidu et al.
5155842	October 1992	Rubin
5187468	February 1993	Garthwaite et al.
5191615	March 1993	Aldava et al.
5195135	March 1993	Palmer
5204960	April 1993	Smith et al.
5214755	May 1993	Mason
5218697	June 1993	Chung
5220675	June 1993	Padawer et al.
5224038	June 1993	Bespalko
5231577	July 1993	Koss
5247658	September 1993	Barrett et al.
5255356	October 1993	Michelman et al.
5257369	October 1993	Skeen et al.
5257370	October 1993	Letwin
5261051	November 1993	Masden et al.
5261101	November 1993	Fenwick
5265261	November 1993	Rubin et al.
5268675	December 1993	Garthwaite et al.
5272628	December 1993	Koss
5274751	December 1993	Rosenberg
5276793	January 1994	Borgendale et al.
5281958	January 1994	Ashum et al.
5283892	February 1994	Nakane et al.
5287417	February 1994	Eller et al.
5287504	February 1994	Carpenter et al.
5287507	February 1994	Hamilton et al.
5287514	February 1994	Gram
5293473	March 1994	Hesse et al.
5297284	March 1994	Jones et al.
5300946	April 1994	Patrick
5301326	April 1994	Linnett et al.
5303151	April 1994	Neumann
5305440	April 1994	Morgan et al.
5313635	May 1994	Ishizuka et al.
5317746	May 1994	Watanabe
5325533	June 1994	McInerney et al.
5327562	July 1994	Adcock
5337258	August 1994	Dennis
5339432	August 1994	Crick
5341464	August 1994	Friedman et al.
5349648	September 1994	Handley
5357603	October 1994	Parker
5357605	October 1994	Rupel et al.
5359430	October 1994	Zhang
5363479	November 1994	Olynyk
5363487	November 1994	Willman et al.
5367617	November 1994	Goossen et al.
5369729	November 1994	Norris
5369766	November 1994	Nakano et al.
5369770	November 1994	Thomason et al.
5371847	December 1994	Hargrove
5371884	December 1994	Ross
5371885	December 1994	Letwin
5371891	December 1994	Gray et al.
5375241	December 1994	Walsh
5379430	January 1995	Nguyen
5379431	January 1995	Lemon et al.
5379432	January 1995	Orton et al.
5381347	January 1995	Gery
5381521	January 1995	Ballard
5390325	February 1995	Miller
5392427	February 1995	Barrett et al.
5394518	February 1995	Friedman et al.
5394523	February 1995	Harris
5398120	March 1995	Friedman et al.
5404529	April 1995	Chernikoff et al.
5410705	April 1995	Jones et al.
5412807	May 1995	Moreland
5414445	May 1995	Kaniko et al.
5414526	May 1995	Friedman
5414854	May 1995	Heninger et al.
5416726	May 1995	Garcia-Duarte et al.
5418956	May 1995	Willman
5423042	June 1995	Jalili et al.
5426760	June 1995	Moreland
5428718	June 1995	Peterson et al.
5428722	June 1995	Marsh et al.
5428725	June 1995	Sugai et al.
5428744	June 1995	Webb et al.
5430876	July 1995	Schreiber et al.
5430878	July 1995	Straub et al.
5432924	July 1995	D'Souza et al.
5432928	July 1995	Sherman
5432932	July 1995	Chen et al.
5432936	July 1995	Gray et al.
5432941	July 1995	Crick et al.
5432948	July 1995	Davis et al.
5434776	July 1995	Jain
5434965	July 1995	Matheny et al.
5437006	July 1995	Turski
5437013	July 1995	Rubin et al.
5437036	July 1995	Stamps et al.
5438433	August 1995	Reifman et al.
5442389	August 1995	Blahut et al.
5442751	August 1995	Patrick et al.
5442793	August 1995	Christian et al.
5446842	August 1995	Schaeffer et al.
5446887	August 1995	Berkowitz
5450536	September 1995	Rosenberg et al.
5452406	September 1995	Butler et al.
5452447	September 1995	Nelson et al.
5454109	September 1995	Bruynoghe et al.
5455577	October 1995	Slivka et al.
5455600	October 1995	Friedman et al.
5455854	October 1995	Dilts et al.
5455951	October 1995	Bolton et al.
5459865	October 1995	Heninger et al.
5461701	October 1995	Voth
5463471	October 1995	Chou
5465363	November 1995	Orton et al.
5467134	November 1995	Laney et al.
5467264	November 1995	Rauch et al.
5467435	November 1995	Douglas et al.
5467472	November 1995	Williams et al.
5469532	November 1995	Gerlach et al.
5469533	November 1995	Dennis
5471563	November 1995	Dennis et al.
5471564	November 1995	Dennis et al.
5471568	November 1995	Webb et al.
5471576	November 1995	Yee
5471675	November 1995	Zias
5473343	December 1995	Kimmich et al.
5473344	December 1995	Bacon et al.
5473362	December 1995	Fitzgerald et al.
5473691	December 1995	Menezes et al.
5473777	December 1995	Moeller et al.
5474840	December 1995	Kwetinetz
5475743	December 1995	Nixon et al.
5475805	December 1995	Murata
5475819	December 1995	Miller et al.
5475835	December 1995	Hickey
5475845	December 1995	Orton et al.
5479589	December 1995	Peterson et al.
5481667	January 1996	Bieniek et al.
5485373	January 1996	Davis et al.
5485460	January 1996	Schrier et al.
5485558	January 1996	Weise et al.
5485574	January 1996	Bolosky et al.
5487145	January 1996	Marsh et al.
5490249	February 1996	Miller
5490274	February 1996	Zbikowski et al.
5491800	February 1996	Goldsmith et al.
5493649	February 1996	Slivka et al.
5495561	February 1996	Holt
5495566	February 1996	Kwatinetz
5495571	February 1996	Corrie, Jr. et al.
5495577	February 1996	Davis et al.
5497463	March 1996	Stein et al.
5497492	March 1996	Zbikowski et al.
5499109	March 1996	Mathur et al.
5499334	March 1996	Staab
5499335	March 1996	Silver et al.
5499343	March 1996	Pettus
5500929	March 1996	Dickinson
5500931	March 1996	Sonnenschein
5504500	April 1996	Garthwaite et al.
5504591	April 1996	Dujari
5504889	April 1996	Burgess
5506983	April 1996	Atkinson et al.
5510811	April 1996	Tobey et al.
5510980	April 1996	Peters
5511197	April 1996	Hill et al.
5512921	April 1996	Mital et al.
5513315	April 1996	Tierney et al.
5515508	May 1996	Pettus et al.
5517257	May 1996	Dunn et al.
5517324	May 1996	Fite, Jr. et al.
5519818	May 1996	Peterson
5519855	May 1996	Neeman et al.
5519862	May 1996	Schaeffer et al.
5519866	May 1996	Lawrence et al.
5519867	May 1996	Moeller et al.
5522068	May 1996	Berkowitz
5524190	June 1996	Schaeffer et al.
5524200	June 1996	Orton et al.
5526485	June 1996	Brodsky
5526515	June 1996	Ross et al.
5526523	June 1996	Straub et al.
5528742	June 1996	Moore et al.
5530794	June 1996	Luebbert
5530799	June 1996	Marsh et al.
5530852	June 1996	Meske, Jr. et al.
5530856	June 1996	Owens et al.
5530864	June 1996	Matheny et al.
5530895	June 1996	Enstrom
5535324	July 1996	Alvarez et al.
5537415	July 1996	Miller et al.
5537526	July 1996	Anderson et al.
5537589	July 1996	Dalal
5537623	July 1996	Luebbert
5539471	July 1996	Myhrvold et al.
5539530	July 1996	Reifman et al.
5541942	July 1996	Strouss
5542068	July 1996	Peters
5542078	July 1996	Martel et al.
5544082	August 1996	Garcia-Duarte et al.
5544286	August 1996	Laney
5544301	August 1996	Orton et al.
5544315	August 1996	Lehfeldt et al.
5544320	August 1996	Konrad
5546518	August 1996	Blossom et al.
5546581	August 1996	McKinnis et al.
5546583	August 1996	Shriver
5546584	August 1996	Lundin et al.
5548305	August 1996	Rupel
5548508	August 1996	Nagami
5548718	August 1996	Siegal et al.
5548723	August 1996	Pettus
5548726	August 1996	Pettus
5548759	August 1996	Lipe
5548779	August 1996	Andert et al.
5550930	August 1996	Berman et al.
5550972	August 1996	Patrick et al.
5551024	August 1996	Waters
5551055	August 1996	Matheny et al.
5552982	September 1996	Jackson et al.
5553205	September 1996	Murray
5553215	September 1996	Kaethler
5553242	September 1996	Russell et al.
5553282	September 1996	Parrish et al.
5555228	September 1996	Izuka
5555368	September 1996	Orton et al.
5557440	September 1996	Hanson et al.
5557714	September 1996	Lines et al.
5557722	September 1996	DeRose et al.
5557723	September 1996	Holt et al.
5559884	September 1996	Davidson et al.
5559943	September 1996	Cyr er et al.
5560005	September 1996	Hoover et al.
5561751	October 1996	Wong
5561786	October 1996	Morse
5561788	October 1996	Letwin
5565886	October 1996	Gibson
5565887	October 1996	McCambridge et al.
5566068	October 1996	Comer et al.
5566278	October 1996	Patel et al.
5566346	October 1996	Andert et al.
5572206	November 1996	Miller et al.
5572589	November 1996	Waters et al.
5572643	November 1996	Judson
5574840	November 1996	Kwatinetz et al.
5574854	November 1996	Blake et al.
5574907	November 1996	Jernigan, IV et al.
5574920	November 1996	Parry
5577173	November 1996	Dennis et al.
5577187	November 1996	Mariani
5577224	November 1996	DeWitt et al.
5579223	November 1996	Raman
5579517	November 1996	Reynolds et al.
5581669	December 1996	Voth
5581686	December 1996	Koppolu et al.
5581736	December 1996	Smith
5581760	December 1996	Atkinson et al.
5583560	December 1996	Florin et al.
5583868	December 1996	Rashid et al.
5583982	December 1996	Matheny et al.
5585838	December 1996	Lawier et al.
5586186	December 1996	Yuval et al.
5586318	December 1996	Toutonghi
5586328	December 1996	Caron et al.
5587902	December 1996	Kugimiya
5588095	December 1996	Dennis et al.
5588099	December 1996	Mogilexsky et al.
5588147	December 1996	Neeman et al.
5590267	December 1996	Butler et al.
5590318	December 1996	Zbikowski et al.
5590336	December 1996	Parry
5590347	December 1996	D'Souza et al.
5592670	January 1997	Pletcher
5594227	January 1997	Deo
5594462	January 1997	Fishman et al.
5594509	January 1997	Florin et al.
5594642	January 1997	Collins et al.
5594847	January 1997	Moursund
5594898	January 1997	Dalal et al.
5594905	January 1997	Mital
5594921	January 1997	Pettus
5596318	January 1997	Mitchell
5596347	January 1997	Robertson et al.
5596696	January 1997	Tindell et al.
5596723	January 1997	Romohr
5596755	January 1997	Pletcher et al.
5596766	January 1997	Thielsen
5598183	January 1997	Robertson et al.
5598519	January 1997	Narayanan
5598520	January 1997	Harel et al.
5598563	January 1997	Spies
5600368	February 1997	Matthews, III
5602974	February 1997	Shaw et al.
5602981	February 1997	Hargrove
5603030	February 1997	Gray et al.
5604839	February 1997	Acero et al.
5604843	February 1997	Shaw et al.
5604847	February 1997	Dennis et al.
5604849	February 1997	Artwick et al.
5604850	February 1997	Whitmer
5604856	February 1997	Guenter
5604887	February 1997	Maidu et al.
5608853	March 1997	Dujari et al.
5608909	March 1997	Atkinson et al.
5611040	March 1997	Brewer et al.
5611060	March 1997	Belfiore et al.
5613079	March 1997	Debique et al.
5613122	March 1997	Burnard et al.
5613123	March 1997	Tsang et al.
5634122	May 1997	Loucks et al.
5636376	June 1997	Chang
5682534	October 1997	Kapoor et al.
5696966	December 1997	Velarde
5752149	May 1998	Faust et al.
5768510	June 1998	Gish
5781189	July 1998	Holleran et al.


	Other References
Berners-Lee et al., "Hypertext Markup Language 2.0" RFC 1866, pp. 1-77 (1995). . Goulde, Michael A. "World Wide Web Servers" Open Information Systems v.10, n. 9 p3 (32) (1995). . Madany, Peter "The Source for Java.TM. Technology" http://hava.sun.com/marketing/collateral/os.html, pp. 1-13 (May 1996). . Shimmin, Bradley Java to Leap Past Web: Sun's Language Creats Client/Server Aps; LAN Times, v. 12, n. 22, pp. 1-2 (Oct. 1995). . Rodriguez, Karen "Sun Fine Tunes Java's Future" Communications Week n. 597, p. 35 (Feb. 19, 1996). . Betz, Mark "Inter-Operable Objects" Dr. Dobb's Journal, pp. 18-30 (Oct. 1994). . Sun Microsystems "The Java Language Specification" Release 1.0 Alpha3 pp. 1-35 (May 1995)..~


Primary Examiner:	Dinh; Dung C.
Attorney, Agent or Firm:	Beyer & Weaver, LLP


	*Claims*

Having thus described my invention, what I claim as new, and desire to secure by Letters Patent is: 1. A presentation engine for a distributed computer system, comprising: (a) a client computer code segment resident on a client computer node and including an user interface; (b) a server computer code segment resident on a server computer node coupled to the client computer node; and (c) an execution framework code segment configured to couple the client code segment and the server code segment to event driven message transfer between the client computer code segment and the server computer code segment; the client computer code segment, including: (1) a user-extendible user interface adaptor component coupling the user interface component to a mediator coupled between the user-extendible user interface adaptor and the execution framework code segment. 2. The distributed computer system as recited in claim 1, in which the execution framework code segment is layered over a communication protocol. 3. The distributed computer system as recited in claim 2, in which the communication protocol comprises the Transmission Control Protocol/Internet Protocol (TCP/IP). 4. The server for a distributed system as recited in claim 1, including a web connection which facilitates communication from the client computer to the server computer. 5. The server for a distributed system as recited in claim 1, including a communication protocol corresponding to the client code segment and the server code segment which is supported by a communication library on the client computer and the server computer. 6. The server for a distributed system as recited in claim 1, including a code segment which authenticates an initial request from a client computer before downloading a client code segment and initiating secure communication. 7. The server for a distributed system as recited in claim 4, wherein the web is the Internet. 8. A method for distributing computing between a server computer system and a client computer system coupled by a network, comprising the steps of: (a) coupling the server computer and the client computer through the network utilizing an execution framework code segment, comprising: (1) a plurality of client computer code segments resident on the server, each for transmission over the network to a client computer to initiate coupling; (2) a plurality of server computer code segments resident on the server which execute on the server in response to initiation of coupling via the network with a particular client utilizing the transmitted client computer code segment for communicating via a particular communication protocol; and (b) receiving event driven messages at the client computer code segment and the server computer code segment; the client computer code segment, including a user-extendible user interface adaptor component coupling the user interface component to a mediator coupled between the user-extendible user interface adaptor and the execution framework code segment for transfer and display of messages. 9. The method as recited in claim 8, including the step of layering the execution framework code segment over a communication protocol. 10. The method as recited in claim 9, in which the communication protocol comprises the Transmission Control Protocol/Internet Protocol (TCP/IP). 11. The method as recited in claim 8, including the step of facilitating communication via a web connection from the client computer to the server computer. 12. The method as recited in claim 8, including the step of initiating a communication protocol corresponding to the client code segment and the server code segment which is supported by a communication library on the client computer and the server computer. 13. The method as recited in claim 8, including the step of authenticating an initial request from a client computer before downloading a client code segment and initiating secure communication. 14. The method as recited in claim 11, wherein the web is the Internet. 15. A computer program embodied on a computer-readable medium for enabling a distributed computer system, comprising: (a) a client computer code segment resident on a client computer node and including an user interface; (b) a server computer code segment resident on a server computer node coupled to the client computer node; and (c) an execution framework code segment configured to couple the client code segment and the server code segment to event driven message transfer between the client computer code segment and the server computer code segment; the client computer code segment, including: (1) a user-extendible user interface adaptor component coupling the user interface component to a mediator coupled between the user-extendible user interface adaptor and the execution framework code segment. 16. The computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 15, in which the execution framework code segment is layered over a communication protocol. 17. The computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 16, in which the communication protocol comprises the Transmission Control Protocol/Internet Protocol (TCP/IP). 18. The computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 15, including a web connection which facilitates communication from the client computer to the server computer. 19. The computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 15, including a communication protocol corresponding to the client code segment and the server code segment which is supported by a communication library on the client computer and the server computer. 20. The computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 15, including a code segment which authenticates an initial request from a client computer before downloading a client code segment and initiating secure communication. 21. The computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 19, wherein the web is the Internet.


	*Description*

COPYRIGHT NOTIFICATION Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the Patent and Trademark Office. FIELD OF THE INVENTION This invention generally relates to improvements in computer systems and, more particularly, to operating system software for managing Interprise computing in a network user interface. BACKGROUND OF THE INVENTION One of the most important aspects of a modern computing system is the interface between the human user and the machine. The earliest and most popular type of interface was text based; a user communicated with the machine by typing text characters on a keyboard and the machine communicated with the user by displaying text characters on a display screen. More recently, graphic user interfaces have become popular where the machine communicates with a user by displaying graphics, including text and pictures, on a display screen and the user communicates with the machine both by typing in textual commands and by manipulating the displayed pictures with a pointing device, such as a mouse. Many modern computer systems operate with a graphic user interface called a window environment. In a typical window environment, the graphical display portrayed on the display screen is arranged to resemble the surface of an electronic "desktop" and each application program running on the computer is represented as one or more electronic "paper sheets" displayed in a rectangular regions of the screen called "windows". Each window region generally displays information which is generated by the associated application program and there may be several window regions simultaneously present on the desktop, each representing information generated by a different application program. An application program presents information to the user through each window by drawing or "painting" images, graphics or text within the window region. The user, in turn, communicates with the application by "pointing at" objects in the window region with a cursor which is controlled by a pointing device and manipulating or moving the objects and also by typing information into the keyboard. The window regions may also be moved around on the display screen and changed in size and appearance so that the user can arrange the desktop in a convenient manner. Each of the window regions also typically includes a number of standard graphical objects such as sizing boxes, buttons and scroll bars. These features represent user interface devices that the user can point at with the cursor to select and manipulate. When the devices are selected or manipulated, the underlying application program is informed, via the window system, that the control has been manipulated by the user. In general, the window environment described above is part of the computer operating system. The operating system also typically includes a collection of utility programs that enable the computer system to perform basic operations, such as storing and retrieving information on a disc memory, communicating with a network and performing file operations including the creation, naming and renaming of files and, in some cases, performing diagnostic operations in order to discover or recover from malfunctions. The last part of the computing system is the "application program" which interacts with the operating system to provide much higher level functionality, perform a specific task and provide a direct interface with the user. The application program typically makes use of operating system functions by sending out series of task commands to the operating system which then performs a requested task. For example, the application program may request that the operating system store particular information on the computer disc memory or display information on the video display. FIG. 1 is a schematic illustration of a typical prior art computer system utilizing both an application program and an operating system. The computer system is schematically represented by box 100, the application is represented by box 102 and the operating system by box 106. The previously-described interaction between the application program 102 and the operating system 106 is illustrated schematically by arrow 104. This dual program system is used on many types of computer systems ranging from main frames to personal computers. The method for handling screen displays varies from computer to computer and, in this regard, FIG. 1 represents a prior art personal computer system. In order to provide screen displays, application program 102 generally stores information to be displayed (the storing operation is shown schematically by arrow 108) into a screen buffer 110. Under control of various hardware and software in the system the contents of the screen buffer 110 are read out of the buffer and provided, as indicated schematically by arrow 114, to a display adapter 112. The display adapter 112 contains hardware and software (sometimes in the form of firmware) which converts the information in screen buffer 110 to a form which can be used to drive the display monitor 118 which is connected to display adapter 112 by cable 116. The prior art configuration shown in FIG. 1 generally works well in a system where a single application program 102 is running at any given time. This simple system works properly because the single application program 102 can write information into any area of the entire screen buffer area 110 without causing a display problem. However, if the configuration shown in FIG. 1 is used in a computer system where more than one application program 102 can be operational at the same time (for example, a "multi-tasking" computer system) display problems can arise. More particularly, if each application program has access to the entire screen buffer 110, in the absence of some direct communication between applications, one application may overwrite a portion of the screen buffer which is being used by another application, thereby causing the display generated by one application to be overwritten by the display generated by the other application. Accordingly, mechanisms were developed to coordinate the operation of the application programs to ensure that each application program was confined to only a portion of the screen buffer thereby separating the other displays. This coordination became complicated in systems where windows were allowed to "overlap" on the screen display. When the screen display is arranged so that windows appear to "overlap", a window which appears on the screen in "front" of another window covers and obscures part of the underlying window. Thus, except for the foremost window, only part of the underlying windows may be drawn on the screen and be "visible" at any given time. Further, because the windows can be moved or resized by the user, the portion of each window which is visible changes as other windows are moved or resized. Thus, the portion of the screen buffer which is assigned to each application window also changes as windows from other applications are moved or resized. In order to efficiently manage the changes to the screen buffer necessary to accommodate rapid screen changes caused by moving or resizing windows, the prior art computer arrangement shown in FIG. 1 was modified as shown in FIG. 2. In this new arrangement computer system 200 is controlled by one or more application programs, of which programs 202 and 216 are shown, which programs may be running simultaneously in the computer system. Each of the programs interfaces with the operating system 204 as illustrated schematically by arrows 206 and 220. However, in order to display information on the display screen, application programs 202 and 216 send display information to a central window manager program 218 located in the operating system 204. The window manager program 218, in turn, interfaces directly with the screen buffer 210 as illustrated schematically by arrow 208. The contents of screen buffer 210 are provided, as indicated by arrow 212, to a display adapter 214 which is connected by a cable 222 to a display monitor 224. In such a system, the window manager 218 is generally responsible for maintaining all of the window displays that the user views during operation of the application programs. Since the window manager 218 is in communication with all application programs, it can coordinate between applications to insure that window displays do not overlap. Consequently, it is generally the task of the window manager to keep track of the location and size of the window and the window areas which must be drawn and redrawn as windows are moved. The window manager 218 receives display requests from each of the applications 202 and 216. However, since only the window manager 218 interfaces with the screen buffer 210, it can allocate respective areas of the screen buffer 210 for each application and insure that no application erroneously overwrites the display generated by another application. There are a number of different window environments commercially available which utilize the arrangement illustrated in FIG. 2. These include the X/Window Operating environment, the WINDOWS' graphical user interface developed by the Microsoft Corporation and the OS/2 Presentation Manager, developed by the International Business Machines Corporation, and the Macintosh OS, developed by Apple Computer Corporation. Each of these window environments has its own internal software architecture, but the architectures can all be classified by using a multi-layer model similar to the multi-layer models used to describe computer network software. A typical multi-layer model includes the following layers: User Interface Window Manager Resource Control and Communication Component Driver Software Computer Hardware where the term "window environment" refers to all of the above layers taken together. The lowest or computer hardware level includes the basic computer and associated input and output devices including display monitors, keyboards, pointing devices, such as mice or trackballs, and other standard components, including printers and disc drives. The next or "component driver software" level consists of device-dependent software that generates the commands and signals necessary to operate the various hardware components. The resource control and communication layer interfaces with the component drivers and includes software routines which allocate resources, communicate between applications and multiplex communications generated by the higher layers to the underlying layers. The window manager handles the user interface to basic window operations, such as moving and resizing windows, activating or inactivating windows and redrawing and repainting windows. The final user interface layer provides high level facilities that implement the various controls (buttons, sliders, boxes and other controls) that application programs use to develop a complete user interface. Although the arrangement shown in FIG. 2 solves the display screen interference problem, it suffers from the drawback that the window manager 218 must process the screen display requests generated by all of the application programs. Since the requests can only be processed serially, the requests are queued for presentation to the window manager before each request is processed to generate a display on terminal 224. In a display where many windows are present simultaneously on the screen, the window manager 218 can easily become a "bottleneck" for display information and prevent rapid changes by of the display by the application programs 202 and 216. A delay in the redrawing of the screen when windows are moved or repositioned by the user often manifests itself by the appearance that the windows are being constructed in a piecemeal fashion which becomes annoying and detracts from the operation of the system. This problem becomes even more accentuated in a client-server environment where many applications are all in contention for very limited resources. The Internet has permeated the workplace as a communication medium of choice. Since the internet is accessible from almost any point in a typical business enterprise a new buzzword has evolved from the form enterprise computer into an "enterprise" computer. Interprise is a concatenation of internet and enterprise. In today's client server enterprises, applications that exist in current client server enterprises are not really built to be managed since they are architected for distributed system environments. New systems are also required to be evolutionary, not revolutionary. Redesign of current systems that require significant expense need to be avoided. A system is required that allows a user to create manageable applications, that can be readily deployed, installed on a variety of platforms, and configured to facilitate partitioning them on clients versus servers and administer the applications once they're running. Systems don't always break because of failure, errors, or bugs, they sometimes break because the enterprise itself is complicated and somebody does something unexpected somewhere which will bring the whole system down. When the system does come down, then a system administrator must be able to readily identify the problems, and deal with them in an effective manner so that a business doesn't stop functioning when one of these unforeseen events happens. The application should be designed based on domain requirements, so it is independent of any platform underneath, and fits more with how commercial developers work. In the commercial world, the development process isn't that important. The regular employees are not applications developers or programmers. Companies usually hire such work out; they get consultants to do that kind of work. Depending on the company and what they want done, it usually hires a consulting firm, individual consultants, or smaller groups of consultants to come in, help it develop an application. Their goal is the end application, which must be maintained. The company configures it, evolves it, and grows it. To allow for modification, the development task must be modular to allow different groups of people working on different parts of an application, without requiring any one group to understand every detail of the whole application of the enterprise. The second criterion requires minimal extra knowledge, burden or sophistication on the part of the people developing the system. Most companies do not desire to have their business hinge on a single individual. Rather, they desire to have people who are primarily domain experts who can work with well-understood tools to produce a application matching company requirements quickly without making special demands on the company. SUMMARY OF THE INVENTION The foregoing problems are overcome in an illustrative embodiment of the invention in which an application is composed of a client (front end) program which communicates utilizing a network with a server (back end) program. The client and server programs are loosely coupled and exchange information using the network. The client program is composed of a User Interface (UI) and an object-oriented framework (Presentation Engine (PE) framework). The UI exchanges data messages with the framework. The framework is designed to handle two types of messages: (1) from the UI, and (2) from the server (back end) program via the network. The framework includes a component, the mediator which manages messages coming into and going out of the framework. A distributed computer system is disclosed with software for a client computer, a server computer and a network for connecting the client computer to the server computer which utilize an execution framework code segment configured to couple the server computer and the client computer via the network, by a plurality of client computer code segments resident on the server, each for transmission over the network to a client computer to initiate coupling; and a plurality of server computer code segments resident on the server which execute on the server in response to initiation of coupling via the network with a particular client utilizing the transmitted client computer code segment for communicating via a particular communication protocol. BRIEF DESCRIPTION OF THE DRAWINGS The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which: FIG. 1 is a schematic block diagram of a prior art computer system showing the relationship of the application program, the operating system, the screen buffer and, the display monitor; FIG. 2 is a schematic block diagram of a modification of the prior art system shown in FIG. 1 which allows several application programs running simultaneously to generate screen displays; FIG. 3 is a block schematic diagram of a computer system for example, a personal computer system on which the inventive object oriented window manager operates; FIG. 4 is a block diagram in accordance with a preferred embodiment; FIG. 5 illustrates how a preferred embodiment leverages Java to facilitate the establishment and implementation of sever-centric policies; FIG. 6 illustrates the processing associated with application startup in accordance with a preferred embodiment; FIG. 7 illustrates the three fundamental components of an application in accordance with a preferred embodiment; FIG. 8 illustrates the migration of an existing client-server application to one supported by a preferred embodiment; FIG. 9 is a block diagram illustrating a PE 960 in accordance with a preferred embodiment; FIG. 10 is a block diagram of a prior art client server architecture in accordance with a preferred embodiment; FIG. 11 illustrates an application in accordance with an alternate embodiment; FIG. 12 illustrates a server 1210 establishing contact with a client 1200 in accordance with an alternate embodiment; FIG. 13 illustrates a loosely coupled client--server application in accordance with an alternate embodiment; FIG. 14 illustrates the system integration task necessary to develop an application 1430 in accordance with a preferred embodiment; FIG. 15 is a block diagram illustrating the modular design of a client application in accordance with a preferred embodiment; FIG. 16 is a block diagram of a framework in accordance with an alternate embodiment; FIG. 17 illustrates the basic building blocks in accordance with an alternate embodiment; FIG. 18 is a block diagram highlighting the steps utilized to extend the framework in accordance with a preferred embodiment; FIG. 19 is an illustration of a PE Object in accordance with a preferred embodiment; FIG. 20 is an illustration of a PE Event Handler 2000 used by Views to handle incoming messages and UI events in accordance with a preferred embodiment; FIG. 21 illustrates a PEInfo object 2100 data in accordance with a preferred embodiment; FIG. 22 illustrates incoming message flow to a model in accordance with a preferred embodiment; FIG. 23 illustrates incoming messages mapping a UI to a Model in accordance with a preferred embodiment; FIG. 24 illustrates outgoing messages mapping a model to messages in accordance with a preferred embodiment; FIG. 25 illustrates outgoing messages mapping a model to a UI in accordance with a preferred embodiment; FIG. 26 illustrates the steps associated with launching an application URL in accordance with a preferred embodiment; FIG. 27 describes the forms of a Presentation Engine, as an abstract Java class, a template for development, and an executable component in an application in accordance with a preferred embodiment; FIG. 28 describes the functions developers must fill in using the server program template in accordance with a preferred embodiment; FIG. 29 illustrates Server Properties in accordance with a preferred embodiment; and FIG. 30 is a table of client and server side exceptions in accordance with a preferred embodiment. DETAILED DESCRIPTION The invention is preferably practiced in the context of an operating system resident on a computer such as a SUN, IBM, PS/2, or Apple, Macintosh, computer. A representative hardware environment is depicted in FIG. 3, which illustrates a typical hardware configuration of a computer 300 in accordance with the subject invention. The computer 300 is controlled by a central processing unit 302 (which may be a conventional microprocessor) and a number of other units, all interconnected via a system bus 308, are provided to accomplish specific tasks. Although a particular computer may only have some of the units illustrated in FIG. 3, or may have additional components not shown, most computers will include at least the units shown. Specifically, computer 300 shown in FIG. 3 includes a random access memory (RAM) 306 for temporary storage of information, a read only memory (ROM) 304 for permanent storage of the computer's configuration and basic operating commands and an input/output (I/O) adapter 310 for connecting peripheral devices such as a disk unit 313 and printer 314 to the bus 308, via cables 315 and 312, respectively. A user interface adapter 316 is also provided for connecting input devices, such as a keyboard 320, and other known interface devices including mice, speakers and microphones to the bus 308. Visual output is provided by a display adapter 318 which connects the bus 308 to a display device 322, such as a video monitor. The computer has resident thereon and is controlled and coordinated by operating system software such as the SUN Solaris or JavaOS operating system. In a preferred embodiment, the invention is implemented in the C++ programming language using object-oriented programming techniques. C++ is a compiled language, that is, programs are written in a human-readable script and this script is then provided to another program called a compiler which generates a machine-readable numeric code that can be loaded into, and directly executed by, a computer. As described below, the C++ language has certain characteristics which allow a software developer to easily use programs written by others while still providing a great deal of control over the reuse of programs to prevent their destruction or improper use. The C++ language is well-known and many articles and texts are available which describe the language in detail. In addition, C++ compilers are commercially available from several vendors including Borland International, Inc. and Microsoft Corporation. Accordingly, for reasons of clarity, the details of the C++ language and the operation of the C++ compiler will not be discussed further in detail herein. As will be understood by those skilled in the art, Object-Oriented Programming (OOP) techniques involve the definition, creation, use and destruction of "objects". These objects are software entities comprising data elements and routines, or functions, which manipulate the data elements. The data and related functions are treated by the software as an entity and can be created, used and deleted as if they were a single item. Together, the data and functions enable objects to model virtually any real-world entity in terms of its characteristics, which can be represented by the data elements, and its behavior, which can be represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs. Objects are defined by creating "classes" which are not objects themselves, but which act as templates that instruct the compiler how to construct the actual object. A class may, for example, specify the number and type of data variables and the steps involved in the functions which manipulate the data. An object is actually created in the program by means of a special function called a constructor which uses the corresponding class definition and additional information, such as arguments provided during object creation, to construct the object. Likewise objects are destroyed by a special function called a destructor. Objects may be used by using their data and invoking their functions. The principle benefits of object-oriented programming techniques arise out of three basic principles; encapsulation, polymorphism and inheritance. More specifically, objects can be designed to hide, or encapsulate, all, or a portion of, the internal data structure and the internal functions. More particularly, during program design, a program developer can define objects in which all or some of the data variables and all or some of the related functions are considered "private" or for use only by the object itself. Other data or functions can be declared "public" or available for use by other programs. Access to the private variables by other programs can be controlled by defining public functions for an object which access the object's private data. The public functions form a controlled and consistent interface between the private data and the "outside" world. Any attempt to write program code which directly accesses the private variables causes the compiler to generate an error during program compilation which error stops the compilation process and prevents the program from being run. Polymorphism is a concept which allows objects and functions which have the same overall format, but which work with different data, to function differently in order to produce consistent results. For example, an addition function may be defined as variable A plus variable B (A+B) and this same format can be used whether the A and B are numbers, characters or dollars and cents. However, the actual program code which performs the addition may differ widely depending on the type of variables that comprise A and B. Polymorphism allows three separate function definitions to be written, one for each type of variable (numbers, characters and dollars). After the functions have been defined, a program can later refer to the addition function by its common format (A+B) and, during compilation, the C++ compiler will determine which of the three functions is actually being used by examining the variable types. The compiler will then substitute the proper function code. Polymorphism allows similar functions which produce analogous results to be "grouped" in the program source code to produce a more logical and clear program flow. The third principle which underlies object-oriented programming is inheritance, which allows program developers to easily reuse pre-existing programs and to avoid creating software from scratch. The principle of inheritance allows a software developer to declare classes (and the objects which are later created from them) as related. Specifically, classes may be designated as subclasses of other base classes. A subclass "inherits" and has access to all of the public functions of its base classes just as if these function appeared in the subclass. Alternatively, a subclass can override some or all of its inherited functions or may modify some or all of its inherited functions merely by defining a new function with the same form (overriding or modification does not alter the function in the base class, but merely modifies the use of the function in the subclass). The creation of a new subclass which has some of the functionality (with selective modification) of another class allows software developers to easily customize existing code to meet their particular needs. Although object-oriented programming offers significant improvements over other programming concepts, program development still requires significant outlays of time and effort, especially if no pre-existing software programs are available for modification. Consequently, a prior art approach has been to provide a program developer with a set of pre-defined, interconnected classes which create a set of objects and additional miscellaneous routines that are all directed to performing commonly-encountered tasks in a particular environment. Such pre-defined classes and libraries are typically called "frameworks" and essentially provide a pre-fabricated structure for a working application. For example, a framework for a user interface might provide a set of pre-defined graphic interface objects which create windows, scroll bars, menus, etc. and provide the support and "default" behavior for these graphic interface objects. Since frameworks are based on object-oriented techniques, the pre-defined classes can be used as base classes and the built-in default behavior can be inherited by developer-defined subclasses and either modified or overridden to allow developers to extend the framework and create customized solutions in a particular area of expertise. This object-oriented approach provides a major advantage over traditional programming since the programmer is not changing the original program, but rather extending the capabilities of the original program. In addition, developers are not blindly working through layers of code because the framework provides architectural guidance and modeling and, at the same time, frees the developers to supply specific actions unique to the problem domain. There are many kinds of frameworks available, depending on the level of the system involved and the kind of problem to be solved. The types of frameworks range from high-level application frameworks that assist in developing a user interface, to lower-level frameworks that provide basic system software services such as communications, printing, file systems support, graphics, etc. Commercial examples of application frameworks include MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXT Step App Kit (NeXT), and Smalltalk-80 MVC (ParcPlace). While the framework approach utilizes all the principles of encapsulation, polymorphism, and inheritance in the object layer, and is a substantial improvement over other programming techniques, there are difficulties which arise. Application frameworks generally consist of one or more object "layers" on top of a monolithic operating system and even with the flexibility of the object layer, it is still often necessary to directly interact with the underlying operating system by means of awkward procedural calls. In the same way that an application framework provides the developer with prefab functionality for an application program, a system framework, such as that included in a preferred embodiment, can provide a prefab functionality for system level services which developers can modify or override to create customized solutions, thereby avoiding the awkward procedural calls necessary with the prior art application frameworks programs. For example, consider a display framework which could provide the foundation for creating, deleting and manipulating windows to display information generated by an application program. An application software developer who needed these capabilities would ordinarily have to write specific routines to provide them. To do this with a framework, the developer only needs to supply the characteristics and behavior of the finished display, while the framework provides the actual routines which perform the tasks. A preferred embodiment takes the concept of frameworks and applies it throughout the entire system, including the application and the operating system. For the commercial or corporate developer, systems integrator, or OEM, this means all of the advantages that have been illustrated for a framework such as MacApp can be leveraged not only at the application level for such things as text and user interfaces, but also at the system level, for services such as printing, graphics, multi-media, file systems, I/O, testing, etc. A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided. OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation. In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others' capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed. OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects. OOP also allows creation of an object that depends from another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance. When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects. With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, our logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows: Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system. Objects can represent elements of the computer-user environment such as windows, menus or graphics objects. An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane. With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future. If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built, objects. This process closely resembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development. Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, common lisp object system (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal. The benefits of object classes can be summarized, as follows: Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems. Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures. Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch. Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways. Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them. Libraries of reusable classes are useful in many situations, but they also have some limitations. For example: Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes. Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects. Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should. Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers. Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way. The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of" the system. Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application. Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure). A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems. Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times. There are three main differences between frameworks and class libraries: Behavior versus protocol Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides. Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together. Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems. Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the merchant. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language--2.0" (November 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. Mogul, "HypertextTransfer Protocol--HTTP/1.1:HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML). To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas: Poor performance; Restricted user interface capabilities; Can only produce static Web pages; Lack of interoperability with existing applications and data; and Inability to scale. Sun Microsystem's Java language solves many of the client-side problems by: Improving performance on the client side; Enabling the creation of dynamic, real-time Web applications; and Providing the ability to create a wide variety of user interface components. Java is compiled into bytecodes in an intermediate form instead of machine code (like C, C++, Fortran, etc.). The bytecodes execute on any machine with a bytecode interpreter. Thus, Java applets can run on a variety of client machines, and the bytecodes are compact and designed to transmit efficiently over a network which enhances a preferred embodiment with universal clients and server-centric policies.