Background of the Invention With the advent and explosion of the Internet, a worldwide network of connected computers has been established. Using the Internet or other type of network, computers and their users are able to communicate with one another quickly and easily. E-mail, File Transfer Protocol ("FTP"), Telnet, and other types of communication protocols have been established that allow computers to communicate with each other quickly and easily. However, despite the advent of expansive computer networks and the protocols for communicating between them, computers have been unable to share documents and other objects in real-time.

For instance, if two or more network computer users want to work on a document together using today's computer networks, they typically must each work on the document separately and at different times. There is simply no mechanism available which allows each of the users to work with the document, and have changes they make to the document reflected at the other users'computers in real- time. This can be extremely frustrating because each computer user must wait until the other users have finished to work on the document.

This same limitation may prevent an object from being shared between two or more computers in real-time under programmatic control. For instance, it may be desirable for an e-commerce merchant to maintain an extensible markup language ("XML") document containing entries for pending orders. The document may be accessible to the merchant's outside vendors who can insert an entry into the document when an order is to be placed. As orders are satisfied by the merchant, the appropriate entries may be removed from the document by the merchant. However, using today's computer systems, both the merchant and its vendors could not access the document simultaneously and have their changes reflected in the document in real-time.

Although application programs do exist for sharing certain types of objects, these types of applications typically only allow the sharing of a user interface, rather than the actual sharing of a document. For instance, network'whiteboard'programs may provide each of a number of network computer users with a whiteboard displayed on their computer screen. Each user may'write'on the whiteboard using a mouse or other input device, and the input will be reflected on the other computer users'screens. While it appears to the users that they are sharing the whiteboard, in reality they are only sharing the user interface. User interface commands are transmitted that cause each users'input to be reflected on the whiteboards of the other users. Therefore, in reality, a whiteboard object is not being shared. Rather, a whiteboard user interface is being shared among the users.

Another drawback of previous computer systems for sharing objects is that the previous systems do not provide programmatic access to the shared object. The operations that may be performed on the shared object are limited to those provided by the application or operating system program that implements the sharing mechanism. Because programmatic access to the shared object is unavailable, custom operations simply cannot be performed on the shared object without creating a custom application program.

Therefore, in light of these problems, there is a need for a method and system for object sharing that provides real-time access to a shared object in a network computing environment. There is a further need for a method and system for real- time object sharing that advantageously provides programmatic access to the shared object. There is an additional need for a method and system for real-time object sharing in a network computing environment that allows multiple computers to truly

share an object in real-time, rather than just allowing multiple computers to share a user interface.

Summary of the Invention The present invention solves the above-described problems by providing a method and apparatus for providing real-time access to a shared object in a network computing environment. According to one actual embodiment of the invention, a shared object server and a client computer are provided that together provide real- time access to a shared object. The shared object is maintained at the shared object server, and an instance of the shared object is maintained at the client computer. The shared object and the instance of the shared object are advantageously synchronized in real-time through a system of communication between the shared object server and the client computer. Moreover, application programming interfaces are advantageously provided on both the shared object server and the client computer so that true programmatic access to the shared object may be permitted.

Generally described, the present invention provides a method and system for providing real-time access to a shared object in a network computing environment.

According to one actual embodiment of the invention, a shared object server and a client computer are provided. The shared object server and the client computer are connected via a distributed computing network, such as the Internet. The shared object server maintains the shared object and receives requests to perform commands on the shared object from the client computer. When a request to perform a command on the shared object is received, the shared object server locks the shared object so that only the requested command may be performed on the shared object and executes the command on the shared object. The shared object server then transmits a request to the client computer to perform the command on an instance of the shared object maintained at the client computer. The shared object server then unlocks the shared object so that additional commands may then be performed on the shared object. In this manner, the shared object maintained at the shared object server and the instance of the shared object maintained at the client computer are synchronized.

More specifically described, an actual embodiment of the present invention provides a shared object server for providing access to a shared object in real-time.

The shared object server is connected to a distributed computing network and may receive requests from client computers to perform commands on a shared object.

The shared object is maintained at the shared object server and may comprise an extensible markup language ("XML") document, a text document, or other type of object known to those skilled in the art.

In order to receive requests to perform commands on the shared object, the shared object server launches network listener programs to"listen"for requests from client computers received at the server's hardware input ports. If a request for a client connection is detected at an input port, the network listener duplicates the input port at which the request was received and connects the incoming connection to the duplicate input port. The shared object server also launches a client input interpreter thread that determines whether a request to perform a command on the shared object has been received at the duplicate input port.

