 |
Claims  |
|
|
What is claimed is:
1. A method in a computer system of transferring data between a client and
a server, the computer system having a persistent global registry for
storing data format information, the method comprising the steps of:
under control of the computer system,
storing in the persistent global registry a plurality of data formats that
the server supports;
under exclusive control of the client and without arbitration from an
external process,
determining from the persistent global registry at least one stored data
format that the server supports without accessing the server; and
selecting a determined data format;
under control of the client,
sending a request to the server to supply data in the selected data format;
under control of the server,
receiving the request to supply data in the selected data format; and
sending data in the selected data format to the client; and
under control of the client,
receiving the data sent by the server
whereby the client can determine at least one data format that the server
supports even though the server is not currently executing.
2. The method of claim 1 wherein the step of determining at least one
stored data format determines a plurality of data formats and the step of
selecting the data format includes:
under control of the client,
displaying on a display device the plurality of determined data formats;
and
in response to user input, selecting a displayed data format.
3. The method of claim 2 wherein the steps of determining the plurality of
stored data formats, displaying the determined data formats, and selecting
the displayed data format are performed without launching a server
stand-alone executable entity, such as a process or a thread or a similar
entity.
4. The method of claim 1 wherein the steps of determining at least one
stored data format and selecting the determined data format are performed
without launching a server stand-alone executable entity.
5. The method of claim 1 wherein the step of storing in the persistent
global registry the plurality of data formats is performed when an
application that corresponds to the server is installed onto the computer
system.
6. The method of claim 1 wherein the step of storing in the persistent
global registry the plurality of data formats is performed when the server
is launched.
7. A method in a computer system of transferring data between a client and
a server, the computer system having a persistent global registry for
storing data format information, the method comprising the steps of:
under control of the computer system,
storing in the persistent global registry a plurality of data formats that
the server supports;
under exclusive control of the client and without arbitration from an
external process,
determining from the persistent global registry at least one stored data
format that the server supports without accessing the server; and
selecting a determined data format;
under control of the client,
sending data to the server in the selected data format; and
under control of the server,
receiving the data sent by the client
whereby the client can determine a data format that the server supports
without accessing the server.
8. The method of claim 7 wherein the step of determining at least one
stored data format determines a plurality of data formats and the step of
selecting the data format includes:
under control of the client,
displaying on a display device the plurality of determined data formats;
and
in response to user input, selecting a displayed data format.
9. The method of claim 8 wherein the steps of determining the plurality of
stored data formats, displaying the determined data formats, and selecting
the displayed data format are performed without launching a server
stand-alone executable entity.
10. The method of claim 7 wherein the steps of determining at least one
stored data format and selecting the determined data format are performed
without launching a server stand-alone executable entity.
11. The method of claim 7 wherein the step of storing in the persistent
global registry the plurality of data formats is performed when an
application that corresponds to the server is installed onto the computer
system.
12. The method of claim 7 wherein the step of storing in the persistent
global registry the plurality of data formats is performed when the server
is launched.
13. The method of claim 7 further comprising the steps of:
under control of the server,
processing the data received from the client; and
sending the processed data back to the client; and
under control of the client,
receiving the processed data sent by the server.
14. A method in a computer system for a server to communicate to a client
the data formats it supports, the computer system having a persistent
global registry for storing data format information, the method comprising
the steps of:
under control of the computer system,
storing in the persistent global registry a data format that the server
supports for receiving data; and
storing in the persistent global registry a data format that the server
supports for sending data; and
under exclusive control of the client and without arbitration from a
process external to the client,
determining from the persistent global registry without accessing the
server the data formats supported by the server for receiving and sending
data,
wherein the server need not be currently executing when determining the
formats; and
selecting one of the data formats for use in transferring data.
15. A method in a computer system of transferring data between a first
process and a second process, the computer system having a persistent
global registry for storing data format information, the method comprising
the steps of:
under control of the computer system,
storing in the persistent global registry an outgoing data format that the
second process supports for receiving data from the first process; and
storing in the persistent global registry an incoming data format that the
second process supports for sending data to the first process;
when data is to be transferred from the first process to the second
process,
under exclusive control of the first process and without arbitration by a
third process,
determining from the persistent global registry at least one stored
outgoing data format that the second process supports for receiving data;
and
selecting a determined outgoing data format;
under control of the first process, sending data to the second process in
the selected outgoing data format; and
under control of the second process, receiving the data sent by the first
process; and
when data is to be transferred from the second process to the first
process,
under exclusive control of the first process and without arbitration by a
third process,
determining from the persistent global registry at least one stored
incoming data format that the second process supports for sending data;
and
selecting a determined incoming data format;
under control of the first process, sending a request to the second process
to supply data in the selected incoming data format;
under control of the second process,
receiving the request to supply data in the selected incoming data format;
and
sending data in the selected incoming data format; and
under control of the first process, receiving the data sent by the second
process.
16. The method of claim 15 wherein the step of determining from the
persistent global registry at least one stored outgoing data format that
the second process supports for receiving data determines a plurality of
outgoing data formats and the step of selecting the outgoing data format
comprises the substeps of:
under control of the first process,
displaying on a display device the plurality of determined outgoing data
formats that the second process supports for receiving data; and
in response to user input, selecting a displayed data format.
17. The method of claim 16 wherein the step of determining from the
persistent global registry at least one stored incoming data format that
the second process supports for sending data determines a plurality of
incoming data formats and the step of selecting the incoming data format
comprises the substeps of:
under control of the first process,
displaying on a display device the plurality of determined incoming data
formats that the second process supports for sending data; and
in response to user input, selecting a displayed data format.
18. The method of claim 15 wherein the step of determining from the
persistent global registry at least one stored incoming data format that
the second process supports for sending data determines a plurality of
incoming data formats and the step of selecting the incoming data format
comprises the substeps of:
under control of the first process,
displaying on a display device the plurality of determined incoming data
formats that the second process supports for sending data; and
in response to user input, selecting a displayed data format.
19. The method of claim 15 wherein the steps of determining at least one
stored outgoing data format and determining at least one stored incoming
data format are performed without launching the second process.
20. The method of claim 15 wherein the steps of storing in a persistent
global registry the outgoing data format that the second process supports
for receiving data and storing in a persistent global registry the
incoming data format that the second process supports for sending data are
performed when an application that is later executed as the second process
is installed onto the computer system.
21. The method of claim 15 wherein the steps of storing in a persistent
global registry the outgoing data format that the second process supports
for receiving data and storing in a persistent global registry the
incoming data format that the second process supports for sending data are
performed when the second process is launched.
22. The method of claim 15 wherein, when data is to be transferred from the
first process to the second process, further comprising the steps of:
under control of the second process,
processing the data received from the first process; and
sending the processed data back to the first process; and
under control of the first process,
receiving the processed data sent by the second process.
23. A method in a computer system of transferring data between a client
application and a server application, the computer system having a
persistent global registry, the persistent global registry having a
plurality of stored data formats that the server application supports and
a stored location of an object handler for the server application, the
object handler comprising code that is not executable as a stand-alone
process, the client application executing as a client process and having
an address space, the method comprising the steps of:
under control of the client process,
retrieving and selecting a stored data format and retrieving the location
of the object handler from the persistent global registry without
accessing the object handler; and
invoking the object handler to supply data in the selected data format, the
object handler being linked into the address space of the client process;
under control of the object handler, supplying data in the selected data
format to the client process; and
under control of the client process, receiving the data supplied by the
object handler
whereby the client process can retrieve the stored data format before
invoking the object handler.
24. A method in a computer system of transferring data between a client
application and a server application, the computer system having a
persistent global registry, the persistent global registry having a
plurality of stored data formats that the server application supports and
a stored location of an object handler for the server application, the
object handler comprising code that is not executable as a stand-alone
process, the client application executing as a client process and having
an address space, the method comprising the steps of:
under control of the client process,
retrieving and selecting a stored data format and retrieving the location
of the object handler from the persistent global registry without
accessing the object handler; and
sending data to the object handler in the selected data format, the object
handler being linked into the address space of the client process; and
under control of the object handler, receiving the data sent by the client
process
whereby the stored data format can be retrieved before invoking the object
handler.
25. A method in a computer system of transferring data between a client
task and a server task, each task being an entity schedulable for
execution on the computer system such as a process or a thread or a
similar entity, the computer system having a persistent global registry
with data that is persistently stored when the computer system is powered
down, the persistent global registry having a plurality of stored data
formats that the server task supports, the method comprising the steps of:
under exclusive control of the client task, selecting from the persistent
global registry a stored data format that the server task supports,
without a third task arbitrating the selection and without accessing the
server task, wherein the stored data format can be selected without
invoking services of the server task;
under control of the client task, sending a request to the server task to
supply data in the selected data format;
under control of the server task,
receiving the request to supply data in the selected data format; and
sending data in the selected data format to the client task; and under
control of the client task, receiving the data sent by the server task.
26. The method of claim 25 wherein the step of selecting the stored data
format is performed without launching the server task.
27. A method in a computer system of transferring data between a client
task and a server task, each task being an entity schedulable for
execution on the computer system, the computer system having a persistent
global registry, the persistent global registry having a plurality of
stored data formats that the server task supports, the method comprising
the steps of:
under exclusive control of the client task, selecting from the persistent
global registry a stored data format that the server task supports,
without a third task arbitrating the selection and without accessing the
server task, wherein the stored data format can be selected without
invoking services of the server task;
under control of the client task, sending data to the server task in the
selected data format; and
under control of the server task, receiving the data sent by the client
task.
28. The method of claim 27 wherein the step of selecting a stored data
format is performed without launching the server task.
29. A computer-readable medium containing instructions for causing a
computer system to transfer data between a client and a server, the
computer system having a persistent global registry for storing data
format information, by:
under control of the computer system, storing in the persistent global
registry a plurality of data formats that the server supports;
under exclusive control of the client and without arbitration from an
external process,
determining from the persistent global registry without accessing the
server at least one stored data format that the server supports; and
selecting a determined data format;
under control of the client, sending data to the server in the selected
data format; and under control of the server, receiving the data sent by
the client.
30. The computer-readable medium of claim 29 wherein determining of at
least one stored data format determines a plurality of data formats and
the selecting of the determined data format includes:
under control of the client,
displaying on a display device the plurality of determined data formats;
and
in response to user input, selecting a displayed data format.
31. The computer-readable medium of claim 30 wherein determining of the
plurality of stored data formats, the displaying of the determined data
formats, and the selecting of the displayed data format are performed
without launching a server stand-alone executable entity.
32. The computer-readable medium of claim 29 wherein the determining of at
least one stored data format and the selecting of the determined data
format are performed without launching a server stand-alone executable
entity.
33. The computer-readable medium of claim 29 wherein the storing in the
persistent global registry of the plurality of data formats is performed
when an application that corresponds to the server is installed onto the
computer system.
34. The computer-readable medium of claim 29 wherein the storing in the
persistent global registry of the plurality of data formats is performed
when the server is launched.
35. The computer-readable medium of claim 29 further comprising:
under control of the server,
processing the data received from the client; and
sending the processed data back to the client; and
under control of the client, receiving the processed data sent by the
server. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
TECHNICAL FIELD
This invention relates generally to a computer method and system for
registering data formats for objects and, more specifically, to a method
and system for storing data formats supported by a server, retrieving data
formats supported by the server, and sending data to the server and
requesting the server to return data in the retrieved format.
BACKGROUND OF THE INVENTION
Current document processing computer systems allow a user to prepare
compound documents. A compound document is a document that contains
information in various formats. For example, a compound document may
contain data in text format, chart format, numerical format, etc. FIG. 1
is an example of a compound document. In this example, the compound
document 101 is generated as a report for a certain manufacturing project.
The compound document 101 contains scheduling data 102, which is presented
in chart format; budgeting data 103, which is presented in spreadsheet
format; and explanatory data 104, which is presented in text format. In
typical prior systems, a user generates the scheduling data 102 using a
project management computer program and the budgeting data 103 using a
spreadsheet computer program. After this data has been generated, the user
creates the compound document 101, enters the explanatory data 104, and
incorporates the scheduling data 102 and budgeting data 103 using a word
processing computer program.
FIG. 2 shows how the scheduling data, budgeting data, and explanatory data
can be incorporated into the compound document. The user generates
scheduling data using the project management program 201 and then stores
the data in the clipboard 203. The user generates budgeting data using the
spreadsheet program 204 and then stores the data in the clipboard 203. The
clipboard 203 is an area of storage (disk or memory) that is typically
accessible by any program. The project management program 201 and the
spreadsheet program 204 typically store the data into the clipboard in a
presentation format. A presentation format is a format in which the data
is easily displayed on an output device. For example, the presentation
format may be a bitmap that can be displayed with a standard bitmap block
transfer operation (BitBlt). The storing of data into a clipboard is
referred to as "copying" to the clipboard.
After data has been copied to the clipboard 203, the user starts up the
word processing program 206 to create the compound document 101. The user
enters the explanatory data 104 and specifies the locations in the
compound document 101 to which the scheduling data and budgeting data that
are in the clipboard 203 are to be copied. The copying of data from a
clipboard to a document is referred to as "pasting" from the clipboard.
The word processing program 206 then copies the scheduling data 102 and
the budgeting data 103 from the clipboard 203 into the compound document
101 at the specified locations. Data that is copied from the clipboard
into a compound document is referred to as "embedded" data. The word
processing program 206 treats the embedded data as simple bitmaps that it
displays with a BitBlt operation when rendering the compound document 101
on an output device. In some prior systems, a clipboard may only be able
to store data for one copy command at a time. In such a system, the
scheduling data can be copied to the clipboard and then pasted into the
compound document. Then, the budgeting data can be copied to the clipboard
and then pasted into the compound document.
Since word processors typically process only text data, users of the word
processing program can move or delete embedded data, but cannot modify
embedded data, unless the data is in text format. Thus, if a user wants to
modify, for example, the budgeting data 103 that is in the compound
document 101, the user must start up the spreadsheet program 204, load in
the budgeting data 103 from a file, make the modifications, copy the
modifications to the clipboard 203, start up the word processing program
206, load in the compound document 101, and paste the modified clipboard
data into the compound document 101.
Some prior systems store links to the data to be included in the compound
document rather than actually embedding the data. When a word processing
program pastes the data from a clipboard into a compound document, a link
is stored in the compound document. The link points to the data (typically
residing in a file) to be included. These prior systems typically provide
links to data in a format that the word processing program recognizes or
treats as presentation format. For example, when the word processing
program 206 is directed by a user to paste the scheduling data and
budgeting data into the compound document by linking, rather than
embedding, the names of files in which the scheduling data and budgeting
data reside in presentation format are inserted into the document. Several
compound documents can contain links to the same data to allow one copy of
the data to be shared by several compound documents.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a method and system for
registering data formats for a server application.
It is another object of the present invention to provide a method and
system for registering data formats that the server application can both
receive and send data in.
It is another object of the present invention to provide a method and
system for a client application to determine which data formats a server
application supports without launching the server application.
It is another object of the present invention to provide a method and
system for transferring data between a server and client application.
These and other objects, which will become apparent as the invention is
more fully described below, are obtained by a method and system for
transferring data between a server and client application. In a preferred
embodiment, the data formats that the server application supports are
stored in a persistent global registry. The client application retrieves
the data formats from the persistent global registry and requests the
server application to supply data in the retrieved format. The server
application, upon receiving the request, supplies the data in the
retrieved format.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an example of a compound document.
FIG. 2 is a block diagram illustrating the incorporation of the scheduling
data, budgeting data, and explanatory data into the compound document.
FIG. 3 is a block diagram illustrating the relationships between client and
server applications in a preferred embodiment.
FIG. 4 is a block diagram illustrating the relationship between an object
handler and client and server processes.
FIG. 5 is a block diagram illustrating the components that comprise the
object linking and embedding facilities and the communications paths.
FIG. 6A is a flow diagram of a client library message dispatching routine.
FIG. 6B is a flow diagram of a typical client application callback routine.
FIG. 7 is an overview flow diagram of a typical function used by a client
application to handle waiting for an asynchronous request to complete.
FIG. 8 is a schematic diagram of an object data structure.
FIG. 9 is an overview flow diagram illustrating a typical input loop for an
application in an event-driven windowing operating system environment.
FIG. 10 is an overview flow diagram for the client library routine
Query.sub.-- Release.sub.-- Status?
FIG. 11 is an overview flow diagram of the procedure a client application
follows to open or create a compound document.
FIG. 12 is a flow diagram of the function Change.sub.-- Object.sub.--
Format implemented by a typical client application.
FIG. 13 is a flow diagram of the client library function Enum.sub.--
Formats.
FIG. 14 is a flow diagram of the client library routine Request.sub.-- Data
and the corresponding server routine.
FIG. 15 is a flow diagram of the client library function Get.sub.-- Data.
FIG. 16 is a flow diagram of the server application routine Server.sub.--
Get.sub.-- Data.
FIG. 17 is a block diagram of the object linking and embedding used to
generate the spreadsheet scheduling data and the weekly reports.
FIG. 18 is a flow diagram of the function Update.sub.-- Object.sub.--
Contents.
FIG. 19 is a flow diagram for the client library routine Send.sub.-- Data
and corresponding server routine.
DETAILED DESCRIPTION OF THE INVENTION
The present invention provides a method in which data that is contained
within a compound document can be manipulated directly by the application
program that creates the data. In a preferred embodiment, an application
program that creates data can store data in various formats and receive
data in various formats. The application program registers the formats by
storing the formats in a persistent registry. Another application program
can check the persistent registry to determine which formats are
supported. The other application can send or receive data in a registered
format. In a preferred embodiment, an application program that creates a
compound document controls the manipulation of linked or embedded data
that was generated by another application. In object-oriented parlance,
this data is referred to as an object. (The reference Budd, T., "An
Introduction to Object-Oriented Programming," Addison-Wesley Publishing
Co., Inc., 1991, provides an introduction to object-oriented concepts and
terminology.) An object that is either linked or embedded into a compound
document is "contained" within the document. Also, a compound document is
referred to as a "container" object and the objects contained within a
compound document are referred to as "containee" objects. Referring to
FIGS. 1 and 2, the scheduling data 102 and budgeting data 103 are
containee objects and the compound document 101 is a container object.
Continuing with the example of FIGS. 1 and 2, the user can indicate to the
word processor that the user wants to edit a containee object, such as the
budgeting data 103. When the user indicates that the budgeting data 103 is
to be edited, the word processing program determines which application
should be used to edit the budgeting data (e.g., the spreadsheet program)
and launches (starts up) that application. The user can then manipulate
the budgeting data using the launched application, and changes are
reflected in the compound document.
In a preferred embodiment of the present invention, applications cooperate
using object linking and embedding facilities to create and manipulate
compound documents. An application that creates a compound document is
referred to as a client application, and applications that create and
manipulate containee objects are referred to as server applications.
Referring to FIG. 2, the project management program 201 and the
spreadsheet program 204 are server applications, and the word processing
program 206 is a client application. A client application is responsible
for selection of the various objects within the container object and for
invoking the proper server application to manipulate the selected
containee object. A server application is responsible for manipulating the
contents of the containee objects.
In a preferred embodiment, applications are provided with an
implementation-independent Application Programming Interface (API) that
provides the object linking and embedding functionality. The API is a set
of routines (functions) that are invoked by client and server applications
that support compound documents. These routines manage, among other
things, the setup and initialization necessary for client applications to
send and receive messages and data to and from server applications. The
API routines are divided into a client library and a server library. The
client library provides routines which invoke the correct server
application to act upon a particular containee object. The server library
provides routines which process requests to manipulate containee objects.
FIG. 3 illustrates the relationships between client and server applications
in a preferred embodiment. In this embodiment, client applications and
server applications are separate processes. The client process 301
includes client application code 303, client library 304, and container
object 307. The server process 302 includes server application code 308,
server library 309, and containee object 311. The client process 301
communicates with the server process 302 through the communications
channel 306. The client library and server library are dynamically linked
with the client application code and server application code,
respectively, when an application process is started up. One skilled in
the art would appreciate other architectural configurations are possible.
For example, the client library and server library functions could be
implemented as processes separate from the client and server processes.
The use of the client library of the present invention allows a client
application program to be developed independently of any particular
containee object format. Indeed, a client application, in general, does
not need to know anything about the contents of a containee object. It is
also preferred that the libraries are linked to the applications
dynamically when an application process is created. The dynamic linking
allows applications to be marketed without library code and to be easily
linked to new versions of the library.
The client library routines typically transfer requests to manipulate a
containee object through the communications channel 306 to the server
process 302. One skilled in the art would appreciate that the
communications channel 306 could be implemented through well-known
interprocess communication mechanisms that are provided by various
operating systems. The server process 302 responds to requests to
manipulate containee objects received through communications channel 306.
The server library provides routines through which the server process
receives requests to manipulate data and processes the requests
accordingly.
An example will help illustrate the relationship between the client process
301 and the server process 302. Referring again to FIG. 1, if a user wants
to edit the budgeting data 103 of the compound document 101, then the
following sequence of events occurs. First, the user starts up the word
processor program, which is dynamically linked to the client library.
Second, the user opens the compound document for editing. Third, the user
selects the budgeting data, which is a containee object, and indicates
that the selected object is to be edited. Fourth, the client application
invokes a client library routine for performing an action on an object
passing the routine a handle (which uniquely identifies the selected
object) to the object and an indicator that the action is edit. Fifth, the
client library routine determines that the spreadsheet program provides
the actions for the budgeting data. Sixth, the client library starts up
the spreadsheet program as a server process, if it is not already started.
Seventh, the word processor application sends a message to the spreadsheet
program that it should edit the budgeting data. Eighth, the server library
receives the request to edit and invokes a routine in the spreadsheet
program for editing the data. When editing is complete, the spreadsheet
routine returns to the server library. The server library sends a message
to the word processor application to indicate that editing is complete.
The client library receives the message and returns from its invocation.
Upon return from the invocation, the word processor application knows that
the editing is complete.
Typically, the start up of a server process can be a relatively slow
process. There are certain situations in which it may be unacceptable to
incur this overhead. For example, if a user wants to print a compound
document that includes many containee objects, it may take an unacceptably
long time to start up the server process for each containee object and
request each server process to print the object. To ameliorate this
unacceptable performance, a server application can provide code that can
be dynamically linked during runtime into the client process to provide
certain functionality in a more expeditious manner. This code is called an
"object handler." Object handlers provide actions on behalf of the server
application so that the client library routines can avoid starting up
server processes and passing messages to the server process. In the above
example, an object handler could provide a print routine that the client
library routines could invoke to print a containee object.
FIG. 4 shows the relationship between an object handler and the client and
server processes. The object handler 402 is linked into the client process
address space during runtime by the client library routines. Typically,
the client library 403 invokes the object handler 402 directly, and the
client application code need not be aware that a handler is providing the
services, rather than a server process.
FIG. 5 shows the components that comprise the object linking and embedding
facilities and communications paths when a compound document includes
containee objects implemented by different server applications. The client
process 500 contains the client application 501, the client library 502,
and the object handlers "A" and "B" 512, 513. The server processes 509,
510, 511 contain the server applications 506, 507, 508 and server
libraries 503, 504, 505. The client process 500 establishes communications
channels with each server process 509, 510, 511. Each server process 509,
510, 511 implements a particular type of containee object of the container
object that is opened by the client process 500. The client application
code 501 is dynamically linked to routines provided by the client library
502. When the client process 500 is running, it communicates synchronously
or asynchronously with the server processes 509, 510, 511 using the
functionality provided by the client library routines. Similarly, each
server process 509, 510, 511 is dynamically linked to routines provided by
the server libraries. When the server processes 509, 510, 511 are running,
they process messages sent from the client process 500. The client library
502 sets up message passing structures and connections to each server 509,
510, 511. When the client application 501 requests an action on a
containee object, the client library 502 sends an appropriate message to
the server process that implements the type of the contained object.
Alternatively, if the server application has defined an object handler for
the requested action, then the client library 502 invokes the object
handler to perform the requested action. FIG. 5 shows that two servers
506, 507 have defined object handlers 512, 513. The client library
routines access the persistent global registry to determine information
such as which server application to use for a particular containee object
and whether an object handler is defined for a server application.
In addition to the client and server libraries, the object linking and
embedding facilities of the present invention provide information to
client and server applications through a persistent global "registry."
This registry is a database of information such as (1) for each type of
object, the server application that implements the object type, (2) the
actions that the each server application provides to client applications,
(3) where the executable files for each server application are located,
and (4) whether each server application has an associated object handler.
Communication between client and server processes occurs either
synchronously or asynchronously. Synchronous communication occurs when one
process sends a message to the other process and the sending process
suspends activity until the other process completely processes the
message. For example, when a client process wants to create a new
containee object, the client process (through the client library routines)
sends a message to the appropriate server process. The client process
waits until the containee object is created before continuing execution.
Asynchronous communication occurs when one process sends a message to the
other process and the sending process continues execution while the
receiving process responds to the message. Typically, when the receiving
process has completed responding to the request, it sends a message
indicating such completion to the sending process. For example, when a
client process wants a containee object saved in a compound document file,
the client process sends a message to the server process. The client
process can continue to execute (e.g. responding to users requests) while
the server process is saving the object. When the server process has
completed saving the object, it send a completion message to the client
process.
In a preferred embodiment, messages are passed between client and server
processes using interprocess communications mechanisms provided by the
underlying operating system. The client and server library routines
provide an interface through which the details of the interprocess
communication are shielded from the client and server applications. A
client or server application requests a synchronous action by invoking a
library routine. When the routine returns to the requesting application,
then the action requested has been completed. Similarly, a client or
server application requests an action to occur asynchronously by invoking
a library routine. The library routine initiates the action and returns to
the requesting application. The requesting application can then continue
executing. When the requested action is complete, a message is received
which the library routines process. In a preferred embodiment, the library
routines use a "callback" routine to respond to the asynchronously
received completion message. A callback routine is provided by the
requesting application. The address of the callback routine is made
available to the corresponding library so that when the library receives
an asynchronous message, the library can invoke the callback routine to
process the message. One skilled in the art would appreciate that there
are numerous ways to accomplish this invocation depending upon the
programming language employed.
FIG. 6A is a flow diagram of a client library message dispatching routine.
When a client process receives a message from a server process, the
message is dispatched by the client library to the appropriate routine for
processing. This dispatching occurs by invoking the Process.sub.--
Client.sub.-- Lib.sub.-- Message routine. This routine determines to which
object the message is directed and invokes the client callback routine to
process the message when required. In steps 601 through 604, the client
library receives a message, processes the message, and optionally invokes
a client callback routine to process the message. In step 601, the routine
determines for which containee object the message is directed. In step
602, the routine performs the client library provided processing. In step
603, if client application processing is needed, then the routine
continues at step 604, else the routine returns. Client application
processing is typically needed to respond to asynchronous messages. In
step 604, the routine invokes the client application callback routine
indicating the type of message received. The routine then returns.
FIG. 6B is a flow diagram of a typical client application callback routine.
This callback routine invokes the appropriate subroutine defined by the
client application to process the asynchronous message. In steps 609
through 617, the callback routine determines the type of message and
invokes the appropriate code to pro | | |
