Browse Prior Art Database

Interprocess Communication

IP.com Disclosure Number: IPCOM000044660D
Original Publication Date: 1984-Dec-01
Included in the Prior Art Database: 2005-Feb-06
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Newman, PS: AUTHOR

Abstract

This invention relates to a method for operating a computing apparatus to unify inter-object communication. Most methods of inter-object communication classify objects such that each can be addressed according to only one convention. For example, more traditional methods distinguish between objects addressable as subroutines and objects addressable as functions. Also, methods allowing concurrent object execution usually provide for synchronous (subroutine or function) or asynchronous (full message transmission without blocking) addressing of those objects, but not both. Finally, differences between procedure and data abstraction usually imply differences in addressing. This method views programmed objects as one of two kinds. Each kind may be addressed by a wide variety of conventions, depending on accessing needs.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Interprocess Communication

This invention relates to a method for operating a computing apparatus to unify inter-object communication. Most methods of inter-object communication classify objects such that each can be addressed according to only one convention. For example, more traditional methods distinguish between objects addressable as subroutines and objects addressable as functions. Also, methods allowing concurrent object execution usually provide for synchronous (subroutine or function) or asynchronous (full message transmission without blocking) addressing of those objects, but not both. Finally, differences between procedure and data abstraction usually imply differences in addressing. This method views programmed objects as one of two kinds. Each kind may be addressed by a wide variety of conventions, depending on accessing needs. The first kind of object - the process - is a continuously executing programming unit with a single associated queue. A process receives messages from its queue selectively, based on message type and other parameters, and need not respond to messages in the order accepted. A given process may be addressed, depending on accessing object needs, using full message transmission (nonblocking SEND followed by an optional RECEIVE at a later time), REQUEST (a shorthand form combining send with an immediately following receive), single-line request (similar to traditional subroutine call), and functional request (similar to traditional function call). Messages in both directions are typed, leading to rather expressive communication. For example, REQUEST sends a message of one type and makes different provisions for subsequent actions, depending on the response message type. Single-line requests can be used as long as one response message type is identified as "expected"; other responses are treated as exceptions. Functional request forms can be used in cases where a single "expected" response message contains a single argument. A process is similar to a data abstraction in that (a) it responds to typed messages (like the operations of a data abstraction), (b) it is persistent, and (c) many processes may rest on the same definition. For example, a process may represent one instance of a stack abstraction. However, it captures much of the flavor of a procedure...