SCBCD CX310-091: Short Notes: Exam passing tips

SCBCD CX310-091: Short Notes: Exam passing tips

Rating:

EJB 3.0 Overview

• EJB 3.0 specification does not require a session bean to implement the javax.ejb.SessionBean interface. A session bean puts all the business methods into a business interface.


• The EJB container for version 3.0 must provide support for persistence. However, it may or may not support load balancing.


• EJB 3.0 specification requires that all the instances of the same enterprise bean must have the same JNDI API name space.


• All EJB 3.0-compliant components must work within any Java EE 5 application server.


• According to the EJB specification, static variables in a bean should be marked final.


• An EJB 3.0 bean should not use AWT to input an information from keyboard or output it to a display. Also, files should not be accessed using the java.io package.


• The Bean Provider is responsible for writing the Java classes to implement the business methods and interfaces. He is also responsible for providing declarative specification and external dependencies, either through the use of annotation or deployment descriptor.


• The Bean Deployer takes the ejb-jar files provided by a bean provider or an Application Assembler and uses the deployment tools from the EJB Container Provider to deploy these files.


• The Container Provider is responsible for providing the tools that are required for the deployment of the beans. He must ensure that the development environment transaction is enabled, scalable, and secure.


• The Persistence Provider provides a standard API between the persistent entities and the object/relational runtime.


• The System Administrator is involved in security management, administration of enterprise's computing and networking infrastructure, and proper execution of deployed enterprise application at runtime.


• An ejb-jar file is a contract between the Bean Provider and the Application Assembler. It is also a contract between the Application Assembler and the Bean Deployer.


• The ejb-jar is a jar file that contains the deployment descriptor and other files necessary for the deployment of an enterprise bean.


• The ejb-jar file can be edited by the Bean Provider, the Bean Deployer, and the Application Assembler.


• When both the deployment descriptor file and annotations are present in an EJB application, the deployment descriptor configuration will override the annotation configuration.

• A message-driven bean should not throw any checked exception.


• The PostConstruct callback method is invoked on a bean instance after the container performs any dependency injection.


• The PostConstruct callback of a message-driven bean class can have any name. However, it must have the return type as void, cannot have any parameter, and cannot declare any checked exception.


• A message-driven bean has two states, namely 'does not exist' and 'method-ready pool'.


• The PreDestroy callback method is invoked on a bean instance before a bean instance is removed from the pool of instances. This method is used to release any resource, such as a database connection that the bean instance holds.


• An interceptor instance is created when a bean instance is created. Similarly, it is passivated, activated, or destroyed when, the associated bean instance is passivated, activated, or destroyed, respectively.


• The AroundInvoke method is supported for session and message-driven beans. This method can have any access modifier.


• The environment entries are represented in the deployment descriptor using the < env-entry > element. The environment entries are valid for a single bean. Two different beans can have environment entries with the same name. However, two environment entries within a bean cannot have the same name.


• The JNDI service is used in EJB to ensure that a client can access the enterprise bean and use its methods by providing multiple naming and directory services.


• The @Resource annotation is used to inject resources in an EJB application. This annotation can be applied to a class, a field, or a method.


• The @PersistenceUnit annotation is used to declare a dependency on an EntityManagerFactory. It can be applied to a class, a field, or a method.


• The @PersistenceContext annotation is used to declare a dependency on an EntityManager persistence context. It can be applied to a class, a field, or a method.


• A bean can implement a timeout callback by implementing the javax.ejb.TimedObject interface.


• A timeout callback method contains the business logic to handle EJB timeouts. The container calls this method when the time specified for the timer has elapsed.


• Programmatic security, also known as instance security, is implemented using the methods of the EJBContext interface.


• If the version attribute of the deployment descriptor is set to 2.1, the container will not recognize the annotations used for EJB 3.0. This means that code written for EJB 3.0 using dependency injection will be ignored.


• The methods of the EJB 3.0 beans can be invoked from EJB 2.1 by using the @RemoteHome and @localHome annotations. A developer can package session beans written using EJB 2.1 and EJB 3.0 in a single module.


• The @Init annotation is applied on a method of a stateless session bean to specify that the method will behave similar to the create< method > method of EJB 2.x version.

• A session bean is a kind of enterprise bean created by a client for the duration of a single client session. They do not survive container crashes.