If the client input interpreter thread determines that a request to perform a command on the shared object has been received at the duplicate input port, the client input interpreter calls a command receiver application programming interface ("API"). The command receiver API locks the shared object on which the command is to be performed so that additional commands may not be performed on the shared object, and executes the command on the shared object. The command may comprise a request to create, update, or delete elements within the shared object, or other commands known to those skilled in the art. Additionally, a request may be transmitted to a client output messenger for performing the command on an instance of the shared object maintained at a client computer or other shared object server.

Once this request has been transmitted, the shared object is unlocked so that additional commands may be performed upon it. Any commands received at the shared object server while the shared object is locked are queued for execution after the shared object has been unlocked.

According to an actual embodiment of the present invention, a client computer is also provided for sharing the shared object maintained by the shared object server. The client computer is connected to the shared object server via a distributed computing network, like the Internet. The client computer executes a client application program and maintains an instance of the shared object. In order to execute a command on the shared object, the client application program transmits a request to perform a command on the shared object to the shared object server. The shared object server receives the request and executes the command on the shared object in the manner described above.

As also described above, the shared object server may transmit a request to the client computer to execute the command on the instance of the shared object maintained at the client computer. In order to process the request from the shared object server, the client application program provides a user-implemented API for executing commands received from the shared object server. When such a request from the shared object server is received, the command is decoded and passed to the user-implemented API. The user-implemented API then executes the command on the instance of the shared object maintained at the client computer. In this manner, the shared object maintained at the shared object server and the instance of the shared object maintained at the client computer are synchronized in real time. Additionally, because APIs are provided at the shared object server and at the client computer, true programmatic access is provided to the shared object.

In accordance with yet other aspects of the invention, a system, a computer-controlled apparatus, and a computer-readable medium containing instructions are also provided for real-time object sharing in a network computing environment.

Brief Description of the Drawings The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein: FIGURE 1 is a block diagram of a representative portion of the Internet.

FIGURE 2 is a block diagram illustrating an actual operating environment for aspects of the present invention.

FIGURE 3 is a block diagram depicting an illustrative architecture for an actual client computer embodying aspects of the present invention.

FIGURE 4 is a block diagram depicting an illustrative software architecture for an actual client computer embodying aspects of the present invention.

FIGURE 5 is a block diagram depicting an illustrative architecture for an actual real-time shared object server computer embodying aspects of the present invention.

FIGURE 6 is a block diagram depicting an illustrative software architecture for an actual real-time shared object server computer embodying aspects of the present invention.

FIGURES 7A, 7B, and 7C are flow diagrams showing a routine for processing commands on a shared object in real-time.

FIGURE 8 is a flow diagram illustrating a routine for processing commands from an application program or a real-time object server on a client computer.

Detailed Description of the Preferred Embodiment As will be better understood from the following description, the present invention is embodied in a client computer and a shared object server connected to a network, such as the Internet. As is well known to those skilled in the art, the term "Internet"refers to the collection of networks and routers that use the Transmission Control Protocol/Internet Protocol ("TCP/IP") to communicate with one another. A representative section of the Internet 20 is shown in FIGURE 1, in which a plurality of local area networks ("LANs") 24 and a wide area network ("WAN") 26 are interconnected by routers 22. The routers 22 are special purpose computers used to interface one LAN or WAN to another. Communication links within the LANs may be twisted pair wire, or coaxial cable, while communication links between networks may utilize 56 Kbps analog telephone lines, 1 Mbps digital T-1 lines, 45 Mbps T-3 lines or other communications links known to those skilled in the art.

Computers, such as client computers 28, a the shared object server 30, and other related electronic devices can be remotely connected to either the LANs 24 or the WAN 26 via a modem and temporary telephone link. Client computers 28 and the shared object server 30 may also be connected to LANs 24 or WAN 26 through other means such as digital subscriber line ("DSL"), hybrid fiber/cable systems, or other means for connecting computers on a network known to those skilled in the art.

Client computers 28 and the shared object server 30 may also be connected on the same LAN 24 or WAN 26, or may be connected directly. It should be appreciated that the Internet 20 comprises a vast number of such interconnected networks, computers, and routers and that only a small, representative section of the Internet 20 is shown in FIGURE 1.

