Title: Method and apparatus for linking data in a distributed data processing system
Abstract: An apparatus for implementing "links" between objects or content items in applications or documents in a distributed system such that changes to the source objects or items are reflected in changes to the target objects or content items. The apparatus includes mechanisms for allowing users to establish links, to break individual links, to copy documents or content including links, and to determine locations and/or descriptions of the source of a given target or any or all of the multiple targets of a given source.Advantageously, the apparatus of this invention uses remote message passing for communication, thereby permitting links to be established even when the source and target applications execute on different platforms and even when they share no common file system.The apparatus includes an availability server which can serve as a surrogate for applications which are currently not running. This permits targets of links to query the state of a link source, to register/unregister with the link source in order to receive notification of updates, create new links linked to the same link source, and to break their link to the link source, even though the application containing the link source is unavailable.The apparatus of the availability server can be generalized to support the ability to support transparent access from one application to objects of a second application in the face of unavailability of the second application.
Patent Number: 6,973,656 Issued on 12/06/2005 to Huynh, et al.
| Inventors:
|
Huynh; Tien (Yorktown Heights, NY);
Strom; Robert Evan (Ridgefield, CT);
Ukelson; Michal Z. (Hartsdale, NY);
Yellin; Daniel M. (Suffern, NY)
|
| Assignee:
|
International Business Machines Corporation (Armonk, NY)
|
| Appl. No.:
|
515778 |
| Filed:
|
August 16, 1995 |
| Current U.S. Class: |
719/315; 719/332 |
| Intern'l Class: |
G06F 009/44 |
| Field of Search: |
395/683
709/315,316,107,108
719/315,316,332,331,310
718/107,108
717/165,164,162
715/500
|
References Cited [Referenced By]
U.S. Patent Documents
| 5175848 | Dec., 1992 | Dysart et al.
| |
| 5185885 | Feb., 1993 | Dysart et al.
| |
| 5303379 | Apr., 1994 | Khoyi et al.
| |
| 5404525 | Apr., 1995 | Endicott et al.
| |
| 5446842 | Aug., 1995 | Schaeffer et al.
| |
| 5608909 | Mar., 1997 | Atkinson et al.
| |
| 5664186 | Sep., 1997 | Bennett et al.
| |
| 5758351 | May., 1998 | Gibson et al.
| |
| 5802367 | Sep., 1998 | Held et al.
| |
| 5896533 | Apr., 1999 | Ramos et al.
| |
| 5913033 | Jun., 1999 | Grout.
| |
| 6104963 | Aug., 2000 | Cebasek et al.
| |
| 6223344 | Apr., 2001 | Gerard et al.
| |
Other References
"A Close-Up of OpenDoc", K. Piersol, BYTE, Mar. 1994, McGraw-Hill, Inc., N.Y,N.Y.
|
Primary Examiner: Lao; Sue
Attorney, Agent or Firm: Buchenhorner; Michael J., August; Casey P.
Claims
1. In a network comprising a first node, a second node and an computer implemented
server located at a node separate from the first and second nodes, an availability
server method for communicating information between a linking application in the
first node and an object of a linked application in the second node, wherein the
linked application is in one of an executing state and a non-executing state, wherein
state data indicate the object is in one of a loaded state and an unloaded state,
the computer implemented method comprising the steps of:
receiving a message from the linking application addressed to the object;
in response to receiving the message, determining whether the linked application
is in the executing or non-executing state;
upon determining that the linked application is in the executing state, forwarding
the message to the object for processing the message and responding to the linking
application accordingly;
upon determining that the linked application is in the non-executing state, accessing
a surrogate object, and forwarding the message to the surrogate object, wherein
the surrogate object comprises first data and second data and wherein the first
data defines the state of the object that cannot be changed when the linked application
is in the non-executing state and the second data defines the state of the object
which can be changed when the linked application is in the non-executing;
wherein the object is initialized utilizing the updated first data by: determining
whether the surrogate object associated with the object is in one of the loaded
state and the unloaded state; if the surrogate object is in the unloaded state,
transferring the first and second data to the linked application; and if the surrogate
object cannot be unloaded, transferring only the first data to the linked application.
2. The method of claim 1, further comprising:
determining whether the surrogate object is in a loaded or unloaded state;
upon determining that the linked application is in the non-executing state and
the surrogate object is in the loaded state, forwarding the message to the surrogate
object for processing the message and responding to the linking application accordingly;
upon determining that the linked application is in the non-executing state and
the surrogate object is in the unloaded state, loading the surrogate object and
forwarding the message to the surrogate object for processing the message and responding
to the linking application accordingly.
3. The method of claim 1, further comprising the steps of:
upon determining that the linked application is in the executing state and the
object is in the unloaded state, controlling the linked application to load and
initialize the object and forwarding the message to the object; and
wherein the object, upon receiving the message, processes the message and responds
to the linking application accordingly.
4. The method of claim 1, further comprising updating the second data accordingly
upon request from the linked application.
5. The method of claim 1, further comprising:
upon detecting that the linked application is changing from the executing state
to the non-executing state, supplying to the availability server the first and
second data
associated with the object in the linked application, wherein the availability
server stores the first and second data; and
upon detecting that the linked application is changing from the non-executing
state to the executing state, communicating the updated first data to the object.
6. The method of claim 1, wherein the object initialization further comprising:
updating the state data to indicate the object is in a loaded state, when the
object changes from the unloaded state to the loaded state;
upon determining that the surrogate object is in the loaded state, determining
whether the surrogate object can be unloaded.
7. The method of claim 1, further comprising the steps of:
when the object changes from the unloaded state to the loaded state, updating
the state data to indicate the object is in a loaded state;
determining whether the surrogate object associated with the object is in one
of the loaded and the unloaded state;
upon determining that the surrogate object is in the loaded state, determining
whether the surrogate object can be unloaded;
if the surrogate object can be unloaded, unloading the surrogate object and updating
the state data to indicate that the surrogate object is in the unloaded state;
if the surrogate object cannot be unloaded, updating the state
11 data
to indicate that the surrogate object is in the loaded state.
8. The method of claim 1, further comprising the steps of:
when the linked application is executing and the surrogate object is in a loaded
state, monitoring messages intended for the object until detecting that the surrogate
object can be unloaded; and
upon detecting that the surrogate object can be unloaded, transferring the second
data state of the surrogate object to the linked application and unloading the
surrogate object and destroying the surrogate object.
9. The method of claim 1, wherein the linking application comprises a document
containing a link target object and the linked application comprises a document,
wherein the object is a link source object that is associated with a content object
for storing content, and wherein the message is sent from the link target object
to the availability server and intended for the link source object.
10. The method of claim 9, wherein the message is one of the following:
i] a request that the link source object supply a change identifier that is updated
when the content stored in the content object is updated;
ii] a request for a lock on the content object associated with the link source object;
iii] a request that the link source object supply a pointer to the content object;
iv] a request to unlock the content object associated with the link source object;
v] a request to register with the link source object such that the link target
object is notified if the content stored in the content object is updated;
vi] a request to un-register with the link source object such that the link target
object is no longer notified if the content stored in the content object is updated; and
vii] a request that the link source object send to the link target object information
related to the link source object.
11. The method of claim 9, wherein the link target object utilizes a link identifier
that uniquely identifies the link source object within a set of link source objects,
and wherein the availability server routes the message to one of:
the link source object within the set of link source objects as determined by
the link identifier, and
the surrogate object corresponding to the link source object within the set of
link source objects as determined by the link identifier.
12. In a network comprising a first node, a second node and an application server
located at a node separate from the first and second nodes, a computer-readable
medium comprising computer implemented instructions for communicating information
between a linking application in the first node and an object in a linked application
in the second node, wherein the linked application is in one of an executing state
and a non-executing state, wherein state data indicate the object is in one of
a loaded state and an unloaded state, the computer implemented instructions comprising:
receiving a message from the linking application addressed to the object;
in response to receiving the message, determining whether the linked application
is in the executing or non-executing state;
upon determining that the linked application is in the executing state, forwarding
the message to the object for processing the message and responding to the linking
application accordingly;
upon determining that the linked application is in the non-executing state, accessing
a surrogate object, and forwarding the message to the surrogate object, wherein
the surrogate object comprises first data and second data and wherein the first
data defines the state of the object that cannot be changed when the linked application
is in the non-executing state and the second data defines the state of the object
which can be changed when the linked application is in the non-executing state;
wherein the object is initialized utilizing the updated first data by: determining
whether the surrogate object associated with the object is in one of the loaded
state and the unloaded state; if the surrogate object is in the unloaded state,
transferring the first and second data to the linked application; and if the surrogate
object cannot be unloaded, transferring only the first data to the linked application.
13. The computer-readable medium of claim 12 further comprising:
determining whether the surrogate object is in a loaded or unloaded state;
upon determining that the linked application is in the non-executing state and
the surrogate object is in the loaded state, forwarding the message to the surrogate
object for processing the message and responding to the linking application accordingly;
determining whether the surrogate object is in a loaded or unloaded state; and
upon determining that the linked application is in the non-executing state and
the surrogate object is in the unloaded state, loading the surrogate object and
forwarding the message to the surrogate object for processing the message and responding
to the linking application accordingly.
14. The computer-readable medium of claim 12 further comprising:
upon determining that the linked application is in the executing state and the
object is in the unloaded state, controlling the linked application to load and
initialize the object and forwarding the message to the object; and
wherein the object, upon receiving the message, processes the message and responds
to the linking application accordingly.
15. The computer-readable medium of claim 12, wherein the object initialization
further comprising:
updating the state data to indicate the object is in a loaded state, when the
object changes from the unloaded state to the loaded state;
upon determining that the surrogate object is in the loaded state, determining
whether the surrogate object can be unloaded.
Description
BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates generally to a distributed data processing system and,
more particularly, to the linking of data in a distributed data processing system.
2. Description of the Related Art
Linking is technology that has roots in various PC technologies, most notably
Dynamic Data Exchange (DDE). In its current form, it is best known in Microsoft's
OLE (Object Linking and Embedding) system. In short, it allows an end-user to select
some portion of a document A, commonly called the source document, and link it
to another document B, commonly called the target document. This can be done by
either copying the selected portion of document A to the clipboard and then pasting
it AS A LINK to document B, or dragging and dropping the selected content from
A to B, specifying that this drag and drop should be treated AS A LINK. After this
is done, the target document B will display the same content copied from the source
document A. Additionally, whenever the end-user modifies the linked portion of
the source document A, the changes to the linked portion will be updated in the
target document B.
The current implementations of linking assume that both the source of the link
and the target of the link are part of a shared file system. The shared file system
is the way that the information is communicated between the source document and
the target document (at least when the source document is not open, and in some
implementations when it is open as well). This means that if the two documents
are not part of a shared file system, the link cannot be established and/or maintained.
For instance, if a document at location X is linked to some other document at location
X, and then one of the documents is transferred to a system at location Y (for
example, by e-mail), the link would not be maintained unless the new location Y
was part of the same shared file system as the location X. Moreover, if a link
is to be established over a network, the current implementations require that the
linked documents shared the same file system. Hence, the current implementations
cannot be used to provide links over the Internet, for instance.
Moreover, because the current implementations require that the source and
target documents share the same file system, such links can only be established/maintained
between documents that reside on the same operating system platform. For example,
one cannot establish/maintain links between one or more documents created under
the Microsoft's Windows operating system platform and one or more documents created
under IBM's OS/2 operating system platform, or between one or more documents created
under the Apple's System
7 operating system platform and one or more documents
created under Microsoft's Windows operating system platform.
In addition, in most linking implementations, the link targets usually track
the
source of each link. Hence the end-user can request the target document to describe
the source of a particular link. However, this is not true for source documents;
thus an end-user cannot find out which target documents are linked to a particular
link source. Similarly the end-user cannot request to selectively break a particular
link target.
Furthermore, in some implementations, the target document is not updated
in certain instances. For example, consider the following scenario. First, a target
document is opened and registers with a source document, requesting a link with
the source document. Both the source and target documents are then closed. Subsequently,
the target document is opened. Sometime later, the source document is opened and
the linked content updated. In some implementations the target document may not
be notified of the change. In a separate example, consider the following. A source
document and a target document are opened. The target document registers with the
source document, requesting to be notified when the link content changes. The source
document is then closed without saving. Subsequently, the source document is reopened
and the linked content of the source document updated. Again, in some implementations,
the target document may not be notified of the change.
SUMMARY OF THE INVENTION
The above-stated problems and related problems of the prior art are solved with
the principles of the present invention, method and apparatus for communicating
information in a distributed data processing system. The system uses a standard
messaging protocol for objects and processes to communicate, thereby alleviating
the need for a shared file system. The system includes a first application and
an object in a second application. The second application may be in one of an executing
state and a non-executing state. The object may be in one of a loaded state and
an unloaded state. The apparatus of the present invention includes an availability
server that, in response to a message-intended for the object that is sent from
the first application to the availability server, when the second application is
in the non-executing state and a surrogate object associated with the object is
in a non-loaded state, loads and initializes the surrogate object, and forwards
the message to the surrogate object. The surrogate object, upon receiving the message
from said availability server, processes the message and responds to the first
application accordingly.
Advantageously, the availability server of the present invention
provides the first application with access to the object within the second application,
regardless of whether the second application is executing or not and regardless
of whether the object is loaded or unloaded, such that the first application can
communicate with the object, for example, to read information stored in the object
or to change the state of the object. The availability server also provides a mechanism
for storing auxiliary data associated with the object that may be updated by the
first application when the second application is not executing.
In another aspect of the present invention, a tracking mechanism is provided
that
identifies the sources and targets of each link, thus providing end-users with
the ability to break existing links and/or providing end-users with information
about the link sources and link targets in a particular document and/or in a particular
part of a document.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a pictorial representation of distributed data communication system;
FIG. 2(A) is a functional block diagram of a computer processing system of FIG.
1; FIG. 2(B) is a pictorial representation of the layers of software that may be
executed on the computer processing system of FIG. 2;
FIG. 3 is a pictorial representation of an OpenDoc document A including a part
X, a part Y, a LinkSpec object, and a LinkService object according to the present invention;
FIG. 4 is a pictorial representation of information stored by the LinkSource
object and the LinkService object according to the present invention;
FIG. 5 is a pictorial representation of information stored by the Availability
Server according to the present invention;
FIG. 6 is a pictorial representation of the operation of the LinkService object
and the Availability Server of the present invention when a document is created;
FIG. 7 is a pictorial representation of the operation of the source part in
creating and externalizing the LinkSpec object of the present invention;
FIG. 8 is a pictorial representation of the operation of the target part in
copying the externalized LinkSpec object according to the present invention;
FIG. 9 is a pictorial representation of the operation of the target part in
establishing a link with the source content identified by the copied LinkSpec object
according to the present invention;
FIG. 10 is a pictorial representation of the operation of the source part in
creating a LinkSource object, registering the newly created LinkSource object with
the Availability Server, and returning the relevant information to the target part;
FIG. 11 is a pictorial representation of the operation of the source part and
the LinkSource object in updating linked content (steps 1 and 2),
and notifying the target part of the update(steps 3 and 4); FIG.
11 (steps 5 and 6) represents operation of the target part and LinkTarget
object in forwarding messages from the LinkTarget object to the LinkSource object
(or a LinkSourceSurrogate object) via the Availability Server according to the
present invention;
FIG. 12 is a pictorial representation of the operation of the Availability Server
in routing messages from the LinkTarget object to the LinkSource object or the
LinkSourceSurrogate object according to the present invention;
FIG. 13 is a pictorial representation of the operation of the Linktarget object,
the Availability Server and the LinkSource object (or the LinkSourceSurrogate object)
when a target part registers to be notified of changes to particular link content
within a part of a document according to the present invention;
FIGS. 14-17 are pictorial representations of the operation of the LinkService
object and the Availability Server when an existing document is opened according
to the present invention.
DETAILED DESCRIPTION OF THE PRESENT INVENTION
A distributed data processing system includes at least two computer systems and
means for communicating data between the two computer systems. Distributed data
processing systems can be local area networks (LANs), which provide direct communication
among the computer systems on the user's local premises, or wide area networks
(WANS), which provide communication services to a geographic area larger than that
served by a LAN. Typically, WANs operate at a slower speed than LANs. Moreover,
at the physical level, distributed data processing systems can run over various
network interfaces, such as Token Ring, Ethernet, PC Network, Fiber Distribution
Data Interface (FDDI), X.25, and Integrated Services Digital Network (ISDN).
An example of a distributed data processing system is shown in FIG. 1, wherein
three computer systems A
1,B
1, and C
1 are networked to a server
system S
1 in a token-ring configuration. The physical communication links
between the computer systems A
1, B
1, C
1 and between the computer
systems A
1,C
1 and the server S
1 may be a T
1 link, a
telephone line, a fiber optic link or other suitable means. In addition, the system
includes three computer systems A
2,B
2,C
2 that are networked
to a server system S
2 in a star configuration. The physical communication
links between the computer systems A
2,B
2,C
2 and the server
S
2 may be a T
1 link, a telephone line, a fiber optic link or other
suitable means. In addition, the server S
1 communicates with the server
S
2 over a communication link. The communication link may be a T
1
link, a telephone line, a fiber-optic link, a microwave link, an Internet connection,
or other suitable means for communicating data between the servers S
1 and
S
2. The servers S
1 and S
2 are typically more robust in terms
of processing power, data storage capacity, and memory than the associated computer
systems, and may be used to share application software and data among the computer
systems. Moreover, the servers S
1 and S
2 typically provide security
to control access to the associated computer systems.
In a distributed processing system, the computer systems communicate data with
one another via a communication protocol. Some of the common communication protocols
used today include Open Systems Interconnect (OSI), Transmission Control Protocol/Internet
Protocol (TCP/IP) and System Network Protocol (SNA). When utilizing TCP/IP for
example, the computer systems communicate packets of data to one another over communication
links as described above. Each packet includes a source identifier that identifies
the source of the data and a target identifier that identifies the target of the
data. For example, if the computer system B
1 is to send one or more data
packets to computer system C
2, each data packet includes a source identifier
that identifies the source of the data as computer system B
1 and a target
identifier that identifies the target of the data as computer system C
2.
The data packets are routed throughout the system according to the target identifier.
Upon receiving the data packet, the target system, in this case C
2, typically
sends a reply to the source utilizing the source identifier encoded in the received
data packet. The reply includes a source identifier that identifies the source
of the data as computer system C
2 and a target identifier that identifies
the target of the data as computer system B
1. The reply is routed throughout
the system according to the target identifier. A more detailed description of TCP/IP
may be found in D. Corner, "Internetworking with TCP/IP: principles, protocols,
and architecture", Prentice-Hall, 1988, herein incorporated by reference in its
entirety. A more detailed description of OSI may be found in Marchall T. Rose,
"The Open Book: A Practical Perspective on OSI", Prentice-Hall, 1990, herein incorporated
by reference in its entirety. And a more detailed description of SNA may be found
in James Martin, "SNA: IBM's Networking Solution", Prentice-Hall, 1987, herein
incorporated by reference in its entirety.
The software that programs the computer systems to communicate with one another
preferably is designed and implemented as a set of smaller pieces. One technique
to decompose the software into the set of smaller pieces that has gained substantial
popularity is the object-oriented programming technique wherein the software is
partitioned into a set of logical objects that interact with one another to achieve
the required system functionality. Each logical object is self-contained and provides
a well-defined interface that permits the orderly interaction between the object
and any other objects in the system. A programming language that supports the object-oriented
programming techniques is C++. A more detailed description of the C++ language
may be found in Stanley B. Lippman, "C++ Primer", Addison-Wesley, 1991 (2nd Edition)
and in M. A. Ellis et al., "The Annotated C++ Reference Manual", Addison-Wesley,
1990, herein incorporated by reference in their entirety. Environments suitable
for programming in C++ include for example IBM's Visual Age C++ and Microsoft's
Visual C++. These environments typically are designed to build software that is
compatible with a specific operating system platform, such as IBM's OS/
2,
Microsoft's Windows, or a UNIX-based operating system platform such as Microsoft's
Windows NT.
In addition, to alleviate the complexity of object-oriented programming in distributed
environments, computer scientists have designed architectures that make the distribution
of the objects of system transparent to the programmer. Such an architecture provides
the programmer with the capability of making location-transparent distributed method
calls, meaning that an object reference can be either to a local object in the
source process, or to a remote object in another process. An example of such an
object architecture is the Common Object Request Broker Architecture (CORBA), described
in detail in "The Common Object Request Broker: Architecture and Specification",
by Digital Equipment Corp. et. al, OMG Document No. 91.12.1, Rev. 1.1, 1992, herein
incorporated by reference in its entirety. An implementation of such an object
architecture is available in IBM's System Object Model (SOM), which complies with
the specifications of the CORBA architecture. Support for SOM is included in IBM's
Visual Age C++ product. A description of SOM may be found in "SOMobjects Developer
Toolkit User's Guide", Version 2.1, October 1994.
A conventional computer system as shown in FIG. 2(A) embodies the present invention.
The computer system includes a processor
10 coupled to memory
12
via a high-speed processor bus
14 and memory interface
16. The memory
212 may include system dynamic memory, cache memory, and/or non-volatile
memory. The memory interface
16 performs functions such as address decoding
and bus control such that the processor
10 can read instructions and data
from the memory
12 and write data to the memory
12. The memory interface
16 may also perform functions such as dynamic memory refresh. A local bus
interface
18 bridges the processor bus
14 to a second bus
20.
The local bus interface
18 converts data transmitted over the processor
bus
14 to the format of the second bus
20 and converts data transmitted
over the second bus
20 to the format of the processor bus
14.
In addition, the computer system includes a display interface
22 for driving
a display
24. The display interface
22 typically includes a graphics
controller and associated memory. The computer system also includes an I/O interface
26 that provides an interface to one or more data storage devices and an
input device
28 such as a keyboard or a pointing device. The data storage
devices may include a fixed hard disk drive
30, a CD-ROM drive
32,
a floppy drive
34, a tape back-up drive (not shown), an optical drive (not
shown), or other suitable devices.
The computer system also includes a communication adapter
36 that provides
a physical interface to the network. The communication adapter
36 can implement
various network interfaces such as Token Ring, Ethernet, PC Network, Fiber Distribution
Data Interface (FDDI), X.25, and Integrated Services Digital Network (ISDN).
As shown in FIG. 2(B), the software
40 that controls each of the computer
systems in a distributed system to communicate with one another preferably includes
an operating system layer
42, a low-level communication protocol layer
44,
a high-level object communication protocol layer
46, and an object-oriented-application
layer
48. Each of the layers
42,
44,
46,
48 can
be stored on one or more floppy disks or CD-ROMs and transferred to the fixed disk
drive via the floppy disk drive
34 or CD-ROM drive
32, respectively.
Moreover, two or more of the layers
42,
44,
46,
48 may
be integrated into a common software package that is stored on one or more floppy
disks or CD-ROMS. In this case, the software package is transferred to the disk
drive via the floppy disk drive
34 or CD-ROM drive
32, respectively.
The software
40 is preferably read from the fixed disk drive
30 (in
the alternative, from the CD-ROM drive
32 or from the floppy disk drive
34) into memory for execution by the processor
10.
The operating system layer
42, when executed by the processor
10,
provides a direct interface to the hardware devices of the computer system, and
more specifically to the communication adapter
36, thus managing the flow
of data between the computer system and other computer systems and providing for
user interaction. The object-oriented-application layer
48 includes a plurality
of objects that, when executed by the processor
10, send and receive data
from other objects or applications (which may be executing on a remote computer
processing system). The high-level object communication protocol layer
46,
for example IBM's SOM, and the low-level communication protocol layer
44,
for example a TCP/IP layer such as IBM's TCP/IP version 2.0, formats the data to
be sent from one object to another object and routes the data over the network
guaranteeing that the data is properly delivered to the appropriate object and
that the correct method of that object is invoked.
To illustrate the functions performed by the various layers of the software
40
in a distributed environment, consider the operation of two remote computer systems
A and B when data generated by a client object that is part of an object-oriented-application
layer
48 executing on computer system A is sent to a server object which
is part of an object-oriented-application layer
48 that is executing on
a computer system B. First, the high-level object communication protocol layer
46 executing on computer system A determines the location of the server
object, and then sends a message to the low-level communication protocol layer
44 to send the data generated by the client object to the server object.
The high-level object communication protocol layer
46 marshals the data
into a transmission format that identifies the object that is to receive the data
and that identifies the method to be invoked by the object to receive the data.
The low-level communication layer protocol layer further formats the data such
that is complies with a standard protocol, for example TCP/IP, and delivers the
formatted data to the communication adapter
36 of the computer system A.
The communication adapter
36 of the computer system A then transfers the
formatted data to the communication adapter
36 of the computer system B
over the network. This transfer may be direct, or indirect via intermediate nodes
within the network.
Upon receipt, the communication adapter
36 of the computer system B delivers
the received data to the low-level communication protocol layer
44 of the
computer system B. The low-level communication protocol layer
44 executing
on computer system B reformats the received data by stripping away, for instance,
any routing information and delivers the reformatted data to the high-level object
communication protocol layer
46 executing on computer system B. The high-level
object communication protocol layer
46 de-marshalls the data and determines
which object and which object method executing on computer system B is the intended
recipient of the data, and reformats the data into a format expected by that object.
The high level object communication protocol layer
46 then invokes the appropriate
method, passing it the reformatted data. This mechanism can also be used to implement
a peer-to-peer environment by making each application operate independently as
both as client and a server.
In addition, it has become apparent that objects work efficiently together when
objects share a common interface architecture. Moreover, such a common interface
architecture allows the objects to interact with one another independent of the
operating system platform for which the objects were designed. OpenDoc, which is
currently being developed by IBM, Apple and Wordperfect, is an example of such
a common interface architecture. OpenDoc is an architectural framework for applications
for preparing, editing, and viewing compound documents. In OpenDoc, a compound
document consists of one or more parts. The parts may contain data as diverse as
navigable movies, sounds, animation, and data bases information, as well as traditional
spreadsheets, graphics, and text. In general, users manipulate and display the
parts using application components called part editors, part viewers and services.
A more detailed description of OpenDoc parts and features may be found in the "OpenDoc
Programmer's Guide", Apple Computer Corp., Preliminary Draft, November 1994, and
K. Piersol, "A Close-Up of OpenDoc", AIXpert, June 1994, available at http://www.austin.ibm.com/developer/aix/library/aixpert/june
94/aixpert
—june
94—closeup.html,
herein incorporated by reference in their entirety.
In a distributed environment, the OpenDoc framework may be viewed as a portion
of the object-oriented application layer
48 that is executed on the computer
systems as illustrated in FIG. 2(B). Importantly, the parts that make up the documents
in OpenDoc are represented by objects within the object-oriented application layer
48. For simplicity, the present invention as described below is embodied
as part of an OpenDoc application layer that includes one or more parts, wherein
communication among the computer systems occurs between objects that comply with
the CORBA standards mentioned above. Preferably, the objects of the present invention
are created in a C++/CORBA environment, for example IBM's Visual Age C++(with SOM
support). Moreover, the software controlling the computer systems of the present
invention preferably include a CORBA compliant high-level object communication
protocol layer
46, for example IBM's SOM, and a TCP/IP compliant low-level
communication protocol layer
44, for example IBM's TCP/IP Version 2.0.
Each OpenDoc part contains content elements. Depending on the type of part and
by the selections made by an end-user, the content elements may be characters,
spreadsheet cells, drawing elements, etc., or aggregates, such as paragraphs, one
or more rows of spreadsheet cells, figures, etc.
According to the present invention, a LinkSpec object, a LinkSource object,
a LinkTarget object, a LinkService object and an Availability Server are used to
link data between a source part and one or more target parts. Any part can potentially
play the role of a source part and a target part, and contain both LinkSource objects
and Linktarget objects. The source part and the target part may be components of
an OpenDoc document executing on a single computer system, may be components of
multiple OpenDoc documents executing on a single computer system, or may be components
of multiple OpenDoc documents executing on separate computer systems.
The LinkSpec object is created by the source part. It represents the capability
of establishing a link to some particular content element in the source part. The
source part provides the Linkspec object with a content specifier that identifies
the linked content element. The content specifier will be used later by the source
part to locate the content element for which a link is requested. As illustrated
in FIG. 3, the Linkspec object
100 contains:
- i) a pointer to the source part, labeled "Part Ref";
- ii) a pointer to the LinkService object associated with the source document,
labeled "Document Ref"; and
- iii) the content specifier, labeled "Cont. Specifier".
The LinkSource object is created by a source part when a target asks the source
to create a link to the content element identified by a particular LinkSpec object.
The LinkSource object resides in the source part. There is potentially more than
one LinkSource object in the source part. As shown in FIG. 4, each LinkSource object
200 contains:
- (i) a Content object 210, which stores a copy of the content
element being linked;
- (ii) a linkID unique to the particular LinkSource object;
- (iii) a pointer to the Content object 210;
- (iv) a table of targets including entries for each registered and tracked
target; each entry corresponding to a registered target or an open tracked target
includes a pointer to the LinkTarget object, a connection ID (as described below
in more detail), and a description of the target; the description includes the
host name and document file name of the target and information related to the target,
for example, a description of how the target is using the linked content;
- (v) a changeID that uniquely identifies a particular version of the
content object 210; and
- (vi) a description of the link content in the source document; the description
includes the host name and document file name of the source document and information
related to the source content.
Whenever the source part wants to update the linked content, the source
part first asks the LinkSource object for a lock on the Content object. Once the
source part obtains this lock, the source part then updates the Content object.
Once the source part is done updating the Content object, the source part provides
a new ChangeId to the LinkSource object, which then stores the ChangeID and frees
the lock on Content object. The source part can break all links by destroying the
LinkSource object. Individual links can also be broken as explained below.
The LinkTarget object is created when a target part requests a link to the content
element specified by a particular LinkSpec object. The LinkTarget object resides
in the target document. There is potentially more than one LinkTarget object in
the target part. The target part can register with one or more LinkTarget objects.
If it is registered, the target part will receive an update message whenever the
content element of the particular link associated with a registered LinkTarget
object is updated. This message will be generated after the source part has updated
the Content object at the source of the link and released the lock on that object.
A target part can ask the LinkTarget for the most recent ChangeId associated with
this link, and can request a lock on the Content object. If it obtains the lock,
it can read the content element of the link. When it is finished reading the content
element, it must release the lock. If it is registered, the target part can ask
to unregister.
As shown in FIG. 10, the Linktarget object
300 contains:
- i) the name of the Availability Server serving the LinkSource object,
for example myhostAS as shown; and
- ii) the LinkID, for example 10 as shown;
- iii) a description of the target part (not shown); the description includes
the host name and document file name of the target and information related to the target.
The name of the Availability Server can be used to locate the Availability Server
with a CORBA compliant naming service. The located Availability Server and the
LinkID can be used to locate and access the LinkSource object whether the source
document is open or not.
The LinkService object is used to help establish links across documents, and
to keep track of the LinkSource objects and LinkTarget objects within a document.
There is one LinkService object for each document. As shown in FIG.
4, the
information retained in the LinkService object
400 includes:
- i) the file location of the document, for example "myhost:e:DOCS\A"
as shown;
- ii) the DocumentId (obtained from the Availability Server when the document
was created as discussed below), for example 23 as shown;
- iii) the name of the Availability Server this document is registered
with, for example "myhostAS" as shown; the LinkService object 400 and LinkTarget
object 300 can use this name to locate the Availability Server using a naming
service such as described in the SOMobjects Developer Toolkit User's Guide, Version
2.1, October 1994, incorporated by reference above; and
- iv) a table of LinkSource objects 410 contained within the document
including, for each LinkSource object, a LinkID, a pointer to the LinkSource object
(if it is open), a storage unit identifier that identifies where the external representation
of the LinkSource object can be found; the information in the table of LinkSource
objects 410 preferably also includes an externalized reference to the part
in which each particular LinkSource object resides; and
- v) a table of Linktarget objects 420 contained within the document
including, for each LinkTarget object, a pointer to the LinkTarget object (if it
is open), a storage unit identifier that identifies where the external representation
of the LinkTarget object can be found; the information in the table of LinkTarget
objects 420 preferably also includes an externalized reference to the part
in which each particular LinkTarget object resides.
The Availability Server is used to provide access to the LinkSource object
200,
and the content element therein, when the document in which the LinkSource object
200 resides is not open. The Availability Server does this by creating a
LinkSourceSurrogate object that is initialized from the persistent state of the
LinkSource object that resides in the document, and from the auxiliary state of
the LinkSource object that resides in the Availability Server. Preferably, there
is one Availability Server per machine running OpenDoc. Thus, file sharing across
the network is not necessary for the Availability Server to read this persistent
state. Usually a LinkSourceSurrogate will only exist if a document in which the
LinkSource resides is closed. However a LinkSource object in the document and a
LinkSourceSurrogate in the Availability Server may briefly coexist for the reasons
described below.
As shown in FIG. 5, the Availability Server maintains the following information:
- i) a table of documents 510 registered with the Availability
Server 500 including, for each document, the location of the document and
the LinkIds of LinkSource objects in that document (not shown); preferably, the
location of the document is specified by the host machine name and an absolute
path name; additionally, if the document is currently open, the Availability Server
maintains a pointer to the document's LinkService object;
- ii) a table of LinkSource objects 520 registered with the Availability
Server 500 including, for each LinkSource object, the DocumentId of the
document in which this LinkSource object resides, the LinkID, the status of the
LinkSource object, a pointer to the LinkSource object if the LinkSource object
is currently open, a pointer to the LinkSourceSurrogate object associated with
the LinkSource object if the LinkSourceSurrogate object is open, and a content
lock flag (not shown) that indicates whether the Content object of the LinkSource
object is locked or not; the status of the LinkSource object is preferably broken
down into four categories: InDoc (meaning that the document is open and the link
source object is also open), InAS (meaning that the document is closed, and a LinkSourceSurrogate
for this link has been created in the Availability Server), InBoth (meaning that
a LinkSource object for this link exists in the document and a LinkSourceSurrogate
exists in the Availability Server), and Unloaded (meaning that neither a Linksource
object nor the LinkSourceSurrogate object exist in the document).
- iii) a table of auxiliary state (not shown) for each LinkSource object
registered with the Availability Server; the auxiliary state lists all of the remote
LinkTarget objects that are registered with or tracked by the LinkSource object;
the auxiliary state of the LinkSource object represents that part of the state
of the LinkSource object which can be changed even while the document is closed;
the remaining state of the LinkSource object cannot be changed when the document
is closed.
In addition, additional interfaces are provided by which the source part can:
- (i) request that the LinkSource object provide a description pertaining
to each target to which the LinkSource object is linked; each target description
includes the host name and document name in which the target resides; each target
description also preferably includes a description of the target part (supplied
by the target part);
- (ii) request that the LinkSource object disconnect a particular target
from being linked to this content element (break a particular link, not all links); and
- (iii) set the source part description; this description will be given
to target parts of the link if they request information about the source part.
In addition, additional interfaces are provided by which the target part can:
- (i) request that the source part provide a description of the source
part; this description includes the host name and document name in which the source
resides; this description also preferably includes a description of the source
part; and
- (ii) set the target part description; this description will be given
to the source part if it requests information about this target part of the link.
Additionally, an interface can be provided wherein any part can request
the LinkService object to:
- (i) list all LinkSource objects and/or LinkTarget objects in the document; and
- (ii) list all the LinkSource objects and/or LinkTarget objects in a
particular part that resides in the document.
An OpenDoc document can be either open or closed. When a document is open, the
parts of the document and the associated content element may be loaded into memory
and the parts executed as one or more processes by the processor. When a document
is closed the parts of the document are not executing and the content elements
of the parts are stored in a file (the document file) in non-volatile memory, for
example, on the hard disk drive associated with the computer system.
When a document A is created on a computer system running an OpenDoc application,
a LinkService object
400 associated with the document A is created within
the document. The Linkservice object
400 registers with the Availability
Server
500 that preferably resides on the same computer system. In the alternative,
the Availability Server
500 may be a process that is executing on a remote
computer system. The Availability Server
500 generates a unique documentID
for document A, for example the number
23 as shown in FIG. 6, and generates
a new entry in the table of documents
510 for document A. As shown in FIG.
6, the entry includes the documentID, the location of the document file, and a
pointer to the LinkService object. The pointer may be set to "empty" to indicate
that the document is closed. The Availability Server
500 then returns the
documentID to the Linkservice object
400. The LinkService object
400
preferably stores the documentID and a pointer to the Availability Server
500.
Links are established between content elements in different parts. FIGS. 7-10
illustrate the operation of the LinkSpec object
100, the LinkSource object
200, the LinkTarget object
300, the LinkService object
400
and the Availability Server
500 in establishing a link between a source
part X of a document A and a target part XX of a document B.
As shown in FIG. 7, the first step in establishing the link is to create a LinkSpec
object
100 that identifies the content element of the source part X of the
document A that will be the source of the link. The LinkSpec object
100
may be created, for example, by the source part X when source part X receives a
request to copy selected content element of the part X to the clipboard or to the
drag-and-drop. In FIG. 7 for example, the user has selected a cell C
2 of
a spreadsheet as the content to be linked. The Linkspec object
100 contains
a content specifier that identifies the particular content element of the link.
The LinkSpec object
100 also contains the pointer to the part, as well as
a pointer to source document's LinkService object
400 as shown.
After the Linkspec object
100 has been created, the source part X calls
a WriteLinkSpec method of the LinkSpec object
100. The WriteLinkSpec method
converts the Linkspec object to a platform independent form and copies it to storage
that is made accessible to other documents. The platform independent form may utilize,
for example, a Bento storage unit and CORBA compliant externalized pointers, such
as the externalized reference to a proxy to a stringID discussed in section
6-
24
of the SOMobjects Developer Toolkit User's Guide, Version 2.1, October 1994, incorporated
by reference above. As shown in FIG. 7, the storage is a clipboard. In the alternative,
the storage may be a drag-and-drop buffer, a shared memory region, or a distributed repository.
After the Linkspec object
100 is converted and copied to storage, the
linking operation turns to the target part XX of a document B as illustrated in
FIG. 8. When the target part XX receives a request to establish a link with the
content element specified by the externalized Linkspec object
100-
1,
which may be a user command such as a PASTE AS LINK or a drag and drop, the target
part XX creates an in-memory LinkSpec object
100-
2 and calls the
ReadLinkSpec method, passing it a pointer to the externalized storage. The ReadLinkSpec
method initializes the state of the in-memory LinkSpec object
100-
2
to the state of the externalized LinkSpec object
100-
1, thereby replicating
the original LinkSpec object
100 in the target document B.
As shown in FIG. 9, the target part XX then requests that a link be created to
the source content element specified by the LinkSpec object
100-
2
by calling method "AcquireLink" on the LinkService object
400 in the target
document B, passing a pointer to the LinkSpec object
100-
2. In response
to this request, a LinkTarget object
300 is created and initialized in the
target document B. The pointer to the source document's LinkService object is then
retrieved from the LinkSpec object
100-
2, and the method "EstablishLink"
is invoked on the LinkService object
400 of the source document A asking
that a link be created. This message has several parameters, including the pointer
to the source part X, a pointer to the target part YY, and the content specifier
identifying the content element of the link.
When the Linkservice object
400 of the source document A receives this
message, the LinkService object
400 responds by invoking the method "CreateLink"
on the source part X asking that it create a link for content element specified
by the given content specifier, for example C
2 as shown in FIG. 10. If a
LinkSource object already exists for the given content specifier (not shown), the
source part X returns a pointer to it. If a LinkSource object does not exist for
the given content specifier (as shown), the source part X responds by creating
a LinkSource object
200, and then returns a pointer to this object.
In the case where the source part X creates a new LinkSource object
200,
the LinkService object
400 of the source document A invokes the "RegisterLink"
method on the Availability Server
500, passing a pointer to the new LinkSource
object and the documentID for the document, for example 23 as shown in FIG. 10,
to thereby register the new Linksource object
200. The "RegisterLink" method
generates a new LinkID (unique to the Availability Server), for example 10 as shown,
and associates the new LinkID with the given documentID. The pair <Availability
Server Name, LinkID> henceforth serves as a persistent reference to the LinkSource
object. The RegisterLink method then writes the DocumentID, the LinkID, and the
pointer to the new Linksource object
200 as an entry in the Table of Linksource
objects stored in the Availability Server
500, and sets the status field
of the entry as "INDOC". The Availability Server
500 then returns the newly
generated LinkID to the LinkService object
400 of the document A. The LinkService
object
400, in turn, adds a ne
