This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.To start at the beginning, follow the link to the first post.The next post in the series is
here.
This series is also available as a podcast on iTunes, Google Play, Stitcher, or use the link to the RSS feed.
-----
I suppose this should have been obvious, but I have to admit when I saw this in the JBeret set of readers and writers I thought, “Wow…that would be cool”. So, as with messaging, let’s consider the writer first.
Basically you’re going to give the writer a URL and it is going to do a PUT or a POST with whatever object payload you give it to write. It is just going to drive this same REST interface over and over as the job runs, pushing data at it to do whatever it does. This seems like a really great way to integrate something at least kind of modern with something like batch that feels, well, less modern, no matter how you write it? I really like this. You’ve got some nifty OLTP REST thing that gets used by your mobile users and you drive that same interface from your batch program. Of course this might subject it to a short, but intense load it doesn’t normally get. You might confuse the heck out of your dynamic scaling…one minute hardly anything, the next you’ve got 1000 requests/second, and then nothing when the job ends.
Alright, but what about the reader? Well, that’s just going to drive a GET against the URL you give it and turn the response into the read results. But think about that for a moment. There’s an assumption that each call returns a different result. So either the client is passing in some information that changes (like incrementing through record indexes or a list of customer identifiers) and getting back the corresponding result, or the REST provider has some state. If you don’t tell it what record you want, there’s an assumption that every time you call you get back a different result to be processed.
Now maybe the GET operation does update something to indicate the result it passed back has been ‘consumed’ and it won’t give it back again. Somehow you’d have to reset that to run the job again. Unless, like messages, the returned result is actually consumed when it is returned and doesn’t exist to be given out again. But now you’ve got some worries about job failures. What if the job died before it finished processing the record and now it is gone? Well, maybe it is ok, but maybe it isn’t.
It seems like it would make more sense for the client to pass in some indication of what it wants back. The REST ItemReader from JBeret has a readerPosition variable (an int) that gets passed to the REST interface to indicate the record you want. And you can control where it starts, but it always increments by one.
I noticed that you can also get the reader to do a DELETE instead of a GET. That seems kind of weird for a reader, but I suppose maybe that fits with the give-me-the-next-one model where the server forgets the item when it has returned it.
So some quirky stuff here, but all in all I think it is pretty cool.