• The container creates instances of a stateless session bean and keeps them in a pool of instances. When there is a method call from a client, the container calls an instance from the pool. The bean instance services the client and goes back to the pool. This instance can be used again later for the same or another client call.


• A stateful session bean must be annotated with the @stateful annotation or denoted in the deployment descriptor as a stateful session bean. It is not required for a stateful session bean to implement the javax.ejb.Session Bean interface.


• If the type of the business interface is not specified for a session bean, it will be a local interface.


• A stateful session bean is destroyed after servicing a client, whereas a stateless session bean can service multiple clients in its life.


• A business interface of a session bean is an ordinary Java interface that contains the business methods for the bean.


• A stateless session bean does not have the @PrePassivate and @PostActivate annotated methods.


• The equals() method returns true when two references to the same business interface type of the same session bean are compared. It returns false when the session bean references to either different business interface types or when different session beans are compared.


• System exceptions are wrapped in the javax.ejb.EJBException before being passed to a client.


• The java:comp/env entry is used to bind the resource objects to the environment context.


• The < res-type > element contains the type of the resource manager connection factory, which is the name of the interface that the resource manager connection factory object will implement.


• The getBusinessObject(Class businessInterface) method is used to obtain the business interface of a session bean. Only session beans with an EJB 3.0 business interface can call this method.


• The web service endpoint interface extends the java.rmi.Remote interface, and all the methods of the interface must throw the RemoteException.


• The @WebMethod annotation is applied to a method to declare it as a Web service method. If this annotation is not used in a class annotated with the @WebService annotation, then all the methods of the class are available to the Web service.


• The arguments and results of the methods of the remote business interface are passed by value, whereas the arguments and results of the methods of the remote business interface are passed by reference.

• The Container Provider is responsible for managing the instance of the bean class at runtime and ensuring that only one thread is executed at a time.


• The methods of the EJBContext interface such as getRollbackOnly and setRollbackOnly cannot be called from the onMessage() method within the Bean-managed transaction demarcation.


• A JMS message-driven bean must implement the MessageListener interface. Hence, the class must provide implementation to the onMessage() method.


• The acknowledgement mode in JMS can be specified using the ActivationConfigProperty element of the @MessageDriven annotation.


• The methods of the EJBContext interface can be called on a bean with the container-managed transaction. The Required transaction attribute is the default attribute. If a method is called with an existing transaction context, the method runs in that transaction. However, if no transaction exists, a new transaction is created by the container.


• A message-driven bean has no business interface and is never invoked directly by a client. Hence, there is no caller, and using the isCallerInRole() method will throw the IllegalStateException.


• A JMS topic ensures that multiple beans can receive a message. Multiple consumers subscribe to a topic so that when a message arrives at the topic, they can receive the message.


• Subscription durability is used for a JMS message driven bean that uses the javax.jms.Topic to specify whether the subscriber is durable or non-durable.

• An EJB 3.0 entity class must have a no argument constructor. The access level of this class must be public or protected. The entity class can also have other constructors with parameters and any access modifier.


• An entity class can extend a non entity class and a non entity class can extend an entity class.


• A mapped superclass can be an abstract or a concrete class. It has no separate table defined for the class.


• An embeddable object is a persistent object that is embedded as a part of an entity class. They do not have their own identity and belong to the entity in which they are embedded.


• A valid entity class must have a no-argument constructor and must have the access modifier as public.


• If property-based access is used, the properties of the primary key class must be public or protected.


• The @Id annotation is used to identify a property that makes up a primary key of a table. It marks a field or a property as an identity of an entity.


• The @GeneratedValue annotation is used with the @Id annotation to provide the specification for the generation of primary keys. It can be applied to a primary key property or to a field of an entity or mapped superclass.


• The @IdClass annotation is used to define a primary key class. Each entity's field that makes up the primary key must be marked with the @Id annotation. An id class or a primary key class can also be represented in the xml descriptor by using the < id-class > element.


• The one-to-many relationship is one in which every instance of the first entity can be associated with more than one instance of the second entity, but for the instance of the second entity, there is exactly one instance of the first entity.


• The ManyToMany relationship is one in which every instance of the first entity has multiple instances of the second entity and every instance of the second entity has more than one instance of the first entity.


