Flux 4.0 J2EE Job Scheduler Adds GUI, JMX Support

Discussions

News: Flux 4.0 J2EE Job Scheduler Adds GUI, JMX Support

  1. Flux 4.0 J2EE Job Scheduler Adds GUI, JMX Support (7 messages)

    Sims Computing has released Flux 4.0. Flux is a job scheduling software component that supports time-based, file-driven, event-driven, charting, and reporting jobs. Flux 4.0 adds a new GUI and JMX support.

    Check out Flux.

    More info
    ----------------------
    The Flux GUI is a standalone Java application with a point-and-click interface. It is used to view and monitor jobs in a running Flux job scheduler. No programming is required to use the Flux GUI.

    Flux GUI screen shots are online.

    In Richard Monson-Haefel's upcoming book, "Guide to Enterprise JavaBeans", the chapter on "EJB 2.1: The Timer Service" discusses the limitations of the EJB 2.1 Timer Service. Flux provides rich functionality well beyond the EJB 2.1 Timer Service.

    A preview of Richard's book is available on TheServerSide.com.
  2. I went to www.google.com for shopping a j2ee scheduler. I searched for
    "j2ee scheduler". I found three major j2ee scheduler: SuperScheduler,
    Flux and Kronos. I compared them.

    SuperScheduler from www.acelet.com is the best.

    The features I like (missing from others) are:
    * It fully supports distributed computing: you can run your scheduler
      on any node of your network at any time. Any scheduled task will be
      run once and only once. There is no difference if you run j2ee on
      one machine or on a cluster.
    * You can "forsee" all your schedule.
    * You can visually set your ejb task.
    * You can easily make it work with legacy (good) C++ program.
  3. Hi Greg,

    Just to clarify, Flux has supported distributed computing since version 1.0. Flux's distributed computing model includes commercial-grade features like clustering and failover and running jobs on remote machines. It is aimed at the needs of professional software manufacturers.

    Different developers have different needs. I encourage folks to compare solutions and see what works best for them.

    Cheers,
    David
  4. The best for what?

    Perhaps you should be more precise and say that "features unique to acelet are". But there are drawbacks as well. Acelet's GUI appears to require that you have a JDBC connection to your database. This can pose a significant security risk.

    That being said, one feature that is unique to Kronos is that it provides a web based user interface (it also provides a Swing GUI). The biggest disadvantage to Kronos is that they don't support multiple job queues (somewhat analogous to Flux's clusters). It is also J2EE based, meaning that for fault tolerance you have to configure a clusterable J2EE server.

    I took a brief look at the new Flux GUI and it certainly appears to be bare bones at this time. However, their API is very flexible (arguably a little too flexible, because it can be a bit cumbersome).

    I'd go into more detail, but work calls..... =(



  5. I agree with David that every development effort has its own needs, and what is appropriate for one, may not be appropriate for the other. As Jim points out, for example, KronosES is strictly J2EE-based; if you're looking for a scheduling component for a "plain" Java app, then Flux or the open-source (but more limited) Quartz would be more suitable.

    And just as a bit of a teaser, KronosES 5.00 is on the horizon, with some significant enhancements that I think will make people very happy. :)
  6. <Jim>
    Perhaps you should be more precise and say that "features unique to acelet are". But there are drawbacks as well. Acelet's GUI appears to require that you have a JDBC connection to your database. This can pose a significant security risk.
    </Jim>

    Scheduler is an administration tool, supposed to run
    inside trusted network.

    Anyway, the next version of SuperScheduler will give
    you a choice of running your scheduler remotely through
    J2EE server using J2EE server's security.
  7. I have visited Flux screen shots. One thing I do not
    understand:

    Cluster should be transparent for client (scheduler is a
    client of J2ee server). There should be no difference for
    scheduler if you have single server or cluster. There should
    be no difference if any server in the cluster is
    out-of-duty.

    By setting clustering (on your GUI windows), it seems that
    your scheduler is machine dependent.

    If my task is to wire money to my customers on each Friday,
    once and only once. I should not worry if the server
    is a single, or cluster, or any particular machine is on or out.
  8. Hi Alex,

    Thank you very much for your feedback on the Flux GUI. I understand what you're saying how a cluster should transparently hide the machines within it.

    As you noted, jobs are not tied to any one machine. Jobs run on different machines in the cluster. If one machine crashes, jobs will run on a different machine.

    The Flux GUI can query any one of the many machines in your Flux cluster to get information about jobs. The goal of the GUI is to locate any one of the machines in the cluster; it doesn't care which one. Once the Flux GUI is attached to a machine, it queries it and displays the cluster's jobs.

    I hope that helps to clarify things.

    Cheers,
    David