EJB - Coding Standards
EJB - Coding Standards
http://www.cjsdn.net/post/view?bid=4&id=92484&sty=1&tpg=1...
Java
| | | | |
200 Bullet Points from the book Head first EJB 2004-05-17 10:52 As Im progressing on SCBCD I abstract 200 Bullet Points from the book Head first EJB. Hopeful it will benefit to your guys. 1. EJB is a component-based development model 2. components are reusable chunks of functionality you can modify for different applications without touching java source code 3. One benefit of EJB is WODA-White-One, Deploy-Where, you can deploy your EJB2.0 components to any app server that EJB2.0-compliant. 4. WODA means you have to learn only one, standard API rather than proprietary vendor-specific APIs. 5. EJB architecture uses an EJBObject to intercept client calls to a bean, This give Server/Contain a chance to step in and add services 6. EJB services include transaction, security, resources management, networking and persistence. 7. Bean become in three flavors: Entity, Session and Message-driven. 8. Entity beans represent a uniquely identifiable thing in a persistent store; usually means a row in database table. 9. Message-driven beans are JMS messaging service consumers. 10. Session beans can be everything else. 11. Session beans can be stateful or stateless. 12. Stateful beans can remember conversional state with a client while stateless beans cannot. 13. EJB uses Java RMI so that your beans can be accessed by remote clients 14. A remote client, in this context, is an object running in a different JVM, which also means a different heap. 15. A Remote object stays in its own heap, while client invoke methods on the Remote objects proxy, calling a stub. 16. The stub object handles all the low-level networking details in communicating with the Remote object. 17. When a client wants to call a method in Remote Object, the client calls the same method in the stub. The stub lives in the same heap as the client. 18. To the client, a remote method call is identical to a local method call, except a remote method can throw a RemoteException( a checked exception) 19. The stub packages up the method arguments and sends information about the call to a skeleton on the server. The skeleton object itself is optional, but skeletons work must be done by something on the server, we dont have to care who- or what is actually doing the skeletons work. 20. Arguments and return values must be one of the following: a primitive, a Serializable object, an array or collection off primitive or Serializable objects, or Remote object. If the value isnt one of these, you will get a runtime exception. 21. If an object is passed as an argument or return value, the object is sent as a serialized copy, and then deserialized on the Remote objects local heap. 22. If a remote object is passed as an argument or return value, the objects stub is sent instead. 23. Beans that are exposed to remote clients have two Remote interface one for the EJBHome and one for the EJBOjbect. 24. A Remote interface must extend (directly or indirectly) java.rmi.Remote, and all methods must declare a java.rmi.RemoteException. 25. In EJB, the interface that extends EJBOjbect is called the Remote Component interface. It is where the business methods are declared. 26. The client never calls methods on the bean itself because the bean is NOT a Remote object. 27. The container implements the Remote Component interface by building a class that
: 41 : 10
1 of 5
5/15/2006 3:34 AM
Java - 200 Bullet Points from the book Head first EJB
http://www.cjsdn.net/post/view?bid=4&id=92484&sty=1&tpg=1...
implements it. This class is used to make the EJBOjbect for the bean.(The Beans bodyguard). 28. The container also creates a stub to the EJBObject. 29. you create the Remote Component Interface by writing an interface that extends javax.ejb.EJBObject (an interface that extends java.rmi.Remote) 30. You also create the bean class where the actual business methods are implemented (despite the fact that the bean class technically doesnt implement the Remote Component interface) 31. The Home is the factory for the bean. Its main job is to hand the client a reference to the bean. But remember, the client can never truly get a reference to the bean the best the client can do is to get a reference to the beans EJBObject. 32. You create the Home interface by writing an interface that extends javax.ejb.EJBHome( and interface that extends java.rmi.Remote) 33. The container is responsible for implementing the Home interface by building a class that implements it, and the container also generates the stub for the Home. 34. There is only one Home per deployed bean. For example, a ShoppingCart bean would have a single ShoppingCart Home, regardless of how many ShoppingCart beans have been created. 35. The methods of the bean are exposed to the client through the component interface. 36. The client cant directly get a reference to the bean; the client must go through the beans EJBObject, which implement the component interface. 37. The client gets a reference to the beans EJBOjbect from the beans home. 38. To get the beans home, the client does a lookup on JNDI, using the logical name under which the bean was deployed. 39. To do a JNDI lookup, the client must first get an initialContext, which is the entry point into the servers JNDI virtual directory tree 40. For a Remote home interface, the stub returned from JNDI must be both cast and narrow. 41. Narrow is exotic casting needed for the stub objects that come from a method that does not return the stubs client interface. Since the JNDI lookup return type object, the object returned from the lookup must be narrowed to the beans Home interface, and then cast to the beans home interface. 42. Narrow is required for IIOP stub(IIOP is wire protocol for CORBA), because whats return from the lookup might not be capable of implementing multiple interface, and thus would know only about the methods in type Objects. Narrowing returns an object that implements the home interface. 43. The home interface extends EJBHome, which have four additional methods the client can see: getEJBMetadata, getHomeHandle, remove(Handle h), remove(Object primarykey), The remove(Object primarykey) must not be called on Session bean. 44. You expose your beans business methods in the component interface. 45. Remote component interface must extend javax.ejb.EJBObject. 46. The client get a reference to the beans EJBOjbect by calling a method on the beans home interface. 47. Reference to both stateless bean and stateful bean are retrieved from the homes create() methods 48. From the EJBObject interface, the client sees five additional methods: getEJBHome, getHandle, remove, isIdentical and getPrimaryKey 49. Only entity bean clients are allowed to call getPrimaryKey() on the beans component interface. SessionBean clients will get a RemoteException. 50. The getEJBHome() method returns a reference to the beans home interface, so that client doesnt have to go through a JNDI lookup, if they want to make more beans of that type. 51. The getHandle() method returns a Serializable object that can be used later to reestablish contact with the server, and get back the stub to the component interface that the client used to get the handle. 52. The handle has one method, getEjbOjbect(), that returns the Remote stub as type EJBObject. That means the stub must be cast and narrowed, just as you must do with the home stub that you get from a JNDI lookup. 53. The isIdentical() method is kind of like doing an equals() method on the server. It returns true for two different stateless beans from the same home, false for two different stateful beans from the same home, and true for references to entities bean with the same primary key. 54. You can expose your bean to local client using a local client view. 55. Local component interfaces must extend javax.ejb.EJBLocalObject. Local home interfaces must extend javax.ejb.EJBLocalHome. 56. Methods in local client interfaces do not declare RemoteException. 57. Some of interface methods exposed to Remote clients are not exposed to local clients. 58. Local client cannot get handles, since handles are used to re-establish a connection to the Remote object. 59. EJBMetadata is not used with local clients, since a local client can use reflection to interrogate the EJB object and Home object. 60. Local home interface have only one remove() method the one that takes a primarykey . the remove() that takes a Handle doesnt exist in the local home interface, since Handle arent used with a local client view. 61. Because of the only remove() in the local home interface requires a primary key argument, local session bean client cant remove a bean using the beans home; they can call remove() only
2 of 5
5/15/2006 3:34 AM
Java - 200 Bullet Points from the book Head first EJB
http://www.cjsdn.net/post/view?bid=4&id=92484&sty=1&tpg=1...
on the beans component interface. 62. EJBLocalHome has only one method: remove() that takes a primary key, because the getHomeHandle(), getEJBMetedate(), and remove(Handle) methods that are in EJBHome dont apply a local view. 63. The only method in EJBObject that is not also in EJBLocalObject is getHandle(). 64. Arguments and return values are passed by value when using a local client view. In other words, theyre passed in the normal java way(object passed by a copy of reference, primitives passed by a copy of the value). 65. Local client donot need to narrow the Home reference because its a normal java reference, not a stub to a remote object. 66. Local client do not need to catch RemoteExceptions, since local interface methods dont declare RemoteException. 67. Container callbacks indicate key milestones in a beans life. 68. As a Bean Provider, youre responsible for implementing the container callbacks in your class. 69. Container callbacks comes from two places: the SessionBean interface, and the home interface. The compiler force you to implement the SessionBean interface, but the callbacks related to the home are your responsibility, and the compiler wont know, since your bean class doesnt implement your home interface. 70. A stateful session bean can be one of three states: does not exist (yes, thats state), method- ready, and passivated. 71. When a bean transitions from does not exist to method ready, its constructor is called, followed by setSessionContext(), and finally the beans ejbCreate(). 72. A bean instance has specific Bean things that it can do, but none are available during the beans constructor, because at that point it is an object but not yet a full bean. It doesnt yet have its beanness. 73. Some of Bean Things a bean can do include: get a reference to its home or EJB object, learn or affect the status of the transaction, get security information about the client, and access a resource such as a database. 74. When a stateful bean is passivated, its put into secondary storage, possible through serialization. You must be sure, by the end of your ejbPassivated() method, that your instance variables are ready for passivation. 75. The Container calls ejbRemove() method on a bean when the client calls remove(), for a stateful bean, or when the container want to reduce the size of pool, for stateless beans. If a passivate bean time out, the Container will kill the bean without invoking ejbRemove(). 76. A bean can also miss an ejbRemove() call if theres a container crash or the bean throws a runtime exception. 77. An entity is real thing that exists outside of EJB, in a persistent store, and an entity bean is an OO representation or realization of an entity. 78. Clients sue entity bean to do database operations, in an OO way. Operation include creating new entities, deleting entities, updating entity state, and searching for/on entities. 79. An entity bean Remote component interface extends EJBOjbect. Theres not a separate interface for session beans and entity beans. That means that the client will see all of the methods in your component interface, plus the five additional methods from EJBObject. 80. Entity Bean Component interface usually contain getters and setters for field values that correspond to columns in a database table, such as getLastName(), getHomePhone(), setFirstName(), etc. 81. Entity Bean Component interface methods are usually meant to be run by a specific, uniquely-identifiable entity. For example, calling getLastName() on the entity with primary key #42, returns the last name of the entity in the database with the primary key #42, James. 82. The rules for how you write an entity bean Remote component interface are the same as the rules ofr session beans, include: extend EJBObject, declare RemoteExceptions on all methods, use only RMI-IIOP types ofr arguments and return values, dont begin method names with the prefix ejb etc. 83. An entity bean home interface is substantially different from that of a session bean, because entity beans are typically found rather than created. In other words, the client is more likely to try to access an existing entity as opposed to making a new entity( which means a new row in the database). 84. In an entity home, a create() methodis not required ( since create() method in entity beans are for inserting new entities into the database, and youre not required to allow your client to do that) 85. Entity bean home interface can have single row or multi-row finder methods. Both create and finder methods return the component interface of a bean, althought multi-entity finders return a Collection of component interface reference. 86. Every entity bean home is required to have at lease one method the findByPrimaryKey() method tha searches for a particular entity and returns its component interface( i.e. a reference to that entitys EJB Object), or throws an exception. 87. Multple-entity finders do not throw an exception if not matching entities are found. They simply return an empty collection.
3 of 5
5/15/2006 3:34 AM
Java - 200 Bullet Points from the book Head first EJB
http://www.cjsdn.net/post/view?bid=4&id=92484&sty=1&tpg=1...
88. Entitle home interface can also have home business methods, for operations that apply to more than one entity, as opposed to one specific entity. Batch updates would be good use for a home business method. 89. the real benefit of home business methods is that unlike create and finder methods home business methods can return something other than an EJB object reference. If the client want only data,say, a Collection of Strings representing the name and phone number of each customer, a home business method can do that while a finder can not. 90. An entity bean create() is very different from a session bean create(), because an entity bean create() inserts a new entity into the underlying persistent store(i.e. new row in the database) 91. An entity bean remove() is dramatically different from a session bean remove(). When a client calls remove on an entity bean, its to delete the entity from the database! That means everyone is done with the bean. 92. Entity bean can have persistent relationship with other entity beans. 93. A container-managed relationship(CMR) field is defined in the bean class just as a CMP field is -- with a pair of abstract getters and setters that return either the local component interface of the bean, or a Collection. 94. If the virtual field is a Collection, it must be declared as either java.util.Collection or java.util.Set. No other Collection type is allowed as the declared return type of a CMR field. 95. Relationship have multiplicities they can be one-to-one, one-to-many, many-to-many. 96. Multiplicity affects the return type of the virtual field. Movie has only one Director, so the CMR field in the bean is getDirector(), that return a reference to a Directors local component interface. But a Director has many Movie, so a Directors virtual field is getMovie(), with return a Collection. 97. A CMP bean must define an abstract persistence schema in the DD, that lists each of the beans CMP fields, and also identifies which of the fields is the primary key ( unless its a compound primary key), The DD must always define the type of the primary key, even if the primary key is not a field of the bean. (remember, if the primary key is not a field of the bean, it must be a primary key class composed of CMP fields from the bean) 98. Relationship fields are not defined in the <enterprise-bean> portion of the DD( where you define your CMP fields), but are instead defined in the <relationship> session of the DD. 99. Each relationship must have two partners, with each partner described in an <ejb-relationship-role> element that include the CMR field name, the source for the partner, the multiplicity and an optional(<cascade-delete/> which means delete me if my partner is deleted). 100. Cascade-delete tell the Container to delete the bean with the <cascade-delete/> tag when the beans partner is deleted. This work only if the bean has a multiplicity of one. ( You wouldnt want to delete a Director just because one of this Movies was deleted; but you might want to delete a Movie if its sole Director was deleted). 101. More coming at Part 2. --------------------------------------SCJP. SCWCD. ----------------------------------------
java Ricol Re:200 Bullet Points from the book Head first EJB [Re:jamesfeng2] 2004-05-17 11:31 Thanks a lot.
: 77 : 0 specialdrink
javaweb
Re:200 Bullet Points from the book Head first EJB [Re:jamesfeng2] 2004-05-19 07:23 Very good, Ths
: 0 : 0
4 of 5
5/15/2006 3:34 AM
Java - 200 Bullet Points from the book Head first EJB
http://www.cjsdn.net/post/view?bid=4&id=92484&sty=1&tpg=1...
Java
Powered by Jute Powerful Forum Version Jute 1.5.6 Ent Copyright 2002-2006 Cjsdn Team. All Righits Reserved. ICP05005120 13606058863 [email protected] QQ 714913
5 of 5
5/15/2006 3:34 AM