Batch Management Console?

[whyBish]

Are there any plans to create a batch management web frontend?

I'm thinking that there are a bunch of common batch tasks that a spring-batch management console would be good for:
- Create/modify Job Schedule (would require a JVM based scheduler)
- Manual job kickoff (with parameters)
- view current jobs
- view job history
- halt executing job
- view status of a current job.
- view logs of a failed job
- etc.?

This would sure beat using the command line, allows a full end-to-end java solution, avoids scheduler->batch OS calls, and avoids needing a OS specific person on staff just for batch monitoring/maintenance

[Dave Syer]

Spring Batch itself is not a runtime application (it provides a configuration and programming model for building batch applications). All the runtime concerns you mention are good ideas. You can expect to see some or all of them appearing as features in the SpringSource Application Platform and/or the SpringSource Application Management Suite, since those are the products that we provide to address runtime concerns.

[Chuck Marten]

Hey that's a great idea! I figured people would just write their own job management console and use CommonJ or something to run their batch apps. An application platform with a built-in console would solve this for everyone.

While snooping around I found a product that already provides an application platform and batch management console. The vendor claims it can host Spring Batch applications. It's called XD Compute Grid.

[whyBish]

It's called XD Compute Grid.

Websphere

I'm trying to keep app server & DB agnostic, as we have various clients that have already made their choice in this area (and it is hard to change the minds of government agencies, large Banks, central banks etc.)

The nirvana for our company platform is an opensource stack with no DB or web/app server specific reliances. The spring framework supports this concept well. Example web stack:
SpringMVC,
Spring Webflow,
Spring bean validation,
apache CXF (web service enabler to bridge presentation->app logic and provide reusable services for non-web channels),
jBPM (Workflow, where the business process logic is configured... I'd prefer jBonita which is better encapsulated and has better management features, but last I looked it was only officially supported on glassfish)
Hibernate
HSQLDB (since the db can be run as a servlet, to keep all individual deployments web based for easy management, at least for dev. Only standard JDBC access so can be switched for vendor DB)
Tomcat (for dev, avoid webserver specific config (unfortunately not always completely possible, but at least we can minimize/document since nightly builds and system test will use the clients web server))
spring-integration? (Ideally needs a mgmt/monitoring console)
spring-batch? (Ideally needs a mgmt/monitoring console)
spring-security? (ideally needs a management page/web services)
quartz? (Ideally needs a management console)
log4j

With these in place, (and possibly some common glue, and common custom consoles ) we can avoid doing the heavy lifting for each project, we can standardise project documentation, we avoid vendor lockin (apart from the common glue & consoles), our BAs can focus on value add (process reengineering), our devs can focus on the business functionality rather than donkeywork, our employees will get more variety of projects, our clients will get software faster,cheaper, more reliable, and easier to understand/maintain/enhance.

[whyBish]

You can expect to see some or all of them appearing as features in the SpringSource Application Platform and/or the SpringSource Application Management Suite, since those are the products that we provide to address runtime concerns.

The application management suite sounds like what I am interested in, but the whole site does not have any cost info or purchasing links. What am I missing?

[Dave Syer]

Thanks for the interest. Send an e-mail to sales@springsource.com, preferably telling us what country / city you are in, and someone will contact you.

[Chuck Marten]

I'm trying to keep app server & DB agnostic.

Yeah, that's understandable. My company is not a software vendor, so our needs are different. I'm in the IT delivery department of a major insurance company. It happens we use WebSphere and are quite satisfied with it. We happily use Spring Framework and have new requirements for batch processing - hence our interest in Spring Batch. Trouble is we really need a complete batch processing system - you know, with a job console, workload management, etc. We really don't want to build our own infrastructure. That's why we're looking at Compute Grid.

In your case, you probably need to stick with a full open-source stack. Our IBM rep leaked to us (doh!) that the next release of Compute Grid will provide management for a portable batch container that runs on various other J2EE servers, like WebLogic and JBOSS. Since apparently you can run Spring Batch apps on Compute Grid, that would open up additional options in the future. If IBM was smart, they'd open source this technology. But that wouldn't be like them, would it? :-)

Best of luck with your project!

[whyBish]

Best of luck with your project!

Cheers. The best thing about open source projects (and open standards) is it keeps you flexible. That means your skills don't become as obsolete as fast, and are more widely applicable.