 |
|
 |
 |
|
|
 
Andreas Schaefer's Blog
«How to Handle Permanent Exceptions after EJB Deployment: a Proposal |
Main
| RE: File Access in EJB »
SLSB -> SFSB: Meaningless ?Posted by schaefa on October 02, 2003 at 03:26 PM | Comments (4)A colleague of mine just pointed out that in Richard Monson-Heafel’s EJB book (3rd edition) configurations like Stateless Session Bean (SLSB) -> Stateful Session Bean (SFSB) are considered meaningless. I understand that any EJB book cannot deal with all possible scenarios otherwise you need a truck to take the book home but I find it too interesting not to talk about. Luckily I can discuss in my weblog any scenario I like and hopefully I can show you that rules are meant to be broken even when the result only confirms the rule. Let us assume that we have a SLSB that has at least one business method in it that is quite elaborate and performs many tasks. In addition we want to have multiple resources or a non-standard resource wrapped in an EJB like a raw TCP/IP socket. Because the resource(s) should participate in a transaction and must be opened before usage and closed at the end it cannot be a SLSB because we never know what instance we get back on each invocation due the fact that the pool is returning the next free instance before a method is invoked. The only way left is to use an SFSB because a particular instance is available to the SLSB instance during the entire method call and so at the end I can close the resource(s) or do any other cleanup task. In this case the SLSB method does represent a client towards the SFSB even thought the life span of the SFSB is not that long. Now one could object that I could just use a plain Java class instead of wrapping the resource(s) into an EJB but an EJB can use JNDI environment variable to specify setup properties, I can look it up very easily on a JNDI server and use an EJB reference in the Environment Naming Context (ENC) of the SLSB. Finally I can deploy the EJB in a separate application and use it throughout the server. One could also suggest using JCA instead but this could either overkill or what is wrapped in the SFSB does not adhere to JCA specification. I want stress the fact that this rule should only be broken when there are compelling reasons to do so and you checked out the other options like keeping the code in the SLSB, creating a plain old Java object or using JCA and then selected the best solution that does not only fit you best now but also in the (near) future. Enjoy - AndyBookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
