Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures

Home

Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips

Books

Submit News
Search the site here...
Search...
 
Search the JavaFAQ.nu
1000 Java Tips ebook

1000 Java Tips - Click here for the high resolution copy!1000 Java Tips - Click here for the high resolution copy!

Java Screensaver, take it here

Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java programming articles and tips. Please take your copy here.

Take your copy of free "Java Technology Screensaver"!.

Easy Learn Java: Programming Articles, Examples and Tips - Page 464


Previous 1060 Stories (530 Pages, 2 Per Page) Next

Read Java Certification SCBCD Study Guide - 7. Session Bean Component Contract.

Go to all tips in Java Certification Books and Tests

Match the correct description about purpose and function to which session bean type they apply: stateless, stateful, or both.

The conversational state of a STATEFUL session object is defined as the session bean instance’s field values, plus the transitive closure of the objects from the instance’s fields reached by following Java object references.

STATELESS session beans are session beans whose instances have no conversational state. This means that all bean instances are equivalent when they are not involved in servicing a client-invoked method.

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.


There is no fixed mapping between clients and STATELESS instances. The container simply delegates a client’s work to any available instance that is method-ready.

There is "method ready" STATE for STATEFUL session beans. Because they have relationship: one client - one bean.

There is "method ready" POOL for STATELESS session beans. Because they have relationship: one client - many beans.

Given a list of responsibilities related to session beans, identify those which are the responsibility of the session bean provider and those which are the responsibility of the EJB container provider.

Bean Provider's responsibility

The session bean provider is responsible for providing the following class files:
  • Session bean class.
  • Session bean’s remote interface and remote home interface, if the session bean provides a remote client view.
  • Session bean’s local interface and local home interface, if the session bean provides a local client view.

Container Provider's responsibility

The container provider is responsible for providing the deployment tools and for managing the session bean instances at runtime.

The deployment tools provided by the container are responsible for the generation of additional classes when the session bean is deployed. The tools obtain the information that they need for generation of the additional classes by introspecting the classes and interfaces provided by the enterprise bean provider and by examining the session bean’s deployment descriptor. The deployment tools must generate the following classes:
  • A class that implements the session bean’s remote home interface (session EJBHome class).
  • A class that implements the session bean’s remote interface (session EJBObject class).
  • A class that implements the session bean’s local home interface (session EJBLocalHome class).
  • A class that implements the session bean’s local interface (session EJBLocalObject class).

The deployment tools may also generate a class that mixes some container-specific code with the session bean class. This code may, for example, help the container to manage the bean instances at runtime. The tools can use subclassing, delegation, and code generation.

  • The session EJBHome class, which is generated by the deployment tools, implements the session bean’s remote home interface. This class implements the methods of the javax.ejb.EJBHome interface and the create<METHOD> methods specific to the session bean. The implementation of each create<METHOD>(...) method invokes a matching ejbCreate<METHOD>(...) method.
  • The session EJBObject class, which is generated by the deployment tools, implements the session bean’s remote interface. It implements the methods of the javax.ejb.EJBObject interface and the business methods specific to the session bean. The implementation of each business method must activate the instance (if the instance is in the passive state) and invoke the matching business method on the instance.
  • The session EJBLocalHome class, which is generated by the deployment tools, implements the session bean’s local home interface. This class implements the methods of the javax.ejb.EJBLocalHome interface and the create<METHOD> methods specific to the session bean. The implementation of each create<METHOD>(...) method invokes a matching ejbCreate<METHOD>(...) method.
  • The session EJBLocalObject class, which is generated by the deployment tools, implements the session bean’s local interface. It implements the methods of the javax.ejb.EJBLocalObject interface and the business methods specific to the session bean. The implementation of each business method must activate the instance (if the instance is in the passive state) and invoke the matching business method on the instance.
  • 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. The class must be a valid RMI Value class and must implement the javax.ejb.EJBMetaData interface.
  • The container must ensure that ONLY ONE thread can be executing an instance at any time. If a client request arrives for an instance while the instance is executing another request, the container may throw the java.rmi.RemoteException to the second request if the client is a remote client, or the javax.ejb.EJBException if the client is a local client.
  • The container MUST follow the rules with respect to transaction scoping, security checking, and exception handling.
  • The container MUST implement the SessionContext.getEJBObject() method such that the bean instance can use the Java language cast to convert the returned value to the session bean’s remote interface type. Specifically, the bean instance does not have to use the PortableRemoteObject.narrow(...) method for the type conversion.

 