FIGURE 2 illustrates additional aspects of an actual operating environment for the present invention. More specifically, FIGURE 2 shows the shared object server 30 connected to the client computers 28. As described above, client computers 28 may be connected to the shared object server 30 via the Internet or other type of network. As will be described in more detail below, the shared object

server 30 maintains one or more shared objects, and provides access to these objects to the client computers 28. Through a system of communication between the shared object server 30 and the client computers 28, instances of the shared object may be maintained on client computers 28 that are synchronized with the shared object maintained at the shared object server 30. It should also be appreciated that the shared objects maintained by the shared object server 30 may also be synchronized with a shared object maintained by another shared object server 30A in a similar manner. In this manner, the shared object maintained by the shared object server 30 may be synchronized to additional instances of the shared object maintained by the client computers 28 connected to the shared object server 30A.

FIGURE 3 depicts several of the key components of one of the client computers 28. Those of ordinary skill in the art will appreciate that the client computers 28 include many more components then those shown in FIGURE 3.

However, it is not necessary that all of these generally conventional components be shown in order to disclose an illustrative embodiment for practicing the present invention. As shown in FIGURE 3, the client computers 28 include a network interface 34 for connecting to the Internet 20, a LAN or WAN, or for connecting remotely to a LAN or WAN. Those of ordinary skill in the art will appreciate that the network interface 34 includes the necessary circuitry for such a connection, and is also constructed for use with the TCP/IP protocol, the particular network configuration of the LAN or WAN it is connecting to, and a particular type of coupling medium. The client computers 28 may also be equipped with a modem 36 for connecting to the Internet 20 through the public switched telephone network 37 by utilizing a point to point protocol ("PPP") connection or a SLIP connection as known to those skilled in the art.

The client computers 28 also include a processing unit 32, a display 38, and a memory 40. The memory 40 generally comprises a random access memory ("RAM"), a read-only memory ("ROM") and a permanent mass storage device, such as a disk drive. The memory 40 stores an operating system 44 for controlling the operation of the client computers 28. The memory 40 also stores a client application program 42, an instance of a shared object 46, and a client API 48. As will be described in more detail below, the client application program 42 is operative to transmit a request to the shared object server 30 (not shown) for performing a command on a shared object. In response to receiving the request from the client computers 28, the shared object server 30 will perform the requested command on

the shared object. Additionally, the shared object server 30 may transmit a request to the client computers 28 to perform the same command on an instance of the shared object 46 maintained at the client computers 28. This request will be received and processed by the client API 48, and the requested command will be performed on the instance of the shared object 46. In this manner, the shared object maintained at the shared object server 30 may be synchronized with the instance of the shared object 46 maintained at the client computers 28. Operation of the client computers 28 is described in more detail below with reference to FIGURES 4 and 8.

It will be appreciated that the client application program 42, the instance of the shared object 46, and the client API 48 components may be stored on a computer-readable medium and loaded into memory 40 of the client computers 28 using a drive mechanism associated with the computer-readable medium, such as a floppy, CD-ROM drive, or DVD-ROM drive. The memory 40, network interface 34, display 38, and modem 50 may all be connected to the processing unit 32 via bus 50.

Other peripherals may also be connected to the processing unit in a similar manner or in a manner known to those skilled in the art.

FIGURE 4 depicts the software architecture of the client computers 28. As described above, the memory 40 stores a client application program 42, an instance of a shared object 46, and a client API 48. The client API 48 comprises a client coder/decoder ("codec") 82 that exposes routines 88A-88N to the client application 42. Client application 42 may call the routines 88A-88N for performing commands on the shared object maintained at the shared object server 30. According to an actual embodiment of the present invention, the routines 88A-88N exposed by the client codec 82 comprise a routine 88A for creating an element within the shared object, a routine 88B for updating an element within the shared object, and a routine 88N for deleting an element within the shared object. Additional routines for performing other commands on the shared object may also be implemented by client codec 82.

The client API 48 may also comprise a client encoder 84. The client encoder 84 receives requests to perform commands on the shared object from the client codec 82, and encodes the requests for transmission to the shared object server 30. Once the requests have been encoded, the client encoder transmits the requests to the shared object server 30 over the Internet 20, or other network. As will be described in more detail below with reference to FIGURES 5-6 and 7A-7C, the shared object server 30 receives the requests and performs the requested command on

the shared object. Additionally, the shared object server 30 may transmit a request to the client computers 28 to perform the command on an instance of the shared object 46 maintained at the client computers 28.

