Discussions

EJB design: Stateless Session Bean accessing ordinary java object

  1. Hi,

    I would like to know more about consequences of stateless session bean accessing an ordinary java object. This java object is not an Entity Bean. I need to use this java object as a wrapper to access the 3rd party API that I want to encapsulate within my app.

    Session Facade-->OrdinaryJavaObject---->3rd Party API.

    All kind of suggestions/feedbacks are welcome..

    Thanks in advance,
  2. I use a Stateless Session bean that connects to a 3rd party vendor in several places.

    In one case, it is LDAP. The ldap vendor comes with a connection pool, so I deploy the LDAP sdk classes on the SERVER classpath. I also deploy a wrapper class like you say around the LDAP, and deploy that as well to the system class path. Using LDAP now is straight forward, .... however .....

    I have a lot of problems. First, I have no security for connections to the LDAP. Second, my container does not handle distributed connections. This sucks, cause I may want ot update LDAP and the db, and want that to be - I guess the word is - atomic.

    To work around this problem, the choice is obviously to use the Java Connector Architecture. Now, a pool of LDAP connections is maintained, the server can enforce security of which web apps can use that service (deployed to JNDI), etc. And finally, using the right deployment, the LDAP connections may indeed participate in distributed transactions (that is transactions managed by the container).

    UNFORTUNATELY, our LDAP does not come out of the box with XA compliant rar for this purpose - I have to create it. I have not, and will be amazed if the next release of the LDAP SDK does not come with one.

    I also have the same problem with TIBCO. Although they finally have JMS connectors / not connectors to the portal builder apis.

    But for other third party vendors where you do not care to manage distributed transactions, pooling, or security, simply wrap the third party API in an object, and place that thing on the server class path, or in the ejb jar, or where ever it makes sense for your J2EE deployment.

    I gues pooling is somewhat managed because you should be able to control the session bean pool size. However, if 10 different session beans use the same apis, you are kinda screwed from having a good scalable solution.

    Hope this clears up some of the implied issues you might be looking at.

    JS
  3. Thanks for yr reply.
    I'm trying to wrap D&B toolkit and other 3rd party API responsible for data cleansing etc.

    I wanted to understand possible ramifications of using this simple java wrapper class that encapsulates business API and use session facade to access the java wrapper object. I wanted to know if any one ever has implemented such solution and how are the issues such as scalability, performance, synchronization etc handled ?
    For e.g if there are 20 stateless session beans all trying to access this wrapper, how would the synchronization etc be handled ?


    Thanks in advance,
    VS
  4. That is very tough to answer, given I know nothing about hte D&B toolkit.

    First, if there are connector objects, then that would imply that the wrapper should act as a pool, blocking when the maximum have been checked out.

    For exmample, a session bean has a business method that needs access to a connector object. It uses some static method to "Acquire()" a connection from the wrapper. The session bean puts a try block around the following code, and implements a finally part to be sure to return the connection to the pool.

    Otherwise, consult the documentation and see if the D&B classes are already thread safe. If not or you are unsure, just make use of a locking object...

    //primitive example

    public class DnBWrapper{
      private static DnBWrapper singleton = new DnBWrapper();
      private static String lock = "";


      private DnBWrapper(){}

      public static DnBWrapper getInstance(){
       return singleton;
      }

      public void someAPImethod(){
        //let no one else can be in an api method
       synchronized(lock){
        //call the method
       }
      }
    }

    I have not coded a lot of thread safe code, and would need to do some research and study before deciding if this fits in your particular application or not.