Given a list of requirements, identify those which are the requirements for a session bean class, a remote component interface, a remote home interface, create methods, business methods, a local component interface, and a local home interface.

The following are the requirements for session BEAN CLASS:
  • The class MUST implement, directly or indirectly, the javax.ejb.SessionBean interface.
  • The class MUST be defined as public, MUST NOT be final, and MUST NOT be abstract (NOTE, CMP ENTITY bean class MUST be abstract).
  • The class MUST have a public constructor that takes NO parameters. The Container uses this constructor to create instances of the session bean class.
  • The class MUST NOT define the finalize() method.
  • The class may, but is not required to, implement the session bean’s component interface (NOTE: AVOID passing of this).
  • The class MUST implement the business methods and the ejbCreate methods.
  • If the class is a STATEFUL session bean, it may optionally implement the javax.ejb.SessionSynchronization interface.
  • The session bean class may have superclasses and/or superinterfaces. If the session bean has superclasses, then the business methods, the ejbCreate<METHOD> methods, the methods of the SessionBean interface, and the methods of the optional SessionSynchronization interface may be defined in the session bean class, or in any of its superclasses.
  • The session bean class is allowed to implement other methods (for example helper methods invoked internally by the business methods) in addition to the methods required by the EJB specification.
The session BEAN CLASS may define zero or more business methods whose signatures must follow these rules:
  • The method names can be arbitrary, but they MUST NOT start with “ejb” to avoid conflicts with the callback methods used by the EJB architecture.
  • The business method MUST be declared as public.
  • The method MUST NOT be declared as final or static.
  • The argument and return value types for a method MUST be legal types for RMI/IIOP if the method corresponds to a business method on the session bean’s remote interface.
  • The throws clause may define arbitrary application exceptions.
The session BEAN CLASS must define one or more ejbCreate<METHOD>(...) methods whose signatures must follow these rules:
  • The method name MUST have ejbCreate as its prefix.
  • The method MUST be declared as public.
  • The method MUST NOT be declared as final or static.
  • The return type MUST be void.
  • The method arguments MUST be legal types for RMI/IIOP if there is a create<METHOD>(...) corresponding to the ejbCreate<METHOD>(...) method on the session bean’s remote home interface.
  • The throws clause may define arbitrary application exceptions, possibly including the javax.ejb.CreateException.
The following are the requirements for the session bean’s REMOTE [component] interface:
  • The interface MUST extend the javax.ejb.EJBObject interface.
  • The methods defined in this interface MUST follow the rules for RMI/IIOP. This means that their argument and return values must be of valid types for RMI/IIOP, and their throws clauses must include the java.rmi.RemoteException.
  • The remote interface is allowed to have superinterfaces. Use of interface inheritance is subject to the RMI/IIOP rules for the definition of remote interfaces.
  • For each method defined in the remote interface, there must be a matching method in the session bean’s class. The matching method must have:
    • The same name.
    • The same number and types of arguments, and the same return type.
    • All the exceptions defined in the throws clause of the matching method of the session bean class must be defined in the throws clause of the method of the remote interface.
  • 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.
The following are the requirements for the session bean’s REMOTE HOME interface:
  • The interface MUST extend the javax.ejb.EJBHome interface.
  • The methods defined in this interface MUST follow the rules for RMI/IIOP. This means that their argument and return values MUST be of valid types for RMI/IIOP, and that their throws clauses MUST include the java.rmi.RemoteException.
  • The remote home interface is allowed to have superinterfaces. Use of interface inheritance is subject to the RMI/IIOP rules for the definition of remote interfaces.
  • A session bean’s remote home interface MUST define one or more create<METHOD>(...) methods. (NOTE, Entity Beans may define ZERO create(...) methods). A STATELESS session bean must define exactly ONE create() method with NO arguments.
  • Each create method MUST be named “create<METHOD>”, and it MUST match one of the ejbCreate<METHOD> methods defined in the session bean class. The matching ejbCreate<METHOD> method MUST have the same number and types of arguments. (Note that the return type is different.) The methods for a STATELESS session bean MUST be named “create” and “ejbCreate”.
  • The return type for a create<METHOD> method MUST be the session bean’s REMOTE INTERFACE type.
  • All the exceptions defined in the throws clause of an ejbCreate<METHOD> method of the session bean class must be defined in the throws clause of the matching create<METHOD> method of the remote home interface.
  • The throws clause of create<METHOD>(...) MUST include javax.ejb.CreateException.