The client decoder 86 receives requests from the shared object server 30 for performing commands on an instance of the shared object 46 maintained at the client computers 28. The client decoder 86 then decodes the requests and calls a specified routine 90A-90N exposed by user-implemented API 87. According to an embodiment of the invention, user-implemented API 87 is implemented by client application program 42 and passed to the client codec 82 when calling one of the routines 88A-88N exposed by the client codec 82. The user-implemented API 87 exposes routines 90A-90N for performing commands on the instance of the shared object 46 maintained at the client computers 28. According to one actual embodiment of the present invention, the routines 90A-90N exposed by the user- implemented API 87 comprise a routine 90A for creating an element within the instance of the shared object 46, a routine 90B for updating an element within the instance of the shared object 46, and a routine 90N for deleting an element within the instance of the shared object 46. Additional routines for performing other commands on the instance of the shared object 46 may also be exposed by user-implemented API 87.

Those skilled in the art should appreciate that the client application program 42 does not directly execute commands on the instance of the shared object 46 maintained at the client computers 28. Rather, commands are performed on the instance of the shared object 46 through calls to routines 90A-90N exposed by user-implemented API 87 in response to requests received by client decoder 86 from the shared object server 30. By processing commands in this manner, the instance of the shared object 46 maintained at the client computers 28 may be synchronized with the shared object maintained at the client computer 30.

FIGURE 5 depicts several of the key components of the shared object server computer 30. Those of ordinary skill in the art will appreciate that the shared object server computer 30 includes many more components then those shown in FIGURE 5.

However, it is not necessary that all of these generally conventional components be shown in order to disclose an illustrative embodiment of the present invention. As shown in FIGURE 5, the shared object server computer 30 includes a network interface 62 for connecting to the Internet 20, a LAN or WAN, or for connecting remotely to a LAN or WAN. Those of ordinary skill in the art will appreciate that

the network interface 62 includes the necessary circuitry for such a connection, and is also constructed for use with the TCP/IP protocol, the particular network configuration of the LAN or WAN it is connecting to, and a particular type of coupling medium.

The shared object server 30 also includes a processing unit 60, a display 66, and a mass memory 68. The mass memory 68 generally comprises a random access memory ("RAM"), a read-only memory ("ROM") and a permanent mass storage device, such as a disk drive. The memory 68 stores an operating system 70 for controlling the operation of the shared object server 30. The mass memory 68 also stores a real-time object server application program 72 and a shared object 74. The shared object 74 may comprise an XML document, text document, or other type of object known to those skilled in the art. Additionally, those skilled in the art will appreciate that the shared object server 30 may permit the sharing of many shared objects 74.

As will be described in more detail below, the real-time shared object server application program 72 is operative to receive requests to perform commands on the shared object 74 from client computers 28, or from other shared object servers. In response to receiving a request from the client computers 28, the real-time shared object server application program 72 performs the requested command on the shared object 74. Additionally, the real-time shared object server application program 72 may transmit a request to the client computers 28 to perform the same command on an instance of the shared object 46 maintained at the client computers 28. Operation of the real-time shared object server application program 72 is described in more detail below with reference to FIGURES 6 and 7A-7C.

It will be appreciated that the real-time shared object server application program 72 and the shared object 74 may be stored on a computer-readable medium and loaded into mass memory 68 of the shared object server 30 using a drive mechanism associated with the computer-readable medium, such as a floppy, CD-ROM drive, or DVD-ROM drive. The mass memory 68, network interface 62, and display 66 may all be connected to the processing unit 60 via bus 80. Other peripherals may also be connected to the processing unit 60 in a similar manner, or in another manner known to those skilled in the art.

FIGURE 6 depicts the software architecture of a shared object server 30 executing a real-time shared object server application program 72. According to an actual embodiment of the present invention, the real-time shared object server

application program 72 comprises an input listener 102 for'listening'at a hardware input port 100 to determine if a request has been received to perform a command on a shared object 74A from a client computers 28. If the input listener 102 determines that such a request has been received, a client input interpreter thread 104A is launched. Moreover, the hardware input port 100 is duplicated and a connection is created between the client input interpreter thread 104A and the duplicate port (not shown). In a like manner, the input listener 102 may determine that a request has been received requesting that an output port be opened for transmitting commands to client computers 28. If such a request is received, an output listener 110 duplicates a hardware output port 112. A client output messenger 108A is also launched and connected to the duplicate hardware output port (not shown). In this manner, the hardware input port 100 and the hardware output port 112 may be freed and may accept additional connections. The duplication of hardware ports is well known to those skilled in the art.

