【 ここから本文 】
オフィス／業務支援
ソーシャルブックマークに登録 ：
印刷用ページの表示
【解説】
SOAのメリットを最大限に引き出す「5つの方法」
United Airlines、Comcastなど先進ユーザーに学ぶ
（2008年03月18日）
CASE STUDY 2
LeapFrog Enterprises http://www.leapfrog.com/
オープンソースESBで拡張性と柔軟性を確保
企業では毎年さまざまなアプリケーションが開発されている。だが、それらをWebポータルなどの共通システムに取り込むとなると、大抵うまく動いてくれない。この古典的なジレンマは、2007年初めにインターネット・ベースで商取引を行うメリットを追求するため、業者や顧客にさまざまなアプリケーションを一貫性のある方法で提供しようと考えた玩具メーカーLeapFrog Enterprisesでも持ち上がった。その年の3月、同社はアプリケーション開発に新しい手法が必要と判断し、SOAプロジェクトを立ち上げた。今日その成果がようやく実を結びつつあるなか、同社のシステム・インフラストラクチャ担当役員、ユージン・キュラナ（Eugene Ciurana）氏は次のように述べている。「われわれはまっさらな状態からWebのインフラとシステムの基盤を作りたかったのだ」
| 画面1：大手玩具メーカーのLeapFrog Enterprisesのショッピング・サイト。同社では、開発者に特定のプラットフォームを強要するのではなく、オープンソースのESBツール「Mule」を採用し、自由度の高いSOA開発を推進している |
 |
