![Session Objectives ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Session 5 Tp5
Similar to Session 5 Tp5 (20)
More from phanleson
More from phanleson (20)
Recently uploaded
Recently uploaded (20)
Session 5 Tp5
- 1. Session 5 Introduction to Entity Beans
- 4. Persistence Persistence Java Object Serialization Three ways to make an object persistent Object Relational Mapping Object database Persistence Storage Obj 1 Obj 2 Persistence Objects Storage Storage Database
- 5. Java Object Serialization Object 1 Object 2 Object n State of the object Compact representation Marshall an object graph into a compact representation Serialization of object graph into byte stream Developer pushes data over the network or saves the stream to a storage Byte Stream
- 6. Object Relational Mapping Database API Relational Database Manual Mapping Use an Object- Relational Mapping Product Object Travel Account String Name String TktNo Double Amount
- 8. Components deployed in Multi-tier Deployment- Application logic components Application logic components are components that provide methods which perform common tasks Computing the price of a ticket Billing of products
- 9. Components deployed in Multi-tier Deployment - Persistent Data Components Object Serialization of data Database Examples are air ticket information such as ticket number and amount Employee data such as salaries and place of work
- 10. Files in an Entity bean Entity Bean Remote Interface Primary Key Class Entity Bean Class Deployment Descriptors Home Interface Local Interfaces
- 11. Entity Bean class Models Java Class Persistent Data Maps Database Schema Entity Definition For example , an entity bean class can map to a relational table definition. An entity bean instance of that class will then map to a row in that table.
- 12. The Entity Bean’s Remote Interface Client Entity Bean Invokes Business Method signatures Remote Interface
- 13. The Home Interface create find destroy The home interface is used by the clients to create, find and destroy entity bean objects. Client Uses Methods Home Interface Entity Bean Object Entity Bean Object Entity Bean Object
- 14. Local Interface Local Clients Entity Beans Methods Entity Beans Exposes Local Interface allows the beans to expose its methods to other beans that reside within the same container (local clients). Container
- 16. The Deployment Descriptors Container Deployment descriptors List of properties Contacts the deployment descriptor for bean deployment Informs the container about the bean and classes
- 17. Pooling of Entity Bean Instances EJB Container Entity Bean 1 Entity Bean 2 Entity Bean n Instantiates Storage Data 1 Data 2 Data n Represents Entity Beans Pooled and Recycled Entity Bean 1 When the bean instance is used ,it is assigned to handle different client request.
- 18. Ways to Persist Entity Beans Data Store Entity Bean Entity Beans map themselves in the data store Bean-managed Persistence Container- Managed Persistence Deployment Descriptor Persistent Beans Deployment Descriptor tells the container about the persistent fields and then the container handles the data logic
- 20. Modifying Entity Beans Directly though the Database EJB Container/ Server Entity Beans Existing Application Database O/R Mapping Direct Database Modifications Bean data
- 23. ejbFind ( ) Creating a BMP EJB and an EJB object Home object EJB object Entity bean instance EJB Container/ Server 1. Call create() 6. Returns object to the client 2. Call ejbCreate() 4. Returns primary key Client Code 3. Create database data 5. Create EJB object
- 26. ejbRemove( )- II Destroying an entity bean’s data representation Home object EJB object Entity bean instance EJB Container/ Server 1. Call remove() 2. Call ejbRemove() Client Code 3. Remove database data 1. Call remove() 2. Call ejbRemove()
Editor's Notes
- This slide is self explanatory. It states the three ways in which objects can be made persistent
- The slide is self explanatory. The state of the object is saved to permanent storage. This is done by object serialization. Here an object graph is marshaled into a compact representation . When the object graph is serialized, it is converted into a byte stream. The developer can then push data over the network or save the stream to a storage such as a file system, database or JNDI tree. However, object serialization has some drawbacks. For example, A file system stores a huge amount of serializable employee objects. This is done by converting the objects to their bit blob representation and then storing the bytes on disk. Suppose, employee information is needed for employees who have a salary above a particular amount. With serialisation each and every employee account serialized bit-blob from the disk, construct the corresponding object and then execute a method query on the object to determine if the salary is over that amount. Also, a number of advanced queries may also have to be done. This cannot be done with object serialisation. Querying objects using object serialization is very expensive and cumbersome. Submitting queries against business data is an absolute necessity for large-scale applications, which make simple object serialization has its purpose, it is best used in restricted domains, such as network communications and simple persistence.
- Here Java Objects are stored in traditional relational databases such as Oracle or Microsoft SQLServer. As evident in the slide each object is disintegrated into into its constituent parts. If you consider the previous example of the employee object, it can be decomposed into various parts. The employee number could be stored in one relational database row, name in another row and salary in another row. When you save these Java objects you will have to use JDBC or SQL/J to map the object data into a relational database.you could also store the name of the Java class that this data corresponds to, so that you know which class to instantiate when reading the object back from the database. When you want to load your objects from the database, you would first instantiate an object from that class, read the data in from the database and then populate that objects’s instance’s fields with the relational data read in. Object relational mapping as a persistence mechanism is a much more sophisticated mechanism of persisting objects than simple object serialisation. By disintegrating the Java objects as relational data you can issue arbitrary queries for information. For example, you can search through all the database records that have salary greater than the amount and load only objects that fulfill this query. More advanced queries are also possible. Mapping of objects to relational data can be done in two ways. You can either hand craft this mapping in your code or use an object-realtional mapping product such as ObjectPeople’s TOPLink or Sun’s JavaBlend to automate or facilitate this mapping. Today, most users hand-craft the mapping using a database access API such as JDBC or SQL/J. Because the cost of developing and maintaining an object relational mapping layer is significant, it is likely that the object relational mapping products will be adopted. Once a bean’s fields are mapped to the relational database, the container takes over the responsibility of keeping the state of an entity bean instance consistent with with corresponding tables in the database. This process is called synchronising the state of the bean instance.In the case of an EmployeeBean, bean insatnces at runtime will map one-to-one to rows in the Employee table of the relational database. When a change is mad e to the EmployeeBean, it is written to the appropriate row in the database. Frequently bean types will map to more than one table. These are more complicated mappings often requiring a SQL join. In addition to synchronizing the state of an entity, EJB provides mecahanisms for creating and removing entities. Calls to the EJB home to create and remove entities will result in a corresponding insertion or deletion of records in the database. Because entities store their state in a database tables, new records can be added from outside the EJB sytem. In other words, inserting a record into the Employee table or by direct access to the database – creates a new Employee entity . It is not created in the sense of instantiating a Java object, but in the sense that the data that describes an Employee entity has been added to the system. Object-to-relational persistence can become vety complex becauseobjects don’t always map cleanly to a relational database. Although you can specify any java serializable type as a container-managed field, Java objects don’t always map seamlessly to a relational database. You frequently need to convert Java types to some nonobject type just prior to synchronisation so that the data can be stored in a relational database. There are many other impedance mismatches when mapping object to realtinal databases, and then some EJB vendor implementations deal with them better than others. Relational databases however are still a very good persistence store because they are stable and well-understood. There is no shortage of developers who understood them or products that support them. In addition, the large number of SQL-standard relational databases makes it easy to migrate from one database to another.
- Object-oriented datbases are designed to preserve object types and object graphs and therefore are a much better match for components written in an object oriented language like Java. They offer a cleaner mapping between entity beans and the database than a relational database. Serilasable objects can be preserved without the mismatch associated with object-to-relational persistence because the object’s definition and state are simply stored as is to the database. Not only are the object’s definition and state saved to the database, complex relationships like circular references can also be maintained. Because object databases store objects, object databases are viewed by many developers as superior database technology for object persistence. While object databases perform well when it comes to very complex object graphs, they are still fairly new to business systems and are not as widely accepted as relational databases. As a result, they are not as standardized as relational databases making it more difficult to migrate from one database to another. In addition, fewer third-party products exist that support object databases, like products for reporting and data warehousing. Several relational databases support extended features for native object persistence. These databases allow some objects to be preserved in relational database tables like other data types and offer some advantages over other databases.
- The slide is self explanatory.
- Other examples could include bank account information and college records and so on. Need for persistent data components- why should you deal with business data as objects rather than dealing with raw database data, such as relational rows. The answer is that it is very handy to treat data as objects because they are represented in a compact manner. We can group related data together in a unified object. You associate some simple methods with that data, such as compression or other data related services. You can also gain implicit middleware services from an application server such as transactions, network accessibility and security.
- The slide is self explanatory.
- No bean is complete without its implementation class. This will reside on the server. When a client invokes a business method on the bean’s remote interface, that method invocation is received by the EJB object, which then delegates it to the bean. When developing any bean, you have to use the bean’s remote interface as a guide. Business methods defined in the remote interface
- The business methods of an enterprise bean are defined by a remote interface provided by the bean developer. The java.ejb.EJBObject interface, which extends the java.rmi.Remote interface is the base class for all remote interfaces. Remote interfaces are focused on the business problem and do not include methods for system level operations such as persistence, security, concurrency or transactions. System level operations are handled by the EJB server which relieves the client developer of many responsibilities. All remote interface methods for beans must throw at the very least, a java.rmi.RemoteException which identifies problems with distributed communications. In addition, methods in the remote interface can throw as many custom exceptions as needed to indicate abnormal business related conditions in executing the business method.
- The home interface of any entity bean is used to create, locate and remove objects from EJB systems. Each entity bean type has its own home interface. The home interface defines two basic kinds of methods-zero or more create methods and one or more find methods. The create methods act like remote constructors and define how new beans are created. In the Employee example, the find method is used to locate a specific example.
- Lets us say you have decided to author your own EJB container/server. Your product is responsible for instantiating entity beans as necessary, with each bean representing data in an underlying storage. As clients connect and disconnect, you could create and destroy data in an underlying storage. As clients connect and disconnect, you could create and destroy beans as necessary to service those clients. Unfortunately, this is not a scalable way to build an application server. Creation and destruction of objects is very expensive, especially if the client requests come frequently. How can we save this overhead? One thing to remember is that an entity bean class describes the fields and rules for your entity bean, but it does not dictate any specific data. For example, an entity bean class may specify that all employee accounts have the following data: Employee name Employee id Salary Department That bean class can then represent any distinct instance of database data such as a particular employee account record. The class itself, though is not specific to any particular employee account. Thus to save precious time instantiating objects, entity bean instances to represent different instances of the same type of data in an underlying storage. For example, a container could could use a employee account to represent different employee accounts. Thus when you are done with an entity bean instance, that instance may be assigned to handle a different client’s request and may be represent different data . The container performs this by dynamically assigning the entity bean instance to different client specific EJB-objects. Not only does this save the container from unnecessarily instantiating bean instances, but this scheme saves on the total amount of resources held by the system. Instance pooling is an interesting optimization that containers may provide and is not all unique to entity beans. Stateless session beans can also be recycled. But as with stateful session beans, there are complications when reassigning entity bean instances to different bean instances to different EJB objects. When your entity beans is assigned to a particular EJB object, it may be holding resources such as socket connections. But when it is in the pool, it may not need that socket. Thus to allow the bean to release and aquire resources, your entity bean class must implement two callback methods. ejbActivate() ejbPassivate()
- The slide is self explanatory. Additional Teaching It is sometimes handy to separate the kind of resources that the beans use into two categories:bean specific resources and bean-independent resources. Bean specific resources are resources that your bean uses that are tied to a specific data instance in an underlying storage. For example, a socket connection is a bean specific resource if that socket is used only when your bean instance is bound to a particular object. Such a resource should be acquired when a bean instance is activated and released when the instance is passivated. Bean-independent resources are resources that can be used over and over again no matter what underlying data your instance represents. For example, a socket connection
- An entity bean’s instance’s ejbCreate() method is used to initialise a bean for a particular client and to create underlying database data. Each ejbCreate() method you define gives clients a different way to create your beans. Here are some of the rules about ejbCreate(): You do not need to write any ejbCreate() methods with entity beans-Session beans require ejbCreate() methods, but they are optional for entities. You would define an ejbCreate() method if you want to providea way to create some underlying data through EJB. But remember that EJB does allow for you to create some underlying data indirectly, via direct database inserts or legacy systems. Thus ejbCreate() is optional. The parameters to ejbCreate() can vary. This allows for multiple ways to intialise an entity bean instance and thus allows for different ways to create entity bean instance and thus allows for different ways to create entity bean data in a database. For example, one ejbCreate() method might create a checking account,, while another might create a savings account. You must duplicate your ejbCreate() methods in your home interface.In EJB, remember that clients don’t directly invoke on beans-they invoke an EJB object proxy. The EJB object is generated through the home object. Therefore, for each ejbCreate() method signature you define in your bean, you must define a corresponding create() in the home interface. The client calls the home object’s create() which delegates to your bean’s interface. The client calls the home object’s create() which delegates to your beans’s ejbCreate().
- Example: Let us say you have a bean-managed persistent bank account entity bean class called AccountBean, with a remote interface account, home interface AccountHome and primary key class AccountPK. Given the following ejbCreate()method in Accountbean: public AccountPK ejbCreate(String accountID,String owner)… You must have this create() in your home interface. public Account create(String accountID, String owner) throws… Notice that there are two different return values here. The bean instance returns a primary key(AccountPK), while the home object returns an EJB object(Account). This makes sense-the bean returns a primary key to the container( that is, to the home object) so that the container can identify the bean. Once the home object has this primary key, it can create an EJB object and return that to the client.