企業システムの連携とオープンソースESB
ESBの普及とその問題点
企業システムを疎結合につなぐミドルウェアとして、Enterprise Service Bus（以下、ESB）が利用されるようになってから長い年月が経ちました。
筆者が記憶する限りでは、ESBは『Enterprise Service Bus: Theory in Practice』（David Chappell著）が2004年に発売されたのをきっかけとして、その後のSOA（サービス指向アーキテクチャー）ブームにのって急速に普及しました。おそらく本記事を読まれている方々の中にも、過去にESB導入を経験された方が数多くいらっしゃるものと予想しております。
しかしながら、このスピードの速いソフトウェアの世界において、長年使われているESBには大きな問題点があります。それは、いまだにESB自体の標準が決まっていないということです。例えばJava EE アプリケーションサーバーであれば、明確な標準が規定されています。このため、様々なベンダからリリースされているJava EEサーバーは、基本的にはどの製品も同様の機能を提供し、非常に高い互換性を備えています。
一方、標準が決まっていないESBは、提供する企業によって機能の違いはもちろん、開発方法、運用方法、アーキテクチャーに大きな差異があります。提供形態にしても、ソフトウェアだけでなくハードウェア（いわゆるアプライアンス）の形で提供されている製品もあります。
過去に様々な企業や団体が、ESBの標準を決めるべくJava Business Integration（JBI）やService Component Architecture（SCA）といった仕様を開発してきましたが、失敗に終わってきました。その中で唯一成功し、標準に近い存在となっているのが、Enterprise Integration Patterns（以下、EIP）です。
EIPは、アプリケーションやシステムを疎結合で連携させるためのデザインパターン集として、2003年に執筆された『Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions』（Gregor Hohpe, Bobby Woolf著）で規定されたものです。そしてこのEIPを実装したものが、現在ESBのデファクトスタンダードプロジェクトの一つとなっているApache Camelです。JBoss Fuseは、このApache Camelと、メッセージングシステムのApache ActiveMQを中心に、企業システムで本格的に利用するためのESB製品として、レッドハットからリリースされているソフトウェアです。
Apache Camel: システム連携のパターン化
システム連携の処理パターンは、検証（Validation）、付加（Enrich）、変換（Transform）、ルーティング（Route）、処理 （Operate）の5パターンに整理できます（これらの頭文字を合わせてVETROと呼ばれています）。このように、システム連携については長年の経験から体系的にパターン化されています。そうなると、これらのパターンに分類される部品群をコンポーネント化して組み合わせることで、簡単に連携したいと考えるのは自然な発想です。これがApache Camelの基本的な設計思想です。
この発想は、シェルプログラミングにも共通する部分が多く、コマンドという良くテストされた部品群を、パイプでつなげて複雑な処理を行うプログラミングモデルが、とても直感的、生産的かつ高品質であることは、みなさんも日々の開発現場で体感されているはずです。
図1：シェルプログラミングのイメージ（クリックで拡大）
Apache Camelはシステム連携のベストプラクティス集である、EIPを実装しており、シェルにおける標準入出力に相当するものを「エンドポイント」、パイプを「チャネル」、コマンドを「プロセッサ」と呼び、システム連携のコンポーネント化を実現しています。
Apache Camelの特徴は以下の通りです。
- エンドポイント、チャネル、プロセッサ（メッセージルーティング、メッセージ変換など）を構成する要素の役割と記法を定義することで、システム連携処理の可視化を実現できます
- システムを一枚岩ではなく、EIPをベースにしたソフトウェアコンポーネントのメッセージ連携によって実現できます
- コンポーネントの追加・変更・削除によって、新規要件に柔軟に対応でき、変化に強いシステムを構築できます。
例えば、注文の明細単位に分割して複数のサブシステムに連携するイメージをEIPで表現すると、図1.2のようなイメージとなります。
図2：EIPを用いた注文処理イメージ（クリックで拡大）
これを見て「あ、電子ブロックみたい！」と思った方は、私と同世代ということですね。トランジスタやコンデンサなどを組み合わせると、うそ発見機やラジオになるのを興奮して試したのを思い出します。企業システムが電子ブロックのように単純化されるにはまだ時間がかかりますが、Apache Camelの目指す方向は、このようにブロックを組み立てるようなシステム連携の実現なのです。
Apache ActiveMQ：メッセージングシステムの標準化
もう一つシステム連携で重要な要素が、システム間のデータ連携方式です。リモートプロシジャー呼び出し（RPC）と並び、重要な方式としてメッセージングの仕組みが長年用いられてきました。
メッセージングシステムには以下の特徴があります。
- 非同期通信ができることで、呼び出し側のシステムを待たせることなく、処理を継続させることができます
- メッセージの発行元のシステムと相手先のシステムは、お互いを知る必要がありません。発行元がメッセージをキューまたはトピックに格納すると、必要なシステムが自分でメッセージを取りにいくことができます。このようなアーキテクチャーにより、M：Nのシステム間連携が非常に柔軟に実現できます
- データをロストすることがなく、処理を継続できる高可用性に優れています。メッセージブローカーと呼ばれるサーバーを分散させ、あらゆる場所で高速で安全にメッセージを送受信するネットワークを組み立てることができます
図3：メッセージングシステムによる企業内外のシステム連携イメージ（クリックで拡大）
Apache ActiveMQは、JMS（Java Message Service）はもちろん、AMQP（Advanced Message Queuing Protocol）やMQTT（MQ Telemetry Transport）などの多様なプロトコルをサポートしている点も特徴的です。
JMSはAPIの仕様であり、メッセージ通信は各製品で独自のプロトコルのため、製品間の相互互換性はありませんでした。その問題を解決すべく、AMQPはワイヤーレベルでのプロトコルを定義した標準化団体OASISの仕様で、数々のソフトウェアベンダーが採用しメッセージングシステムの標準化を推進しています。
AMQP
また、センサーなどの軽量デバイスに適したMQTTという軽量プロトコルもサポートしており、様々なシステム連携のニーズに対応することができるよう設計されています。
MQTT
SOAを進化させた「マイクロサービス」
「マイクロサービス」という言葉を聞いた事はありますか？ 最近では業務ロジックの再利用性を高める考え方として、SOAをさらに進化させた「マイクロサービス」が広まり始めています。これは、汎用的な機能をなるべく小さく、より多く作ることによって、再利用可能なコンポーネントの組み合わせによるアプリケーション開発を目指すというものです。
さらにDockerなどのコンテナ技術の進化とともに、OSの仮想化よりもさらに上位レベルでのリソース管理も現実のものとなってきました。これにより、コンテナ単位でアプリケーションのライブラリのバージョンが指定でき、コンテナ単位に十分にテストされた構成を維持しながら、本番環境へのデプロイが可能となります。
システム連携アプリケーションのマイクロサービス化が進むことで、これまでの一枚岩で構成されたシステムでは、年に数回しか実現できなかった機能のアップグレードが、よりきめ細やかなサービス単位ですばやく行えるようになります。一方で、マイクロサービス単位での構成管理やアップグレード作業が必要になり、システム管理は複雑性が増すことになります。JBoss Fuseには、このような課題を解決するための統合システム管理フレームワークも搭載されています。
これからますます重要になるシステム連携技術
SOAは、もはやバズワードとして使われることはなくなりましたが、企業システムにおいてサービス指向のシステム連携はますます重要な要素となっています。例えば、Salesforce.comなどのように顧客管理システムをクラウド上で利用することで、パブリッククラウドをサービスとして自社内システムで連携することが当たり前になってきました。また企業間の吸収や合併が活発になるにつれて、情報システムは素早くビジネス要求に対応するため共通の業務機能を集約し、複数のサブシステムをサービスとして利用することもどんどん増えてきています。
また、アプリケーション機能の共通化を推進することで、開発生産性を高める動きも進んでいます。ビジネスプロセスやビジネスルール、データ仮想化などの機能を共通サービスとして用意し、アプリケーションから共通利用する場合にもシステム連携は必要となってきます。
併せて、リアルタイムトランザクションの重要性は、ますます高まっています。これまでのようなファイル渡しによる夜間バッチの仕組みでは、お客様のサービスに付加価値を付与できず、他社にビジネスを奪われてしまうことになります。ESBによりシステムを連携させ、（ニア）リアルタイムに処理させることで、注文した直後には、販売、在庫、物流、顧客の各システムを同期が取れた状態にすることが可能となります。
ESBに必要な要件とは？
このように進化を続ける企業システムを連携するためにESBを導入する際には、以下の要件が重要となります。
- オープンで標準仕様に準拠していること
- 多様な連携をサポートする仕組みであること
- 低コストでスケーラブルに拡張可能なこと
システム連携機能は、企業システムの全体に影響する非常に重要なシステム要素です。将来にわたり、継続してこの基盤を維持していくためには、オープンでかつ標準仕様に基づいた技術で開発・運用されることが重要です。またシステム連携の技術は常に進化し、様々なプロトコルが発明されていきます。システム連携のフレームワークでは、アダプタやプラグインといった拡張機能により、柔軟に新しい技術に適応できる仕組みが必要です。さらに企業の合併に伴うシステム統合、ユーザー数の急激な増加など、ビジネスの変化はこれまで以上にダイナミックになります。この環境に柔軟かつ低コストで対応できる仕組みである必要があります。
次回からはJBoss Fuseの機能的な概要を説明し、簡単なチュートリアル形式で実際にJBoss Fuseを使いながら、上記の課題を解決する方法を説明していきたいと思います。
