Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-03-12
2002-05-28
Gossage, Glenn (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S057000
Reexamination Certificate
active
06397346
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of multi-threaded, object-oriented computer environments.
2. Background
In multi-threaded, object-oriented computer environments of the prior art, problems arise when, as an object server is shutting down, a new object server is being started as a response to an invocation by a client. The daemon process responsible for starting a new server assumes that the old server shuts down instantaneously. In actuality certain cleanup processes, such as the release of database locks, may still be in progress when a new object server is started. These cleanup processes can cause the new object server to abort startup. Thus, an undesired race condition exists between the shutdown of old object servers and the startup of new object servers.
Networked Object Environment
In the networked object environment, an object server, also referred to as a server process, is a multi-threaded process that controls access to, instantiation of, and deletion of, the methods, data, etc., embodied in the objects within its domain. Objects are self-contained, clearly defined, software modules that encapsulate procedures, such as business practices, and their data. Communicating with each other through carefully defined interfaces, objects allow complex solutions to be constructed similar to the manner in which computers are manufactured from standardized electronic components. Multiple levels of re-use and standardization are made possible, enabling engineers to produce modules, applications, and entire systems that are highly reusable and leveragable.
Networked object technology allows applications access to objects and their shared services anywhere in the network, substantially independent of where the application or object resides. Networked objects also permit individual objects to be updated without the risk of disrupting the application or business process it models, facilitating the graceful, incremental evolution of complex systems. For example, if a new component fails, the component's predecessor can be re-instated quickly and transparently.
An example of the networked object environment is the CORBA-compliant NEO product family from SunSoft™, which provides for sharing of objects across networks and differing computing platforms.
Consisting of over 600 software vendors, developers, and end user organizations, the Object Management Group (OMG) has developed and continues to develop standards for a common architecture supporting heterogeneous, distributed, object-oriented applications. The OMG Common Object Request Broker Architecture (CORBA) is designed to allow different object systems from multiple vendors to interact with each other on a network. The CORBA specification comprises the following four components:
i) An Object Request Broker (ORB) to manage objects in a networked environment;
ii) Interoperability for ORB-to-ORB communications;
iii) Common Object Services (CORBAservices); and
iv) Mappings for commonly used programming languages.
The Network Object Request Broker (ORB) is a CORBA-compliant network-based software system providing for the location and execution of objects through a standard interface protocol, enabling objects and programs to interact with each other across the network. The NEO ORB is implemented as one or more multi-threaded UNIX processes, providing scalable performance and availability as needed.
To promote heterogeneous object interoperability, the OMG has provided a portable source code reference implementation of the CORBA 2.0 Internet Inter-ORB Protocol to assist software vendors in testing and delivering OMG-compliant products. The Internet Inter-ORB Protocol (Internet IOP) provides a standardized way of connecting ORBs from different CORBA 2.0 compliant vendors, enabling them to communicate with each other. The current Internet IOP is based on TCP/IP protocols.
The OMG CORBAservices definition describes the basic operations required for building distributed systems with objects, such as naming, events, properties, lifecycle and relationship services.
For different object systems to interact, language independence is a concern. The Interface Definition Language (IDL) enables the separation of interface and implementation, allowing object implementation details to change without compromising the plug-and-play qualities of the object. The OMG IDL is a neutral interface definition of an object's operations, allowing the behavior of the object to be defined in IDL, but accommodating the automated transformation of the interface to the C, C++, Objective C, or Smalltalk languages.
A multi-threaded environment, such as that provided by UNIX, is typically used for supporting networked objects. Threads are subprocesses spawned off of larger processes for performing a certain function, e.g. performing a printing process, acting on a database object, etc. By supporting multiple threads, the system can serve many clients and processes simultaneously. This enables the sharing of objects and services on the network.
In the CORBA environment, an Object Request Broker Daemon process (ORBD) receives object requests, also referred to as method invocations, from the client processes registered to it. The ORB daemon then locates the object on the network, and acts as the interface between the client process and the networked object. In the NEO environment, the ORB daemon may activate a NEO object server to act as a further interface for the object which may be a standard NEO object or, in some instances, a legacy process encapsulated in a NEO shell to perform as a NEO object. The NEO object server acts to instantiate the object as is necessary to respond to the requests forwarded by the ORB daemon.
System Block Diagram
FIG. 1
is a block diagram of a CORBA-compliant networked object system. Multiple threads are represented by elements
100
-
103
, where threads
100
-
101
are threads spawned from a first client process, Client Process
1
, and threads
102
-
103
are threads spawned from a second client process, Client Process N. As indicated in
FIG. 1
, a single client process can spawn any number of threads. Each of threads
100
-
103
is linked to Object Request Broker Daemon (ORBD) process
104
. ORBD process
104
is in turn linked to a plurality of object servers represented by object server
105
and object server
107
. A second ORBD process, ORBD process
110
, is further linked to ORBD process
104
. ORBD process
110
could also be coupled to further object servers and/or client processes (not shown). Object server
105
is linked to object
106
. Object server
107
is linked to objects
108
and
109
.
ORBD process
104
receives object requests, such as method invocations in the form of locate requests, from client process threads
100
-
103
, and determines which object server is supporting the appropriate object. If the necessary server is not currently running, the server is activated and the object is instantiated. Information on the location of the object is returned in response to the locate request, and further requests between the thread and the object are directed by the location information. The same object can be similarly invoked by locate requests from other threads to establish interaction between the object and all applicable threads concurrently.
ORB daemon
110
may provide a gateway for the networked object environment over a large network such as the Internet and/or it may provide cross-platform interaction by providing a platform dependent interface to clients and object servers in its own domain, while providing a standardized interface to ORBD
104
.
Object servers
105
and
107
provide access to objects or object libraries, such as shown by objects
106
and
108
-
109
. Legacy objects, that is those objects comprising stand-alone applications and other objects not originally designed for the networked object environment, are provided with an IDL shell that forms an interface through which the object server can access the functions
Callsen Christian J.
Cavanaugh Ken M.
Beyer Weaver & Thomas LLP
Bonzo Bryce P.
Gossage Glenn
Sun Microsystems Inc.
LandOfFree
Method and apparatus for controlling server activation in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for controlling server activation in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for controlling server activation in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2864973