Java开发网 - 200 Bullet Points from the book” Head first EJB”

Topic: 200 Bullet Points from the book” Head first EJB”

1.200 Bullet Points from the book” Head first EJB”

Posted by: jamesfeng2
Posted on: 2004-05-17 10:52

As I’m 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 object’s 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 skeleton’s work must be done by something on the server, we don’t have to care who- or what – is actually doing the skeleton’s 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 isn’t 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 object’s local heap.
22.  If a remote object is passed as an argument or return value, the object’s 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 implements it. This class is used to make the EJBOjbect for the bean.(The Bean’s 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 doesn’t 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 bean’s 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 can’t directly get a reference to the bean; the client must go through the bean’s EJBObject, which implement the component interface.
37.  The client gets a reference to the bean’s EJBOjbect from the bean’s home.
38.  To get the bean’s 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 server’s 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 stub’s client interface. Since the JNDI lookup return type object, the object returned from the lookup must be narrowed to the bean’s Home interface, and then cast to the bean’s home interface.
42.  Narrow is required for IIOP stub(IIOP is wire protocol for CORBA), because what’s 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 bean’s business methods in the component interface.
45.  Remote component interface must extend javax.ejb.EJBObject.
46.  The client get a reference to the bean’s EJBOjbect by calling a method on the bean’s home interface.
47.  Reference to both stateless bean and stateful bean are retrieved from the home’s 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 bean’s component interface. SessionBean clients will get a RemoteException.
50.  The getEJBHome() method returns a reference to the bean’s home interface, so that client doesn’t 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 doesn’t exist in the local home interface, since Handle aren’t 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 can’t remove a bean using the bean’s home; they can call remove() only on the bean’s 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 don’t 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, they’re 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 it’s a normal java reference, not a stub to a remote object.
66.  Local client do not need to catch RemoteExceptions, since local interface methods don’t declare RemoteException.
67.  Container callbacks indicate key milestones in a bean’s life.
68.  As a Bean Provider, you’re 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 won’t know, since your bean class doesn’t implement your home interface.
70.  A stateful session bean can be one of three states: does not exist (yes, that’s 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 bean’s ejbCreate().
72.  A bean instance has specific Bean things that it can do, but none are available during the bean’s constructor, because at that point it is an object but not yet a full bean. It doesn’t 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, it’s 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 there’s 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. There’s 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, don’t 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 you’re 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 entity’s 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.
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, it’s 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 Director’s local component interface. But a Director has many Movie, so a Director’s 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 bean’s CMP fields, and also identifies which of the fields is the primary key ( unless it’s 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 bean’s partner is deleted. This work only if the bean has a multiplicity of one. ( You wouldn’t 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.
----------------------------------------

2.Re:200 Bullet Points from the book” Head first EJB” [Re: jamesfeng2]	Copy to clipboard
Posted by: Ricol Posted on: 2004-05-17 11:31 Thanks a lot.

3.Re:200 Bullet Points from the book” Head first EJB” [Re: jamesfeng2]	Copy to clipboard
Posted by: specialdrink Posted on: 2004-05-19 07:23 Very good, Ths