Flux Job Scheduler 3.4 Released

Discussions

News: Flux Job Scheduler 3.4 Released

  1. Flux Job Scheduler 3.4 Released (15 messages)

    Sims Computing today announced the release of Flux 3.4, a software component that provides job scheduling functionality to Java and J2EE applications. Expanding on its workflow and flow chart model for creating and running jobs, Flux 3.4 includes new JMS triggers that fire when JMS messages arrive and XML functionality.

    Check out Flux.

    Press Release
    -----------------
    Sims Computing today announced the release of Flux 3.4.</a> Flux is a software component that provides sophisticated job scheduling functionality to Java and J2EE applications.

    Expanding on its workflow and flow chart model for creating and running jobs, Flux 3.4 contains new triggers and actions for creating arbitrarily complex jobs that accurately meet application requirements. The new triggers include JMS triggers that fire when JMS messages arrive. Flux 3.4 also contains new XML functionality for creating jobs using XML.

    "By plugging in pre-defined and custom components, Flux users can assemble jobs to perform tasks as time and events dictate," said David Sims, President of Sims Computing. "The Flux scheduling engine enables software developers to create powerful jobs with ease and flexibility."

    About Sims Computing

    Sims Computing, founded in 1997 and based in Billings, Montana, develops lasting software solutions for enterprises. Sims Computing's Flux is used in 21 countries by hundreds of customers. For more information, visit www.simscomputing.com.
  2. Congratulations guys!

    In addition to JMS consumption, do you have simple JMS "send" capability on a schedule?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  3. Thanks!

    Yes, you can send both JMS queue and topic messages on a schedule. These are what we call "JMS actions". You can plug them in anywhere in your job's workflow or flow chart to send JMS messages on a schedule or whenever some other event occurs.

    Kyle
  4. Can anyone tell me how Flux compares to Kronos (http://www.indcon.com)?
  5. I'd be glad to, but keep in mind that I'm the Product Manager for Kronos Enterprise Scheduler, so I may be a bit biased. :)

    Kronos Enterprise Scheduler is a complete end-user system with an open API, rather than a scheduling component. Our end user interfaces allow you to create, modify, and monitor jobs either from a Java client or over the Web. Admittedly, Flux does have some very basic Web pages for defining a command-line job and for monitoring job status, but Flux is really intended as a programmer's product, not an end-user product. Kronos Enterprise Scheduler was always intended to serve both needs.

    A second key difference is that scheduling Java-based jobs in Flux requires that your Java class implement a Flux-provided interface. Kronos Enterprise Scheduler has no such requirement, which makes it much easier to schedule execution of functionality in existing applications. This has been a deciding factor for many of our customers.

    That being said, Flux's "job flow" concept is a nice feature that we don't have - yet. With Kronos Enterprise Scheduler, a job can consist of multiple tasks, but the tasks are simply executed in sequence. If a task fails, you can branch to failure task, but that is the full extent of branching that we provide. We do intend to provide complex task flows later this year, complete with sophisticated user interfaces for defining them.

    If you'd like to see a feature-by-feature comparison of Kronos Enterprise Scheduler with Flux and Tempo, send me an e-mail at dgeorg at indcon dot com and I'd be more than happy to forward it to you.
  6. Just need to clear up a misconception. Flux 3.4 does not require your Java or EJB classes to implement a Flux-provided interface. We have new "Dynamic Java" and "Dynamic EJB Session" actions. These actions do not require your code to implement any specific interface.
  7. My apologies, then, Kyle. It wasn't my intention to be misleading. I hadn't seen anything on your website announcing that enhancement, so I figured the requirement to implement the Flux interface was still there.
  8. I'm glad to see here both Kyle from Sims Computing and Dale from Indcon.

    I want now to take an opportunity to ask some questions:

    I think that job scheduling products are more successful and useful in practice then full-blown WfMS. The main problem with WfMS is how do you describe those things that are common enough to be implemented by WfMS and not applications? This is definitely the field that has not yet proven its existence as standalone. Each real project needs much customization and does not need many things that are already build-in to WfMS. So its often preferable to write all WfMS functionality yourself for each project case instead of trying to adopt you business needs to some WfMS functionality.

    So here is the question:
    Do you recognize the need for full-blown WfMC's XPDL like processes?

    Things that usually belongs to WfMS, but now some job scheduling systems already have them supported(to some extent):

    o Job networks:
    Simple Job dependances in scheduling sense:
    Dependent Job Scheduling, Conditional Job Scheduling

    I know that Flux for example supports Branching and Looping.
    o Branching: How does it differ from Conditional Job Scheduling?
    o Looping: How loops can be useful in practice? Isn't it the thing that can be easily done by the application itself?

    o Data associated with a process/job:
    I do recognize the need for stateful Job: each launched job instance should have access to it's state data that is transparently persisted in DBMS.

    In general, each process can have the data associated with it that it uses and manipulates. This data can be transactional: if the job fail, associated data should be recovered (if possible) transparently to the application (and some by the application itself in some special callback method like rollback()) and an alternative job should be launched to accomplish the task (again if possible). Rollback of a single job could also result in cascade rollback of all parent/dependant jobs(nested transaction model).
    Do you consider this scenario useful in practice or plan to support in future?

    It will be very interesting for me (and hope for many other people here) to hear your thoughts..

    Regards,
    Basil
  9. I think workflow management systems are wonderful things. The old adage still applies: use the right tool for the job. Perhaps one major difference between Java schedulers and WfMS is that Java schedulers try to fit into an application without fundamentally altering that application's design. In other words, perhaps it can be said that schedulers adapt to the application design rather than encouraging the application to adapt the scheduler.

    People are using full-blown workflow management systems today, and obviously, for some of them, it is saving them a ton of time and money. And that's great anytime a piece of technology provides the best solution to a problem.

    Just the same, Java schedulers are solving problems too, savings tons of keystrokes and brain cycles on the part of application developers.

    One does not replace the other. They are both needed.

    Regarding the difference between conditional job scheduling and branching: they are two different ways of thinking about the same thing. Conditional job scheduling essentially says to only run a job step if a certain condition holds true. And of course, a branch can go around a job step if that certain condition is false. They're really the same thing.

    Regarding the usefulness of looping: think of creating a job using a traditional flow chart. Flow charts, like workflows, are very high level concepts, unlike the "for" and "while" loops in Java. Since flow charts and schedulers can provide services such as transactional integrity, parallelism, and resource management, as an application developer, it's much easier to use a loop built into a flow chart rather than a Java loop. You get these properties (txn integrity, etc) built-in without having to write code to acommodate that.

    Your comment about jobs transparently saving state is absolutely dead-on. Anytime an application developer can be saved the trouble of writing JDBC and SQL leaves more time for concentrating on the real problem at hand.

    And of course, a scheduler and a job ought to provide built-in transaction management, including support for multiple transactions in different parts of a job, including failure recovery (rollbacks), etc.

    These scenarios are all extremely useful in practice and are used everyday by different applications that employ Java schedulers. After all, if the computer crashes in the middle of running a job, you want to throw away any work that was not committed and re-do it on system restart.

    Kyle
  10. I think workflow management systems

    >> are wonderful things.

      Me too. In fact I'm used to be WfMS advocate, not vice versa.
      
    >> Perhaps one major difference between
    >> Java schedulers and WfMS is that Java
    >> schedulers try to fit into an application
    >> without fundamentally altering that application's design.

      Agree. This is why integration of job scheduler into application is much easier that WfMS. This altering is often a health-giving thing but it requires much efforts to do some BPR & formalization.

    >> One does not replace the other. They are both needed.

      Off cause, I meant only that Job schedulers are embracing functionality that usually belongs to WfMS(job networks).

      Regarding flowcharts:
      My understanding of this is that flowchart is just another method of modeling workflows just like Petri Nets. These two are most common and supplementary ones. Well, not directly, they needs much extensions to be done. So one could draw these diagrams with many attributes like type of action, transaction scope, data flows, etc.

    BTW: It seems to me that you use JVM implementations of wait() and sleep() methods, instead of some native library.
    I've made simple job scheduler myself and found that Date and Calendar classes in the Windows JVM implementations have very low time resolutions - for example, to 1/100th second. So I've used IBM's High Resolution Time Stamp Facility to manage this issue.
    Well, this doesn't matter for most business cases like daily jobs, but rather for system programming & performance evaluations.

    Regards,
    Basil
  11. Yes, you are correct that for flow charts to be useful in a scheduling sense, they need to include the concepts of action types, transaction attributes, data flows, and so forth.

    You'll find that Java schedulers do not use native code to get below the Windows timer resolution of roughly 10 milliseconds because Java schedulers tend to run on so many different architectures. WORA really works. Plus, as you correctly pointed out, sub-10 ms precision begins to fall into the domain of real-time schedulers, not enterprise schedulers that address business cases.

    Kyle
  12. Hi, Basil
    I am new to WfMS. Could you point out some realizations of such a systems that could be used in J2EE projects. Some comments are appreciated.

    thnx.
  13. Lari,
    As of implementations there are quite many products that are called WfMS/BPMS by their vendors.
    They range from FileNet(top-ranked WfMS vendor) products to BEA Integrator(???) to simple workflow engines that come with some CMS/DMS. They do cost quite a lot, often more than app. servers.
    As of integration with J2EE many vendors claim this but do not support J2EE directly. Some like BEA Integrator are built on top of J2EE servers, but AFAIK these types of products only work with native servers - e.g. BEA Integrator requires you to have WebLogic Server.

    There are a few from open source community. Though they in no way can compare with full-blown commercial ones yet, guys that made them did a good work. And a year ago, AFAIK, there were no open source Java workflow solutions at all.
    Current open source workflow engines (engines, not WfMS!) include:
    Ofbiz workflow engine - was created for ofbiz project (lead by David Jones) and therefore needs some proprietary ofbiz modules. It was created as XPDL implementation effort, not full-blown WfMS.
    OSWorkflow(OpenSymphony) - very simple but good if your requirements are not so high, it has pluggable storage providers including EJB. Created by Patrick Lightbody.

    Its a pity, but AFAIK there is no any general purpose workflow management list (like cms-list) on the net.

    There is also a huge amount of information about workflow management on scientific sites such as ResearchIndex. Recently I've read a few hundreds of these papers during my so called research and wrote a modest and rather skeptical report to the cms-list. You may find it here if you wish.

    BTW: I'm currently beginning my own project of full featured WfMS which may become open source. Its supposed to have many features that are not present in many of todays not so expensive WfMSs..
  14. Open Source Job Scheduler[ Go to top ]

    FYI: Here is an open-source java job scheduler (we may have to rephrase the intro pitch to focus more on scheduling than clustering and add a few links...):

    http://medusa-cs.sourceforge.net/

    Regards/m
  15. Open Source Job Scheduler[ Go to top ]

    Hi Miron,
    Very interesting.. but where can I get the code or binaries? Neither project site http://medusa-cs.sourceforge.net/ nor sourceforge home http://sourceforge.net/projects/medusa-cs/ seems to have it.

    Also, interesting to know how it compares to Quartz.
    Quartz doesn't have clusters, but seems that Medusa doesn't have stateful jobs and Cron-like triggers and heavily relies on Java timer implementations.
    In fact it seems to me that Medusa is very low lewel compared to Quartz, it's more like robust platform to build enterprise job scheduler on.
    Is this right?
  16. Hi Basil,

    sorry for the incomplete information but http://sourceforge.net/projects/medusa-cs/ should work fine and here is the CVS link: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/medusa-cs/

    You are correct in some of your assumptions. The motivation behind the Medusa project was the following: The usual gang of J2EE servers are serving requests, typically from users on the web or other systems - basically some external triggers processing, in addition to being expensive and huge in size. What we needed was a system that monitors certain conditions reliably and then takes action. Java Timer is fine for our requirements and timed triggers can be set up in properties files.

    Regarding statful jobs, I am not sure what you are referring to but basically this is where the clustering comes into play. The 'Joblets' have in-memory state replication across servers vs. Flux, which seems to keep state in a database. We have been thinking of adding the database feature, which apperars to be fairly easy, but one has only that many hands (which are currently busy with other projects).
    Another feature on the agenda is to provide a mechanism for the Medusa system to receive serialized jobs, which needs some well designed API. The original idea was using RMI but we would prefer a protocol more suitable for distributed systemes.
    Finally a web based admin interface is on the to do list but would increase the size significantly.

    The stuff on sourceforge is not the very latest code base, which is centered around a non-open-source implementation/application of Medusa but it is fairly close.

    The binaries are very small and we are actually thinking of supporting mobile devices. It would be fun creating a cluster of Java PDAs but currently we can not think of any reasonable application.

    Please have a look at the code if you find the time. We are always glad to receive feedback or even additional pairs of hands. I will also have to upload the compiled binaries, which are basically a demonstration job scheduling cluster out of a zip file.

    Regards/m