Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-12-31
2001-10-02
Chaki, Kakali (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000, C717S152000
Reexamination Certificate
active
06298478
ABSTRACT:
RELATED INVENTIONS
This application is related to U.S. patent application Ser. No. 09/224,535 entitled “Technique for Managing Associations Between Enterprise JavaBeans™ which are the Target of Multiple Concurrent and/or Nested Transactions”, filed concurrently herewith on Dec. 31, 1998, and U.S. patent application Ser. No. 09/001,980 entitled “Technique for Managing Objects which are the Target of Multiple Transactions in a Client/Server Environment”, filed Dec. 31, 1997.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of computer programming, and more particularly to a technique for managing Enterprise JavaBeans™ which are being utilized by concurrent and/or nested transactions. This technique enables maintaining the integrity of the Enterprise JavaBeans™.
2. Description of the Related Art
“JavaBeans” is the name of a component architecture for use with the Java programming language. (“JavaBeans” and “Java” are trademarks of Sun Microsystems, Inc.) A JavaBean is the Java term for a “component”, where a component is a reusable building block of application logic that a programmer can combine with other components to form an application program. “Enterprise JavaBeans” is a server component architecture which extends the JavaBeans architecture to the enterprise. “Enterprise” in this sense refers to an organization that uses computers in a networking environment, typically on a very large scale.
A Java programmer creates a Java application program by assembling components that provide the desired functionality for his application. A JavaBean may contain code for a relatively simple function such as displaying a button on a graphical user interface (“GUI”), but it may also contain quite complex code. An Enterprise JavaBean, or “EJB”, is similar to a JavaBean, with several notable exceptions. JavaBeans are intended to execute locally, within the Java Virtual Machine (“JVM”) on which a Java application is running. EJBs, on the other hand, are intended to execute on a server machine in a network, where they are remotely invoked by messages sent from a client machine's JVM. JavaBeans may provide code for visual objects, such as the GUI button discussed above; EJBs are always non-visual.
For an EJB, the executable business logic is stored within the entity bean. An EJB's business methods are invoked by sending a message to the EJB's wrapper, where a “wrapper” is the Java term for functionality required to adapt an EJB to its container, and a “container” is the Java terminology for the run-time environment in which an EJB (including the entity bean) is executed. The business method invocations are forwarded to the entity bean by the wrapper for execution. Thus, the wrapper is not always able to detect when an EJB has been modified. This differs from the approach of the related application filed Dec. 31, 1997, titled “Technique for Managing Objects which are the Target of Multiple Transactions in a Client/Server Environment”, which is hereinafter referred to as “the related application”, where the executable business logic is stored within the wrapper (referred to as a “shell” in the related application).
Both JavaBeans and EJBs differ from “pure” objects in object-oriented programming in that they have a required external interface. This interface is called the “properties” interface. Using this external interface, a development tool can interrogate the JavaBean or EJB, to determine what its component does and how its function is to be invoked by other components. The properties interface also enables developers to customize the behavior of components without having access to the source code. As a simple example, when the component contains code for displaying a button on a GUI, the developer may use a component property to specify the text that should be displayed on the button face.
In large-scale enterprise computing environments, a single server application may serve multiple concurrent client applications, each accessing an overlapping set of EJBs, while other server applications are also accessing the EJBs. See
FIG. 1
, which depicts a simple example of this situation. A collection of EJBs is stored in a data store, such as database
110
. These stored EJBs may be accessed concurrently by one or more server application programs. Two server applications
120
,
122
are shown in
FIG. 1
, but many more than two applications may share access to a data store, as is known in the art. (The collection of EJBs being accessed by the applications may reside on multiple data stores, although only one data store
110
has been shown in
FIG. 1.
) Each server application may have one or more clients that are executing the application at a given time. Server application
120
is shown in
FIG. 1
as having two clients
130
,
135
, and server application
122
is shown as having three clients
140
,
145
,
150
.
Many enterprise applications that reflect complex business processes require that users have the ability to navigate freely between different elements of the user interface. For example, the user may wish to have multiple windows for one application open on the display at the same time. Users of such applications have come to expect that they can switch from processing information in one window to processing information in a different window without having to take special precautions to ensure consistency of the data between the different windows. In particular, if the user makes changes to data values in one window, he does not expect to have to take steps to permanently store the changes in a data store before subsequently-opened windows for the same application can recognize the changed data.
The related application defines a technique for solving this problem for objects using a transactional approach, where the tasks a user (or application program) performs are organized into transactions. Using commonly-known industry terms, a transaction represents a logical group of changes to one or more objects that will be performed in an atomic manner (that is, either all operations within the transaction are performed, or none of them are performed). Using the transactional approach defined in this related application, all changes that the user wants to make to an object within the scope of a transaction are made first to an internal copy (called a “version”) of the object, without actually updating the persistent, stored object itself. The user eventually decides whether to permanently commit the changes encompassed by the transaction, or whether to discard them. If the user chooses to commit, then the updated object in the version is copied to the persistent store. If the user chooses to discard (or “roll back”) the changes, the persistent store is left unchanged.
The technique defined in this related application enables nested transactions to have views of an object that are completely independent from the views of other concurrent transactions. A nested transaction is one where the transaction is logically viewed as a tree, each subtree being either nested or flat. Nested transaction subtrees are internal nodes within the tree structure, and flat transactions are leaf nodes of the tree. The root of a transaction is called the “top-level transaction”; nodes below this top level are called “subtransactions”. A transaction's predecessor node in the tree is called a “parent” and nodes below that transaction in the tree are called “child” nodes, using the terminology for tree structures that is commonly known in the computer programming art. Within the scope of a nested transaction, a subtransaction at any level may either commit its changes or roll them back. When a subtransaction commits its changes, the changed values are made accessible upward in the tree only to the parent node of this subtransaction. The change does not actually update the persistent store unless and until the top-level transaction is committed. Further, the changes are not visible to any siblings of the committed subtransaction, or to any nodes
Nally Martin P.
Rich Lawrence Scott
Salo Timo J.
Chaki Kakali
Doubet Marcia L.
Doudnikoff Gregory M.
International Business Machines - Corporation
Vo Ted T.
LandOfFree
Technique for managing enterprise JavaBeans (™) which... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Technique for managing enterprise JavaBeans (™) which..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Technique for managing enterprise JavaBeans (™) which... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2586356