Proč jsem nepoužil Spring Batch?

Když jsem si srovnal zadání na mém posledním projektu, tak vše na první pohled nasvědčovalo tomu, že bude vhodné použít Spring Batch, další projekt z rodiny Springů. Za to jsem byl moc rád, protože jsem již delší dobu hledal příležitost, abych tento zajímavý projekt vyzkoušel.

Na začátku jsem Spring Batch znal jen z několika článků, a proto, když se mi v zadání projektu objevovala slova jako "dávkové zpracování, škálovatelné, rychlé, vícevláknové, robustní, procesy", tak se mi to automaticky spojilo s tímto Springovským projektem. Nastudoval jsem referenční příručku a přidal do mé aplikace.

Bohužel žádný Spring Batch ve výsledné aplikaci nenajdete. Když se teď na to koukám již z dvouměsíčním odstupem, tak se musím trochu smát, jak jsem opravdu chtěl za každou cenu Spring Batch využít, jak jsem se to snažil napasovat na všechny možné podporované "patterny" z dávkového zpracování dat apod. Nakonec jsem Spring Batch kompletně opustil a vystačil si jen ze základními funkcemi Spring frameworku pro scheduling a práci s táskama - Task Execution and Scheduling.

Výhody použití Spring Batch:

• Spring Batch pomáhá s řešením dávkového zpracování dat, což má svá určitá specifika ve srovnání s "normálními" aplikacemi. Pokud náš řešený problém dokážeme napasovat na podporované scénáře, tak máme vyhráno a můžeme Spring Batch použít.
  
  
• dávkové zpracování hodně souvisí se správně zvolenou strategií transakcí a zde podle mě nabízí Spring Batch největší přidanou hodnotu, kdy jsme většinou zcela oproštěni od řízení transakcí.
  
  
• dávkové zpracování ve většině případů vyžaduje nějaké vstupní funkce na čtení a pak výsledné zapisovače. Spring Batch obsahuje čtečky pro flat soubory, XML soubory, databáze atd., data je možné zapisovat do databáze přes JDBC, Hibernate nebo JPA. Samozřejmě není problém si cokoliv upravit či dopsat - já sám jsem si napsal čtečku dat z mailové serveru.
  
  
• Spring Batch nabízí funkce na opakování a znovu-spuštění dílčích operací (repeat a retry). To vše díky tomu, že Spring Batch si ukládá všechny informace k tomu, aby mohl jakýkoliv proces, krok procesu znovu spustit nebo ho pustit opakovaně.
  Spring Batch vyžaduje určitý datový model, do kterého si ukládá informace o aktuálním procesu, kroku, zpracovaných datech. Ukládání těchto dat není povinné, ale pak je řada funkcí nedostupná.
  
  
• Spring Batch Admin - pokud necháme Spring Batch ukládat běhová data, pak můžeme využít webovou aplikaci pro zobrazení těchto dat, pro jejich administraci, včetně funkcí na znovu-spuštění procesů či jednotlivých kroků.
  
  
• jak už jsem psal, dávkové zpracování má svoje specifika včetně řady "paternů" pro různé scénáře a pokud naše řešení dokážeme napasovat na tyto paterny, tak budeme mít aspoň nějakou jistotu, že daný problém řešíme dobře.
  

Já jsem Spring Batch nevyužil z těchto důvodů:

• zažil jsem to poprvé, ale měl jsem od zákazníka celkem přesné zadání, jak by workflow aplikace mělo vypadat. Neměl jsem tedy úplně možnost si to udělat podle sebe. (ono by to šlo napasovat, vše jde, ale došel jsem k názoru, že to udělám mnohem jednodušeji bez Spring Batch, viz dále)
  
  
• nepotřeboval jsem žádné repeat a retry funkce, žádné držení stavu, žádné informace o počtu procesů, kdy běžely, žádnou webovou vizualizaci dat atd.
  
  
• po nějakém zhodnocení jsem došel k závěru, že jediné co by mi Spring Batch přinesl, tak by bylo transakční řízení, které jsem navíc potřeboval také nepatrně jinak, než bylo standardně nabízenou.
  

I když Spring Batch ve výsledné aplikaci není, tak i přesto jsem se s ním detailně seznámil, řadu věcí vyzkoušel a pokud budu zase někdy něco řešit dávkově, tak určitě budu přemýšlet o jeho využití.