cached session bean -wrapper


EJB design: cached session bean -wrapper

  1. cached session bean -wrapper (1 messages)

    newbie to J2EE/EJB's but trying to grasp this.

     here is the scenario..
    I have a MDB(inbound) that that picks up msgs from a remote sys and and does some work, lets say creates a big string with the msg and it then calls a pojo that inturn does stuff to the data passes it away- eventually some component in the back system updates a DB and sends the request data back. lets say a string again.
    So, I created a stateless session bean(outbound) - it basically has 1 method that takes a string and builds a jms message and places it onto a remoteQ.

    originally I understood that the 'return pojo' would just make a lookup call to get a home obj for my session bean and simply call my method and pass it the return string. voila!

    I am told I need to create a service locator 'wrapper' instead !?
    -so the 'return pojo' doesnt even know anything about the session bean and have to worry about calling the lookup etc. (cache it at the beginning instead)

    is this a popular design and how exactly to I do this??

    do I need to write another class(pojo) that the MDB calls to do all this work and pass the
    original pojo the string AND ..this cached obj??

    I'm a little confused, any help would be great.

    I looked in Core J2ee patterns and was wondering if EJB service locator strategy is similar?

    thanks in advance.
  2. cached session bean -wrapper[ Go to top ]

    David -
    Yeap it's popular. In fact, I do similar type things all the time.

    The ServiceLocator pattern in the J2ee Core Patterns is very similar to what you need. The only caveat though is don't cache the SLSB per se, rather cache the HomeHandle and instantiate the Bean as needed by calling the getEJBHome() method. This protects you from using the same Bean over and over again. This is a problem if you are in a clustered environment and aren't entirely sure which server is facilitating your request.

    Also, it is probably safer to write a wrapper class around your processing and use that Object within your MDB. I would suggest modelling it after a chain-of-responsibilty so that if you need to add functionality in the future you can do so very quickly by adding a handler to the chain. You can load the chain Objects dynamically by using reflection (e.g. Class.forName()) and a property file, separating the chain Objects by comma's.

    Hope this helps -