These are some of the points that I made while studying and doing some mock exams. Hope it will be of some help to you people. Sorry, it's not so well organized and aligned. Do let me know if I have made any mistakes in my points. Please keep adding to this thread your points and thus we can help others who are preparing for the exam.
ALL THE BEST !!!
------------------------------------------------- EJB OVERVIEW ------------------------------------------------- 1. The following are considered to be goals of the EJB 2.0 Specification:
* Define the integration of EJB with the Java Message Service. * Provide a local client view and support for efficient, lightweight access to enterprise beans from local clients. * Provide improved support for the persistence of entity beans. * Provide improved support for the management of relationships among entity beans. * Provide a query syntax for entity bean finder methods. * Provide support for additional methods in the home interface. * Provide for network interoperability among EJB servers.
The following are goals of the EJB architecture:
* The Enterprise JavaBeans architecture will be the standard component architecture for building distributed object-oriented business applications in the Java programming language.
* Application developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling, and other complex low-level APIs.
* An enterprise Bean can be developed once, and then deployed on multiple platforms without recompilation or source code modification.
* The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime.
* The Enterprise JavaBeans architecture will be compatible with existing server platforms. Vendors will be able to extend their existing products to support Enterprise JavaBeans.
* The Enterprise JavaBeans architecture will be compatible with other Java programming language APIs.
* The Enterprise JavaBeans architecture will provide interoperability between enterprise Beans and Java 2 Platform Enterprise Edition (J2EE) components as well as non-Java programming language applications.
* The Enterprise JavaBeans architecture will be compatible with the CORBA protocols.
2.Enterprise Bean provider: The Enterprise Bean Provider is the producer of enterprise beans. His or her output is an ejb-jar file that contains one or more enterprise beans.
Application Assembler: The Application Assembler combines enterprise beans into larger deployable application units. The input to the Application Assembler is one or more ejb-jar files produced by the Bean Provider(s).
Deployer: The Deployer takes one or more ejb-jar files produced by a Bean Provider or Application Assembler and deploys the enterprise beans contained in the ejb-jar files in a specific operational environment.
EJB Server Provider: The EJB Server Provider is a specialist in the area of distributed transaction management, distribute objects, and other lower-level system-level services. A typical EJB Server Provider is an OS vendor, middleware vendor, or database vendor.
EJB Container Provider: The EJB Container Provider (Container Provider for short) provides: 1) The deployment tools necessary for the deployment of enterprise beans and 2) The runtime support for the deployed enterprise bean instances.
System Administrator: The System Administrator is responsible for the configuration and administration of the enterprise's computing and networking infrastructure that includes the EJB Server and Container.
3.Parameters are passed by value when used remotely Parameters are passed by reference when used locally.
4. When fetching frequently used read-only data, a stateless session bean should be used.
5.The SERIALIZED DD and ejb-jar MANIFEST file have been deprecated in EJB 2.0
6.Multiple clients can access the same EJBObject concurrently ( I think for stateless and entity beans).
7.Static variables should be final eg :- private static final x;
8.NON-SERIALIZABLE Objects cannot be accessed remotely.
9.Only the send part of Javamail is available to an EJB.
1.Any methods associated with a primary key defined by a local home or component interface raises a javax.ejb.EJBException if the method is invoked on a session bean. Likewise, any methods associated with a primary key defined by a remote home or component interface raises a java.rmi.RemoteException if the method is invoked on a session bean.
1. A session object�s conversational state is not transactional. It is not automatically rolled back to its initial state if the transaction in which the object has participated rolls back. If a rollback could result in an inconsistency between a session object�s conversational state and the state of the underlying database, the bean developer (or the application development tools used by the developer) must use the afterCompletion notification to manually reset its state.
2. Since a session bean instance�s conversational state is not transactional, it may need to manually reset its state if a rollback occurred.(using SessionSyncronization)
3. The container may not call the beforeCompletion method if the transaction has been marked for rollback (nor does the instance write any cached updates to the database).
4. A session bean can be passivated only between transactions, and not within a transaction.
5. The ejbRemove() method cannot be called when the instance is participating in a transaction.
6. A session bean instance can participate in at most a single transaction at a time. (Also don't try to interrupt this transaction from the client side, by calling this same method in a diff tx or in an unspecified tx).
7. The home interface of a stateless session bean must have one create method that takes no arguments.
8.Transaction in stateless Session beans :- Because all instances of a stateless session bean are equivalent, the container can choose to delegate a client-invoked method to any available instance. This means, for example, that the Container may delegate the requests from the same client within the same transaction to different instances, and that the Container may interleave requests from multiple transactions to the same instance.
9. A stateless session bean must not implement the javax.ejb.SessionSynchronization interface.
10. All beas(session/entity) should have a public constructor that takes no parameters. The Container uses this constructor to create instances of the session bean class.
12.RemoteException from Business methods:- EJB 1.0 allowed the business methods to throw the java.rmi.RemoteException to indicate a non-application exception. This practice was deprecated in EJB 1.1�an EJB 1.1 or EJB 2.0 compliant enterprise bean should throw the javax.ejb.EJBException or another RuntimeException to indicate non-application exceptions to the Container (see Section 18.2.2). An EJB 2.0 compliant enterprise bean should not throw the java.rmi.RemoteException from a business method.
(MAKE THIS CLEAR !!!)
13.The remote interface methods must not expose local interface types, local home interface types, or the managed collection classes that are used for entity beans with container-managed persistence as arguments or results. Because a Local Home/object won't know how to marshall a method call since it's outside the JVM and also it uses RMI instead of RMI-IIOP.
14.The methods for a stateless session bean must be named �create� and �ejbCreate�. And not create<METHOD>.
15. The throws clause of a method defined in the local interface/local home interface must not include the java.rmi.RemoteException.
16.The container generated classes "implements" the interfaces the bean developer writes.
The deployment tools are responsible for implementing the handle classes for the session bean�s remote home and remote interfaces.
The deployment tools are responsible for implementing the class that provides meta-data to the remote client view contract.
17.Note that a session object is intended to support only a single client. Therefore, it would be an application error if two clients attempted to invoke the same session object. BUT --> In a case with the stateless session beans one bean instance can service multiple clients as long as the clients are not concurrent.
220.127.116.11 (MAKE THIS CLEAR !!!)
19.All methods in the remote home and remote component interfaces are defined to throw "java.rmi.RemoteException". (And NOT javax.rmi............).
20.A session bean's conversational state is not transactional and is not automatically reset to its initial state if a transaction is rolled back. The afterCompletion notification may be used to manually reset the bean instance's conversational state in the event of a transaction roll back.
21.New stateless session bean instances are created when is it necessary to handle an increase in client work load. Also the container decides when to remove the session object, no matter whether the client called remove or not.
22.The "java:comp/env" environment space is only used for EJB references *inside* the server. External lookups in remote client should use the "real" JNDI name of your EJB. Dig around to figure out what this is. Possibilities include "ejb/Ordine" or "Ordine".
23.Session beans executes on behalf of only one client at a time.
24.If a session bean implements SessionSynchronization interface, then the app assembler may ONLY SPECIFY Required, RequiresNew or Mandatory attributes
25.Create methods can be OVERLOADED , EXCEPT for stateless Session beans.
1.the persistent state of the instance at the beginning of the ejbRemove() method is the same as it would be at the beginning of a business method. The container must invoke ejbLoad before it invokes ejbRemove().
2.Entity beans should be in the same local scope if they have a relationship.
3. The bean proider can manipulate the relationships at runtime via get and set accessor method.
4.For ejbSelect method, the container should make sure that no duplicates are returned.
5.Invoking javax.ejb.EJBContext.getUserTransaction() in an entity bean instance method results in java.lang.IllegalStateException because entity beans must always use container-managed transactions.
6.In ejbActivate, initialize transient fields. Since the transient fields are not preserved while serialization- deserialization process, you need initialize such fields to appropriate values in ejbActivate() method
7.Customer 0..1 ----------- 0..* Address What will be the result of the follow method call made by a client? somecustomer.setAddresses(null);
This call is illegal. It should pass an empty Collection object if it wants to remove all the addresses for a customer.
8.With container-managed persistence, the container performs the database insert after the ejbCreate(...) method completes (anytime after this).
9.The Container must establish the primary key before it invokes the ejbPostCreate(...) method.
10.The container synchronizes the instance�s state before it invokes the ejbRemove method. This means that the state of the instance variables at the beginning of the ejbRemove method is the same as it would be at the beginning of a business method.
ejbActivate()/ejbLoad is called prior to calling ejbRemove().
To synchronize instance's state, call ejbLoad(). To synchronize entity object's state in db, call ejbStore().
11.Valid types of persistent CMP fields of a 2.0 CMP entity bean A primitive type. All serializable types
12.Caller of the finder method must always be prepared for FinderException.
13.The lack of a local interface prevents other entity beans from having a relationship to it.
14.The abstract-schema defines the bean's persistent fields and relationships. It is used ONLY with CMP.
15. All static fields in the bean should be marked FINAL.
16.CMR can only exists among entity beans with the same LOCAL RELATIONSHIP SCOPE
17.For ejbSelect method, the container should ensure that NO DUPLICATES are returned.
19.Multi-object finders:- The collection of values returned by the Container may contain duplicates if DISTINCT is not specified in the SELECT clause of the query for the finder method. A client program must use the PortableRemoteObject.narrow(...) method to convert the objects contained in the collections returned by a finder method on the entity bean�s remote home interface to the entity bean�s remote interface type.
20.Return Types:- finder methods :- EJBObjects or EJBLocalObjects of the same type as the entity bean (or collection of it) select methods :- EJBObjects, EJBLocalObjects, or cmp-field types (or collection of it), or cmr-field types (or collection of it).
21.If a single object return finder/select method returns more than one values, then it should throw a FinderException.
22.<cascade-delete> The cascade-delete element can only be specified for an ejb-relationship-role element contained in an ejb-relation element if the other ejb-relationship-role element in the same ejb-relation element specifies a multiplicity of One. The cascade-delete option cannot be specified for a many-to-many relationship.
24.Home methods cannot be declared static.. ( ie it can be declared final) Select methods can be declared static and final. (well, this is abstract by default) create method/business method cannot be declared final OR static
25.The Container MUST establish the primary key BEFORE it invokes the ejbPostCreate<METHOD>(...) method.
26.The instance is in the READY STATE when ejbRemove() is invoked and it will be entered into the POOL when the method completes. The container synchronizes the instance�s state before it invokes the ejbRemove method
27.For CMP, no need to define a default constructor. A default one will be provided.
28.ejbLoad(), ejbStore() and business methods can be called in ANY order.
29.Container needs to call ejbActivate(), ejbLoad() before it can call a ejbRemove().
30.ejbLoad(), ejbRemove(), ejbSelect() --> runs in the tx context of the method that causes it's invocation.
31.<res-sharing-scope>shareable</..> Other beans in the same app using the same resource, in the same tx can share.
34.BEWARE OF the word "EXISTING OBJECT" and "NEW OBJECT".
------------------------------------------------- EJB QL ------------------------------------------------- 1.domain of a query may be restricted by the navigability of the relationships of the entity bean on which it is based. The cmr-fields of an entity bean's abstract schema type determine navigability. Using the cmr-fields and their values, a query can select related entity bean's and use their abstract schema types in the query. The '.' operator is the navigation operator used to navigate through container managed relationships.
2.The data model for container-managed persistence does not support inheritance. For this reason entity objects or value classes of different types cannot be compared. Any EJB QL queries that contain such comparisons are invalid.
3.Another restriction regarding the use of EJB QL is that date and time values should use the standard Java long millisecond value.
4.The following are the reserved identifiers in EJB QL: SELECT, FROM, WHERE, DISTINCT, OBJECT, NULL, TRUE, FALSE, NOT, AND, OR, BETWEEN, LIKE, IN, AS, UNKNOWN (not used as yet but reserved), EMPTY, MEMBER, OF and IS.
5.IS NULL is used to test whether a cmp-field or single-valued cmr-field value is NULL. IS EMPTY tests whether or not the collection designated by the collection-valued path expression is empty (i.e., has no elements). (A collection-valued path expression can only be used in the WHERE clause in an empty collection comparison expression or in a collection member expression.)
6.must define names used by entity beans in query : - Abstract Persistance Schema can be declared in a FROM clause optionally using AS or IN :- Identification Variables constrain the query domain :- Path Expressions way to reference arguments from finder and select methods :- Input Parameters
operators (+ - * /) comparisons (= > >= < <= <> , for strings only = and <> NOT BETWEEN arithmetic-expression AND arithmetic-expression IN: value IN (value1, value2, ...) LIKE, using wild card characters _ and % null comparison: IS NULL empty comparison: collection-valued-path-expr IS EMPTY collection member expression: MEMBER OF collection-valued-path-expr functional expressions: CONCAT, SUBSTRING, LOCATE, LENGTH, ABS, SQRT
10.A null comparison expression tests whether or not the single valued path expression is a NULL value. Path expressions containing NULL values during evaluation return NULL values.
NameAge Joe Bloggs35 Dave Smith32 Steve Jones36X Sid Young27 Simon Wood54X
Select all Customers whose name begins with S and are older than customer Joe Bloggs
Select Object(c1) from Customer c1,Customer c2 where c1.age > c2.age and c2.name='Joe Bloggs'
------------------------------------------------- EXCEPTIONS ------------------------------------------------- 1. Calling remove twice on a bean results in java.rmi.NoSuchObjectException. similarly, calling a business method on an already removed bean.
2.Invoking javax.ejb.EJBContext.getUserTransaction() in an entity bean instance method results in java.lang.IllegalStateException because entity beans must always use container-managed transactions.
3.When the bean provider tries to reset the primary key value by means of a set method on any of the CMP fields after it has been set in the ejbCreate method, it throws IllegalStateException.
5.The container does not always throws a RemoteException when the tx is rolledback, but it MAY rollback the tx when the remoteException occurs.
6.The Container MUST detect an attempt to assign a removed entity object as the value of a cmr-field of another object (whether as an argument to a set accessor method or as an argument to a method of the java.util.Collection API) and throw the java.lang.IllegalArgumentException.
9.If the container fails to start or commit a CMT, the container must throw RemoteException/EJBException (For MDB- EJBException)
10.RemoteException/EJBException - indicates a failure to invoke an enterprise bean method or to properly complete it's invocation.
11.If a client receive's RemoteException/EJBException, he can (a) Discontinue Tx :- By calling rollback() or throwing a RuntimeException (if it's not the tx orginator) (b) Continue Tx :- By first enquiring the tx status and then committing it.
12.In case of a CMT:- If the bean method throws an application exception but does not mark the transaction for rollback, the container will commit the transaction before re-throwing the application exception to the client. If the bean method marks the transaction for rollback, the container will roll back the transaction before re-throwing the application exception to the client.
------------------------------------------------- BEAN ENVIRONMENT ------------------------------------------------- 1.The system administrator is responsible for adding, removing and configuring resource managers in the EJB environment.
2.Can Environment entries can be shared with different enterprise beans ???
3."<res-auth>Container</res-auth>" Since the value of the res-auth element is Container, the deployer is responsible for configuring the sign-in information of the resource manager by supplying the principle mapping information. On the other hand, if the value of the res-auth element was Application the bean provider would be responsible for performing a sign-on to the resource manager programmatically in the enterprise bean code.
4.Managed Resources :- The connections acquired through the resource manager connection factory references are called managed resources. Managed by J2EE container itself. Administered Objects :-Managed by a separate server like a JMS provider or a JavaMail server.
5.Enterprise bean instances are NOT ALLOWED to modify the bean's environment at runtime.
6.Environment entry is INACCESSIBLE from other enterprise beans at runtime, and that other enterprise beans may define env-entry elements with the same env-entry-name without causing a name conflict.
7.<env-entry> are NOT UNIQUE for instances of the same bean type. They share.
------------------------------------------------- MESSAGE BEAN ------------------------------------------------- 1.The following are the requirements for the message-driven bean class:
The class must implement, directly or indirectly, the javax.ejb.MessageDrivenBean interface. The class must implement, directly or indirectly, the javax.jms.MessageListener interface. The class must be defined as public, must not be final, and must not be abstract. The class must have a public constructor that takes no arguments. The Container uses this constructor to create instances of the message-driven bean class. Each message-driven bean class must have one ejbCreate method, with no arguments. The class must not define the finalize() method.
2.The order is not guaranteed for javax.jms.Topic (but it is for javax.jms.Queue)
3.Container may create multiple instances of the bean but one message will be given to only one bean instance whether it is bound to a queue or topic.
4.Only one thread will execute a MDB instance at a time.
5.A message-driven bean does not have to be coded as reentrant. A container allows many instances of a message-driven bean class to be executing concurrently.
6.By default, there is NO tx attribute for onMessage()
7.If a durable topic subscription is used (also Queues), then even if the EJB Server is NOT running, the messages will NOT be missed. Non-durable Topics can be missed
8.A container may create multiple instances of the bean but one message will be given to only one bean instance whether it is bound to a queue or topic.
------------------------------------------------- SECURITY ------------------------------------------------- 1.If a security role is defined but not used in any method-permission elements it does not mean that the role has permission to invoke all methods. A caller with this role will have the same rights as a caller without a specified security role.
2.The responsibilities as described in the EJB specification state that the Bean Provider and Application Assembler should describe all the requirements for the caller's principal management of inter-enterprise bean invocations as part of the description.
3. The Deployer's Role :- - Along with the Application Assembler define the appropriate security policies for the application. - Setting up the appropriate security policy for the enterprise bean application. - Along with the System Administrator setting up of the principal delegation in a Container-specific way.
4.isCallerInRole :- It tests whether the caller of the bean belongs to the role that is passed as a parameter to this method
Returns the principal that represents the CALLER of the enterprise bean, not the principal that corresponds to the run-as security identity for the bean, if any.
boolean isCallerInRole(String roleName);
Tests the principal that represents the CALLER of the enterprise bean, not the principal that corresponds to the run-as security identity for the bean, if any.
5.Security Policies can be hard-coded but the bean provider is encouraged to write the business methods WITHOUT any security logic.
------------------------------------------------- TRANSACTION ------------------------------------------------- 1.When an instance attempts to start a transaction using the begin() method of the javax.transaction. UserTransaction interface while the instance has not committed the previous transaction, the Container must throw the javax.transaction.NotSupportedException in the begin() method
2.The Container must throw the java.lang.IllegalStateException if an instance of a bean with bean-managed transaction demarcation attempts to invoke the setRollbackOnly() or getRollbackOnly() method of the javax.ejb.EJBContext interface.
3. If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke the getUserTransaction() method of the EJBContext interface, the Container must throw the java.lang.IllegalStateException.
4.When the container starts a transaction, it is responsible for controlling the transaction when it receives an exception. If the bean method throws an application exception but does not mark the transaction for rollback, the container will commit the transaction before re-throwing the application exception to the client. If the bean method marks the transaction for rollback, the container will roll back the transaction before re-throwing the application exception to the client.
5.The container always discards an enterprise bean instance because the bean may end up in an inconsistent state as a result of the non-application exception thus becoming unsafe for further use.
Discarding the bean prevents both the container and the client from further invoking methods on the bean.
Unlike business methods of a session or entity bean, message-driven bean methods do not throw application exceptions.
The container is responsible for performing any clean up actions before throwing a non-application exception.
The container is not responsible for committing or rolling back transactions that have been initiated by the client.
6.The container is only responsible for rolling back a system exception for an message-driven bean with container-managed transaction demarcation and when the bean method runs in the context of a transaction started by the container.
A transaction is not rolled backed by the container as a result of a system exception thrown when the transaction runs with an unspecified transaction context and also when a bean is declared with bean-managed transaction demaraction.
7.If a remote client in a transaction context invokes a business method on a bean with container-managed transaction and the bean throws a non-application exception, the transaction is marked for rollback. The client then receives javax.transaction.TransactionRolledbackException (subclass of java.rmi.RemoteException) which indicates that the transaction has definitely been marked for rollback.
8.An application assembler cannot affect transactional behaviour for enterprise beans that use bean-managed transaction demarcation. The application assembler can only affect transactional behaviour of beans that use container-managed transaction demarcation.
9.An entity beans can only use the CMT (IS THIS NOT CMP ???)
10.Only Session Beans and Message driven beans can be designed to use Bean Managed Transaction demarcation. Entity beans can only be designed to use Container Managed Transaction demarcation.
11.getRollbackOnly() and setRollbackOnly() should be ONLY invoked from methods having Required, RequiresNew, Mandatory attribute. Otherwise it throws an IllegalStateException.
12.The Enterprise JavaBeans architecture supports FLAT transactions. A flat transaction cannot have any child (nested) transactions.
13.If an enterprise bean implements the javax.ejb.SessionSynchronization interface, the Application Assembler can specify only the following values for the transaction attributes of the bean's methods: Required, RequiresNew,or Mandatory. This restriction is necessary to ensure that the enterprise bean is invoked only in a transaction. If the bean were invoked without a transaction, the Container would not be able to send the transaction synchronization calls.