REGISTER  |  SIGN IN
United States Patent6038590
GishMarch 14, 2000
Title
Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system
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. A mediator state machine is utilized to parse various message types and route the messages to appropriate parts of the execution framework for further processing.
Inventors:Gish; Sheri L. (Mountain View, CA)
Assignee:Sun Microsystems, Inc. (Mountain View, CA)
Appl. No.:675231
Filed:July 1, 1996
Current U.S. Class:709/203 709/218 709/201 
Current International Class:G06F 9/46 (20060101)
Field of Search:395/200.01,200.03,200.09,200.13,610,200.02,200.31,200.32,200.33,200.47,200.48
U.S. Patent Documents
3946503March 1976Buchan et al.
4200867April 1980Hill
4588074May 1986Strong et al.
4682957July 1987Young
4739477April 1988Barker et al.
4779187October 1988Letwin
4798543January 1989Spiece
4800488January 1989Agrawal et al.
4803643February 1989Hickey
4825358April 1989Letwin
4829468May 1989Nonaka et al.
4837487June 1989Kurakake et al.
4866602September 1989Hall
4897781January 1990Chang et al.
4933880June 1990Borgendale et al.
4954818September 1990Nakane et al.
4955066September 1990Notenboom
4967378October 1990Rupel et al.
4974159November 1990Hargrove et al.
4990907February 1991Jikihara et al.
5021974June 1991Pisculli et al.
5027273June 1991Letwin
5109433April 1992Notenboom
5113341May 1992Kozol et al.
5124989June 1992Padawer et al.
5125077June 1992Hall
5125087June 1992Randell
5138303August 1992Rupel
5146580September 1992Naidu et al.
5155842October 1992Rubin
5187468February 1993Garthwaite et al.
5191615March 1993Aldava et al.
5195135March 1993Palmer
5204960April 1993Smith et al.
5214755May 1993Mason
5218697June 1993Chung
5220675June 1993Padawer et al.
5224038June 1993Bespalko
5231577July 1993Koss
5247658September 1993Barrett et al.
5255356October 1993Michelman et al.
5257369October 1993Skeen et al.
5257370October 1993Letwin
5261051November 1993Masden et al.
5261101November 1993Fenwick
5265261November 1993Rubin et al.
5268675December 1993Garthwaite et al.
5272628December 1993Koss
5274751December 1993Rosenberg
5276793January 1994Borgendale et al.
5281958January 1994Ashum et al.
5283892February 1994Nakane et al.
5287417February 1994Eller et al.
5287504February 1994Carpenter et al.
5287507February 1994Hamilton et al.
5287514February 1994Gram
5293473March 1994Hesse et al.
5297284March 1994Jones et al.
5300946April 1994Patrick
5301326April 1994Linnett et al.
5303151April 1994Neumann
5305440April 1994Morgan et al.
5313635May 1994Ishizuka et al.
5317746May 1994Watanabe
5325533June 1994McInerney et al.
5327562July 1994Adcock
5337258August 1994Dennis
5339432August 1994Crick
5341464August 1994Friedman et al.
5349648September 1994Handley
5357603October 1994Parker
5357605October 1994Rupel et al.
5359430October 1994Zhang
5363479November 1994Olynyk
5363487November 1994Willman et al.
5367617November 1994Goossen et al.
5369729November 1994Norris
5369766November 1994Nakano et al.
5369770November 1994Thomason et al.
5371847December 1994Hargrove
5371884December 1994Ross
5371885December 1994Letwin
5371891December 1994Gray et al.
5375241December 1994Walsh
5379430January 1995Nguyen
5379431January 1995Lemon et al.
5379432January 1995Orton et al.
5381347January 1995Gery
5381521January 1995Ballard
5390325February 1995Miller
5392427February 1995Barrett et al.
5394518February 1995Friedman et al.
5394523February 1995Harris
5398120March 1995Friedman et al.
5404529April 1995Chernikoff et al.
5410705April 1995Jones et al.
5412807May 1995Moreland
5414445May 1995Kaniko et al.
5414526May 1995Friedman
5414854May 1995Heninger et al.
5416726May 1995Garcia-Duarte et al.
5418956May 1995Willman
5423042June 1995Jalili et al.
5426760June 1995Moreland
5428718June 1995Peterson et al.
5428722June 1995Marsh et al.
5428725June 1995Sugai et al.
5428744June 1995Webb et al.
5430876July 1995Schreiber et al.
5430878July 1995Straub et al.
5432924July 1995D'Souza et al.
5432928July 1995Sherman
5432932July 1995Chen et al.
5432936July 1995Gray et al.
5432941July 1995Crick et al.
5432948July 1995Davis et al.
5434776July 1995Jain
5434965July 1995Matheny et al.
5437006July 1995Turski
5437013July 1995Rubin et al.
5437036July 1995Stamps et al.
5438433August 1995Reifman et al.
5442389August 1995Blahut et al.
5442751August 1995Patrick et al.
5442793August 1995Christian et al.
5446842August 1995Schaeffer et al.
5446887August 1995Berkowitz
5450536September 1995Rosenberg et al.
5452406September 1995Butler et al.
5452447September 1995Nelson et al.
5454109September 1995Bruynooghe et al.
5455577October 1995Slivka et al.
5455600October 1995Friedman et al.
5455854October 1995Dilts et al.
5455951October 1995Bolton et al.
5459865October 1995Heninger et al.
5461701October 1995Voth
5463471October 1995Chou
5465363November 1995Orton et al.
5467134November 1995Laney et al.
5467264November 1995Rauch et al.
5467435November 1995Douglas et al.
5467472November 1995Williams et al.
5469532November 1995Gerlach et al.
5469533November 1995Dennis
5471563November 1995Dennis et al.
5471564November 1995Dennis et al.
5471568November 1995Webb et al.
5471576November 1995Yee
5471675November 1995Zias
5473343December 1995Kimmich et al.
5473344December 1995Bacon et al.
5473362December 1995Fitzgerald et al.
5473691December 1995Menezes et al.
5473777December 1995Moeller et al.
5474840December 1995Kwetinetz
5475743December 1995Nixon et al.
5475805December 1995Murata
5475819December 1995Miller et al.
5475835December 1995Hickey
5475845December 1995Orton et al.
5479589December 1995Peterson et al.
5481677January 1996Bieniek et al.
5485373January 1996Davis et al.
5485460January 1996Schrier et al.
5485558January 1996Weise et al.
5485574January 1996Bolosky et al.
5487145January 1996Marsh et al.
5490249February 1996Miller
5490274February 1996Zbikowski et al.
5491800February 1996Goldsmith et al.
5493649February 1996Slivka et al.
5495561February 1996Holt
5495566February 1996Kwatinetz
5495571February 1996Corrie, Jr. et al.
5495577February 1996Davis et al.
5497463March 1996Stein et al.
5497492March 1996Zbikowski et al.
5499109March 1996Mathur et al.
5499334March 1996Staab
5499335March 1996Silver et al.
5499343March 1996Pettus
5500929March 1996Dickinson
5500931March 1996Sonnenschein
5504500April 1996Garthwaite et al.
5504591April 1996Dujari
5504889April 1996Burgess
5506983April 1996Atkinson et al.
5510811April 1996Tobey et al.
5510980April 1996Peters
5511197April 1996Hill et al.
5512921April 1996Mital et al.
5513315April 1996Tierney et al.
5515508May 1996Pettus et al.
5517257May 1996Dunn et al.
5517324May 1996Fite, Jr. et al.
5519818May 1996Peterson
5519855May 1996Neeman et al.
5519862May 1996Schaeffer et al.
5519866May 1996Lawrence et al.
5519867May 1996Moeller et al.
5522068May 1996Berkowitz
5524190June 1996Schaeffer et al.
5524200June 1996Orton et al.
5526485June 1996Brodsky
5526515June 1996Ross et al.
5526523June 1996Straub et al.
5528742June 1996Moore et al.
5530794June 1996Luebbert
5530799June 1996Marsh et al.
5530852June 1996Meske, Jr. et al.
5530864June 1996Matheny et al.
5530865June 1996Owens et al.
5530895June 1996Enstrom
5535324July 1996Alvarez et al.
5537415July 1996Miller et al.
5537526July 1996Anderson et al.
5537589July 1996Dalal
5537623July 1996Luebbert
5539471July 1996Myhrvold et al.
5539530July 1996Reifman et al.
5541942July 1996Strouss
5542068July 1996Peters
5542078July 1996Martel et al.
5544082August 1996Garcia-Duarte et al.
5544286August 1996Laney
5544301August 1996Orton et al.
5544315August 1996Lehfeldt et al.
5544320August 1996Konrad
5546518August 1996Blossom et al.
5546581August 1996McKinnis et al.
5546583August 1996Shriver
5546584August 1996Lundin et al.
5548305August 1996Rupel
5548508August 1996Nagami
5548718August 1996Siegal et al.
5548723August 1996Pettus
5548726August 1996Pettus
5548759August 1996Lipe
5548779August 1996Andert et al.
5550930August 1996Berman et al.
5550972August 1996Patrick et al.
5551024August 1996Waters
5551055August 1996Matheny et al.
5552982September 1996Jackson et al.
5553205September 1996Murray
5553215September 1996Kaethler
5553242September 1996Russell et al.
5553282September 1996Parrish et al.
5555228September 1996Izuka
5555368September 1996Orton et al.
5557440September 1996Hanson et al.
5557714September 1996Lines et al.
5557722September 1996DeRose et al.
5557723September 1996Holt et al.
5559884September 1996Davidson et al.
5559943September 1996Cyr et al.
5560005September 1996Hoover et al.
5561751October 1996Wong
5561786October 1996Morse
5561788October 1996Letwin
5565886October 1996Gibson
5565887October 1996McCambridge et al.
5566068October 1996Comer et al.
5566278October 1996Patel et al.
5566346October 1996Andert et al.
5572206November 1996Miller et al.
5572589November 1996Waters et al.
5572643November 1996Judson
5574840November 1996Kwatinetz et al.
5574854November 1996Blake et al.
5574907November 1996Jernigan, IV et al.
5574920November 1996Parry
5577173November 1996Dennis et al.
5577187November 1996Mariani
5577224November 1996DeWitt et al.
5579223November 1996Raman
5579517November 1996Reynolds et al.
5581669December 1996Voth
5581686December 1996Koppolu et al.
5581736December 1996Smith
5581760December 1996Atkinson et al.
5583560December 1996Florin et al.
5583868December 1996Rashid et al.
5583982December 1996Matheny et al.
5585838December 1996Lawier et al.
5586186December 1996Yuval et al.
5586318December 1996Toutonghi
5586328December 1996Caron et al.
5587902December 1996Kugimiya
5588095December 1996Dennis et al.
5588099December 1996Mogilexsky et al.
5588147December 1996Neeman et al.
5590267December 1996Butler et al.
5590318December 1996Zbikowski et al.
5590336December 1996Parry
5590347December 1996D'Souza et al.
5592670January 1997Pletcher
5594227January 1997Deo
5594462January 1997Fishman et al.
5594509January 1997Florin et al.
5594642January 1997Collins et al.
5594847January 1997Moursund
5594898January 1997Dalal et al.
5594905January 1997Mital
5594921January 1997Pettus
5596318January 1997Mitchell
5596347January 1997Robertson et al.
5596696January 1997Tindell et al.
5596723January 1997Romohr
5596726January 1997Thielsen
5596755January 1997Pletcher et al.
5598183January 1997Robertson et al.
5598519January 1997Narayanan
5598520January 1997Harel et al.
5598563January 1997Spies
5600368February 1997Matthews, III
5602974February 1997Shaw et al.
5602981February 1997Hargrove
5603030February 1997Gray et al.
5604839February 1997Acero et al.
5604843February 1997Shaw et al.
5604847February 1997Dennis et al.
5604849February 1997Artwick et al.
5604850February 1997Whitmer
5604856February 1997Guenter
5604887February 1997Maidu et al.
5608853March 1997Dujari et al.
5608909March 1997Atkinson et al.
5611040March 1997Brewer et al.
5611060March 1997Belfiore et al.
5613079March 1997Debique et al.
5613122March 1997Burnard et al.
5613123March 1997Tsang et al.
5634122May 1997Loucks et al.
5636376June 1997Chang
5682534October 1997Kapoor et al.
5689708November 1997Regnier et al.
5696966December 1997Velarde
5752159May 1998Faust et al.
5768510June 1998Gish
5781189July 1998Holleran et al.
5848246December 1998Gish
Other References
Betz, Mark, InterOperable Objects: Laying the foundation for distributed-object computing, Oct., 1994, Dr. Dobb's Journal. .
Gould, Michael A., World Wibe Web servers, Sep., 1995, Open Information Systems, v10, n9, p3 (32). .
Herman, James, Sun's Solstice: a turning point in enterprise management, May 1995, Distributed Computing Monitor, v10, n5, p3 (9). .
Sun Microsystems, Inc., The Java Language Specification, May 11, 1995, Release 1.0 Alpha 3. .
Rodriguez, Karen, Sun Fine-Tunes Java's Future, Feb. 19, 1998, v.597, p. 35. .
Internet posting for "The Source for Java Technology", JavaOS: A Standalone Java Environment, Sep. 10, 1998, http://java.sun.com/marketing/collateral/os.html. .
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)..~
Primary Examiner: Peikari; B. James
Attorney, Agent or Firm:Beyer & Weaer, LLP
Claims

