EJB Management

Discussions

EJB design: EJB Management

  1. EJB Management (3 messages)

    I'm currently designing a framework for my application consisting of :
    - a MVC2 framework for the presentation layer.
    - an EJB framework for the business layer.

    The presentation layer will communicate with the EJB layer (or other non J2EE components) using a Command pattern.

    On the EJB layer I would like to automate some technical tasks such as :
    - logging.
    - security (if we don't use J2EE security).
    - management.

    For the passive tasks (such as logging), called whenever a business method is called, I will use the proxy design pattern.

    For the active tasks (initiated by an administrator) such as changing the logging level at runtime, it's another problem.

    Some solutions I see are :
    1. implementing the management as a remote method on the EJB.
    i.e.
    public void changeLoggingLevel (LoggingLevel aLevel) {
        LoggerFactory.getInstance ().setLevel (aLevel);
    }

    But there's a problem when using load balancing strategy :
    only one EJB on one application server will be called, and I would need the logging level change for all EJB of the same type.

    Problem :
    - this solution doesn't seem usable.

    2. Using a persistent store (such as SGBD) shared by all my application servers. The management state will be stored there for all my EJBs.
    A thread for every EJB module will scan the management table and call the administrative method if the value changed since the last time.

    Advantages :
    - easy to implement.

    Problems :
    - delay of scanning when executing the management command.
    - threads aren't allowed in J2EE specs. So I use the Timer Service (which isn't available on my application server I think : it's WAS), or ... I use threads in my EJB.

    3. Using JMX
    I don't know very well JMX but here is how I would do it :
    The first time an EJB class is loaded on a container, I would register it's implementation (or the manageable interface of my EJB) with a JMX server.
    The EJB will register with a name such as :
    <EJBclassName>/<UId>
    So, if I have three EJB, two used with a load balancing strategy I will have registered :
    - com.xxx.SomeEJB/000-02-15552
    - com.xxx.SomeEJB/015-02-15553
    - com.yyy.AnotherEJB/000-04-15243
    When I want to change log level on com.xxx.SomeEJB, I will execute the management command on all objects with ids starting with com.xxx.SomeEJB.

    This sounds great to me...
    But :
    - here's another technology to deal on. bof !
    - don't know if JMX implementations are free and mature and the use of it is widespread (don't wan't to be a beta or gamma tester).
    - it' perhaps more complicated than solution 2 (JDBC).

    Perhaps there are more and better solutions.

    Some advice ?

    Thanks

    Threaded Messages (3)

  2. EJB Management[ Go to top ]

    <q>
    But :
    - here's another technology to deal on. bof !
    - don't know if JMX implementations are free and mature and the use of it is widespread (don't wan't to be a beta or gamma tester).
    - it' perhaps more complicated than solution 2 (JDBC).

    Perhaps there are more and better solutions.

    Some advice ?
    </q>

    As you said, Option 2 is a nono according to the spec. AFIK there is an option 1b. You could make your singleton a RMI server exposing the setLevel method.

    JMX IMHO is the best solution, however, It might bind you (for now) to 1 or 2 vendors since it will only be introduced as obligatory in the J2EE 1.4 spec. I know In WLS it works great, you can (at least in WLS 7) create a plugin for the admin console of your loggin feature.
  3. EJB Management[ Go to top ]


    One solution is to bind the log level in the JNDI namespace of the application server. It can be set initially by a startup class (if avalilable on your app server), changed by any application code (Servlet or EJB) and read from anywhere. This will also work in a cluster!

    /Tomas
  4. EJB Management[ Go to top ]

    Thanks for your responses.

    I'm going to read a little more the JMX specs and then choose between solution 1b backed by the JNDI namespace and the JMX solution.

    Using the JNDI Namespace in order to store the logging level (or other management information) appears a better idea than using a SGBD (in fact, the JNDI is backed by a SGBD).

    Solution 1b will abstract the solution implementation (management info on a SGBD, on the JNDI namespace or elsewhere).

    I'll post more on this thread later.