前回は “smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” の意味することにについて考察しました。
今回は、マイクロサービス間の連携を支えるこの “smart endpoints and dumb pipes” の具体的なアーキテクチャについて考えてみます。
マイクロサービスとは、複数のマイクロサービスが連携して業務処理を実現するアプリケーション アーキテクチャです。
単一の機能にしぼった小さな (マイクロな) サービスを連携させることで、大きな処理を実現するアプローチは、UNIX シェルのパイプのエッセンスを有しています。
前回は、マイクロサービスについてUNIX のパイプ機能をアナロジーとして取り上げ説明しました。
今回は、マイクロサービス間の連携を支える “マイクロサービスにおけるパイプ機能” について考察してみたいと思います。
マイクロサービスを提唱したJames Lewis氏が Martin Fowler氏と共に著した『Microservices』*1という記事の中で、「Smart endpoints and dumb pipes」*1というセクションを設けて、マイクロサービス間の連携について説明しています。
このセクションではまず、対極にある smart pipe を説明しています。smart pipe の例として ESB (エンタープライズ サービス バス) などのアプリケーション連携製品をあげています。
現実世界の業務処理では、”何らかの事象 (イベント) が発生するとそれに応じた業務処理が実行される” というケースが数多くあります。例えば、イベントには次のようなものがあります。
今回は、イベント駆動によるアプリケーション実行とメッセージングとの関係について考察します。
“メッセージング” という言葉は、コンピュータの世界のさまざまな場面で広く使われています。例えば、OS のコンセプトを説明する場面や e-メール システムを説明する場合にも使われています。
ここで説明するメッセージングとは、JMS におけるメッセージングを指し、アプリケーション間の非同期通信 を説明する言葉として用いています。
また、”メッセージ” とは、非同期に送受信される情報データ、リクエスト、レポート、イベントなどを指し、人間ではなくアプリケーション ソフトウェアによってコンシューム (受信、処理) されるものを指してしています。
今回は、JMS をメッセージングのプロトコルとして使用することの意味について考察します。
Twitter