ひしだまの変更履歴

ひしだまHPの更新履歴。
主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。

Batch DSLの功罪

2013-12-08 19:44:15 | PG(分散処理)

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はとても分かり易い」というメリットもあるので。


コメント    この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« Asakusa DSLの裏側 | トップ | Flow DSL・インポーター・エ... »
最新の画像もっと見る

コメントを投稿

PG(分散処理)」カテゴリの最新記事