Mule ESBとは？

MuleをはじめとするESBは、複数の連携ポイントがある場合や3種類以上のアプリケーションを統合する場合に真価を発揮します。また、疎結合や拡張性、堅牢性が求められるケースにも最適です。

以下は、ESBの選択のための簡単なチェックリストです。ESBを選択すべきケースについてより包括的な説明については、MuleSoftの創設者 兼 製品戦略部門副社長のRoss Masonによる記事、『To ESB or not to ESB（ESBを選択すべきかどうか）』をご覧ください。

• 1.3種類以上のアプリケーションやサービスを統合しようとしているか？
• 2.将来、既存または新規のアプリケーションを追加で接続する可能性はあるか？
• 3.2種類以上の通信プロトコルを使用する必要があるか？
• 4.メッセージのルーティング機能（メッセージフローの分岐や集約、コンテンツベースのルーティングなど）が必要か？
• 5.他のアプリケーションが利用するサービスを公開する必要があるか？

Muleは軽量でありながら高い拡張性を備えているため、小規模から始め、後からアプリケーションを追加接続することで、複雑なエンタープライズアプリケーション統合の管理が可能です。ESBは、アプリケーションとコンポーネント間のすべてのやり取りを透過的に管理します。これらが、同じ仮想マシン上に存在する場合でも、インターネットを介して接続されている場合でも管理でき、使用する転送プロトコルにかかわらず対応します。

現在、商用のESB実装サービスが複数存在します。しかし、これらの多くは機能が限られていたり、既存のアプリケーションサーバやメッセージングサーバの上に構築されているため、特定のベンダーに縛られることになります。例えば、既存サーバを構築・提供しているベンダーを継続的に利用しなければなりません。Muleランタイムエンジンはベンダーを選ばないため、さまざまなベンダーが接続することができます。つまり、Muleランタイムエンジンを使用すれば、特定のベンダーに縛られることがなくなります。

• Muleランタイムエンジンのコンポーネントはあらゆるタイプに対応します。POJO（Plain Old Java Object）から他のフレームワークのコンポーネントまで、どんなタイプでも簡単に統合可能です。
• MuleランタイムエンジンとESBモデルにより、ビジネスロジックはメッセージングロジックから完全分離され、コンポーネントの大幅な再利用が可能になります。他のフレームワークと異なり、既存コンポーネントを変更せずに使用できるのです。そして、コンポーネントはMuleランタイムエンジンのための固有のコードを必要としません。API構築のためにプログラムを記述する必要もありません。
• メッセージは、SOAPからバイナリイメージファイルまで、あらゆる形式に対応しています。Muleランタイムでは、XMLメッセージングやWSDLサービスコントラクトのような設計上の制約を設計者に強いることはありません。
• Muleは、ESBやiPaaSだけでなく、さまざまなトポロジーでデプロイできます。変化に適応し、必要に応じてスケールアップ／スケールダウンが可能な、安全で、拡張性のあるアプリケーションを提供するプロジェクトにおいて、軽量で組み込み可能なMuleは、市場投入までの時間を劇的に短縮し、生産性を向上させることができます。
• 段階的イベント駆動型アーキテクチャ（SEDA: Stage event-driven architecture）により、高い拡張性を実現します。ある大手金融サービス企業では、Muleランタイムエンジンを導入し、高度な分散処理と数千台のサーバを通じて、1日あたり何十億ものトランザクションを処理しています。

Muleには、CommunityとEnterpriseの2つのエディションがあります。EnterpriseはESBのエンタープライズクラスのバージョンで、パフォーマンス、HA、回復力、またはテクニカルサポートの要件のあるMuleのプロダクションデプロイメントに最適な特長や機能が追加されています。Mule CommunityとMule Enterpriseは共通のコードベース上で構築されているため、CommunityからEnterpriseへ簡単にアップグレードできます。Mule ESB CommunityエディションとMule ESB Enterpriseエディションの比較についても、ぜひご確認ください。

30日間の無料トライアルをご用意しています。今すぐMuleをダウンロードしてください。