Batch DSLの功罪

Asakusa Framework Advent Calendar 2013の8日目です。大仰なタイトルは釣りです(笑)
今日はBatch DSLについてです。

Batch DSLは、バッチを定義する為のDSLです。
ここで言う「バッチ」とは、実行する単位のことで、Windowsで言えばひとつのexeファイル、UNIXで言えばひとつのa.outのようなイメージです。（今どきのUNIXでもa.outって通じるんだろうか＾＾；）

例えば「Example1Batch」というバッチを定義したら、AsakusaFWが提供しているYAESSのシェルを使って、以下のようにして実行することが出来ます。

$ASAKUSA_HOME/yaess/bin/yaess-batch.sh Example1Batch

---

実際にBatch DSLをどう記述するかというと、以下のような感じです。

Work jobA = run(JobFlowA.class).soon();
Work jobB = run(JobFlowB.class).after(jobA);

「まずJobFlowAを実行し、JobFlowA（jobA）の後でJobFlowBを実行する」という記述ですが、詳しい説明を受けなくても、なんとなくそう読めると思います。
「.class」が出てきたり変数jobAを定義したりしているのは、Javaを使ったDSLだからですね。

このように、Batch DSLの例を見ると、「Javaをホスト言語とするDSL」がどういうものなのか掴み易いと思います。
ジョブフローが2つだけだと少々さびしいので、4つくらいのジョブフローを書いた例をよく見かけます。

---

しかし、実際のところは、1つのバッチの中には1つのジョブフローしか書かない事の方が多いです＾＾；

1つのバッチの中に複数のジョブフローを書くとなると、どういう切り分け方でジョブフローを分けるのか、という基準が必要になります。
ジョブフローはファイルを出力する（出力が一旦確定する）ので、ジョブフローを分けておくと、後続ジョブフローの実行が失敗した場合、後続ジョブフローだけリラン（再実行）するという事が可能になります。（ひとつのジョブフローでひとつのロングトランザクション（業務トランザクション）を構成する、という考え方です）

しかし個人的には、それならバッチごと分けてしまって、後続バッチをリランする、という形でもいいんじゃないかなーと思うのです。
JP1やA-AUTOといったジョブ管理ツールに登録するのはバッチ単位なので、バッチで分けておけば、リランの管理はジョブ管理ツールに任せることが出来るからです。

ついでに言えば、1バッチの中に複数のジョブフローを描いている図を見ると、Batch DSLを「（ジョブ管理ツールのような）ジョブネットを記述する言語」のように誤解する可能性もあります。（というか、自分は最初そうなのかと思いました＾＾；）

---

という訳で、ここからは空想ですが。

仮に、1バッチには常に1ジョブフローしか無いという考えだったなら、ジョブフロー（＝バッチ）だけ定義すれば済むことになります。すなわち、Batch DSLというものは不要になります。
そうなると、Batch DSLを覚える必要は無くなるし、ジョブネットを記述するかのような誤解も生じません。
AsakusaFWの「ジョブブロー」はファイルを入力としてファイルを出力しますが、その「ジョブフロー」が「バッチ」という位置付けになれば、一般的なバッチもファイルを読み込んでファイルを出力するので、対応付けとしても分かりやすいのではないかと想像しました。

まぁ、分かってしまえばBatch DSLはほとんど機械的に書けるので、あまり深く考えても意味が無いかもしれません＾＾；
先に書いた通り、「Javaをホスト言語とするDSLの例としては、Batch DSLはとても分かり易い」というメリットもあるので。