Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-07-20
2004-07-20
Mizrahi, Diane D. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06766324
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to computer systems and object-oriented programming languages. More particularly, the present invention relates to the design and use of persistent configurable Java classes that have attributes and methods that are alterable during run-time of the system without requiring the removal and redeployment of the classes.
2. Description of the Related Art
In volatile industries, where standards are being formed, such as in the world of business to business (B2B) systems, developers need to be able to adjust applications rapidly. This includes making changes to the implemented business processes and the data these processes work with. In an object-oriented environment, this leads to the requirement of being able to define new classes (behavior and state) and to change existing classes within the application, without disrupting any of the existing functionality, and without having to “redeploy” the application into its target environment. For example, if an existing application with a business-to-business (B2B) interface needs to react to evolving data exchange format standards rapidly, new definitions of that standard lead to new and changed behavior and state within the existing application.
In a business computer environment, Enterprise JavaBeans (EJB) is a common server-side component architecture for the Java 2 Platform, Enterprise Edition (J2EE). EJB is a specification that defines a standard architecture for implementing the business logic of multi-tier applications as reusable components. In addition to EJB components, the EJB architecture has servers, containers, and clients.
There are three categories of EJB methods: home interface methods, business logic methods, and container interaction methods. Home interface methods correspond to methods in the bean's home interface, and such methods are largely for creating, locating and accessing instances of the bean. Business logic methods are methods provided by the bean's remote interface to facilitate the functionality of the bean in its intended business environment. Container interaction methods are methods for interacting with the container and are not intended for client access. Consequently, the container access methods are hidden by the container.
There are two types of enterprise beans: session beans and entity beans, and each type of bean represents a different level of business logic abstraction. Session beans represent behavior associated with client sessions generally implemented to perform a sequence of tasks within the context of a transaction. A session bean runs processes on behalf of the client remotely on the server as a logical extension of the client program. Entity beans represent specific data or collections of data, such as a row in a relational database. Entity bean methods provide operations for acting on the data represented by the bean. An entity bean is persistent and survives as long as its data remains in the database.
A client accesses an Enterprise JavaBean by looking up the instance of the class implementing its home interface by name. The client then uses methods of the home interface to acquire access to an instance of the class implementing the remote interface. In addition to generating classes to implement both the home and remote interface, the container is responsible for binding the home class using a name server, which it communicates with via the standard JNDI API. Such function is generally handled automatically by the container tools at deployment time.
A container provides Enterprise Java Beans components with services of several types. First, the container provides services for lifecycle management and instance pooling, including creation, activation, passivation, and destruction. Second, the container intercedes between client calls on the remote interface and the corresponding methods in a bean to enforce transaction and security constraints. The container can provide notification at the start and end of each transaction involving a bean instance. Finally, the container enforces policies and restrictions on bean instances, such as reentrance rules, security policies, and others.
The tools for a container generate additional classes for a session bean at deployment time. These tools get information from the EJB architecture at deployment time based upon the EJB's deployment descriptor or by introspecting the architecture classes and interfaces. The tools use this information to dynamically generate two classes to implement the home and remote interfaces of the bean. The interface classes enable the container to intercede in all client calls on the session bean. The container also generates a serializable “Handle” class, providing a way to identify a session bean instance within a specific life cycle. Such classes can be implemented to mix in container-specific code for performing customized operations and functionality. In addition to custom classes, each container provides a class to provide metadata to the client and implements the SessionContext interface to provide access to information about the environment in which a bean is invoked.
Session beans are not persistent, whether stateful or stateless. The data maintained by a stateful session bean is transitional, and solely for the purposes of a particular session with a particular client. A stateful session bean instance does not survive system failures and other destructive events. While a session bean has a container-provided identity (the “handle”), that identity passes when the session bean is removed by the client at the end of a session. If a client needs to revive a stateful session bean that has disappeared, it must provide its own means to reconstruct the disappeared bean's state. The entity bean developer defines the home and remote interfaces that represent the client view of the bean. Entity bean developers also create a class that implements the EntityBean interface, as well as methods corresponding to the methods in that bean's home and remote interfaces. In addition to defining methods in the EJB Home interface, the entity bean developer also implements finder methods.
A “finder” method provides a way to access an entity bean through the bean's contents. Finder methods are designed to be introspected and displayed by development and deployment tools, which enables a user to graphically manipulate entity beans in the process of developing applications. The principal finder method that must be implemented by all entity beans is “findByPrimaryKey.” In addition to this method, the developer can implement a “PrimaryKey” class to provide each entity bean with a unique, serializable identity, and in accord with the EJB 1.1 specification, any base type attribute of the EJB can be declared to be the primary key.
As with session beans, the tools for a container generate additional classes for an entity bean at deployment time to implement the home and remote interfaces. The additional classes enable the container to intercede in all client calls on the same entity bean. The container also generates the serializable Handle class to providing a method to identify the entity bean within a specific life cycle. The additional classes can be implemented to mix in container-specific code for performing customized operations and functionality. Each container provides a class to provide metadata to the client. And a container also manages persistence of selected fields of the entity bean where specified by a particular bean.
A container supports the following values for the transaction attribute of an Enterprise JavaBean:
“Not Supported”—The bean runs outside the context of a transaction, and existing transactions are suspended for the duration of method calls.
“Required”—This method call requires a transaction context, so if one exists, it will be used, and if none exists, a transaction context will be created.
“Supports”—This method call uses the current transaction context if one exists, and will not create
Carlson Brent
da Cruz Valquiria Cristina
Graser Tim
Marandici Mircea P.
Pietrocarlo Gary Joseph
Arnall Golden & Gregory LLP
International Business Machines - Corporation
Mizrahi Diane D.
Mofiz Apu
LandOfFree
System and method for defining, configuring and using... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for defining, configuring and using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for defining, configuring and using... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3219885