• The mappedBy element identifies the inverse side of a relationship. This element can be used with the OneToOne, OneToMany, and ManyToMany annotations, but not with the ManyToOne annotation.


• The table per concrete class strategy is one in which each class in the hierarchy is mapped to a separate database table.


• The @Transient annotation is used to specify that a field or a method of an entity is not persistent.


• The persistence.xml file contains the configuration information of one or several persistent units. This file must be present inside the META-INF directory of the ejb deployment.


• The @PersistenceContext annotation is used to declare a dependency on an EntityManager persistence context.


• The close() method of the EntityManager interface closes an application-managed EntityManager.


• A new entity instance becomes managed by the cascade persist operation invoked from related entities that have the cascade=PERSIST or cascade=ALL elements set in the relationship annotation.


• A class containing an entity instance that is passed as a detached object must implement the Serializable interface.


• The persist operation of an entity instance is used to make an entity instance persistent. Either this operation or the persist() method is used to persist an entity instance.


• The remove() operation can be performed only on a managed entity, i.e., an entity that is present in a persistent context.


• Entity operations such as persist, merge, remove, etc. do not cause immediate changes to a database. The changes occur only when the EntityManager is flushed.


• The @Basic annotation is applied to a property or an instance variable to mark it as persistent.


• The PrePersist callback method is invoked before invoking the persist operation on an entity. This method is also invoked when an entity instance is to be inserted into a database by using the merge operation.


• The PostLoad callback method is invoked after an entity instance has been loaded using the find() or the getreference() method, or after the refresh() method has been called on the instance.


• If there is more than one entity listener, the order of execution of entity listeners is the order in which they were declared in the @EntityListeners annotation or ORM XML mapping file.


• A developer can disable a default entity class for a particular entity by using the @ExcludeDefaultListeners annotation or the <exclude-default-listeners> deployment descriptor element.

• The Persistence Provider is responsible for managing a transaction in case of a resource-local entity manager.


• An extended persistence context is one that has a lifetime of more than a single transaction. It can be applied only to stateful session beans.


• The setFlushMode() method of the EntityManager interface is used to set the flush mode of the EntityManager's persistent context. It can be set to AUTO or COMMIT. The default mode is AUTO.
• An application can use the EntityManager.createEntityManager() or EntityManager.createEntityManager(Map map) method to create an application-managed entity manager.


• For the application-managed entity manager, an instance of EntityManager can be obtained using the @PersistenceUnit annotation.


• The joinTransaction() method of the EntityManager interface is used to synchronize an application-managed entity manager of a class with an active JTA transaction.


• The EntityTransaction interface is obtained using the getTransaction() method of the EntityManager interface.


• The name of the entity class and other embedded classes must be defined in the persistence.xml file, so that they can be included as parts of the persistence group.


• The javax.persistence.PersistenceException is thrown by the persistence provider to notify the container that an entity has violated the database's integrity constraint during the persistence operation.


• The changes made to managed entities are lost when the clear() method of the EntityManager interface is called.

• The SELECT and FROM clauses are mandatory in an EJB query.


• Rows resulting from the SELECT statement are sorted by columns specified in the ORDER BY clause. By default, the ORDER BY clause sorts rows in ascending order.


• The GROUP BY clause suppresses duplicate rows for the grouping column(s). It does not guarantee the order of the result set. Therefore, an ORDER BY clause should be used with the GROUP BY clause to sort the result set in the desired order.


• The @JoinTable annotation is used to declare the association between two entities. It is specified in the many-to-many association in the owning side of the association, or in a unidirectional one-to-many association.


• A subquery is evaluated once for the entire parent statement. In case a parent statement contains many nested subqueries, the innermost subquery is evaluated first.


• The BETWEEN expression in the Java Persistence Query Language represents a value in the specified range.


• The IS EMPTY and IS NOT EMPTY expressions in the Java Persistence Query Language are used to test whether or not the Collection returned as a result of a query is empty.


• The LIKE and NOT LIKE expressions are used in the Java Persistence Query Language to match a pattern for a given criterion. The underscore (_) matches a single character and the percent (%) matches zero to many characters.


• An input parameter is used to make a query flexible, so that the parameters may not be hard coded in a bean class. It must be numbered using integer values starting from 1.