The following are the requirements for the session bean’s LOCAL [component] interface:
  • The interface MUST extend the javax.ejb.EJBLocalObject interface.
  • The throws clause of a method defined in the LOCAL interface MUST NOT include the java.rmi.RemoteException.
  • The local interface is allowed to have superinterfaces.
  • For each method defined in the local interface, there must be a matching method in the session bean’s class. The matching method must have:
    • The same name.
    • The SAME number and types of arguments, and the SAME return type.
    • All the exceptions defined in the throws clause of the matching method of the session bean class must be defined in the throws clause of the method of the local interface.
The following are the requirements for the session bean’s LOCAL HOME interface:
  • The interface MUST extend the javax.ejb.EJBLocalHome interface.
  • The throws clause of a method in the LOCAL home interface MUST NOT include the java.rmi.RemoteException.
  • The local home interface is allowed to have superinterfaces.
  • A session bean’s local home interface MUST define one or more create<METHOD>(...) methods. A STATELESS session bean MUST define exactly ONE create() method with NO arguments.
  • Each create method MUST be named “create<METHOD>”, and it MUST match one of the ejbCreate<METHOD> methods defined in the session bean class. The matching ejbCreate<METHOD> method MUST have the same number and types of arguments. (Note that the return type is different.) The methods for a STATELESS session bean MUST be named “create” and “ejbCreate”.
  • The return type for a create<METHOD> method MUST be the session bean’s local interface type.
  • All the exceptions defined in the throws clause of an ejbCreate<METHOD> method of the session bean class MUST be defined in the throws clause of the matching create<METHOD> method of the local home interface.
  • The throws clause of create<METHOD> method MUST include javax.ejb.CreateException.
IBA JV

17416 bytes more | comments? | Printer Friendly Page  Send to a Friend | Score: 5
Posted by aalex on Monday, July 03, 2006 (01:00:00) (4744 reads)

Read Java Certification SCBCD Study Guide - 6. Session Bean Component Contract

Go to all tips in Java Certification Books and Tests

Identify the use and the behavior of the ejbPassivate method in a session bean, including the responsibilities of both the container and the bean provider.

Bean Provider's responsibility

Passivation is performed only for STATEFUL session beans. The Bean Provider is required to ensure that the ejbPassivate method leaves the instance fields ready to be serialized by the Container. The objects that are assigned to the instance’s non-transient fields after the ejbPassivate method completes must be one of the following:
  • A serializable object.
  • A null.
  • An enterprise bean’s remote interface reference.
  • An enterprise bean’s remote home interface reference.
  • An entity bean’s local interface reference.
  • An entity bean’s local home interface reference.
  • A reference to the SessionContext object.
  • A reference to the environment naming context (java:comp/env JNDI)
  • A reference to the UserTransaction interface.
  • A reference to a resource manager connection factory.
  • An object that is not directly serializable, because it contains references on "non-serializable" objects mentioned above.

Bean Provider must close all JDBC™ connections in ejbPassivate and assign the instance’s fields storing the connections to null .

The Bean Provider must assume that the content of transient fields MAY be lost between the ejbPassivate and ejbActivate notifications.

Container's responsibility

The container performs the Java programming language Serialization (or its equivalent) of the instance’s state after it invokes the ejbPassivate method on the instance.

The container must be able to properly save and restore the reference to the home and component interfaces of the enterprise beans stored in the instance’s state even if the classes that implement the object references are not serializable.

If the session bean instance stores in its conversational state an object reference to the javax.ejb.SessionContext interface, java:comp/env JNDI context or UserTransaction interface, the container must be able to save and restore the object reference across the instance’s passivation.

The container may destroy a session bean instance if the instance does not meet the requirements for serialization after ejbPassivate.

While the container is not required to use the Serialization protocol for the Java programming language to store the state of a passivated session instance, it must achieve the equivalent result. The one exception is that containers are NOT REQUIRED to reset the value of transient fields during activation (as opposed to pure Serialization, which GUARANTEES that transient variables will come back with default values for that type).

Passivation typically happens spontaneously based on the needs of the container. It happens just BEFORE writing state to secondary storage.

Activation typically occurs when a client calls a method. It happens just AFTER reading state from secondary storage.

Identify the interface and method for each of the following: retrieve the session bean's remote home interface, retrieve the session bean's local component interface, determine if the session bean's caller has a particular role, allow the instance to mark the current transaction as a rollback, retrieve the UserTransaction interface, prepare the instance for reuse following passivation, release resources prior to removal, identify the invoker of the bean instance's component interface, be notified that a new transaction has begun, and be notified that the current transaction has completed.

