Following short-notes I made while preparing for SCBCD. I hope it may help others in pursuit of the same.
(DISCLAIMER: IT MAY HAVE FEW INCONSISTENCIES, CONSULT EJB SPECS WHENEVER IN DOUBT)
1. Method getEJBMetaData() is defined in which interface? EJBHome
2. Stateless Session Bean
When client invokes create(), its not deligated to bean instance�s ejbCreate()
Never passivated / activated so ejbActivate() / ejbPassivate() never invoked
When client invokes one of remove() methods, its not delegated to bean instance�s ejbRemove() method. ejbRemove() is invoked by the container whenever it don�t need the bean instance anymore
Session context and JNDI ENC are available to the bean when executing ejbRemove()
Which of the methods can be invoked on a stateless session bean when its in method ready state
From business methods only we can access resource manager and other beans but not from ejbRemove() or ejbCreate()
Remember, from ejbCreate() u cant access another bean
From setSessionContext, you can�t access your EJBObject � it�s executed before any client makes any call.
Must not implement SessionSynchronization.
MDB can throw system exceptions upon which, the container discard the bean instance, however those exceptions are not propagated to the client as there is no client � due to the same reason, MDBs cant throw application exception.
When system exception occurs in a session bean, the bean instance is discarded, thus client�s conversational state is lost and the bean instance�s reference held by the client is invalidated.
If an entity bean instance method is executing in a client�s transactional context and throws a system exception, the exception is throws again as TransactionRolledbackException to remote client and TransactionRolledbackLocalException to local client.
(javax.ejb.) CreateException, RemoveException and FinderException are application exception
javax.transaction.TransactionRolledbackException is subclass of java.rmi.Remote and javax.transaction.TransactionRolledbackLocalException is subclass of javax.ejb.EJBException � both are system exception
NoSuchEntityException is subclass of EJBException � so system exception � thrown to indicate that underlying entity has been removed from the database
Javax.ejb.ObjectNotFoundException is subclass of javax.ejb.FinderException, which is an application exception throws by single entity finder methods � if no mathcing primayr key is found.
4. Guaranteed capabilities of EJB 2.0
To provide local client view and support for efficient, lightweight access to enterprise beans from local clients
To provide network-interoperability between EJB servers
Read only CMP entity beans may or may not be supported
Attached to a message destination, not any client
Supports bean managed transaction (BMT) demarcation but not bean managed persistence (BMP)
They are stateless component, so don�t maintain conversational state
MessageDrivenBean interface defines two methods � ejbRemove() and setMessageDrivenContext()
For MDB if <security-identity> is specified, <use-caller-identity> can�t be used as it has no client-view. Only <run-as> can be specified. <run-as> is used when bean is to act as someone other than the calling client. This new identity (<run-as>
would be used when call to other EJB would be made.
6. Stateful session bean
Transient variables are not passivated
Home and component interface types are passivated
If bean timeouts during passivated state, its ejbRemove() is not invoked
Access to resource manager and other beans are not allowed from bean constructor, setSessionContext, and afterCompletion. From other methods � ejbCreate, business methods and beforeCompletion its allowed.
A stateful session bean calculates compound interest based on the interest rate, which can be read by the bean at run-time. This is achieved with env-entry element in the deployment descriptor.
When client invokes create() method on bean�s home interface, Class.newInstance() is invoked, sessionContext is set and appropriate ejbCreate<METHOD>() is called. Now bean is in method-ready state.
The container passivate the bean, and after time-out remove bean instance by calling ejbRemove().
What do local and remote component interfaces of session bean have in common?
Removing the session bean & Retrieving their respective home interface
Creating a new session bean is responsibility of remote/local home
7. Entity bean
Which method of local home interface takes primary key type as an argument and return type is entity�s local interface � findByPrimaryKey � this method cant be overloaded
An entity bean always uses CMT � so a bean itself can�t manage its own transaction. Its not even allowed to retrieve UserTransaction object from JNDI ENC and invoke methods on it. If it tries to, the container would throw java.naming.NameNotFoundException.
Interface javax.ejb.HomeHandle must be implemented by an entity bean�s home handle class.
Only ejbActivate(), ejbPassivate(), setSessionContext(), unsetSesionContext() runs in �unspecified transaction context� otherwise all others need transactional context or u get java.lang.IllegalStateException.
An entity bean can be passivated only when it�s in (method) ready state. It can be passivated just after being activated as after activation it comes to ready state.
8. DD - EJB Reference (<ejb-ref>
Its responsibility of bean provider to declare all ejb references in DD
EJB Reference is scoped to the enterprise bean whose declaration contains <ejb-ref> or <ejb-local-ref> element. This means EJB Reference is not available to other enterprise beans at run-time and other enterprise beans may define <ejb-ref> or <ejb-local-ref> element with the same name without causing a name conflict.
<ejb-ref> element contains description, <ejb-ref-name>, <ejb-ref-type>, <home> and <remote> elements
<ejb-ref> element is used for referencing an enterprise bean that is accessed through its remote home and remote interface. It�s required child elements are <ejb-ref-name> (specified ejb reference name, its name is used in bean code), <ejb-ref-type> (specifies bean type � session or entity), <remote> and <home> (referenced bean�s remote and home interface). <ejb-link> (optional, used by assembler to link to target bean, must be equal to corresponding bean�s <ejb-name>
and <description> are optional fields.
9. Entity bean � primary key
Primary key fields cant be modified by the client once it is set
Primary key fields must follow RMI-IIOP as being used in remote invocation
In some cases bean provider may choose not to specify primary key class or field, in that case primary key class / field would be specified at deploy time
The primary bean class must be public, implement java.io.Serializable and have public no-arg constructor. All fields in primary key class must be public.
The name of fields in primary key class must be subset of CMP fields.
There must not be any mutator (set<FIELD_NAME>
in component interface for any of primary key fields.
If the <use-caller-identity> is specified as child of <security-identity> element, the called enterprise bean will always see the same returned value of EJBContext.getCallerPrincipal() as the calling enterprise bean.
DD : Security role reference <security-role-ref>
Defined by bean provider. Scoped within session or entity bean whose declaration contains <security-role-ref>
<role-name>Administrator</role-name> //hard coded by bean provider
<role-link>Root</role-link> //defined in <security-role> by assembler
11. EJBs Requirements
EJBs are not allowed to create or install a new security manager, as this would create a security risk.
EJBs are allowed to invoke Class.getResource in order to retrieve bundled resources (text, images, properties etc), bundled within the same enterprise application archive.
EJBs are not allowed to return or pass �this� as an argument to another bean�s method, but they are allowed to use �this� reference to access its their own members.
EJBs are not supposed to use synchronized block or declare their methods to be synchronized
12. EJB Recommendation
Organize all references to enterprise beans in ejb sub-contexts
Organize all references to JDBC datasource in jdbc sub-context
Organize all resource environment reference to in jms sub-context
13. DD - <res-auth>
Used when sign-on procedure for a resource manager must be specified
Two possible values
Application � means enterprise bean sign-on programmatically to the resource manager
Container � means the container would perform sign-on on behalf of the application using information provided by the deployer
Methods defined in this interface
getCallerPrincipal, isCallerInRole (client)
getRollbackOnly, setRollbackOnly (CMT)
public void java.security.Principal getCallerPrincipal()
Session context defines additional methods: getEJBObject(), getEJBLocalObject
Entity context defines additional methods: getEJBObject(), getEJBLocalObject(), getPrimaryKey()
MessageDrivenContext don�t defines any additional methods
EJB-QL defines &, ==, != as AND, =, <>
What if a bean with CMT tries to retrieve a UserTransaction object through JNDI by looking up the java:comp/UserTransaction name?
The container would throw javax.naming.NameNotFoundException
What is counterpart of javax.transaction.TransactionrequiredException for local clients?
Javax.ejb.TransactionRequiredLocalException � these two exceptions are throws to remote / local clients whenever a system exception is thrown from a method that runs in caller�s transaction context (possible with mandatory, supporrts and required attributes)
<transaction-type> element is used to specify which transaction type � CMT or BMT being used. As entity bean can only use CMT, this element can only be specified for Session and Message beans. This is responsibility of bean provider.
When a business methos that executes in the transactional context of caller and throws javax.ejb.EJBException � the container is required to throw javax.ejb.TransactionRollbackLocalException to the client (local)
If the business method�s transactional attribute were mandatory and the client (local) were trying to access it without a transactional context, it would receive javax.transaction.TransactionRequiredLocalException
A bean which want to use SessionSynchronization (except of course, stateless bean) must not use transactional attributes of Never, NotSupported or Supports. Bean has to be in transactional state before it can ask for its transactional status.
For portability, an entity bean must use Required, RequiresNew or Mandatory.
To use EJBContext�s setRollbackOnly()/getRollbackOnly() the TA must be Required, RequiresNew, Mandatory.
The assembler uses <container-transaction> to define transactional attributes
If methods are overloaded <method-params> and <method-param> could be used.
BMT � provider uses javax.transaction.UserTransaction to explicitly demarcate transactions. Pseudo code:
UserTransaction ut = ejbContext.getUserTransaction();
17. Environment Context
Following string used for JNDI lookup of managed server resources (JMS resources) � java:comp/env/jms/StockQueue
18. Apart from <ejb-name> in <relationship-role-source> which other element should an assembler never modify - <abstract- schema-name>
19. Write class name that is used to perform type-narrowing of client side representation of remote interface. � javax.rmi.ProtableRemoteObject
20. Which DD element is used to specify entity bean type in EJB-QL?
21. Child elements of <ejb-jar>
22. BMT (session and message driven) are responsible for managing their own transactions � they can start new transaction (using context.getUserTransaction()) in any method except for setSessionContext()/SetMessageDrivenContext()
23. CMT Session and Message Driven beans� create method runs in �unspecified transaction context�
24. Which DD element bean provider can use to tell deployer which destination a message driven bean should be associated with - <destination-type> (value � javax.jms.Queue / javax.jms.Topic)
25. Only for stateless session bean (both BMT & CMT) there exists the restriction that a transaction must not span multiple method calls � which means for others (stateful � both BMT & CMT - and enitty ) a transaction can span multiple method calls. [bit doubtful � in CMT transaction scope is method-level � so a transaction will only span for a single method call � verify this)