• The keyword OBJECT is used only for SELECT queries that return an abstract schema. It cannot be used for the SELECT queries that return a CMP field type.


• The executeUpdate() method must always be called within the scope of a transaction.


• A named query in Java Persistence Query Language is a static query that is declared once and stored for later reuse. It is declared using the NamedQuery annotation.


• The MEMBER OF operator is used to determine whether an entity belongs to a specific collection-based relationship.

• A BMT bean cannot have nested transactions.


• The bean class implementing the javax.ejb.SessionSynchronization interface can use only the Required, RequiresNew, or Mandatory transaction attributes.


• A message-driven bean can use either the Required or the Not Supported transaction attribute.
  The Required transaction attribute is the default attribute.


• Overloaded methods in a CMT bean can be distinguished using the < method-param > element of the deployment descriptor.


• The @ApplicationException annotation, when applied to a class, marks a checked or unchecked exception as an application exception.


• For a BMT bean, transaction attributes must be declared in the deployment descriptor.


• The getUserTransaction() method of the EJBContext interface is used to get a reference to a UserTransaction object. This method can be called only for a BMT bean. It throws an IllegalStateException if called on a CMT bean.


• Only stateful session beans with container-managed transactions can implement the SessionSynchronization interface.


• The beforeCompletion() method of the SessionSynchronization interface is called when a transaction is about to be committed. The bean instance in this method is still in a transaction.


• The afterCompletion(boolean isCommitted) method of the SessionSynchronization interface is called after a transaction is committed or rolled back. Any operation that should be performed after the completion of the transaction can be performed in this method, as the status of the method, i.e., committed or rolled back, is known.


• The SessionSynchronization interface helps a session bean to synchronize its state with a transaction.

• An application exception can be caught and handled in a catch block, or can be declared in the throws clause of the method. Since these are checked exceptions, they are caught at compilation time and can be handled.


• NoSuchObjectException is thrown by the container when a method is called on a session bean that has been deleted or an entity bean that has been removed from a database. This exception is thrown only when the call is made by a remote client.


• A method should not attempt to recover from a system exception. If a method receives a checked system exception, it must be wrapped in the EJBException.


• Setting the value of the < rollback > sub-element of the < application-exception > as true means that the current transaction should be rolled back if an application exception is thrown.


• Except for the RemoteException, all system exceptions are unchecked.


• ObjectNotFoundException is a subclass of FinderException. It indicates that an entity with the given key could not be found. This exception must be included in the throws clause of all find methods in an entity bean's home interface.


• The Bean Provider is responsible for ensuring that the transaction in which the bean method has participated will be rolled back in case a non-application is thrown. The container is also responsible for performing any cleanup actions before throwing a non-application exception.


• The TransactionRolledbackException is thrown when an active transaction needs to roll back due to an erroneous condition in the code. A transaction is active only when the attribute is Mandatory, Required, or Supports.


• TransactionRequiredException is thrown when a method with the Mandatory transaction attribute is invoked by a remote client within an unspecified transaction context.

• The Application Assembler uses the < method-permission > element to define the permission that a particular role can have.


• The < role-link > element is a sub-element of the element. It is used to link the logical security role to the role hard-coded in the isCallerInRole method in the bean class.


• The @RolesAllowed annotation specifies the roles allowed to invoke a bean method. This annotation can be applied either to an EJB business method or to an entire class.


• The @RunAs annotation is used when a security role tries to invoke methods on other beans. It specifies the run-as identity to be used for the execution of the enterprise bean.


• The getCallerPrincipal() method of the EJBContext interface is used to identify a caller using a java.security.Principal object. It retrieves information about the client's security identity. This method is used to implement programmatic security.


• The isCallerInRole() method can be invoked only from the business method of an enterprise bean. This method cannot be called from a message-driven bean.


• The @PermitAll annotation is used to mark a class or method to be invoked by any security role.


• The < unchecked/ > element is a sub-element of the < method-permission > element. When this element replaces the < role-name > element, the method specified in the < method-name > sub-element of the < method > element is not checked for authorization.


• The < exclude-list > element is a sub-element of the < assembly-descriptor > element. It specifies the methods that should not be called by any client.


• The < security-role > element of the deployment descriptor is used to declare the security role in the deployment descriptor.

Rating: