United States Patent [19]
`Christensen et ai.
`
`[54] METHOD AND SYSTEM FOR REMOTE
`AUTOMATION OF OBJECT ORIENTED
`APPLICATIONS
`
`[75]
`
`Inventors: Erik B. Christensen; Bradford H.
`Lovering, both of Seattle, Wash.
`
`[73] Assignee: Microsoft Corporation, Redmond,
`Wash.
`
`[21] Appi. No.: 679,224
`
`[22] Filed:
`
`Jun. 24, 1996
`
`Int. CI.6
`[51]
`...................................................... G06F 13/00
`[52] U.S. CI. ................................ 395/200.33; 395/200.47;
`395/200.49
`[58] Field of Search ............................ 395/200.33, 200.3,
`395/200.47, 200.48, 200.49, 683, 684
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,687,331 11/1997 Vilk et al. ............................... 345/327
`5,689,664 11/1997 Narayanan et al.
`.................... 345/340
`5,692,157 11/1997 Williams ................................. 395/500
`5,729,745
`3/1998 Reina et al.
`............................ 395/683
`5,740,439
`4/1998 Atkinson et al. ....................... 395/701
`5,748,188
`5/1998 Hu et al. ................................. 345/326
`5,752,027
`5/1998 Familiar et al. ........................ 395/677
`5,761,684
`6/1998 Gibson .................................... 707/515
`5,764,908
`6/1998 Shoji et al.
`........................ 395/200.47
`
`OlliER PUBLICATIONS
`
`to extend OLE architecture with
`Leach, "Microsoft
`OCX96," PC Week, p. 9 (Jan. 22, 1996).
`Leach, "OMG calls on Microsoft to share net OLE data," PC
`Week, p. 10 (Jan. 22, 1996).
`Leach, "NeXT, Willows craft technology options," PC
`Week, pp. 27-28 (Jan. 22, 1996).
`Pompeii, "Distributed Objects and the Internet," Dr. Dobb's
`Journal, pp. 70-76 (Mar. 1996).
`
`111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US005881230A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,881,230
`Mar. 9, 1999
`
`Orfali and Harkey, "The Server Side of CORBA," OS/2
`Developer, pp. 26-30 (Jul./Aug. 1995).
`Orfali et aI., "Intergalactic Client/Server Computing,"
`BYTE, pp. 108-122 (Apr. 1995).
`Orfali and Harkey, "Client/Server with Distributed Objects,"
`BYTE, pp. 151-162 (Apr. 1995).
`Orfali et aI., "OLE vs OpenDoc: Are All Parts JUST Parts?",
`Datamation, pp. 38-46 (Nov. 15, 1994).
`Reeves et aI., "A Distributed Object Road Map for Devel(cid:173)
`opers," OS/2 Developer, pp. 31-53 (Sep./Oct. 1994).
`Orfali and Harkey, "Client/Server Programming with
`CORBA Objects," OS/2 Developer, pp. 46-53 (Sep./Oct.
`1994).
`Orfali et aI., The Essential Distributed Objects Survival
`Guide, John Wiley & Sons, Inc. (1996).
`
`Primary Examiner-Zarni Maung
`Attorney, Agent, or Firm-Klarquist Sparkman Campbell
`Leigh & Whinston
`
`[57]
`
`ABSTRACT
`
`An object oriented programming environment is extended to
`allow a client object oriented application running under a
`client/server operating system to communicate with a plu(cid:173)
`rality of server object oriented applications located on one or
`more remote computers in a distributed computer environ(cid:173)
`ment. The extended object oriented programming environ(cid:173)
`ment provides the capability for a client object oriented
`application to connect to, and communicate with remote
`server object oriented applications as well as make object
`references to remote objects and remote object data. The
`extended object oriented programming environment is used
`for designing N-tiered logical models for distributed com(cid:173)
`puting applications, while providing a flexible and adaptable
`M-tiered physical model underneath the N-tiered logical
`model. This environment is also used to provide the ability
`to reference remote objects from Internet and other client
`network applications.
`
`19 Claims, 8 Drawing Sheets
`
`Page 1 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 1 of 8
`
`5,881,230
`
`FIG. 1
`
`10
`
`/
`-------------------1
`r--
`COMPUTER 12
`14
`-
`
`(16
`MEMORY SYSTEM
`
`24,\
`
`CPU
`
`ALU
`
`(18
`INPUT
`DEVICE
`
`1
`1
`
`1
`
`(KEYBOARD,
`POINTING
`1
`DEVICE,
`I
`MODEM,
`IC
`I~
`NETWORK
`221
`CONNECTION,
`1
`ETC.)
`1
`1 L..-____ ---'
`
`MAIN
`MEMORY
`
`~o
`
`~ 26
`.... t_
`. ~ REGISTERS
`...
`....
`
`SECONDARY
`STORAGE
`
`28\ CONTROL
`UNIT
`
`'I
`32
`
`1
`1
`L __ ______________ ___ J
`
`1 ~------,
`OUTPUT
`DEVICE
`
`1
`1
`1
`\.1
`221
`
`(DISPLAY,
`PRINTER,
`MODEM,
`NETWORK
`CONNECTION,
`ETC.)
`
`20./
`
`Page 2 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 2 of 8
`
`5,881,230
`
`FIG. 2
`
`START
`
`PROVIDE
`A TWO-WAY
`COMMUNICATION
`PATH FOR
`REMOTE OBJECT
`REFERENCES
`
`ACCEPT AN
`OBJECT
`REFERENCE TO
`A REMOTE
`OBJECT
`
`34
`
`/
`
`36
`
`38
`
`PASS REMOTE
`OBJECT
`REFERENCE
`OVER TWO-WAY
`OBJECT
`COMMUNICATION 40
`PATH
`
`SEND
`REMOTE
`OBJECT TO
`REQUESTOR
`
`42
`
`Page 3 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 3 of 8
`
`5,881,230
`
`FIG. 3
`
`10
`
`CLIENT APP.
`
`52
`
`SERVER APP.
`54
`56
`\-4---1..-.("------. r 48
`OLE
`X::FOOO
`STUB
`OBJECT
`
`OLE
`PROXY
`OBJECT
`46 1...-----1 1...--___ --' OLE
`L . . . - - - - r - - - - - - - - - - I CHAN.
`44
`
`SINGLE COMPUTER
`
`50
`
`PRIOR ART
`ILLUSTRATION
`
`FIG. 4
`
`60
`
`l-
`
`RA OBJECT MANAGER
`
`RA
`CHAN.
`
`70
`
`,58
`CLIENT APP. /68
`
`r-r~ RA
`
`PROXY
`OBJ.
`
`62
`
`CLIENT COMPUTER
`
`j
`
`,
`
`DATA
`BASE
`..,
`....
`67 J
`
`66 i
`02
`
`f'--.
`r- 80
`
`~86
`,.,
`
`I+- OLE
`RA
`STUB r-- PROXY
`OBJ.
`OBJ.
`I
`74 J
`
`OLE
`CHAN.
`
`82 ____
`
`(64
`OLE
`STUB p:FOOO
`OBJ.
`84 =----'"
`SERVER APP .
`
`t
`
`REMOTE SERVER COMPUTER
`
`Page 4 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 4 of 8
`
`5,881,230
`
`FIG. 5
`
`X->FOOO
`62)
`
`..
`
`(76
`FOO
`FACELET
`
`RA PROXY OBJ.
`:J
`68
`
`70
`
`88
`
`/'
`USER'
`SERVICES
`APPLICATION
`
`-
`;-
`
`92
`
`FIG. 6
`94
`/'
`BUSINESS'
`SERVICES
`APPLICATION
`
`-
`1-
`92
`
`90)
`
`96)
`
`CLIENT
`COMPUTER
`
`SERVER/CLIENT
`COMPUTER
`
`/78
`FOO
`STUBLET
`
`RASTUBOBJ.
`
`74 J
`
`98
`/'
`DATA'
`SERVICES
`APPLICATION
`
`100J
`
`J
`
`,
`
`DATA
`BASE
`....
`,-
`10Q"
`
`SERVER
`COMPUTER
`
`LOGICAL
`TIER 1
`USER SERVICES
`
`LOGICAL
`TIER2
`BUSINESS SERVICES
`
`LOGICAL
`TIER3
`DATA SERVICES
`
`Page 5 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 5 of 8
`
`5,881,230
`
`104
`
`USER
`SERVICES
`APPLICATION
`
`10
`CLIENT
`COMPUTER
`
`FIG.7A
`110
`
`BUSINESS
`SERVICES
`APPLICATION 1
`BUSINESS 112
`SERVICES
`APPLICATION 2
`
`BUSINESS 114
`SERVICES
`APPLICATION 3
`
`116
`
`SERVER/CLIENT
`COMPUTER
`
`108
`
`118
`
`DATA
`SERVICES
`APPLICATION
`
`DATA
`BASE
`
`12
`
`SERVER
`COMPUTER
`
`PHYSICAL
`TIER 1
`USER SERVICES
`(1 LAYER)
`
`PHYSICAL
`TIER2
`BUSINESS SERVICES
`(1 LAYER)
`
`PHYSICAL
`TIER 3
`DATA SERVICES
`(1 LAYER)
`
`Page 6 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 6 of 8
`
`5,881,230
`
`FIG.7B
`
`104
`
`(
`
`110
`
`USER
`SERVICES
`APPLICATION
`
`108
`
`BUSINESS
`SERVICES
`APPLICATION 1
`
`10
`
`BUSINESS 112
`SERVICES
`APPLICATION 2
`
`BUSINESS 114
`SERVICES
`APPLICATION 3
`
`118
`
`DATA
`SERVICES
`APPLICATION 1
`
`130
`
`108
`
`DATA
`SERVICES
`APPLICATION 2
`
`DATA
`BASE
`
`12
`
`PHYSICAL
`TIER 1
`USER SERVICES
`(1 LAYER)
`
`PHYSICAL
`TIER 2
`BUSINESS SERVICES
`(3 LAYERS)
`
`PHYSICAL
`TIER 3
`DATA SERVICES
`(2 LAYERS)
`
`Page 7 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 7 of 8
`
`5,881,230
`
`/
`
`134
`
`(" 150
`
`(,152
`
`REMOTE OLE
`CREATES AN
`OLE REMOTE
`STUB OBJECT
`
`r
`
`REMOTE OLE
`CREATES OLE
`CHANNEL ON
`REMOTE
`COMPUTER
`
`FIG. 8
`
`START
`
`!
`
`CLIENT APP.
`MAKES A REMOTE
`OBJECT
`REFERENCE
`
`11
`
`136
`
`~
`LOCAL OLE
`CREATESARA
`
`CLIENT
`COMPUTER
`.!.
`CONNECTION
`ESTABLISHED
`BETWEEN CLIENT
`
`138
`
`REMOTE SERVER
`COMPUTER
`
`140
`
`COMMUNICATION Ir--
`142
`CHANNEL
`ESTABLISHED
`FROM
`CLIENT
`COMPUTER TO
`REMOTE RA
`OBJECT
`MANAGER
`
`PROXY APP. ON " OLE CREATES
`COMPUTER AND h
`!
`
`i
`
`REMOTE
`
`SERVER APP.
`
`i
`
`REMOTE
`OLE
`CREATES
`REMOTE OLE
`PROXY OBJECT
`
`r
`
`148
`
`!
`
`TWO-WAY
`COMM. PATH
`ESTABLISHED
`BETWEEN
`CLIENT AND
`REMOTE
`SERVER
`COMPUTER
`
`r-'-
`54
`1
`
`V-
`146 SEND REMOTE
`OBJECT
`INFORMATION
`FROM REMOTE r--
`1
`56
`SERVER
`COMPTUER TO
`CLIENT
`COMPUTER
`
`REMOTE RA
`OBJECT
`MANAGER V 144
`CREATES A
`REMOTE RA
`STUB OBJECT
`
`r
`
`END
`
`Page 8 of 19
`
`

`

`u.s. Patent
`
`Mar. 9, 1999
`
`Sheet 8 of 8
`
`5,881,230
`
`START
`
`DETERMINE
`LOGICAL AND
`INITIAL
`PHYSICAL
`LAYERS
`
`ALLOCATE
`APPLICATON
`OBJECTS
`AMOUNG INITIAL
`PHYSICAL
`LAYERS
`
`160 /
`
`FIG. 9
`
`162
`
`164
`
`PERFORMANCE
`OF
`SYSTEM
`ACCETPABLE?
`
`NO
`
`168
`
`ADD ADDITIONAL
`PHYSICAL
`LAYERS AND RE(cid:173)
`ALLOCATE
`APPLICATON
`OBJECTS
`AMOUNG
`PHYSICAL
`LAYERS
`
`YES G
`
`Page 9 of 19
`
`

`

`5,881,230
`
`1
`METHOD AND SYSTEM FOR REMOTE
`AUTOMATION OF OBJECT ORIENTED
`APPLICATIONS
`
`FIELD OF INVENTION
`
`The present invention relates to communications between
`client/server object oriented applications. More particularly
`it relates to the communication of object oriented informa(cid:173)
`tion between a client object oriented application and a server
`object oriented application running on a remote computer in 10
`a distributed computing environment.
`
`BACKGROUND AND SUMMARY OF THE
`INVENTION
`
`2
`cannot contain an object reference to a server application
`running on a remote computer. There is also no way to
`maintain object identity if an object reference was passed
`from a client object application to a remote server object
`5 application on a remote computer since object references are
`not known outside the local computer. This limits the ability
`of software developers to write distributed object applica(cid:173)
`tions using existing OLE and other object oriented frame(cid:173)
`works.
`The OLE proxy/OLE channel/OLE stub model also limits
`the ability of developers to create anything more than
`traditional two-tier client/server applications. If a client
`application could contain references to more than one
`remote server application (i.e., on one or more remote
`15 computers), then three-tier, four-tier, and potentially N-tier
`client/server layering could be accomplished. Three-tier
`client/server object layering is desirable for many business
`applications (e.g., a first tier providing user services, a
`remote second tier providing business services, and a remote
`20 third tier providing data services).
`The inability to reference a remote object also limits the
`scope of a network client object application (e.g., an Internet
`object application), as only objects on the same computer
`can currently be referenced. The ability to reference a
`(
`remote object e.g., from a hypertext markup language
`(HTML) file, or in a HTML universal resource locator
`(URL)) would greatly enhance the variety and format of
`information (i.e. including audio, video, etc.) that could be
`accessed by a client network object application.
`In accordance with the present invention, the ability to
`reference remote server object oriented applications on
`remote computers is achieved. The present invention pro(cid:173)
`vides a method for remote automation of object oriented
`35 applications. The remote automation method includes pro(cid:173)
`viding a two-way communications path between a client
`object oriented application on a client computer and one or
`more server object oriented applications residing on one or
`more remote computers, where the two-way communica-
`40 tions path includes an object linking and embedding chan(cid:173)
`nel. The object linking and embedding channel allows object
`linking and embedding information (e.g., OLE information)
`to be sent to a remote computer. An object reference that is
`uniquely represented and identifiable by both the client
`45 object oriented application and the multiple server object
`oriented applications is accepted from the client object
`oriented application. The accepted object reference is passed
`over the two-way communications path using the object
`linking and embedding channel to the remote server object
`50 oriented application. The object linking and embedding
`channel allows object linking and embedding information to
`be sent to a remote computer with the minimum data
`manipulation or conversion. The remote object is returned to
`the client object oriented application from a selected server
`55 object oriented application.
`Using the remote automation method, a client object
`oriented application can reference remote objects and
`remote object data on server object oriented applications
`running on one or more remote computers, provided the
`client and server computers are connected by a compatible
`computer network. The remote automation method provides
`multiple network connection possibilities including TCP/IP,
`PPP, and SLIP to connect the client and server computers.
`The remote automation method is used to extend the OLE
`object creation process and modify OLE object data. Since
`only OLE object data is modified, the remote automation
`method is compatible with existing and previously written
`
`30
`
`25
`
`Object oriented programming, as is well known in the art,
`is used to design computer software that is easy to create,
`cost effective to modify, and reusable. Object oriented
`software provides data abstraction, which hides the physical
`representation of data within objects, and thus lessens the
`impact of changes when modifications are made to the
`software.
`The Component Object Model (COM) for object oriented
`programming specifies how objects within a single applica(cid:173)
`tion or between applications (e.g. client/server applications)
`interact and communicate by defining a set of standard
`interfaces. Interfaces are groupings of semantically related
`functions through which a client application accesses the
`services of a server application.
`Object Linking and Embedding (OLE), such as OLE
`Version 2 by Microsoft Corporation of Redmond, Wash., is
`based in part on the Component Object Model and allows
`the creation of objects of different formats which operate on
`object data through defined interfaces, rather than on the
`applications responsible for the data. Using OLE, object data
`can be embedded within an object, or linked to it, so that
`only a reference to the object data is stored in the object.
`OLE enables developers to create sophisticated and exten(cid:173)
`sible client/server applications.
`At the heart of the OLE object system is the ability for a
`client object oriented application to have a reference to an
`object in a server object application, even though the two
`applications are not sharing computer process memory (e.g.,
`computer memory, in the same operating system process
`space). In many client/server systems, both the client and
`server application exist within the same operating system
`process, and thus are able to share process memory. To allow
`an out-of-shared memory reference, two additional objects
`are created to maintain the object reference: an OLE proxy
`object in the client application, and an OLE stub object in the
`server application. An OLE channel is also created that
`connects the OLE proxy and stub objects. To the client, the
`OLE proxy object looks and acts just like the real object,
`because the OLE proxy intercepts and forwards all calls to
`the real object through the OLE channel to the OLE stub
`object. The OLE stub object in turn calls the real object. The
`communication between the OLE proxy and OLE stub is
`managed by an OLE channel object, which sends informa(cid:173)
`tion between the client and server processes.
`There are several problems associated with the existing 60
`OLE proxy/OLE channel/OLE stub model to maintain an
`object reference for client/server object applications that do
`not share memory. The OLE channel is not capable of
`sending information between client and server processes on
`different computers. In a distributed computing 65
`environment, client and server applications are typically
`located on different computers; therefore a client application
`
`Page 10 of 19
`
`

`

`5,881,230
`
`3
`OLE client and server object oriented applications, and can
`be used without modifying these existing applications. In
`addition, the remote automation method maintains the iden(cid:173)
`tity of an object as an object reference is passed to one or
`more remote computers using the remote automation 5
`method.
`With the remote automation method, an N-tiered client/
`server object application model is possible. In addition,
`object references to remote objects can now be added to
`network object applications (e.g., in HTML or HTML
`URLs), greatly enhancing the variety and format of infor(cid:173)
`mation available to network object applications.
`The remote automation method allows developers to
`quickly and cleanly create distributed client/server object
`applications, using a known and familiar object oriented 15
`programming environment (i.e., OLE), which decreases
`development time, and lowers overall development costs.
`The foregoing and other features and advantages of the
`present invention will be more readily apparent from the
`following detailed description, which proceeds with refer(cid:173)
`ence to the accompanying drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block diagram of a computer system used to 25
`implement a preferred embodiment of the present invention.
`FIG. 2 is a flow diagram of a method for one embodiment
`of the present invention.
`FIG. 3 is a block diagram illustrating the existing OLE
`object oriented communication between a client and server
`object oriented application on the same computer.
`FIG. 4 is a block diagram illustrating remote OLE object
`oriented communications between a client object oriented
`application and a remote server object oriented application 35
`on a remote computer.
`FIG. 5 is a block diagram illustrating the facelet/stublet
`interaction between a proxy and remote stub.
`FIG. 6 is a block diagram illustrating one example of a
`logical three-tiered services model.
`FIG. 7A is a block diagram illustrating one physical
`embodiment of the logical three-tiered services model
`shown in FIG. 6.
`FIG. 7B is a block diagram illustrating a second physical
`embodiment of the logical three-tiered services model 45
`shown in FIG. 6.
`FIG. 8 is flow chart illustrating a method for one embodi(cid:173)
`ment of the present invention.
`FIG. 9 is a flow chart illustrating N-tier layering for one
`embodiment of the present invention.
`
`4
`CPU 14. Although shown with one CPU 14, computer
`system 10 may alternatively include multiple processing
`units.
`The memory system 16 includes main memory 30 and
`secondary storage 32. Illustrated main memory 30 is high
`speed random access memory (RAM) and read only
`memory (ROM). Main memory 30 can include any addi(cid:173)
`tional or alternative high speed memory device or memory
`circuitry. Secondary storage 32 takes the form of long term
`10 storage, such as ROM, optical or magnetic disks, organic
`memory or any other volatile or non-volatile mass storage
`system. Those skilled in the art will recognize that memory
`16 can comprise a variety and/or combination of alternative
`components.
`The input and output devices 18, 20 are also familiar. The
`input device 18 can comprise a keyboard, mouse, pointing
`device, audio device (e.g. a microphone, etc.), or any other
`device providing input to the computer system 10. The
`output device 20 can comprise a display, a printer, an audio
`20 device (e.g. a speaker, etc.), or other device providing output
`to the computer system 10. The input/output devices 18, 20
`can also include network connections, modems, or other
`devices used for communications with other computer sys-
`tems or devices.
`As is familiar to those skilled in the art, the computer
`system 10 further includes an operating system and at least
`one application program. The operating system is a set of
`software which controls the computer system's operation
`30 and the allocation of resources. The application program is
`a set of software that performs a task desired by the user,
`making use of computer resources made available through
`the operating system. Both are resident in the illustrated
`memory system 16.
`In accordance with the practices of persons skilled in the
`art of computer programming, the present invention is
`described below with reference to acts and symbolic repre(cid:173)
`sentations of operations that are performed by computer
`system 10, unless indicated otherwise. Such acts and opera-
`40 tions are sometimes referred to as being computer-executed.
`It will be appreciated that the acts and symbolically repre(cid:173)
`sented operations include the manipulation by the CPU 14 of
`electrical signals representing data bits which causes a
`resulting transformation or reduction of the electrical signal
`representation, and the maintenance of data bits at memory
`locations in memory system 16 to thereby reconfigure or
`otherwise alter the computer system's operation, as well as
`other processing of signals. The memory locations where
`data bits are maintained are physical locations that have
`50 particular electrical, magnetic, optical, or organic properties
`corresponding to the data bits.
`The data bits may also be maintained on a computer
`readable medium including magnetic disks, and any other
`volatile or non-volatile mass storage system readable by the
`computer 12. The computer readable medium includes
`cooperating or interconnected computer readable media,
`which exist exclusively on computer system 10 or are
`distributed among multiple interconnected computer sys(cid:173)
`tems 10 that may be local or remote.
`In a preferred embodiment of the present invention, the
`computer system 10 preferably uses the Windows® 95
`client/server operating system. However, other client/server
`operating systems (e.g. Windows NPM, OS/2®, by IBM,
`etc.) could also be used. A client/server operating system is
`an operating system which is divided into a plurality of
`processes of two different types: server processes, each of
`which typically implements a single set of services, and
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENT
`
`Referring to FIG. 1, an operating environment for the 55
`preferred embodiment of the present invention is a computer
`system 10 with a computer 12 that comprises at least one
`high speed processing unit (CPU) 14, in conjunction with a
`memory system 16, an input device 18, and an output device
`20. These elements are interconnected by a bus structure 22. 60
`The illustrated CPU 14 is of familiar design and includes
`an ALU 24 for performing computations, a collection of
`registers 26 for temporary storage of data and instructions,
`and a control unit 28 for controlling operation of the system
`10. Any of a variety of processors, including those from 65
`Digital Equipment, Sun, MIPS, IBM, Motorola, NEC, Intel,
`Cyrix, AMD, Nexgen and others are equally preferred for
`
`Page 11 of 19
`
`

`

`5,881,230
`
`5
`client processes, which request a variety of services from the
`server processes. Object oriented programming is used to
`design the client/server operating system, where objects
`represent system resources.
`For example, the Windows®95 client/server operating
`system provides shareable resources, such as files, memory,
`processes and threads, which are implemented as "objects"
`and are accessed by using "object services." As is well
`known in the art, an "object" is a data structure whose
`physical format is hidden behind a type definition. Data 10
`structures, also referred to as records or formats, are orga(cid:173)
`nization schemes applied to data so that it can be interpreted,
`and so that specific operations can be performed on that data.
`Such data structures impose a physical organization on the
`collection of data stored within computer memory 16 and 15
`represent specific electrical, magnetic or organic elements.
`An "object type," also called an "object class," comprises
`a data -type, services that operate on instances of the data
`type, and a set of object attributes. An "object attribute" is
`a field of data in an object that partially defines that object's 20
`state. An "object service" implements and manipulates
`objects, usually by reading or changing the object attributes.
`"Object oriented design" is a software development tech(cid:173)
`nique in which a system or component is expressed using
`~~
`An object typically has two components: a function table,
`containing a pointer to each object member function (i.e.
`sometimes known as an object method) defined in the
`object's class, and a data block, containing the current
`values for each object variable (i.e., data members, some(cid:173)
`times known as an object property). An application has some
`reference to an object through an object pointer. An appli(cid:173)
`cation obtains this object reference by using some type of
`function call (direct or implied) in which that function
`allocates an object block in computer memory, initializes the
`function table, and returns the reference to the computer
`memory to an application. The computer memory may be
`local or distributed on a remote computer.
`The Windows® 95 operating system allows users to
`execute more than one program at a time by organizing the
`many tasks that it must perform into "processes." The
`operating system allocates a portion of the computer's
`resources to each process and ensures that each process's
`program is dispatched for execution at the appropriate time
`and in the appropriate order.
`In one embodiment of the present invention, processes are
`implemented as objects. A process object comprises the
`following elements: an executable program; a private
`address space; system resources (e.g., communication ports
`and files) that the operating system allocates to the process
`as the program executes; and at least one "thread of execu(cid:173)
`tion." A "thread" is the entity within a process that the
`operating system kernel schedules for execution. As is well
`known in the art, each thread has an associated "context"
`which is the volatile data associated with the execution of
`the thread. A thread's context includes the contents of
`system registers and the virtual address belonging to the
`thread's process. Thus, the actual data comprising a thread's
`context varies as it executes.
`The Component Object Model (COM) is a model used for
`object oriented programming. The COM specifies how
`objects within a single application or between applications
`(e.g. client/server applications) interact and communicate by
`defining a set of standard interfaces. Interfaces are groupings
`of semantically related functions through which a client
`application accesses the services of a server application.
`
`6
`Object Linking and Embedding (OLE), such as OLE
`Version 2 by the Microsoft Corporation of Redmond, Wash.,
`is based in part on the Component Object Model and allows
`the creation of objects of different formats which operate on
`5 data through defined interfaces, rather than operating on the
`applications responsible for the data. The object data can be
`embedded within an object, or linked to it, so that only a link
`reference to the data is stored in the object.
`FIG. 2 shows a method 34 for remote automation of
`object oriented applications according to a preferred
`embodiment of the present invention. Method 34 allows a
`client object oriented application to make remote object
`references, such as object linking and embedded references,
`to multiple server object oriented applications over a two-
`way communications path, where the two-way communica(cid:173)
`tions path includes an object linking and embedding chan-
`nel. The remote object references are used to obtain remote
`object and remote object data.
`As is shown in FIG. 2, the remote automation method 34
`includes providing a two-way communications path
`between a client object oriented application on a client
`computer and one or more server object oriented applica(cid:173)
`tions residing on one or more remote computers 36, where
`the two-way communications path includes an object linking
`~
`and embedding channel. A remote object reference that is
`uniquely represented and identifiable by both the client
`object oriented application and the multiple server object
`oriented applications is accepted from the client object
`oriented application 38. The accepted remote object refer-
`30 ence is passed over the two-way communications path using
`the object linking and embedding channel to the server
`object oriented application 40. The remote object is returned
`to the client object oriented application from the server
`object oriented application over the object linking and
`35 embedding channel 42.
`As is shown in FIG. 3, the existing OLE object system
`provides the ability for a client object oriented application
`44 (hereinafter client application) to have a reference 46 to
`40 an object 48 in a server object oriented application 50
`(hereinafter server application) executing on the same com(cid:173)
`puter 10, even though the two applications are not sharing
`process memory. In many client/server operating systems,
`client and server applications are confined to a single
`45 operating system process which allows the client and server
`application to communicate using shared process memory.
`In Windows® 95 by Microsoft, and other client/server
`operating systems, client and server applications are created
`in separate processes, which typically do not share the same
`50 memory space, or use shared memory to communicate.
`To allow out-of-shared memory references, two addi(cid:173)
`tional objects are created by OLE to maintain the object
`reference: an OLE proxy object 52 in the client application
`44, and an OLE stub object 54 in the server application 50.
`55 An OLE channel 56 is also created which connects the OLE
`proxy and stub objects (52, 54).
`When the object reference X~FOO() 46 is made on the
`client application 44, the OLE proxy object 52 is treated
`internally just like the real object X::FOO() 48, because the
`60 OLE proxy object 52 intercepts and forwards all calls to the
`real object through the OLE channel 56 to the OLE stub
`object 54. The OLE stub object 54 in turn calls the real
`object 48. The communication between the proxy and stub
`is managed by an OLE channel object 56, which understands
`65 how to send object information between the client 44 and
`server 50 applications. The OLE object reference support
`just described is typically used from a high level object
`
`Page 12 of 19
`
`

`

