• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How do you deal with batch / background processes in a Java EE enviroment ?

 
Bartender
Posts: 1357
39
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As everyone knows, pratically any enterprise application needs to execute long time running processes, like creating billing reports, creating invoices, handling payroll and many other similar examples. Java EE defines a lot of enterprise-level constructs (EJBs, Servlet, RESTFul API ...) and services, and you may run all of them in an Application Server. Typically an application server is used to deploy interactive applications (mainly web based, but there's place for server-side of desktop client applications too), and I'm not aware of an "Batch Application Server" specialized to hosting batch processes.

With JSR 352 - or Java Batch API, you are able to deploy batch jobs in an application server. Since I'm required to propose a batch-processing solution, I stared reading here and there, and at the moment I'm oriented to propose following solution:

- use a Java EE 7 compliant application server as batch-server;
- adopt Spring batch as framework to write and execute batch jobs;
- develop each job as a WAR project, so that I can redeploy a single artifact and I should be able to expose a REST based API to start, stop, restart jobs (it seems that Spring took a similar approach).

The question is: what shortcomings do you see in proposed approach ? Generally, how do you deal with background and batch processing of long-lasting operations ?

I'd love to hear your suggestions !


 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Those candidates all look good to me. In the past, I have used these approaches:

1. Run background tasks separately, from a "command line" Java process/daemon that waits for requests to kick off batch jobs. A simple message-based or RESTful API is provided so the main app can send requests to kick off jobs. Coordination and status synch is done either by other API call(s) or simply via a shared DB. I prefer the API calls but it's pretty much the same difference.

2. I have used Quartz Job Scheduler in the past to schedule and run background processes.

I wouldn't say these approaches have many shortcomings that I can think of, just things to consider. Coordination, status checks, duplicate job requests and preventing them, suspending jobs, aborting jobs, restarting jobs. It can get complicated once you start finding value in the initial implementation. Once you start seeing value, you or user will always think of more "cool" stuff this thing should be able to do.
 
Claude Moore
Bartender
Posts: 1357
39
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Junilu for your reply.

Junilu Lacar wrote:
1. Run background tasks separately, from a "command line" Java process/daemon that waits for requests to kick off batch jobs. A simple message-based or RESTful API is provided so the main app can send requests to kick off jobs. Coordination and status synch is done either by other API call(s) or simply via a shared DB. I prefer the API calls but it's pretty much the same difference.


It may be a feasible approach, only I think that it sounds too much hand-crafted. I'd like to rely upon some rock-solid foundation, that's why I'm looking for something similar to an appserver, but specialised on batch processing...

Junilu Lacar wrote:
2. I have used Quartz Job Scheduler in the past to schedule and run background processes.


Sounds a reasonable choice.

Junilu Lacar wrote:
I wouldn't say these approaches have many shortcomings that I can think of, just things to consider. Coordination, status checks, duplicate job requests and preventing them, suspending jobs, aborting jobs, restarting jobs. It can get complicated once you start finding value in the initial implementation. Once you start seeing value, you or user will always think of more "cool" stuff this thing should be able to do.



Those are my main concerns pulling me to avoid self-made architectures. Spring batch seems interesting, and I though to deploy batch modules as "regular" Java EE modules (more precisely, WAR modules). My concern in this case is to have the same appserver running both web applications and batch modules.
A background / batch task is tipically long lasting and may be CPU intensive.. what about performances ?

 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Software development involves experimentation. You should experiment with a few alternatives if you're bent on finding the "best" solution. Otherwise, just go with an approach that you are comfortable with. If you are concerned about performance then don't use your gut to judge whether or not you have a problem. Use a profiler instead. A profiler is much more reliable than your digestive tract or intuition. If CPU usage becomes an issue, you can always run the batch process on another machine. Then you'd have to go with some kind of messaging system or web service to communicate with that process from your main app.
 
I didn't like the taste of tongue and it didn't like the taste of me. I will now try this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic