Discussions

EJB design: EJB Container design PROBLEM, need GURUS

  1. EJB Container design PROBLEM, need GURUS (7 messages)

    Hi I have two questions and love to hear your opinion.

    1. How does an EJB container handle non-ejb classes, simple Java classes? (I m intressted about how transactions, threading,... are handled).
    E.g. A session bean that do a call as:
    SimpleClass sc = new SimpleClass();
    sc.dosomething();
    and so on.

    2. How do one create a connection from an EJB container (SessionBean or MDB) to some URL. (Just a simple urlconnection). Best practice?


    Thank you very very much for your time.
  2. 1. How does an EJB container handle non-ejb classes, simple > Java classes? (I m intressted about how transactions, > threading,... are handled).E.g. A session bean that do a call > as:SimpleClass sc = new SimpleClass();sc.dosomething();and
    > so on.


    The transaction context is associated with the thread that executes the sessoin bean method. As long as you are invoking methods on the non-ejb object from the same thread which executed the session bean class, all transactional guarantees by the container holds good - provided of course you obtain resource connections appropriately from the container in your plane java object.

    However if you create a NEW thread and do things in that thread, the container wouldn't know anything about it.



    2. How do one create a connection from an EJB container (SessionBean or MDB) to some URL. (Just a simple urlconnection). Best practice?Thank you very very much for your time.

    Never done such a thing from within a container, so this is clearly opinion without backed by experience -

    URL connection could be created normally like in a normal java program. How quickly you get the response back could be one area of concern - since you may be reading/writing to the url connection after you have started a transaction. Depending on what you have done before accessing the url you may have resources blocked, locks acqured, .. waiting for the transaction completion. The ejb servers I have seen also have a transaction timeout mechanism.

    Let us know if you find out more (or any best practices) about opening url connection from within an ejb.

    Regards
    Kingshuk
  3. Thank you Kingshuk,

    Well, talking about case 1.

    My real life scenario is (for no 1).
    StateLessSessionBean {
      public void setSessionContext(SessionContext ctx)
        plugin = Class.forName(pluginclass);
        ...
      }

      Result callPlugin( pluginclass, cmd ) {
        return plugin.auth(cmd);
      }
    }

    We could say that the plugin.class is a simple java class
    (but it could do ejb stuff, lookup resources, send jms messages, notify other session beans that creates new entity beans, and so on).


    I really want the "plugin" to be an EJB-component but the problem is that the plugin could be a "company customized" class, that maybe wont do any ejb-stuff.

    Do you have any advice on this solution? simple-class that will or will not do any ejb-work.


    For the case 2.
    There is in 1.4.2 net-properties for time-out settings, for the java.net.URLConnection
    sun.net.client.defaultConnectTimeout
    sun.net.client.defaultReadTimeout

    I wonder how this flags will effect the EJB container.

    Or maybe I should take a look at HTTPClient from apache ?


    Thanks alot King and the rest who feels for participating this issues.
  4. EJB Container design PROBLEM, need GURUS[ Go to top ]

    Please let me know if you need more details, I really need to discuss this issue.
    Thanks.
    /John C.
  5. Thank you Kingshuk,Well, talking about case 1.My real life scenario is (for no 1).StateLessSessionBean {  public void setSessionContext(SessionContext ctx)    plugin = Class.forName(pluginclass);    ...  }  Result callPlugin( pluginclass, cmd ) {    return plugin.auth(cmd);  }}We could say that the plugin.class is a simple java class (but it could do ejb stuff, lookup resources, send jms messages, notify other session beans that creates new entity beans, and so on).I really want the "plugin" to be an EJB-component but the problem is that the plugin could be a "company customized" class, that maybe wont do any ejb-stuff.Do you have any advice on this solution? simple-class that will or will not do any ejb-work.For the case 2.There is in 1.4.2 net-properties for time-out settings, for the java.net.URLConnectionsun.net.client.defaultConnectTimeoutsun.net.client.defaultReadTimeoutI wonder how this flags will effect the EJB container.Or maybe I should take a look at HTTPClient from apache ?Thanks alot King and the rest who feels for participating this issues.


    >I really want the "plugin" to be an EJB-component but the
    > problem is that the plugin could be a "company customized" > class, that maybe wont do any ejb-stuff.Do you have any
    > advice on this solution? simple-class that will or will > not do any ejb-work.


    If guess there are two options if you go the "non ejb pluggable class way".

    1. The ejb(s) instantiate the plug in and invoke methods on it. The plug knows how to use container resources like - JNDI, JMS connection/queues/topics/, data source etc. Here are the few issues I see in this approach -

    a) If something fails the plugin object CAN NOT decide to rollback - since it doesn't have access to the SessionContext that your ejb has. So it will have to fail with an exception. The invoking ejb(s) will have to inspect the exception to decide what to do.

    b)The plugin method will ALWAYS inherit the transaction attribute of the calling method. If more than one ejb can call this plugin then you may have the plugin method called with different transaction attributes at different times - may or may not be a problem - depends on what you are doing in that plugin.

    c)If you are using container security - the plugin object can not access the security information - since it doesn't have the context.

    2. Same as option 1 but this time the plugin interface has a setContext method that accepts, lets say, a SessionContext object. After instantiating a plugin everyone calls "setContext" before calling any business method on the plugin. This way you can avoid problem a and c. But b still remains. Then again, if the pluging is really a simple java class, and someone else is developing the plugin, this makes developing and testing the plugin cumbersome - you will now need a container to build and test a simple java class :-)

    > For the case 2.There is in 1.4.2 net-properties for
    > time-out settings, for the >
    > java.net.URLConnectionsun.net.client.defaultConnectTimeoutsun.net.client.defaultReadTimeoutI

    Didn't know about these. Thanks!

    Regards
    Kingshuk
  6. You only shed light King, thanks.

    It sounds more as solution 1 fits good, while this plugins could be developed and tested by different companies.


    I m curious how you (Kingshuk and the others) would solve such a problem?

    You got a Stateless Session Bean (Session Facade) that will instantiate a plug-in, (non-ejb class = simple java class).

    The plug-ins will perform ejb calls (but maybe later on other plug-ins wont). Any good pattern for this issue?

    Thanks alot so far King!
  7. EJB Container design PROBLEM, need GURUS[ Go to top ]

    Hi!
       I do this in the project im working on all the time. In fact, is a service provided by the framework. The underlaying implementation retrieves the plugin's class from the database, instantiates the class through reflection and returns the object to the calling EJB.
       In out architecture, a plugin can do just about anything: JNDI lookups (through a Service Locator), access the DB (through a DAO), etcetera. Transactions are delimited by transactional attributes for each EJB method. So, it's kind of the 1st solution proposed in some reply to your post.
       I DON'T reccomend ejb-aware plugins... you must throw them away if you change the platform, they are not reusable, etc.

    Regards,
    Martin

    PS: he title of your post is kind of misleading, isn't it?
  8. EJB Container design PROBLEM, need GURUS[ Go to top ]

    Thanks Martin, your real-life experience is worth to keep in mind while developing the plugins.

    > PS: he title of your post is kind of misleading, isn't it?
    it sure it is, I will figure out better titles next time. :)

    About the case 2 (making http connections from an EJB is further discussed in "Connection creation issues from an EJB - discussion"

    Best regards, John