`5,881,230
`
`7
`oriented programming language. For example, the Visual
`Basic® programming language by Microsoft provides the
`support for the OLE client/server proxy/stub object refer(cid:173)
`ence scheme described above.
`The. OLE proxy/stub object reference scheme only works 5
`for clIent and server application executing on the same
`computer, which is a severe limitation. In a distributed
`co~puting en:,ironment, it is typical to have a client appli(cid:173)
`catIon executmg on one computer and server application
`executing on another, remote computer.
`In one embodiment of the present invention, the OLE
`environment is modified and enhanced to allow object
`references to objects on remote computers. An object ori(cid:173)
`ented application called Remote Automation (RA) is pro(cid:173)
`vided that works as an extension of, and in conjunction, with
`OLE. The Remote Automation object oriented application
`uses the remote automation method 34 to allow a server
`object oriented application to make a remote object refer(cid:173)
`ence to a remote object or remote object data on a server
`object oriented application.
`The Remote Automation application extends the OLE
`object creation process by modifying the system registry
`data on the client computer. Since only OLE data is
`modified, Remote Automation is compatible with existing
`OLE automation client/server applications. Existing OLE 25
`applications do not have to be changed or recompiled using
`Remote Automation. On each host client/server operating
`system, preferably the operating system registry (also called
`the registration database) is used to store relevant informa(cid:173)
`tion about object components according to their CLass
`IDentifier (CLSID). An object registers its CLSID in the
`operating system registry to enable client applications to
`locate and load the executable code associated with the
`objects.
`The CLSIDs are given the alias "GUID," which stands for
`Globally Unique IDentifiers. Each object class is repre(cid:173)
`sented by a GUID, a l28-bit (l6-byte) number that is
`assumed to be unique in the world across space and time. A
`GUID is a l6-byte value with a specific structural definition
`that has an ASCII representation shown below as a group of
`hexadecimal digits within braces such as" {42754850-l6b7-
`llce-90eb-OOaa003d7352}" (The groupings of the hex dig-
`its and the hyphens are part of the ASCII representation as
`well~. T~e structural definition of a GUID is manipulated by
`applIcatIons programs such as the Remote Automation
`object oriented appli