Asynchronous transport optimizing observer-pattern-like...

Details Asynchronous transport optimizing observer-pattern-like... Asynchronous transport optimizing observer-pattern-like...

1996-07-03

2001-08-14

Banankhah, Majid (Department: 2151)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C709S241000, C709S241000

Reexamination Certificate

active

06275871

ABSTRACT:

BACKGROUND OF THE INVENTION
The present application is directed to application programmers interfaces (API) for programmer applications for communications systems.
As set forth in U.S. Pat. No. 5,499,365, full incorporated herein by reference, object oriented programming systems and processes, also referred to as “object oriented computing environments,” have been the subject of much investigation and interest. As is well known to those having skill in the art, object oriented programming systems are composed of a large number of “objects.” An object is a data structure, also referred to as a “frame,” and a set of operations or functions, also referred to as “methods,” that can access that data structure. The frame may have “slots,” each of which contains an “attribute” of the data in the slot. The attribute may be a primitive (such as an integer or string) or an object reference which is a pointer to another object. Objects having identical data structures and common behavior can be grouped together into, and collectively identified as a “class.”
Each defined class of objects will usually be manifested in a number of “instances”. Each instance contains the particular data structure for a particular example of the object. In an object oriented computing environment, the data is processed by requesting an object to perform one of its methods by sending the object a “message”. The receiving object responds to the message by choosing the method that implements the message name, executing this method on the named instance, and returning control to the calling high level routine along with the results of the method. The relationships between classes, objects and instances traditionally have been established during “build time” or generation of the object oriented computing environment, i.e., prior to “run time” or execution of the object oriented computing environment.
In addition to the relationships between classes, objects and instances identified above, inheritance relationships also exist between two or more classes such that a first class may be considered a “parent” of a second class and the second class may be considered a “child” of the first class. In other words, the first class is an ancestor of the second class and the second class is a descendant of the first class, such that the second class (i.e., the descendant) is said to inherit from the first class (i.e., the ancestor). The data structure of the child class includes all of the attributes of the parent class.
Object oriented systems have heretofore recognized “versions” of objects. A version of an object is the same data as the object at a different point in time. For example, an object which relates to a “work in progress”, is a separate version of the same object data which relates to a completed and approved work. Many applications also require historical records of data as it existed at various points in time. Thus, different versions of an object are required.
Two articles providing further general background are E. W. Dijkstra,
The Structure of “THE” Multi programming System
, Communications of the ACM, Vol. 11, No. 5, May 1968, pp. 341-346, and C. A. R. Hoare,
Monitors: Operating Systems Structuring Concepts
, Communications of the ACM, Vol. 17, No. 10, October, 1974, pp. 549-557, both of which are incorporated herein by reference. The earlier article describes methods for synchronizing using primitives and explains the use of semaphores while the latter article develops Brinch-Hansen's concept of a monitor as a method of structuring an operating system. In particular, the Hoare article introduces a form of synchronization for processes and describes a possible method of implementation in terms of semaphores and gives a proof rule as well as illustrative examples.
As set forth in the Hoare article, a primary aim of an operating system is to share a computer installation among many programs making unpredictable demands upon its resources. A primary task of the designer is, therefore, to design a resource allocation with scheduling algorithms for resources of various kinds (for example, main store, drum store, magnetic tape handlers, consoles). In order to simplify this task, the programmer tries to construct separate schedulers for each class of resources. Each scheduler then consists of a certain amount of local administrative data, together with some procedures and functions which are called by programs wishing to acquire and release resources. Such a collection of associated data and procedures is known as a monitor.
The adaptive communication environment (ACE) is an object-oriented type of network programming system developed by Douglas C. Schmidt, an Assistant Professor with the Department of Computer Science, School of Engineering and Applied Science, Washington University. ACE encapsulates user level units and WIN32 (Windows NT and Windows 95) OS mechanisms via type-secured, efficient and object-oriented interfaces:
IPC mechanisms—Internet-domain and UNIX-domain sockets, TLI, Named pipes (for UNIX and Win 32) and STREAM pipes;
Event multiplexing—via select( ) and poll( ) on UNIX and WaitForMultipleObjects on Win 32;
Solaris threads, POSIX Pthreads, and Win 32 threads;
Explicit dynamic linking facilities—e.g., dlopen/dlsym/dlclose on UNIX and LoadLibrary/GetProc on Win 32;
Memory-mapped files;
System VIPC—shared memory, semaphores, message queues; and
Sun RPC (GNU rpc++).
In addition, ACE contains a number of higher-level class categories and network programming frameworks to integrate and enhance the lower-level C++ wrappers. The higher-level components in ACE support the dynamic configuration of concurrent network daemons composed of application services. ACE is currently being used in a number of commercial products including ATM signaling software products, PBX monitoring applications, network management and general gateway communication for mobile communications systems and enterprise-wide distributed medical systems. A wealth of information and documentation regarding ACE is available on the worldwide web at the following universal resource locator:
http://www.cs.wustl.edu/. . . schmidt/ACE-overview.html.
The following abbreviations are or may be utilized in this application:
Thread—a parallel execution unit within a process. A monitor synchronizes, by forced sequentialization, the parallel access of several simultaneously running Threads, which all call up functions of one object that are protected through a monitor.
Synchronizations-Primitive—a means of the operating system for reciprocal justification of parallel activities.
Semaphore—a Synchronizations-Primitive for parallel activities.
Mutex—a special Synchronizations-Primitive for parallel activities, for mutual exclusion purposes, it includes a critical code range.
Condition Queue—an event waiting queue for parallel activities referring to a certain condition.
Gate Lock—a mutex of the monitor for each entry-function, for protection of an object, for allowing only one parallel activity at a time to use an Entry-Routine of the object.
Long Term Scheduling—longtime delay of one parallel activity within a condition queue or event waiting queue for parallel activities.
Broker—a distributor.
In addition, the following acronyms are or may be used herein:
AFM
A
synchronous
F
unction
M
anager
SESAM
S
ervice &
E
vent
S
ynchronous
A
synchronous
M
anager
PAL
P
rogrammable
A
rea
L
ogic
API
A
pplication
P
rogrammers
I
nterface
IDL
I
nterface
D
efinition
L
anguage
ATOMIC
A
synchron
T
ransport
O
ptimizing observer-pattern-like system supporting several
M
odes (client/server—push/pull) for an IDL-less
C
ommunication subsystem, described herein
XDR
E
xternal
D
ata
R
epresentation
I/O
I
nput/
O
utput
IPC
I
nter
P
rocess
C
ommunication
CSA
C
ommon
S
oftware
A
rchitecture (a Siemens AG computing system convention)
SW
S
oft
w
are
SUMMARY OF THE INVENTION
The present invention provides a location and protocol transparent object oriented communication system that implicitly encodes and decodes transfer

Affiliated with

Also associated with

Rating

Asynchronous transport optimizing observer-pattern-like... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Asynchronous transport optimizing observer-pattern-like..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Asynchronous transport optimizing observer-pattern-like... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2538611