Having thus described our invention, what we claim as new, and desire to secure by Letters Patent is:
1. A server for a distributed system, comprising:
(a) a client computer;
(b) a server computer;
(c) a network connecting the client computer to the server computer; and
(d) an execution framework code segment configured to couple the server computer and the client computer via the network, 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, the client computer code segments comprising a user interface and an object-oriented presentation engine framework including a mediator state machine which receives a plurality of messages, determines which message should be handled by which part of the execution framework, and forwards the message for further processing to the execution framework; and
(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.

2. The server for a distributed system as recited in claim 1, including a user interface part of the client computer code segment which receives messages containing user interface information and translates the user interface information into display information.

3. The server for a distributed system as recited in claim 1, including a communication adaptor in the client computer code segment for communicating message types bound for external consumption to the network.

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) responding to a request from a client computer system to a server computer system;
(b) downloading an execution framework code segment configured to couple the server computer and the client computer via the network, 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, the client computer code segments comprising a user interface and an object-oriented presentation engine framework including a mediator state machine which receives a plurality of messages, determines which message should be handled by which part of the execution framework, and forwards the message for further processing to the execution framework; and
(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;
(c) receiving a plurality of messages in the mediator state machine in the client computer code segment;
(d) determining which messages should be handled by which part of the execution framework; and
(e) forwarding the messages for further processing to the execution framework.

9. A method for distributing computing between a server computer system and a client computer system coupled by a network as recited in claim 8, including the step of invoking a user interface part of the client computer code segment which receives messages containing user interface information and translates the user interface information into display information.

10. A method for distributing computing between a server computer system and a client computer system coupled by a network as recited in claim 8, including the step of invoking a communication adaptor in the client computer code segment for communicating message types bound for external consumption to the network.

11. A method for distributing computing between a server computer system and a client computer system coupled by a network as recited in claim 8, including the step of invoking a web connection which facilitates communication from the client computer to the server computer.

12. A method for distributing computing between a server computer system and a client computer system coupled by a network 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. A method for distributing computing between a server computer system and a client computer system coupled by a network 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. A method for distributing computing between a server computer system and a client computer system coupled by a network 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 code segment for responding to a request from a client computer system to a server computer system; and
(b) an execution framework code segment configured to couple the server computer and the client computer via the network, 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, the client computer code segments comprising a user interface and an object-oriented presentation engine framework including a mediator state machine which receives a plurality of messages, determines which message should be handled by which part of the execution framework, and forwards the message for further processing to the execution framework;
(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.

16. A computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 15, including a user interface part of the client computer code segment which receives messages containing user interface information and translates the user interface information into display information.

17. A computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 15, including a communication adaptor in the client computer code segment for communicating message types bound for external consumption to the network.

18. A computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 15, including a web connection code segment which facilitates communication from the client computer to the server computer.

19. A 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. A 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. A computer program embodied on a computer-readable medium for enabling a distributed computer system as recited in claim 18, 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 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 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. A mediator state machine is utilized to parse various message types and route the messages to appropriate parts of the execution framework for further processing.

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 schematic clock diagram of a typical hardware configuration of a computer in a accordance with the subject invention;

FIG. 4 is a block diagram in accordance with a preferred embodiment in an Enterprise Network;

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 Presentation Engine in accordance with a preferred embodiment;

FIG. 10 is a block diagram of a prior art client server architecture,

FIG. 11 illustrates an application in accordance with an alternate embodiment;

FIG. 12 illustrates a server establishing contact with a client 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 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 Presentation Engine Object in accordance with a preferred embodiment;

FIG. 20 is an illustration of a Presentation Engine Event Handler used by Views to handle incoming messages and User Interface events in accordance with a preferred embodiment;

FIG. 21 illustrates a PEInfo object 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 User Interface 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 User Interface in accordance with a preferred embodiment;

FIG. 26 illustrates an arrangement that facilitates the launch and utilization of an application URL in accordance with a preferred embodiment;

FIG. 27 is a table that 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 which 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 codebecause 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 pre fabricated functionality for an application program, a system framework, such as that included in a preferred embodiment, can provide a prefabricated 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. Objected-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 OOP principles 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.

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, signific