Announcement Announcement Module
No announcement yet.
Spring Batch & JSR 352 Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Batch & JSR 352

    First thing: your forum application prevent me to search things like JSR or 352 because is too short ...
    So, if this post is duplicated, it's not my bad.

    Second thing: the JSR is very similar to Spring Batch. I read this fact as a public recognization of Spring Batch value.

    I'm wondering (not alone, I think) what are the strategic decisionson Spring Batch, from now.
    [From the jira issues] it seems that you are going to completely support the JSR spec. Is is correct?
    • Will you enhance or differentiate?
    • The Spring Batch framework could be included (in TOMEE??) as delegate to support the JSR spec for the JEE compliance?
    • Will be some sort of classpath scan to recognize the jobs in META-INF subdir?
    • What other?

    Please: share your thoughts with your base-developers...


    [[ EDIT ]]
    Re-reading my post, i suspect that is a bit confused...

    Definitely: what are the actual strategic guidelines that you are following for the development of Spring Batch, in respect to the official JSR 352 ?
    Last edited by giovanni.dalloglio; Jun 14th, 2013, 08:52 AM.

  • #2

    First of all, thank you for the congrats. Myself and Wayne Lund worked hard for many months on the expert group for JSR-352 to help mould it into what we believe to be a solid specification. As such, Spring Batch is implementing JSR-352. The progress can be followed via our Jira here:

    With regards to your bullet points:
    • Will you enhance or differentiate? We believe that Spring Batch already provides a superset of the functionality required in JSR-352. Between things like java config, distributed processing via remote chunking or remote partitioning, and a battle tested set of implementations for virtually all of the components within the spec we believe that we will not only provide what the spec requires but much more. Keep in mind, JSR-352 provides only a spec (similar to JSF) and requires no specifics around provided functionality (no required ItemReader implementations for example). Beyond that, Spring Batch is still a growing framework. With it's influences in Spring Hadoop and Spring XD, we believe that Spring batch will differentiate itself by demonstrating how it can be applied in a number of new use cases including big data.
    • The Spring Batch framework could be included (in TOMEE??) as delegate to support the JSR spec for the JEE compliance? Anything is possible but I have no knowledge of that being in the works.
    • Will be some sort of classpath scan to recognize the jobs in META-INF subdir? The spec provides an order of precedence for the bootstrapping of jobs. It will be our recommendation to use the already strong toolset of Spring to configure your jobs, however we will support what the spec requires.
    • What other? Do you have any requests?


    • #3
      Hello Michael.

      Thanks for the response. You were very kind, and I would share something more.

      During these weeks we're wondering what will happen to our customers, with the arrival of the JSR.
      I'd like to share with you (with everibody's reading) some hypotheses about possible future trends, and understand what you think about.

      My job:
      My company develops software for Italian banks.
      We were among the early Spring Batch adopters... and promoters.
      It was not easy: our customers would have felt more comfortable with proprietary solutions.

      However, three years of java batches with Spring Batch: three years of satisfaction.

      Ok. I finished with the introduction, and with the free advertising .

      My market:
      Let me tell you a little about what (very modestly) I believe to be the scenario of Italian banks:
      our customers have very advanced needs, are very bureaucratic, and we must meet several offices (architectures, policies, security, ...) to obtain approval for a project.

      In addition, for many reasons, our customers have difficulty to structure itself to support batch java.
      They have pretty much only COBOL batch.
      It would be a long process, which would involve many offices, and will unbalance the established power relations.

      This bureaucracy makes everything more difficult, and many developers do not want to deal with the required steps.
      So they use Spring Batch, but they use it a bit "hidden" saying <<we have asynchronous processes, but don't worry about those, rather I wish to bring your attention to ... >>.

      In this way Spring Batch is spreading un-seen and un-noticed.

      My HYPOTHESIS about the future [for this class of customers].
      With the release of the JSR, many things could change: when the Application Server will provide support to the official batch java, even for banks it will be quite easy to provide "official support" to this technology.

      So those who have so far developed "in the shadows" may arise "in the light" (since the JSR seems to be a really good specification, and remaining "in the shadows" will be very risky).
      Thus would begin a period of cohabitation/transition between the two modes of batch java.

      It may happen, from the technical point of view:

      The 95% jobs (that we should try to keep as simple as possible)
      • The XML job description, will be written according to the JSR (and the chosen Application Server will manage the execution)
      • Spring Batch will be an application library, for available implementations (something like JSF and RichFaces)

      The 5% jobs, with "really need for extra requirements" (feature like "remote chunking or remote partitioning"):
      • Spring Batch will be used "full blown"

      I'd like to know what you think:
      • Do you agree on my viewpoint about the bank market?
      • Similar markets?
      • What do you think about my hypotheses about future?

      Thank you, Michael (I hope you'll answer this also), but also to all others who will contribute to this thread.