A container provides the session bean instances with a SessionContext, which gives the session bean instance access to the instance’s context maintained by the container. The SessionContext interface has the following methods:
  • The getEJBObject method returns the session bean’s remote interface.
  • The getEJBHome method returns the session bean’s remote home interface.
  • The getEJBLocalObject method returns the session bean’s local interface.
  • The getEJBLocalHome method returns the session bean’s local home interface.
  • The getCallerPrincipal method returns the java.security.Principal that identifies the invoker of the bean instance’s EJB object.
  • The isCallerInRole method tests if the session bean instance’s caller has a particular role.
  • The setRollbackOnly method allows the instance to mark the current transaction such that the only outcome of the transaction is a rollback. ONLY instances of a session bean with CONTAINER-managed transaction (CMT) demarcation can use this method.
  • The getRollbackOnly method allows the instance to test if the current transaction has been marked for rollback. ONLY instances of a session bean with CONTAINER-managed transaction (CMT) demarcation can use this method.
  • The getUserTransaction method returns the javax.transaction.UserTransaction interface. The instance can use this interface to demarcate transactions and to obtain transaction status. ONLY instances of a session bean with BEAN-managed transaction demarcation (BMT) can use this method.
		public interface SessionContext extends EJBContext {
		   EJBLocalObject getEJBLocalObject() throws IllegalStateException;
		   EJBObject getEJBObject() throws IllegalStateException;
		}

		public interface EJBContext {
		   EJBHome getEJBHome();
		   EJBLocalHome getEJBLocalHome();
		   java.security.Principal getCallerPrincipal();
		   boolean isCallerInRole(String roleName);
		   UserTransaction getUserTransaction() throws IllegalStateException;
		   void setRollbackOnly() throws IllegalStateException;
		   boolean getRollbackOnly() throws IllegalStateException;
		}

		/**
		* This interface represents the abstract notion of a principal, which
		* can be used to represent any entity, such as an individual, a
		* corporation, and a login id.
		*/
		public interface Principal {
		   public String getName();
		}
	

The ejbRemove notification signals that the instance is in the process of being removed by the container. In the ejbRemove method, the instance typically releases the same resources that it releases in the ejbPassivate method.

The Bean Provider CANNOT assume that the Container will always invoke the ejbRemove() method on a session bean instance. The following scenarios result in ejbRemove() NOT being called on an instance:
  • A crash of the EJB Container.
  • A SYSTEM exception thrown from the instance’s method to the Container.
  • A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB Container implementation specific way.
If the session bean instance allocates resources in the ejbCreate<METHOD>(...) method and/or in the business methods, and normally releases the resources in the ejbRemove() method, these resources will not be automatically released in the above scenarios. The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.

The ejbPassivate notification signals the intent of the container to passivate the instance. The ejbActivate notification signals the instance it has just been reactivated. Because containers automatically maintain the conversational state of a session bean instance when it is passivated, most session beans can ignore these notifications. Their purpose is to allow session beans to maintain those open resources that need to be closed prior to an instance’s passivation and then reopened during an instance’s activation (for example, DB connections).

A STATEFUL session bean class (CMT only) can optionally implement the javax.ejb.SessionSynchronization interface. This interface provides the session bean instances with transaction synchronization notifications. The instances can use these notifications, for example, to manage database data they may cache within transactions :
  • The afterBegin notification signals a session bean instance that a new transaction has begun. The container invokes this method before the first business method within a transaction (which is not necessarily at the beginning of the transaction). The afterBegin notification is invoked with the transaction context. The instance may do any database work it requires within the scope of the transaction.
  • The beforeCompletion notification is issued when a session bean instance’s client has completed work on its current transaction but prior to committing the resource managers used by the instance. At this time, the instance should write out any database updates it has cached. The instance can cause the transaction to roll back by invoking the setRollbackOnly method on its session context.
  • The afterCompletion notification signals that the current transaction has completed. A completion status of true indicates that the transaction has committed; a status of false indicates that a rollback has occurred. Since a session bean instance’s conversational state is not transactional, it may need to manually reset its state if a rollback occurred.
		public interface SessionSynchronization {
		   void afterBegin() throws EJBException, RemoteException;
		   void afterCompletion(boolean committed) throws EJBException, RemoteException;
		   void beforeCompletion() throws EJBException, RemoteException;
		}
	
ONLY a STATEFUL Session bean with CONTAINER-managed transaction (CMT) demarcation may implement the SessionSynchronization interface. A stateless Session bean MUST NOT implement the SessionSynchronization interface.
IBA JV

