News: Flux 5.0 Job Scheduler adds standalone mode, desktop GUI
The Flux 5.0 Job Scheduler has been released. Flux 5.0 allows non-programmers to schedule jobs by using a new desktop GUI for creating, editing, and monitoring jobs using a point-and-click, drag-and-drop GUI for creating 2-dimensional flow charts (jobs) as well as a new command line interface.
- Posted by: David Sims
- Posted on: September 02 2003 17:15 EDT
Other new features include much better dependencies between jobs, job queuing, default error handlers, forecasting, concurrency throttles, job pinning, and split/join workflow enhancements.
Flux 5.0 info and downloads here.
Flux 5.0 screen shots here.
The above screen shots give an idea how jobs are designed using a workflow (flow chart) job model.
- question. by The Industry Observer on September 03 2003 13:12 EDT
- Maestro Vs Flux by Vilas Shettigar on September 03 2003 14:33 EDT
- Flux 5.0 Job Scheduler adds standalone mode, desktop GUI by Andreas Mueller on September 03 2003 14:43 EDT
- Flux 5.0 Job Scheduler adds standalone mode, desktop GUI by David Sims on September 03 2003 15:44 EDT
- EJB Timer Service by Sean Sullivan on September 03 2003 16:28 EDT
- millisecond resolution? by Wei Jiang on September 03 2003 17:20 EDT
- SuperScheduler vs Flux by Alex Ivanov on September 03 2003 17:32 EDT
can the Java Actions in the Screen Shots be part of J2EE environment.
I mean can it be a EJB Client.
> can the Java Actions in the Screen Shots be part of J2EE environment.
> I mean can it be a EJB Client.
Sure. Besides the Java Action in the screen shot, you can use other actions that call EJB session beans, EJB message-driven beans, and EJB entity beans.
For Flux to talk to message-driven beans, you actually use an action called JmsTopicAction or JmsQueueAction, which publish JMS topic and queue messages, respectively. That, in turn, contacts your message-driven beans.
Basically, you plug in different actions and triggers into your job's flow chart, depending on what you want your job to do.
The list of available triggers and actions is here. You can also write your own and plug them into Flux. Flux can run in both J2SE and J2EE environments.
Link to the list of built-in triggers and actions that Flux supports.
How is this different from a product like Maestro? Maestro is also a unix schedular. And does this product interact with other schedulars? We have a system that has a batch cycle running on the mainframe (using Jobtrac) and AIX (usnig Maestro). These jobs are dependant on each other (a few jobs run on AIX followed by some on the mainframe and then again on AIX). Currently there is no communication between Maestro or JobTrac. We introduced dependencies artifically by making some of the jobs file dependant. To kick off a job in JobTrac, I would typically set a dataset/file dependancy on it and then from AIX ftp a file on the mainframe. Soemthing similar to kick off a job in Maestro from JobTrac.
> How is this different from a product like Maestro?
I can best explain this by describing a little of the history of Flux. Flux started out as a Java software component (and still is one). Until Flux 5.0 was just released, you *had* to be a software developer to use Flux's Java, J2EE, XML and Web Services APIs. But now that's changed, so a comparison of Flux to Maestro is appropriate.
To answer your question then, the obvious difference between Flux and Maestro (or something like Maestro) is:
a) Flux is completely defined by its APIs. There are J2SE, J2EE, XML, and Web Services APIs.
b) Flux's GUI, web-based, and command line interfaces were built using Flux's APIs exclusively.
c) Flux is written completely in Java. (Flux's GUI tool is written in Swing instead of SWT. The reason for that is simple: we have a lot of customers running on some crazy hardware, and we can't be sure that there will be a SWT port for that architecture waiting for us.)
d) Flux uses a workflow model to define jobs, which is more expressive than the typical "job chaining" technique used by traditional job schedulers.
e) Flux uses a messaging model (think JMS, but it's not JMS) to define dependencies between jobs. This makes setting up dependencies between jobs more expressive.
So, the significant differences between Flux and Maestro are that:
1) Flux has full APIs that you can use if you want. The Flux APIs access the full Flux functionality, not a subset.
2) Flux and its user interfaces will run anywhere there is a JVM supporting JDK 1.3+. That means Unix, IBM mainframes, Linux, HP-UX, AIX, Windows, etc.
3) Flux's workflow and messaging models may be more expressive than Maestro's job model. However, I cannot say for certain that Flux is more expressive than Maestro, because I'm not familiar with Maestro.
> And does this product interact with other schedulars?
Only to the extent that other schedulers using standard communication mechanisms like Web Services, JMS, and files (your solution -- a good, practical solution).
Unless other schedulers had Web Services or JMS interfaces, I would do the same thing you did.
> I would typically set a dataset/file dependancy on it and
> then from AIX ftp a file on the mainframe.
Yes, in the absence of Web Services and JMS support in other schedulers, I would have defined it this way too, since Flux supports triggering jobs when files arrive on FTP sites as well as copying files up to FTP servers.
The GUI seems to be based on Eclipse or not?
Could you tell your prices? I don't find it on your site.
> The GUI seems to be based on Eclipse or not?
No, not based on Eclipse at all. The Flux GUI is written in pure Swing. There's no SWT in there, and it's not based on Eclipse.
The reason for basing the Flux GUI on Swing instead of SWT was to be sure that it would run everywhere there was a JVM with Swing support.
> Could you tell your prices? I don't find it on your site.
They're not published, but that doesn't mean they're high. Some circumstances merit special considerations. We ask people to contact us at sales at simscomputing dot com or +1 406.656.7398 for pricing.
Question: Is it possible to build a GUI frontend for EJB's Timer Service?
> Question: Is it possible to build a GUI frontend for EJB's Timer Service?
(The EJB Timer Service is very basic, but there could possibly be room for a GUI to get and set EJB Timer Service info, which consists of:
a) Executing an EJB at a specific date and time (eg, 3 Sep 2003 @ 3 PM)
b) Executing an EJB at a period of N milliseconds (eg, every day at noon)
Fyi, some apps' requirements may be basic enough that the EJB Timer Service will suffice. But there is a *lot* of job scheduling fundamentals that the Timer Service doesn't address. Cron-style schedules and pause/resume of jobs are just the beginning.)
I just had a quick glance on the online doc and found:
"Flux's Business Calendars have millisecond resolution"
It is missleading. The time resolution of Java virutal machine (Sun's implementation) is about 10 milliseconds. The tolarence of network time synchronization is 10 millisecondes, at best. How can Java applications be more accurate than that?
> "Flux's Business Calendars have millisecond resolution"
You're right, of course, about JVM resolutions, etc. The point on our website is not to say that Flux is a real-time scheduler, which it's not.
The point is to say that Flux's business calendars are not "day oriented". You can create a business calendar that's oriented to something that makes sense for your business, such as blacking out a period of time from 10 pm until 2:45 am the next morning, Monday through Friday. This is actually something that one of our financial customers uses.
I should take this text I've typed above and paste it on our website to clear up any confusion.
Not that it's all that important, Dave's said his piece to straighten it out...
The resolution of the smallest measurable (outside of realtime Java) is up to the OS. Windows only bothers with 10ms. Sun's 1.4.1 VM on linux easily times down to 1 millisecond for time measuring. I'd also assume it for the thread scheduling.
My reference for this information (besides my linux dev environment) is also gleaned from "Multithreaded Programming with Java Technology -- Bil Lewis & Daniel J. Berg". My one stop shop for all things threads, including this timing issue. Very low level. Anyways...
Dave, top work once again to you and your team. It's a sweet thing.
How do you compare SuperScheduler (http://www.acelet.com) and Flux?
> How do you compare SuperScheduler (http://www.acelet.com) and Flux?
I'm not sure if you directed this at Wei or myself, but since I'm not overly familiar with SuperScheduler, I don't want to misrepresent it. Perhaps Wei should answer this.
However, I can list 4 Flux features that highlight what's great about Flux:
1) In Flux, jobs are modeled using a workflow (flow chart) model. This allows you to create very simple or very complex jobs with sequencing, branching, and looping, which has proved very useful in practice.
2) In Flux, different jobs coordinate their work using Flux's messaging model (think JMS, but it's not JMS). This allow complex dependencies between jobs. For example, jobs X, Y, and Z can wait for job A to reach a milestone before they execute. Or vice-versa: job A can wait for jobs X, Y, and Z to finish first.
Flux's messaging model provides for job queuing too. Different producer jobs can generate work and place it in a Flux queue. Then other consumer jobs can process that queued data in first-come-first-server order.
3) Flux jobs are not just about time. They're about time, events, and files. A lot of people user Flux to trigger jobs when files arrive on FTP servers or when other events occur. It's not just about time.
4) Finally, Flux's timing capabilities are extremely expressive. In a single schedule (we call them "Time Expressions"), you can specify that a job should fire using these complex schedules:
- From 7:10 AM through 6:30 PM, every 7 minutes, Monday through Friday.
- From 10 PM until 2:15 AM the next morning, Monday through Friday.
- Mon/Wed/Fri at 3 PM, skip 3 weeks, then repeat.
These real-world schedules are hard to represent in a single schedule, much less multiple overlapping schedules, but Flux is really good at this sort of thing.
How do you compare SuperScheduler (http://www.acelet.com) and Flux?
My knowledge about Flux comes from quick glance of its online doc. I can not really compare them but only list a couple features of SuperScheduler. SuperScheduler is one component in our j2ee tool suite.
* SuperScheduler fully supports distributed computing environment: you can run SuperScheduler on any node of your network at any time. A job will run once and only once, if one or more instances of SuperScheduler are running, regardless of how many application servers or which server are running. Missed tasks (from hardware failure) or critical errors will trigger alert emails.
* SuperScheduler works in both native mode (rmi-iiop) and HTTP/HTTPS mode. You can manage/monitor tasks in your data center or remote warehouse where the only protocol available is HTTP.
* SuperScheduler allows system tasks be grouped by business subjects and run on different offices.
* SuperScheduler is very user friendly. You can visually set EJB tasks. In case of programmatically scheduling tasks, you just call very simple APIs, no complicated expressions: giving very little chance to make an error.
* SuperScheduler works with SuperLogging, SuperReport and SuperPatrol to do business analysis. Should anything is wrong, an alarm email will be sent specified receipient according to the subject.
* See http://www.acelet.com/super/SuperScheduler for more features.
Another all java scheduler with advanced plugin API (GWT and Mule/SOA supported) is JobServer. It is an all java job scheduler with a nice Java/GWT plugin API for writing tasklets and giving tasklets GWT GUI interfaces for customization. It has lots of nice reporting and tracking features and very good scheduling rules. Rauf http://grandlogic.com "The SOA Automation Company"