5 Replies Latest reply on Feb 28, 2005 2:49 AM by stevenpeh

    General query - usage of stateless session bean

    baskar_bharadwaj

      Hi all,
      I have some doubts regarding the proper usage of stateless session beans.
      My application has a 'session facade' for receiving all external requests. After receiving requests, the facade interacts with 3 other state less session beans(individual components - each having a distinct functionality) to service the requests. And, each of the individual session bean components can interact with one or more entity bean for DB access/updates.

      That was my application design - untill I got this doubt:
      Why should I use stateless session beans for the individual components ?
      why can't they be plain java classes that access the entity beans(just like the session beans where accessing before)

      By this I can avoid a JNDI lookup - each time I want to access the component.

      I'am not sure of the negative effects this may have - related to transactions/scalability..,,.

      So, I would be happy - if some one can contribute their opinion in this regard.

      Thanks in advance,
      Baskar

        • 1. Re: General query - usage of stateless session bean
          kamal_tavant

          I would suggest that you go ahead with the Single session bean solution. The main reasons for using a stateless session bean would be to leverage the declarative transaction support. If the transaction handling is straight forward (all operations are carried out as a part of single transaction) then the facade can take care of it, you don't need the other session beans.

          Also its still a good idea to maintain a logical separation. The facade should be coded to work with interfaces than actual implementation, this would ensure logical separation between the the three components & the facade and also make it easier to wrap those in a session bean if required at a later point.

          • 2. Re: General query - usage of stateless session bean
            baskar_bharadwaj

            Thanks for the analysis. Even I feel that the session beans are not required, except for a single point that:

            When the individual components are designed as session beans - independantly thay can be tested - (when deployed) - through the remote interface(using db Unit, probably).

            But when they are modelled as plain Java classes(which access the DB using other entity beans), component level testing cannot be performed.
            So all unit test cases may have to be done through the facade.(which may not be that much successful)

            I'am still not that much clear on taking the decision.(because of the above concern)

            Am I thinking in the wrong way / is there any way to test components - independantly, when deployed ?

            • 3. Re: General query - usage of stateless session bean
              kamal_tavant


              Using plain java classes instead of using SessionBeans would actually make testing the component easier. You can write component tests as normal Junit tests. You can run them outside the container (IDE, build script etc) by using mocks for the dependent entity beans and if you want to test in a container environment you can use the same tests to run inside the container by using the Cactus framework.

              Look at option B, reuse Junit testcase.
              http://jakarta.apache.org/cactus/writing/howto_testcase.html

              I would also suggest that you relook your decision to use Entity bean for persistence. Going with Hibernate for persistence is a better alternative. That would make it really easy to test your code outside of a container.

              • 4. Re: General query - usage of stateless session bean
                baskar_bharadwaj

                Thanks a lot. Information - was very good for me to proceed.
                Its a bit difficult to turn the mindset towards Hibernate, after thinking a lot about Entity beans.

                • 5. Re: General query - usage of stateless session bean
                  stevenpeh

                   


                  Its a bit difficult to turn the mindset towards Hibernate, after thinking a lot about Entity beans.


                  hmmm... if you're using BMP entities, then hibernate should be a very natural fit.... just skip the hibernate transaction stuff...