特集 開発現場からの提言（後編） SOAの導入を成功させる現実的な方法とは？ 有限会社アークウェイ　黒石 高広 2005/12/03

Page1 Page2 Page3

　前回の記事では、サービス指向アーキテクチャ（Service-Oriented Architecture。以下、SOA）の概要とそのSOAが注目される背景や歴史、一般的にいわれている「SOA＝Webサービス」の問題点、特に同期連携の問題を中心に解説した。

　今回の記事では、多くの企業で見られるアプリケーション間連携の現状（AS-IS）とその問題点やあるべき姿（TO-BE）について解説し、SOAという考え方を実現するためにどのように取り組むべきか、またマイクロソフト技術を利用してどのように実現することができるかを説明する。

1. アプリケーション間連携の現状（AS-IS）

　多くの企業では、メインフレームやUNIX、Windowsなどの複数のプラットフォーム上で、会計や人事、購買、在庫管理などの数多くのアプリケーションが稼働している。また、それら複数のアプリケーション間でも、共有データベースやFTP、メッセージ・キューなどの複数の連携方法や連携用ミドルウェアが混在し、スパゲティ状に複雑に絡み合って連携している。

　次の図に、アプリケーション間のスパゲティ連携のイメージを示す。

スパゲティ連携となっている状態のイメージ図

DWは「Data Warehouse：データ・ウェアハウス」を、SCMは「Supply Chain Management：サプライ・チェイン・マネジメント」を、ECは「Electronic Commerce：電子商取引」を意味する。

　この図のように、アプリケーション同士がスパゲティ状に複雑に絡み合っていると、それらがどのように連携しているかを把握できないため、あるアプリケーションで障害が発生すると予測もしていなかったほかのアプリケーションまでが異常停止するといった問題や、バックエンドでデータがどこまで処理されているか分からないといった問題などが発生する。

　では、なぜこのような状況に陥ってしまったのか、業務アプリケーションの歴史から考察してみたい。

■業務アプリケーションの発展の歴史

　歴史を振り返ってみると、ホスト・コンピュータからオフコンやオープン系へのダウンサイジングやクライアント／サーバ型アプリケーション、インターネット技術の登場など、その時代ごとにさまざまなトレンドや最新技術が生まれ、企業はそれらをどんどん業務アプリケーションに取り込みながら発展してきた。

　そのようなIT技術の進歩やビジネス環境の変化を特に制限を設けずに取り込んできたことが原因となり、さまざまなプラットフォームやミドルウェアが混在した複雑なスパゲティ連携を生み出したと考えられる。

　それでは、企業内のアプリケーション間連携のあるべき姿（TO-BE）とはどのようなものだろうか。

2. アプリケーション間連携のあるべき姿（TO-BE）

　まず、企業内のすべてのアプリケーションを1つのアプリケーションに統合することは現実的ではない。ERPパッケージが初めて登場したころには、盛んにERPパッケージだけで企業内すべての業務が実現可能となるようにいわれたが、結局はERPパッケージの導入が進んだ企業においてもERP以外の業務アプリケーションがなくなることはなく、ERPパッケージ以外の新しいアプリケーションの構築は続いている。

　このことは、同じ企業内アプリケーションの中にも、ECサイトなどのように最新技術をどんどん取り込んで、バージョン・アップが必要となる「ライフサイクルの短いアプリケーション」と、最新技術よりも安定性や信頼性が重視される「ライフサイクルの長いアプリケーション」の2種類のアプリケーションが存在するという事実を示している。

　また前回の記事で解説したように、アプリケーション間連携では非同期連携を基本に考えた方がよいが、すべてのアプリケーション間連携を非同期連携で行うこともまた現実的ではない。非同期連携は、アプリケーション間を疎結合に保ち、耐障害性や柔軟性を向上させるというメリットがある半面、レスポンス性能が悪くなるというデメリットも抱えている。

　以上のことを考慮すると、企業内にあるアプリケーションをいくつかのグループに分類し、異なるグループのアプリケーションと連携を行う場合は非同期連携、同じグループ内のアプリケーション同士であれば同期連携を許可するようアプリケーション間連携の社内標準を定めることが最良の解決策となる。