The client input interpreter thread 104A is operative to receive requests for performing commands on the shared object 74A from the client computers 28 and, in particular, from the client API 48. Additional client input interpreters 104B-104N may also be executed to receive such commands from other client computers 28, or from other shared object servers. When the client input interpreter thread 104A is launched, a command receiver API 106A is also executed. The command receiver API 106A is operative to receive a request to perform a command on the shared object 74A from the client input interpreter 104A and to translate the request into a command that can be performed on the shared object 74A. Those skilled in the art should appreciate that each client input interpreter 104A-104N is associated with a command receiver API 106A-106N.

When the command receiver API 106A receives a request to perform a command on the shared object 74A, the command receiver API 106A translates the request into a command that can be performed on the shared object 74A. The command receiver API 106A then calls the command on the shared object 74A.

According to an embodiment of the present invention, the shared object 74A is locked prior to the execution of the command so that no other command receiver API, such as command receiver APIs 106B-106N, may simultaneously perform a command on the shared object 74A. After the command has been executed, the shared object 74A is unlocked so that additional commands may be performed upon it. Commands can be received at any command receiver API 106A-106N.

According to an embodiment of the present invention, the command receiver API 106A may also transmit a request to each active client output messenger 108A-108N requesting that the command be performed on an instance of the shared object. Each active client output messenger 108A-108N that receives such a command transmits the request to its connected client API 48. Commands executed on the shared object 74A are therefore performed in real-time on instances of the shared object maintained at a client computer. In this manner, the shared object 74A is continually synchronized with the instance of the shared object maintained at the client computer.

Referring now to FIGURE 7A, an illustrative routine 700 for providing real- time access to a shared object in a network computing environment will be described.

Routine 700 begins at block 702, where the shared object server 30 reads a configuration file that identifies the objects that are to be shared. The shared object server 30 also reads from the configuration file the identity of the hardware network ports on which requests for performing commands on each shared object are to be received.

From block 702, routine 700 continues to block 704, where the shared object server 30 identifies the first object identified in the configuration file as a selected object. At block 706, the shared object server 30 parses the selected object into its constituent elements. For example, if the selected object comprises an XML document, the shared object server 30 will parse the XML document into the individual XML elements that makeup the XML document. Other types of documents may be parsed into their constituent elements in a similar manner. Next, at block 708, the shared object server 30 stores the constituent elements in a memory vector. The constituent elements are stored in this manner so that individual elements may be retrieved quickly and so that commands may be easily performed on individual elements.

From block 708, routine 700 continues to block 710 where the shared object server 30 determines whether there are additional objects identified in the configuration file. If the shared object server 30 determines that additional objects have been identified in the configuration file, routine 700 branches to block 712, where the shared object server 30 selects the next object identified in the configuration file as a selected object. Routine 700 then continues to blocks 706 and 708 where the selected object is parsed into its constituent elements and saved in a memory vector as described above. In this manner, each object identified in the

configuration file may be parsed into its constituent elements and saved in a memory vector.

If, at block 710, the shared object server 30 determines that there are no additional objects identified in the configuration file, routine 700 continues to block 714. At block 714, the shared object server 30 launches network listeners to 'listen'for connection requests at each of the hardware ports identified in the configuration file. From block 714, routine 700 continues to block 728 and block 716 (shown in FIGURE 7B) in parallel. As described in greater detail below, the shared object server 30 processes incoming connection requests and incoming requests to perform commands on shared objects in parallel.

At block 728, a determination is made by the shared object server 30 as to whether a client connection request has been detected by a network listener. If a client connection request has not been detected, routine 700 branches back to block 728. If such a connection request is detected, routine 700 continues to block 730, where the hardware input port at which the connection requested is duplicated. Additionally, the incoming connection is attached to the duplicate input port, thereby freeing the hardware input port to receive additional connections.

From block 730, routine 700 continues to block 732, shown in FIGURE 7C.

At block 732 the shared object server 30 determines whether the client connection request included a request that an outbound client connection be established. If such a request was made, routine 700 branches to block 734, where a client output messenger is launched. As described above, the client output messenger receives commands from a command interpreter API and transmits them to connected client computers. From block 734, routine 700 continues to block 736, where a primary hardware output port is duplicated and the outbound client connection is attached to the duplicate output port. At block 738, the client output messenger is attached to the duplicate output port. In this manner, a request to perform a command on an instance of the shared object maintained at the client computer may be transmitted from the client output messenger to the client API. Routine 700 then continues from block 738 to block 740.

