Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

A Quick Look at Spring Batch

06.17.2011
| 6368 views |
  • submit to reddit

If you‘ve looked at one Spring project, you‘ve seen them all. They have a huge document on how to use Batch, but as you slog through it, it‘s the usual Spring ‘architecture,‘ which is basically super vanilla, painfully procedural, and based on the idea of leaving you a bazillion little crags to climb on. The problem with that approach to framework design is it leads straight to Microsoft Access land. You know, you make something moderately complex, and when you come back to it, you spend hours mumbling to yourself ‘maybe it was in the onnext from panel y or on start on task x…?‘ There is no logic, no real model, just a bunch of little snippets and doohickeys adorning the magnificent glory that is the tool itself.

At one point, in the docs, they roll out what they call ‘The Delegate Pattern.‘ Ok, specious use of the word pattern is a misdemeanor in these parts (an immediate Soupy Sales Award for that). There is no pattern there. I think the authors started realizing that 30 pages of block quoted xml examples was making their audience think teething was the only stage they would pass through in using the product. Seriously, are we still doing little snippets of xml bean definitions to build things?

Finally, about the actual framework and design. Even on the naming side, the choices are pretty lame. There‘s a Job and there‘s a JobInstance. This is a classic naming problem, but I like to go in the other direction: I would call the actual thing running Job. The idea here is clearly a simple example of the Prototype pattern. You could hold a Job instance somewhere as the current template or you could make a class called JobTemplate or JobDefinition, and then when the time comes, you would clone that object. There are a ton of legitimate design patterns that could come up in doing a Job engine: Command, Strategy, State (for the job itself), Composite (tasks that include other tasks), etc. None of those show up. Basically, you have a plethora of basic classes like ItemReader, ItemWriter, ItemProcessor. Interestingly, they use generics (something Spring has never thought it was important to support on the DI side). But it‘s hard to see what that does for you really.

I‘m not saying Spring Batch is bad, I would just like to see more. I may try it, god knows it‘s a lot better than Quartz, even after the Terracotta reincarnation… The sad part is, we desperately need things like this. There really are no good ways to do simple scalable and parallelizable jobs. If you are running in a container, you should not use the wonderful threadpool classes in the concurrency framework. You could fire up a message queue, but 15 years in on Enterprise Java, that prospect seems like overkill and even if you did do that, you would have to add a lot of the stuff we are talking about here: tasks, etc.

Call me old school, but when I read a doc for a Framework, I want to see what all it‘s going to do for me, and what I have to do to make it do those things. At one point, they talk about scaling your jobs and I expect to see some discussion of concurrency, queueing, etc. Instead, there‘s a meek, yawning kind of ‘well, we‘re not really hadoop, but if you close your eyes you can make believe.‘

This gets to the core of my issues with Spring: it‘s the Al Gore of the programming world: a Tin Man trying to seem earnest whose whole message seems to be ‘point us to a problem and we can apply our approach to giving you a solution.‘ Imagination score? Zero. Excitement score? about the same as the prospect of seeing the surviving members of The Village People in Vegas. Like Al Gore, you get the feeling that you are in the presence of someone who is too impressed with his own powers to hear the constant squeaking as he does his little jig.

 

From http://www.jroller.com/robwilliams/entry/a_quick_look_at_spring

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fabien Bergeret replied on Fri, 2011/06/17 - 2:26am

Few years back, when Spring batch was so young it was still a beta, I had to implement some batches in Java.

I went through the docs, and, finally, chose to implement the Spring batch way, without Spring batch (because it was still in beta...). I used ItemReader, ItemReader, Step, Job, ... but implemented my way.

The result : strictly no gain in performance, but a code organisation that was crystal clear. It was really easy to maintain, knowing exactly which class was doing what.

 Now that Spring batch is released, I'd certainly use it, mainly for maintenance reasons...

My 2 cents...

Karl Peterbauer replied on Fri, 2011/06/17 - 5:12am

You hit the nail. Spring-style bloatware at its best. 532 classes for a batch library? Wow, that looks impressive! Let's see what's in the treasure chest...

Uhhh, yet another ClasspathXmlApplicationContextsFactoryBean? For what? Yet another ContextFactory? A Classifier<C,T> for classifying what? For heaven's sake, isn't stuff like that supposed to be in the Spring core?

A Validator<T> for the next mini validation framework? A MethodResolver for a mini reflection facility? A DataFieldMaxValueIncrementer with the inevitable corresponding DataFieldMaxValueIncrementerFactory (yeah!) for yet another database sequence abstraction?

And then the grand finale:

public enum DatabaseType extends Enum<DatabaseType>

Enum representing a database type, such as DB2 or oracle. 

WTF???

Manuel Jordan replied on Fri, 2011/06/17 - 8:12am

Hello Guys BTW Apress soon going to release Pro Spring Batch book, I am the technical reviewer of this book, I suggest you consider in read this work Best Regards

Reza Rahman replied on Fri, 2011/06/17 - 1:45pm

BTW, Java EE is introducing concurrency utilities in Java EE 7. I think you could come up with a much cleaner Hadoop style batch procesing model using that API as a basis and creating a Seam style CDI portable extension. Personally, I do see batch processing as an edge case not worth standardizing in core Java EE.

Rob Williams replied on Thu, 2012/01/05 - 7:18pm

How is batch an edge case, Reza? Sheesh, I wish it was, but if anything, Hadoop shows you that years of neglect have resulted in a feral spawn starting to look more powerful than its father.

 I gotta start looking at these comments sooner. Thanks for the intelligent discussion, Guys. @Karl, I agree that it's the weird combination of looking like a huge bloated blob and also a shrunken homonculus that ran around trying to encapsulate way too much stuff. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.