Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-02-26
2001-07-31
Choules, Jack (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C709S241000, C709S241000, C709S241000
Reexamination Certificate
active
06269373
ABSTRACT:
CROSS-REFERENCE TO RELATED APPLICATIONS
The present application is related to Application Ser. No. 09/259,141, filed Feb. 26, 1999, titled “Process and System for a Client Object to Perform a Remote Method Invocation of a Method in a Server Object,” which is hereby incorporated by reference.
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to an improved distributed data processing system and in particular to a method and apparatus for a distributed application comprising objects on clients and servers within the distributed data processing system.
2. Description of Related Art
Software developers face the fundamental problem that writing an enterprise-wide application is difficult, and writing a distributed application is even more difficult. In addition, an enterprise seeks to build an application as fast as possible without being locked into one platform. Ideally, enterprise developers would like to be able to write the application once and run it on all of their platforms. Enterprise JavaBeans™ technology seeks to provide this ability.
The Enterprise JavaBeans (EJB) component architecture is designed to enable enterprises to build scalable, secure, multi-platform, business-critical applications as reusable, server-side components. Its purpose is to solve the enterprise problems by allowing the enterprise developer to focus only on writing business logic.
The EJB specification creates an infrastructure that takes care of the system-level programming, such as transactions, security, threading, naming, object-life cycle, resource pooling, remote access, and persistence. It also simplifies access to existing applications, and provides a uniform application development model for tool creation use.
Java provides a mechanism by which a Java client can invoke methods on a Java server that is running in a separate process using a methodology called Remote Method Invocation (RMI) However, if the server is not running in a Java environment, such as a CORBA-compliant (Common Object Request Broker Architecture) server, then the Java client is unable to make any method calls to the method on the CORBA server since Java does not provide an inherent mechanism for communicating with CORBA objects.
Simply stated, CORBA is an Object Request Broker (ORB) that allows applications to communicate with one another no matter where they are located or who has designed them. An ORB is the middleware that establishes the client-server relationships between objects. Enterprises have turned to CORBA as a solution to provide inter-operability between various software applications.
When an application is deployed on a CORBA server, the deployer of such an application decides how to save the application's state information so that the deployer can resurrect the application to its correct state after the application has been passivated. Although the state information can be stored persistently by the application itself, typically the container of the server application manages this state information so that the server application is not concerned with the specifics of the back-end store that persists the state information.
Most back-end data stores allow the persistence of primitive data types. However, if a server application running inside a CORBA server needs to persist references to other servers, there is no direct way of doing so. This is especially true for a CORBA server that executes EJBs.
According to the EJB standard specification, the state information of an EJB can be persisted by serializing the EJBHandle that can be obtained from the EJB. The EJBHandle object is supposed to store within itself all the information necessary to resurrect the EJB. However, the use of EJBHandle poses the following problems.
First, portability is a problem. An EJBHandle is a very Java-specific and EJB-specific way of persisting EJB references. A C++ client or some other type of non-EJB client can not construct a remote object from a serialized EJBHandle.
The second problem is the implementation of EJB Handles. An EJBHandle is a Java interface defined in the EJB standard specification. A serialized EJBHandle object contains references to the Handle implementation class. The EJB server is responsible for defining the implementation for EJBHandle. Different EJB servers can have different EJBHandle implementations. Therefore, it may not be possible for an EJB server to resurrect an EJB from a serialized EJBHandle since it may have a completely different implementation class for that Handle, especially if the EJBHandle was serialized by a different EJB server.
Hence, serializing an EJBHandle is not a foolproof method to persist EJB references in container-managed entity beans. Another method that can uniquely identify an EJB and can be used to persist an EJB is to store the Home Name and Key value of the EJB. This information can be enough to locate the referred EJB. However, this information may not always be available at runtime. For example, according to the EJB standard specification, the Home Name is not available to a bean at runtime. Therefore, one cannot persist EJBs by storing their Home Name and Key value.
Therefore, it would be advantageous to have a method for enabling the transparent persistence of an object reference for a JavaBean as a container-managed field within a CORBA server.
SUMMARY OF THE INVENTION
The present invention provides a method for persisting a container-managed server object or bean in a distributed data processing system. A method in a Tie object is invoked by the container of the bean to assist in the persistence of the bean. The bean may have container-managed fields of both primitive and complex data-types, and the complex data-types may include references to other objects or beans. The Tie object obtains the object reference to the other object. The Tie object unwraps an adapter from the object reference to obtain a proxy of the referred object and stringifies the proxy. The string is then stored by the container in a back-end data store as a known primitive data-type. The referred object may be resurrected. by unstringifying the string and reversing the process.
REFERENCES:
patent: 5794250 (1998-08-01), Carino, Jr. et al.
patent: 5822580 (1998-10-01), Leung
patent: 6006230 (1999-05-01), Ludwig et al.
patent: 6115736 (2000-09-01), Devrakonda et al.
patent: 6178457 (2001-01-01), Pitchford et al.
patent: 6182154 (2001-01-01), Campagnoni et al.
“Enterprise Javabeans in NIIP Virtual Enterprise”, 1998 IEEE, by Art Goldschmidt, Paul Horstmann,and John Lauretiev.*
Sun Microsystems Inc. , “Sun MicroSystems Enterprise Javabeans: version 1.0”, Mar. 1998.
Acker Liane Elizabeth
Apte Ajay Arvind
Choules Jack
International Business Machines - Corporation
Mims Jr. David A.
Rayyan Susan
Yee Duke W.
LandOfFree
Method and system for persisting beans as container-managed... 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 system for persisting beans as container-managed..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for persisting beans as container-managed... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2476057