11902 bytes more | comments? | Printer Friendly Page  Send to a Friend | Score: 5
Posted by aalex on Monday, June 26, 2006 (01:00:00) (3524 reads)

Previous 1060 Stories (530 Pages, 2 Per Page) Next

530| 529| 528| 527| 526| 525| 524| 523| 522| 521| 520| 519| 518| 517| 516| 515| 514| 513| 512| 511| 510| 509| 508| 507| 506| 505| 504| 503| 502| 501| 500| 499| 498| 497| 496| 495| 494| 493| 492| 491| 490| 489| 488| 487| 486| 485| 484| 483| 482| 481| 480| 479| 478| 477| 476| 475| 474| 473| 472| 471| 470| 469| 468| 467| 466| 465|
464
| 463| 462| 461| 460| 459| 458| 457| 456| 455| 454| 453| 452| 451| 450| 449| 448| 447| 446| 445| 444| 443| 442| 441| 440| 439| 438| 437| 436| 435| 434| 433| 432| 431| 430| 429| 428| 427| 426| 425| 424| 423| 422| 421| 420| 419| 418| 417| 416| 415| 414| 413| 412| 411| 410| 409| 408| 407| 406| 405| 404| 403| 402| 401| 400| 399| 398| 397| 396| 395| 394| 393| 392| 391| 390| 389| 388| 387| 386| 385| 384| 383| 382| 381| 380| 379| 378| 377| 376| 375| 374| 373| 372| 371| 370| 369| 368| 367| 366| 365| 364| 363| 362| 361| 360| 359| 358| 357| 356| 355| 354| 353| 352| 351| 350| 349| 348| 347| 346| 345| 344| 343| 342| 341| 340| 339| 338| 337| 336| 335| 334| 333| 332| 331| 330| 329| 328| 327| 326| 325| 324| 323| 322| 321| 320| 319| 318| 317| 316| 315| 314| 313| 312| 311| 310| 309| 308| 307| 306| 305| 304| 303| 302| 301| 300| 299| 298| 297| 296| 295| 294| 293| 292| 291| 290| 289| 288| 287| 286| 285| 284| 283| 282| 281| 280| 279| 278| 277| 276| 275| 274| 273| 272| 271| 270| 269| 268| 267| 266| 265| 264| 263| 262| 261| 260| 259| 258| 257| 256| 255| 254| 253| 252| 251| 250| 249| 248| 247| 246| 245| 244| 243| 242| 241| 240| 239| 238| 237| 236| 235| 234| 233| 232| 231| 230| 229| 228| 227| 226| 225| 224| 223| 222| 221| 220| 219| 218| 217| 216| 215| 214| 213| 212| 211| 210| 209| 208| 207| 206| 205| 204| 203| 202| 201| 200| 199| 198| 197| 196| 195| 194| 193| 192| 191| 190| 189| 188| 187| 186| 185| 184| 183| 182| 181| 180| 179| 178| 177| 176| 175| 174| 173| 172| 171| 170| 169| 168| 167| 166| 165| 164| 163| 162| 161| 160| 159| 158| 157| 156| 155| 154| 153| 152| 151| 150| 149| 148| 147| 146| 145| 144| 143| 142| 141| 140| 139| 138| 137| 136| 135| 134| 133| 132| 131| 130| 129| 128| 127| 126| 125| 124| 123| 122| 121| 120| 119| 118| 117| 116| 115| 114| 113| 112| 111| 110| 109| 108| 107| 106| 105| 104| 103| 102| 101| 100| 99| 98| 97| 96| 95| 94| 93| 92| 91| 90| 89| 88| 87| 86| 85| 84| 83| 82| 81| 80| 79| 78| 77| 76| 75| 74| 73| 72| 71| 70| 69| 68| 67| 66| 65| 64| 63| 62| 61| 60| 59| 58| 57| 56| 55| 54| 53| 52| 51| 50| 49| 48| 47| 46| 45| 44| 43| 42| 41| 40| 39| 38| 37| 36| 35| 34| 33| 32| 31| 30| 29| 28| 27| 26| 25| 24| 23| 22| 21| 20| 19| 18| 17| 16| 15| 14| 13| 12| 11| 10| 9| 8| 7| 6| 5| 4| 3| 2| 1|


Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

RSS feed Java FAQ RSS feed Java FAQ News     

    RSS feed Java Forums RSS feed Java Forums

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

Interactive software released under GNU GPL, Code Credits, Privacy Policy