ESB／EAIを利用し、データ連携とコンポーネントで成長するシステムを構築する

エンタープライズシステムのためのマイクロサービスアーキテクチャの実現　第3回

ESB／EAIを代替する手段

　ESB／EAIフレームワークは多くの場合、Javaなどの業務型ソリューションで多く使われる言語を必要としてしまうという傾向があります。しかし、開発にJavaが使えないというケースもあります。その場合には、Webhookを使ってシステム間連携するシステムを提案しています。

　図16はWebhookを用いて月次レポート機能を構成する場合の例です。

図16：Webhookを用いてプロセスを連携する

　また、それぞれの処理には一連の処理を示す処理IDをもうけます。このようにすることで処理に応じた分岐や変換処理をREST処理として実装し、全体として簡易的なESB／EAIシステムと同じようなことが可能にします。実際には、もうすこし処理が大きい単位で行いますが、実用としては十分なケースも多々あるはずです。

　また、EAIエンジンの中で動くコンポーネントであっても、筆者は、図17のように途中経過を把握したい場合にはWebhook機能を用いてその途中状況を記録することがよくあります。

図17：Webhookを途中状況の把握と例外時の再実行に使う

　特にマイクロサービスによりサーバが異なる場合、それぞれのライフタイムが異なるために処理が失敗した場合の把握とその再実行方法を設計しておく必要があります。

　そのような対策としてWebhook機能を設けておくことが多々あります。

最後に

　第1回で統合型／分散型のシステムの特徴について説明し、第2回ではデータ連係についての考え方について説明しました。そして、最終回である第3回では、それらの基本的な考え方にこだわらず、いろいろと混ぜて使う実例について紹介しました。

　この第3回では、ESB／EAIフレームワーク等がもつ特徴や制約をあえて超えて、メリットを既存のソリューションの中でより得るために組み込む方法について述べました。

　より自由な構成ができ、制約も少ないなかで機能を作っていくと、どうしても場当たり的な実装も増えてしまい、結果、複雑化していく傾向になりやすくなります。

　そのためにも第1回と第2回で述べた本来あるべき制約や考え方はできるだけ崩さないように心がけることも大切になります。そのようにすることでメリットを最大化できれば、組織やその事業にとってより最適な形に成長し続けるシステムが構築できるようになるはずです。

参考資料

• Redhat Fuse
• Apache Camel
• Mule