Computer graphics processing and selective visual display system – Computer graphics processing – Graphic manipulation
Reexamination Certificate
2000-01-14
2003-07-22
Bella, Matthew C. (Department: 2676)
Computer graphics processing and selective visual display system
Computer graphics processing
Graphic manipulation
Reexamination Certificate
active
06597366
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to distributed object systems, and more particularly to a method for isolating shared objects for transparent manipulation of the shared objects for a plurality of applications.
2. Description of the Related Art
The ENTERPRISE JAVABEANS™ architecture is a component architecture for the development of and deployment of JAVA™ (see The JAVA Language Specification, J. Gosling, B. Joy and G. Steele, Addison-Wesley Longman, Reading, Mass., 1996) applications in a multi-tier distributed object environment. (ENTERPRISE JAVABEANS and JAVA are trademarks of Sun Microsystems, Inc.). In a multi-tier application architecture most of an applications' logic is moved to one or more servers. The server components (those that run on the server) which conform to this architecture are referred to as enterprise beans and are portable across all ENTERPRISE JAVABEANS' server systems i.e., component execution systems that support ENTERPRISE JAVABEANS (EJBs). ENTERPRISE JAVABEANS which have a persistent state are referred to as entity beans. The persistent state of an entity bean is maintained in a relational or object database.
Support for transactions is an essential part of ENTERPRISE JAVABEANS. Transactions are used not only for making units of work atomic but also for isolating concurrently executing units of work from each other. The actual implementation of transactions is the responsibility of the provider of the ENTERPRISE JAVABEANS server. Typically, the implementation utilizes the transaction capabilities of the relational or object database used to maintain the persistent state of the beans. These database systems normally maintain just one version of each bean instance. Isolation is achieved by controlling the read and write access to that single version. This is appropriate for some applications, but for others, it is desirable to have the system maintain versions.
Having a relational or object database support multiple versions of an object has been described many times and for many different purposes in the literature. For example:
a) for implementing temporal databases. In these databases each version has the values of the attributes of the object that pertained for a particular time period and were considered valid for some other time period. (see “Temporal Databases”, R. Snodgrass and I. Ahn, Computer, Vol.10, No.9, September 1986).
b) for recovery. Versions are used to represent consistent database states to which a system can return to after a crash. (see “Parallelism and Recovery in Database Systems”, R. Bayer, H. Heller and A. Reiser, ACM Transactions on Database Systems, Vol.5, No.2, June 1980).
c) for support of documents or engineering designs. The versions may represent different alternatives for a design or document (see “Version Support for Engineering DataBase Systems”, K. Dittrich and R. Lorie, IEEE Transactions on Software Engineering, Vol.14, No. 2, April 1988).
It is important to note that these examples expose the versions to the client application, and versions have been used internally to a relational or object database system, for example:
a) for enhancing performance in distributed systems. Typically several copies of the same object exist at different sites (see “Distributed Databases, Principles and Systems”, S. Ceri and G. Pelagatti, McGraw-Hill 1984, (ISBN 0-07-010829-3)).
b) for concurrency control. In multi-version concurrency control, temporary non-persistent versions are maintained (see “Concurrency Control and Recovery in Database Systems”, P. Bernstein, V. Hadzilacos and N. Goodman, Addison-Wesley 1987, (ISBN 0-201-10715-5)). Therefore, a need exists for a system and method for transparent, general purpose object isolation such that an object provider and/or an object user are unaware of the manipulations of objects as will be described in detail below.
SUMMARY OF THE INVENTION
A method for manipulating objects in isolation, in accordance with the invention, includes providing a shared object, B, from an object provider for use on a distributed object system, from which a new class of objects are provided which include a facade object, Bf, for B and a versionable representation object, Bv, for B wherein Bf supports a same interface as B. B is permitted to be manipulated, through the new class of objects, in a given context isolated from other contexts for the object B wherein the object provider and an object user are unaware of the production and manipulation of the new class of objects. Method invocations on Bf in the given context are delegated to Bv to associate an instance of Bv with the given context such that one or more versions of object B are persistently maintained in the distributed object system. Another method for manipulating objects in isolation includes the steps of transforming an object class, B, into a new object class, B′, which subsumes B, such that instances of B′ are substituted for instances of B, where B′ provides behavior permitting a same instance of B′ to be used concurrently by multiple object users, such that each object user can manipulate a state of the object instance isolated from effects of other object users and an object provider and an object user are unaware of the transformation to the new object class. The step of transforming further includes the steps of providing an object class, B, from an object provider for use on a distributed object system. For the new class B′, the following steps are included: producing a version class, Bv, where Bv supports the behavior and attributes of B, and producing a facade class, Bf, where Bf supports a same interface as B, wherein instances of Bf are substituted for instances of B such that invocations on an instance of Bf are delegated to an instance of Bv which is associated with an object user.
In alternate methods, the step of producing may include the step of automatically producing the facade object and the version object upon presentation of the object, B. The given context is preferably client specific. The given context may include a unique client identifier to identify a version of Bv. The step of delegating method invocations on Bf in the given context to Bv may include the step of identifying versions of the object B by comparing attributes of versions of the object Bv. The step of delegating method invocations on Bf in the given context to Bv, may further include the step of maintaining version instances at the facade Bf and transparently dispatching client requests on the object Bv to the version associated with the client. The step of producing a facade object, Bf, for B and a versionable representation object, Bv, may include the step of generating classes for the facade object and the versionable representation object, the classes including a remote interface, a home interface, a primary key and an implementation.
The methods may further include the step of producing version state-classes for representing attributes of the object B and copying one version of the attributes to another version of the attributes in accordance with version updates. The method as recited in claim
25
, wherein the step of manipulating Bf in a given context includes the step of mapping client requests to versions of the object B in the versionable representation Bv. The step of delegating method invocations on Bf in the given context to Bv may include the step of identifying versions of the object B by key attributes of versions of objects. The object B may include an ENTERPRISE JAVABEAN. The objects Bf and Bv may also include ENTERPRISE JAVABEANs. The method may include the step of storing a plurality of versions of B in Bv on a memory storage device. The step of reconciling object manipulations in Bv with the distributed object system may also be included.
It should be noted that objects B and Bf and Bv need not be the same type for example, they need not be EJBs. The methods and method steps as described herein above may be implemented with or on a program
Bennett Brian T.
Leff Avraham
Mikalsen Thomas A.
Rayfield James T.
Rouvellou Isabelle M.
Bella Matthew C.
Cunningham G. F.
F. Chau & Associates LLP
International Business Machines - Corporation
LandOfFree
Transparent general purpose object isolation for multi-tier... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Transparent general purpose object isolation for multi-tier..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transparent general purpose object isolation for multi-tier... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3049892