If, at block 732, it is determined that a request for an outbound client connection was not received, routine 700 continues to block 740. At block 740, the hardware input ports are opened to receive additional incoming communications.

From block 740, routine 700 continues to block 742, where the shared object server launches a client interpreter thread and a corresponding command receiver API for

the new client connection. As described above, the client interpreter thread receives requests to perform commands on the shared object maintained by the shared object server and passes the requests to the command receiver API, and the command receiver API translates the commands into a format that may be executed on the shared object. From block 742, routine 700 returns to block 728, shown in FIGURE 7A.

Referring now to FIGURES 7A and 7B, routine 700 continues from block 714 to block 716. This operation proceeds in parallel with the opening of client input and output connections as described above with reference to blocks 728-742. At block 716, each of the active client input interpreters'listens'for requests to perform commands on a shared object maintained by the shared object server. Next, at block 718, a determination is made as to whether a request to perform a command on a shared object was received at any client input interpreter. If such a request was not received, routine 700 branches to block 716, where each client input interpreter continues to'listen'for incoming command requests. If such a request was received, routine 700 continues from block 718 to block 720.

At block 720, the shared object on which the command is to be performed is locked so that no additional commands may be performed upon the object simultaneously with the requested command. From block 720, routine 700 continues to block 722 where the requested command is executed on the shared object. As described above, commands may include requests to create, update, or delete elements within the shared object. Other commands known to those skilled in the art may also be executed on the shared object.

From block 722, routine 700 continues to block 724, where a request to perform the command on an instance of the shared object maintained at a client computer is transmitted to each of the active client output messengers. In this manner, commands executed on the shared object maintained by the shared object server may be applied in real-time to instances of the shared object maintained at client computers or other shared object servers. From block 724, routine 700 continues to block 726 where the shared object is unlocked so that additional commands may be performed upon it. Requests to perform commands on the shared object that were received while the shared object was locked may be queued and subsequently executed in the order they were received in a manner similar to that described above. Routine 700 continues from block 726 to block 726 where the above process repeats.

FIGURE 8 shows an illustrative routine 800 for the operation of a client computer utilized to share an object maintained at a shared object server. The routine 800 begins at block 802, where the client computer makes a determination as to whether a request to perform a command on a shared object has been received from a client application executing on the client computer. If such a request was received, routine 800 branches to block 804 where a determination is made as to whether the client application passed a user-implement API with the request. As described above, the user-implemented API is utilized to invoke commands on the instance of the shared object maintained at the client computer in response to commands received from the shared object server. If a user-implemented API is not passed by the application program, such commands cannot be invoked on the instance of the shared object maintained at the client computer. Therefore, if a user- implemented API was not passed, routine 800 branches to block 806, where an error message is returned to the client application. The routine 800 then returns to block 802.

If, at block 804, it is determined that a user-implemented API was passed by the client application, routine 800 continues to block 808, where the command requested by the client application is transmitted from the client codec to the client encoder. At block 810, the client encoder encodes the command for transmission to the shared object server. From block 810, the encoded command is transmitted from the client encoder to the appropriate input port on the shared object server. The shared object server then executes the command on the shared object in the manner described above. Routine 800 then returns to block 802 to receive additional command requests.

If, at block 802, it is determined that a request to perform a command on the shared object was not received from the client application, routine 800 continues to block 814. At block 814, a determination is made as to whether a request to perform a command on the instance of the shared object maintained at the client computer was received at the client computer. If such a request was not received, routine 800 returns to block 802. If such a request was received, routine 800 continues to block 816, where the command is decoded by the client decoder. At block 818, the command is passed to the user-implemented API which implements the command.

At block 820, the command is executed on the instance of the shared object maintained at the client computer. Additionally, the client application is notified that

a command has been executed on the instance of the shared object maintained at the client computer.

In light of the above, it should be appreciated that the present invention provides a method and system for real-time shared access to an object in a network computing environment. According to an embodiment of the invention, a shared object server and a client computer are provided. The shared object server maintains the shared object and receives requests to perform commands on the shared object from the client computer. When a request to perform a command on the shared object is received, the shared object server locks the shared object so that only the requested command may be performed on the shared object and executes the command on the shared object. The shared object server then transmits a request to the client computer to perform the command on an instance of the shared object maintained at the client computer. The shared object server then unlocks the shared object so that additional commands may then be performed on the shared object.

While an actual embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.