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.

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 A1,B1, and C1 are networked to a server system S1 in a token-ring configuration. The physical communication links between the computer systems A1, B1, C1 and between the computer systems A1,C1 and the server S1 may be a T1 link, a telephone line, a fiber optic link or other suitable means. In addition, the system includes three computer systems A2,B2,C2 that are networked to a server system S2 in a star configuration. The physical communication links between the computer systems A2,B2,C2 and the server S2 may be a T1 link, a telephone line, a fiber optic link or other suitable means. In addition, the server S1 communicates with the server S2 over a communication link. The communication link may be a T1 link, a telephone line, a fiber-optic link, a microwave link, an Internet connection, or other suitable means for communicating data between the servers S1 and S2. The servers S1 and S2 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 S1 and S2 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 B1 is to send one or more data packets to computer system C2, each data packet includes a source identifier that identifies the source of the data as computer system B1 and a target identifier that identifies the target of the data as computer system C2. The data packets are routed throughout the system according to the target identifier. Upon receiving the data packet, the target system, in this case C2, 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 C2 and a target identifier that identifies the target of the data as computer system B1. 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/june94/aixpert_—june94_—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:

• Inventors
  Huynh, Tien; Strom, Robert Evan; Ukelson, Michal Z.; Yellin, Daniel M.;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  Dec-6-2005
• Current US Classes:
  719/315
  719/332
• Application #
  515778
• International Classes
  G06F 009/44
• Field of Search
  395/683 709/315 709/316 709/107 709/108 719/315 719/316 719/332 719/331 719/310 718/107 718/108 717/165 717/164 717/162 715/500
• Examiner
  Lao; Sue
• Agent
  Buchenhorner; Michael J., August; Casey P.
• US Patent References:
  5175848
  5185885
  5303379
  5404525
  5446842
  5608909
  5664186
  5758351
  5802367
  5896533
  5913033
  6104963
  6223344