LeapFrogには典型的なSOAプロジェクトと同じような目標がいくつかあった。すなわち、コードの再利用、開発期間の短縮、統合の容易化などだ。しかし同社は、SOAを開発ツールや統合化プラットフォームの単なる変更とは考えていなかった。むしろ、開発者には特定のプラットフォームを強要せず、アプリケーションの機能性にフォーカスし、最適な技術を幅広く利用してもらうことを望んだ（LeapFrogの開発者は、Java 5と6、MicrosoftのC#、各種Webサービスに加え、多様なサードパーティ・ライブラリを利用している）。
例えば、Ciurana氏は開発者全員に同一のトランスポートを強制するのではなく、トランスポート・インタフェースとやり取りするメッセージング・バックボーンにオープンソースのESBツール「Mule」を採用した。「そうすることで、開発者はその部分の実装にわずらわされることがなくなり、本来実現すべき機能に集中できる」と同氏は説明する。同社の開発者はトランスポート・メカニズムにHTTPを用いる傾向にあるが、REST（Representational State Transfer）やSOAPを利用する者もいる。それについてCiurana氏は、「開発者が使いやすければそれでかまわない」と断言する。
Muleを採用したことで、LeapFrogの開発者は特定のSOAPスタックに何が含まれているか、あるいはどのIDEを利用しているかを気にする必要がなくなった。Ciurana氏は、同氏が以前務めていたWal-Mart StoresでもMuleを利用していた経験から、LeapFrogが目指した「まっさらな状態」からのプロジェクトにもMuleが使えると確信していた。
このアプローチがLeapFrogで成功したのは、アプリケーションの統合化という点にフォーカスしたからだとCiurana氏は言う。統合化のほとんどの部分は、アプリケーション間レベルで行われる。つまり問題はアプリケーションの入力と出力にあった。そこで、開発者はサービスをPOJO（Plain Old Java Objects）として記述し、Mule ESBがPOJOをメッセージング・ネットワークに“ワイヤ”して、ESB内のあらゆるトランスフォーメーションをハンドリングした。「通常、SOAPやRESTを扱う場合、外部の世界へどのように接続しようかと考える。POJOであれば、そうした心配はない」と同氏。
Ciurana氏はまた、メッセージング管理以外のアジェンダがないMule ESBのシンプルさを気に入っている。「SOAのメリットは、固定されたシステムから別のシステムへ容易に移行できる点にあるにもかかわらず、どの商用ベンダーも包括的な製品群をわれわれに売り込もうとしていた」と同氏は言う。Muleを導入したLeapFrogでは、SOAスタックのさまざまなレイヤを組み立てる必要があったが、同氏は常にベストな技術を利用できる柔軟性と引き換えに、そうした負担を喜んで受け入れたという。
LeapFrogでは2つのESBが利用されている。1つはERPやActive Directory、データ・ウェアハウスなどの内部システム間のデータフローとアプリケーション・ハンドオフを管理するためのもので、もう1つは顧客向けのWebベース・アプリケーション用だ。このように2系統になっているのは、セキュリティとアクセス管理の要請に加え、必要に応じてそれぞれのESBが相互にバックアップできるようにするためだ。
Ciurana氏によると、それぞれのESB上でサービスを実行するためには、共通サービスのネーミング・スキームを作成する必要がある。その作業は骨が折れるが、同氏は「ESBの自由度を維持するためのコスト」ととらえているという。
CASE STUDY 3
United Airlines http://www.untied.com/
SOAとイベント駆動アーキテクチャを統合
ビジネス・プロセスを構成単位で分解し、それらの要素をビジネス・ニーズに合わせて自由に組み替えられるスタンドアロンのサービスを開発するというSOAのコンセプトは、離散的なトランザクション機能の利用を想定している。SOAの基本的な前提は、個々のサービスの機能を、ほぼ無限に組み合わせられるビルディング・ブロックに分解することだ。
しかしビジネス・タスクの多くは、複数のイベント間で特定のシーケンスに依存し、それほど容易に分解できるものではない。航空会社はそうしたイベント駆動プロセスの古典的な事例であり、それらのイベントを処理するための典型的なイベント駆動アーキテクチャ（EDA）を実装している。「EDAはフロー指向だが、SOAは離散型のブラックボックスだ」と説明するのは、United Airlinesのミドルウェア・エンジニアリング・マネジャー、リミナス・シダンビ（Ramnath Cidambi）氏だ。もっとも、それぞれに利点があり、結局、航空会社でも着陸時の給油車配送やフライト情報ボードの更新といったイベント駆動型のシステムだけでなく、チケット予約や座席割り当てなどのトランザクション・システムにも採用されている。
Unitedは古くからEDAに投資し、7年前からメッセージング・バスとしてIBMの「WebSphere」を利用してきた。その一方で、自社サイトの「United.com」で最新のWebサービスを提供するため、2006年からSOAへの取り組みも開始した。Cidambi氏も、これら2つのシステム環境は比較的はっきり分かれているため並列的に共存させることができるとしていた。しかし最近、その状況が変わりつつあるという。各空港のゲートに配置する要員を割り当てるために人事システムから従業員の出勤情報を取り出し、テキスト・メッセージ（Webサービス）で個々の顧客サービス要員に通知するといったトランザクション・サービスを内部オペレーションに追加するなど、Webサービスがイベント駆動プロセスと同一の環境に組み込まれ、SOAプロジェクトがUnited.comプログラムを超えて社内に広がってきているのだ。
Unitedの課題は、2つのアーキテクチャを必要とするビジネスで、サービスをどのように構築、展開するかを見極めることだ。同社の社内オペレーションは2つのアーキテクチャを持つが、完全に分離されたものとして取り扱うことはできない。結局、欠航（イベント）があれば、トランザクション・システム（フライトの再スケジューリング、Webベースのフライト情報の更新、キャンセル伝票の発行など）も無縁ではいられないからだ。また、多くのプロセスがイベントとトランザクション・コンポーネントの両方を持つ。顧客サービス要員は、その日のスケジュールをトランザクション・システムで入手するが、もし悪天候やその他の事情で欠航が生じれば、当然、それらの情報は顧客サービス要員のスケジュールに反映されなければならない。そうしたなか、イベント駆動システムはフライトの運行状況を追跡し、スケジューリングのトランザクション・システムは運行状況を定期的にチェックして、スタッフの配置を更新するのである。
Unitedの最大の課題は、メッセージング・システムにあった。ESBにはWebサービス標準以外の標準がないため、イベント駆動サービスとのやり取りは、製品やツールごとに異なり、不明確で一貫性を保つことができなかった。しかし、それでもSOAとEDAの双方にESBを利用したいとCidambi氏は考えた。メッセージングやデータ・トランスフォーメーションのほかに、重要データのルーティングなどもハンドリングできるからだ。
現在、Unitedには2つのESBが存在する。1つはEDAサービス用、もう1つはSOAサービス用だ。同社は、IBMの WebSphere統合ブローカをイベント駆動サービス向けのパブリッシュ／サブスクライブ型メッセージング・プラットフォームとして利用し、必要に応じてイベントを伝達するとともに、サービス間のトランスフォーメーションを処理している（基本的にはEDA ESBとして機能）。トランスポート用には、既存のJ2EEアプリケーションがメッセージ指向なため、Webサービスではなく、JMS（Java Message Service）をメッセージング標準として利用している。
| 画面2：United Airlinesで現在、導入が進められているESBツール「BEA AquaLogic Service Bus」の画面。Unitedでは、EDAサービス用とSOAサービス用の2つのESBをうまく使い分けているという |
 |
Unitedでは現在、BEA SystemsのESBツール「BEA AquaLogic Service Bus」（画面2）の導入が進められている。「同ツールはUnitedのWebLogicサーバ環境やEclipse開発環境との親和性が高く、基本的にWebLogic上で実行するため、統合作業も必要ない」とCidambi氏は語る。
EDAサービスをAquaLogicに移行しない理由は、不必要な負担を避けたいからだ。WebSphereは現在非常にうまく機能しているが、新しいESBに移行すれば不要な混乱や動揺が起きかねない。Unitedは7年かけてWebSphereプラットフォームを最適化し、オペレーション上の不具合を解決した。AquaLogicなどの新しいESBへ移行すれば、まちがいなくそうした作業を繰り返すことになるだろう。
ちなみに、Cidambi氏が直面しているもう1つの問題は、EDA用の標準XMLスキーマがないことだ。そのためにEDAサービスとSOAサービスの間のメッセージング開発が複雑になり、膨大な労力の投入を余儀なくされているという。