　次の図に、企業内のアプリケーション間連携のあるべき姿（TO-BE）のイメージ図を示す。

アプリケーション間連携のあるべき姿のイメージ図

アプリケーションをいくつかのグループに分類し、異なるグループのアプリケーションと連携を行う場合は非同期連携、同じグループ内のアプリケーション同士であれば同期連携を許可する。

　この図では、企業内のアプリケーションをインターネット系、分析系、基幹系、情報系の4種類にグループ分けしている。どのようにグループ分けするかは、企業の規模や存在するアプリケーション数などによって異なる。

　この例で解説すると、インターネット系のアプリケーションと基幹系のアプリケーションが連携を行う場合は、非同期のミドルウェアで連携を行うことを示している。このように企業内に非同期連携の層を設けることで、あるアプリケーションで発生した障害がほかのアプリケーションへ波及することを極力抑え、障害に強いIT基盤を構築することが可能となる。

　SOAを実現するうえでは、同期連携と非同期連携の両立を考慮することが、企業全体のサービスレベル向上、耐障害性の向上といった観点でも非常に重要である。

■街づくりにおける火防線の考え方と、SOAの設計への応用

　突然だが読者の皆さんは「火防線」という言葉をご存じだろうか？ これは、市街地での火災の延焼を局所的に抑えるために、街路樹を植えた大きな通りや公園などを設置する街づくりの考え方である。火防線として有名なものには、札幌の大通公園がある。

札幌の大通公園の火防線（By Google Earth）

　この写真のように、札幌では市街地を民地（写真左側）と官地（写真右側）にグループ分けし、その間に火防線としての大通公園を設けることで、市街地での火災の延焼を一定範囲に抑えるように街全体が設計されている。

　アプリケーション間連携の世界では、同期連携は建物同士を密接に結合する密結合の技術であり、非同期連携は火防線のように建物同士の距離を空ける疎結合の技術であるといえる。このように企業内の複数のアプリケーションの間にも、火防線のような非同期の層を設けることによって、障害の広がりを一定範囲に抑えられるようになる。

　現在のところ、この非同期の層の実現方法には、エンタープライズ・アプリケーション統合（Enterprise Application Integration。以下、EAI）やエンタープライズ・サービス・バス（Enterprise Service Bus。以下、ESB）などがある。

　EAIは、「メッセージ・ブローカ（Message Broker）」と呼ばれる（メッセージ・ハブとも呼ばれる）統合パターンであり、アプリケーションは、ブローカを仲介してメッセージのやりとりを行う特徴を持つ。

メッセージ・ブローカのイメージ図

アプリケーションは、ブローカを介してメッセージのやり取りを行う。

　ブローカを介して連携を行うため企業内のアプリケーション連携を中央管理できるというメリットがあるが、メッセージ・ブローカが単一障害点となりうるというデメリットを抱えている。

　またEAIを導入するには、通常EAIパッケージを購入するが、EAIパッケージ固有の技術を習得する必要があり、その技術者を確保・育成することが難しいという問題や、パッケージ費用や専門の技術者を雇うなどの導入コストが高いといった問題点も指摘されている。

　それに対してESBは、SOAという考え方から生まれた新しい概念であり、業界内で統一された見解はまだ存在していない。そのため、ESBの実現方法はベンダによって異なっているのが現状であり、残念ながらWebサービスに対応したEAIパッケージのキャッチコピーとしてESBと呼んでいることも多い。またマイクロソフトの技術や製品には、現在のところESBとイコールなものが存在しない。

　そこで筆者としては「メッセージ・バス（Message Bus）」と呼ばれる統合パターンを用いて、このESBを独自に構築することをお勧めする。次に、このメッセージ・バスによるSOAシステムの構築について解説していこう。

INDEX
	[特集]
	開発現場からの提言（前編）
	サービス指向アーキテクチャ（SOA）の実際
	1．なぜいまSOAが求められているのか？
	2．「SOA＝Webサービス」だけではうまくいかない
	開発現場からの提言（後編）
	SOAの導入を成功させる現実的な方法とは？
	1．アプリケーション間連携の現状（AS-IS）とあるべき姿（TO-BE）
	2．メッセージ・バスによるSOAシステムの構築方法
	3．メッセージ・バスだけでは難しい問題

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）