ESB／EAIの動作形態
前回はESBとEAIの機能や目的の違いについて簡単に説明しましたが、今回は動作形態の違いにフォーカスを当てて説明します。ESBやEAIを導入するというと、SaaS型やパッケージ型だけのように思いがちですが、図9のようにエンジン型のように既存のアプリケーション内部に組み込む方法もあります。
利用用途や目的に応じて、どの形態がよいのかを検討してみます。
SaaS型／パッケージ型
SaaSやパッケージ型のESBサービスには、以下のようなものがあると前回も紹介しました。
どちらも、そのシステム内に別のシステムを組み込むことを前提もしくは主な目的としたものではありません。一方、「ノーコード開発」であったり、既存のサービス、特に日本にしかないサービスとの連携は充実しています。
特に最終的な出力に日本特有のサービスと連携したり、RPAやオフィス業務と連携したい場合には、こういったサービスは有効だと思います。しかし、この記事の趣旨である自社で開発したマイクロサービスと密に連携したいケースでは少々、目的は異なると思います。
フレームワーク／エンジン型
フレームワーク／エンジン（ライブラリ）型にも大きく分けて以下のように2つの種類があります。
- 統合型バックエンドシステムフレームワーク（アプリケーションフレームワーク上に配置して動作）
- ライブラリとして提供（内部でEAIエンジンとして利用されることが前提）
例えば、Red Hat Fuseが統合型バックエンドシステムフレームワークにあたりますが、その中には、Apache CamelというオープンソースのライブラリとしてのEAIエンジンを内包しています。
また、MuleSoftという会社では、自社で有料の統合型バックエンドシステムフレームワークとしても提供していますが、一方で無料版としてもMule Kernelとしての提供しています。
従って、ライブラリとして導入しEAIエンジンとして組み込んでから、後で有料版へと引き上げるという方法もあります。筆者がいる会社で主につかっているのは、Apache Camelになります。
エンジン型の利用例
Apache Camelを前提に記述しますが、オープンソースといってもさまざまな連携コンポーネントがすでにあり、300以上もの連携コンポーネントをそろえています。
例えば、Google Calendarに予定タスク情報を追加したいといった場合でもGoogle Calendarコンポーネントを使えば良く、個別の開発をせずにすみます。
また、エンジン型でもあり、オープンソースという利点もあるため、筆者はよく図10のようにマイクロサービスにEAIエンジンを内包してEAIの強みである既存の連携コンポーネントを使います。
このようにすることであたかも、1つのマイクロサービスの機能自体がESB／EAIシステムの1つの部品機能のように見なせます。先ほど紹介した「ファイルの保存」や「通知機能」のためだけにESBシステムを別に1つ構築するとなると何やら大げさに感じますが、エンジン型を採用すれば途中でDBなどのようなアプリケーション依存の入力処理を途中にいれてもそれほど、複雑化せずに実装可能です。
ただし、このようなEAIエンジンを導入しながら、多くの内部環境に依存するとどんどん利点が薄れていき、また、異なる実装方法ができてしまうので、余計に複雑化していく可能性があるので注意は必要です。
