Weaving microservices : DSL

respect to : http://www.w3.org/People/Berners-Lee/Weaving/Overview.html

ある程度以上の規模のサービスは分割の’仕方を工夫すればMQTTのようなプロトコルを介したマイクロサービスに分解できる。 そしてその構造はDSLで書けるんじゃないか

たとえばS3をMQTTを使って分割し直すとする場合、 CRUDとかRESTとかいう方針というか「戦術」は使えるが、全体として運用する「戦略」を記述したい。

で、分割した結果を形式的に’表現して

• チェック
• 実装へ落とし込む
• デザイン言語として共有する

ことができて欲しい

そんなDSLが欲しい

それはServer Engineなのか、いやそれは「切れ目」であろう

言語要素としては（通信プロトコルの細部の差異は無視して）

• publisher、subscriber, broker
• Queue
• worker, supervisor, scenario(Luaコード片とか)
• 永続化、キャッシュ
• トランザクション範囲、ロールバック、QoS、エラー、リトライ、タイムアウト
• HAについては透過性があるとする（記述しない＝逃げ）

全体の構造はモノリシックアーキテクチャの言語のデザインパターンでカバーされているはず。 それを疎結合化する、という方向で既存の技術があるはずだ。

自分としてはそれよりも、bottom upで考えてどこまでいけるかやってみたい。

DSL定義

構文

top level

サービス: サービス名 '(' データのリスト ')' '{' roleのリスト '|' シナリオのリスト '}'

verbs

予約済みのverb(PUB, SUB, 永続化, KEY, etc.)がある。 CRUDやRESTを考えれば、PUT, GET, UPDATE, DELETEも含まれるだろう。

※verbは引数としてデータのやり取りの相手とデータを指定することになる。

store SUB topic > broker

と書くべきかも。

データ

• atom : a
• list : [a, b]
• tuple : {a,b}

修飾、制約、契約

• transaction
• QoS
  • retry scheme

samples

chat service

chat (topic, message) { viewer, store, broker, publisher |

publisher PUB {topic, message} > broker;
store SUB topic > broker;
store 永続化 {topic, message};
viewer GET topic > store > message;
viewer SUB topic > broker;
}