［IT Architect連動企画］
サービス指向アーキテクチャの未来を考察する（後編）

SOAを成功させるテクノロジ要件とは？

多くのEAIベンダが次々とサービス指向アーキテクチャ（SOA）に名乗りを上げている。WebサービスとSOAの関係は？ サービス指向とオブジェクト指向とはどう違う？ そしてSOA時代が到来すると、エンジニアは必要なくなる？ SOAを取り巻く多くの疑問に、最新情報をもとにした回答をお届けしよう。（編集局）

ITコンサルタント
安田 正義
2004/2/26

■エンタープライズ・システムでのSOAの実現方法と課題

主な内容 エンタープライズ・システムでのSOAの 　 実現方法と課題 　・（1）経営戦略とEA（Enterprise Architecture）の融合 　・（2）セマンティック統一、情報統合の重要性 　・（3）BPMによるサービスの実装 　・（4）メッセージング・インフラストラクチャの構築 　・（5）サービス運用管理インフラストラクチャの構築 情報システム部門、ITエンジニアの今後の役割 本記事は、「ITアーキテクト」と＠ITの各フォーラムが展開する、分析／設計工程に焦点を絞った『ITアーキテクト連動企画』記事です。

　前回の「SOAはエンタープライズ・システムを変革するか？」では、サービス指向アーキテクチャ（以下、SOA）の概要を議論し、SAPのビッグバン・アプローチに代表される従来型のエンタープライズ・システム・モデルを「モノリシック・アプリケーション」と定義し、これに対するSOAの優位性を明らかにした。従来型モデルに代わるIT戦略のアプローチとして非常に重要なSOAについて、本稿では今後エンタープライズ・システムでSOAを実現していくうえでの課題を考えていきたい。

　ちまたではSOAとWebサービスは同義であるかのように語られることが多いが、顧客企業の立場に立ってSOAを実現するに当っては、両者の相違を把握していくことが大切である。一言でいえば、SOAはシステム・アーキテクチャの考え方であり、WebサービスはSOAを実現するために非常に有効で親和性の高いテクノロジ（道具）、とりわけインターフェイス実装技術である^[9]。Webサービスを利用して単に2つのシステムのインターフェイスを技術的に結合したことだけをもって、SOAを実現したとはいえない。また、SOAは必ずしもWebサービスを利用しなければ実現できないアーキテクチャではなく、むしろエンタープライズ・システムにおいてはWebサービスを補強するより高度なメッセージング機構や、あるいは、WebサービスではないMOM（Message Oriented Middleware）を利用することもあり得る^[4]。

　エンタープライズ・システムでのSOAの適応レイヤをモデル化すると、次のように表せると筆者は考える。

図　エンタープライズ・システムにおけるSOA適応レイヤ・モデル

　より上流に行けば行くほど、Webサービスといったテクノロジとは関係なく、経営戦略、ビジネス・モデル、IT戦略をどのように立てるかといった視点が大切となる。一方、より下流に行くほど、Webサービスの標準化動向、ベンダ・ツールなどの影響を受けて、どのように物理的な実装を行っていくかが大切なテーマとなってくる。それでは、以下、トップダウンで各レイヤでのSOA実現方法と課題について見ていこう。

（1）経営戦略とEA（Enterprise Architecture）の融合

　変化の激しい環境の中で、経営戦略およびビジネス・モデルは、状況に応じ迅速に変化できることが求められている。中長期的な経営計画は役に立たない状況になってきている。SOAが第1に解決しなければならない目的は、このような経営戦略の変革と同期した形で速やかにITアーキテクチャを改造していくことである。換言すれば、ビジネス戦略はIT戦略と同時に、一体化した形で構想されなければならない。ガートナーはこのような考え方を「ビジネス・アーキテクチャ」と呼んでいる^[23]。

　次に大事な考え方は、SOAが前提とする企業モデルは、M＆Aによって巨大化していくようなモノリシックな企業ではなく、コア・コンピタンスをお互いに連携することで競争優位を築く企業連合体を前提としている点である。企業のパフォーマンスは、いかに優れたパートナー、サプライヤ、チャネルと組むことで、より強固な「エコシステム」をつくることができるかが大切になってくる^[24]。Dell、Cisco、トヨタなどの先進的な企業を見れば、各社が非常に優れたエコシステムを形成していることが分かるであろう。

　このようなエコシステムの中では、全体最適の観点から、汎用性の高いビジネス・プロセスを設計し共有していくことが極めて大切である。このような設計を行ううえで、最近脚光を浴びているEA（Enterprise Architecture）という考え方は非常に有効である。EAはソフトウェア工学でのシステム開発方法論の新しい潮流であり、次のように定義される^[3]。

エンタープライズ・アーキテクチャとは、経営戦略を企業内の各レベルで実行するために、「誰が」「何を」「どのように」行うか、経営資源を構造化して、実行体を作り出すための企業構造設計図のことである。

　EAは、経営戦略を実現するITシステムのスピーディな開発、企業あるいはエコシステムの全体最適の観点からのITシステム構築、IT資産にかかわる知識の汎用化を目的としたシステム開発方法論であり、SOAとの親和性が極めて高いことは理解できるだろう。

　SOAを単にWebサービスといった実装技術だけからとらえてしまうと、局所的なインターフェイス開発に終わってしまい、SOAが本来目的とすべき汎用性の高いサービスを実現できない。SOAでは、EAの観点から全体最適なサービスを設計していくことが極めて大切である。

（2）セマンティック統一、情報統合の重要性

　この問題は、情報、ビジネス・オブジェクトあるいはデータの持つ意味を、異種サービス間、異種システム間において、理解可能なものとすることである。例えば、「顧客」というデータがあった場合に、SAP、Siebel、レガシーシステムそれぞれでの顧客データの定義は異なっており、そのままでは相互にデータをやりとりできない。とりわけ顧客コード体系がアプリケーションごと、あるいは部門ごとに異なっており、同じ顧客を特定することが極めて難しいというコード体系の問題もある。

　SOAを実現するためには、このような情報統合、セマンティック統一を企業規模で行うことが大事になってくる。この問題に関しては、岩本幸男氏のWebサービスに関する記事「Webサービスの光と陰を考察する（2）　データ標準化から目をそらす守旧派の罪と罰」^[2]が詳細な考察をしているので参照してほしい。

　ここから下のレイヤにおいては、Webサービスの標準規格に準拠した形で、すでに各種ベンダがツールを提供しており、物理的な実装が必要となってくる。

（3）BPMによるサービスの実装

　SOAにおけるサービスはビジネス・プロセスであるが、例えば、注文受け付けというビジネス・プロセスを実装するためには、複数アプリケーションや、場合によっては人手を介した事務処理を含める必要がある。このようなビジネス・プロセス・フローを実装するソリューションはBPM（Business Process Management）と呼ばれている。SOAにおいてサービスを実装する場面では、このようなBPMツールを活用して、複数のアプリケーションを組み合わせて1つのビジネス・プロセスを実現することが極めて大切である（これは「コンポジット・アプリケーション」と呼ばれる）。

　Webサービスにおいては現段階で、IBM、Microsoft、BEA Systemsによって発表されOASISに提案されているBPEL4WS（Business Process Execution Language for Web Services）と、Intalio、Sun Microsystems、SAP、BEA SystemsによってW3Cに提案されたWSCI（Web Services Choreography Interface）の2つが存在しているが、いずれ1つの標準規格に収れんしていくものと思われる。

　BPMツールには、BPEL4WSに準拠したものもいくつか現れてきており、将来的には1つのBPMツールで構築したビジネス・プロセス・フローはそのままほかのBPMツールでも再利用できるようになると思われる。BPEL4WSに準拠したBPMツールとしては、webMethods Modeler、TIBCO BusinessWorks、Microsoft BizTalk Serverなどがある。

（4）メッセージング・インフラストラクチャの構築

　SOAをエンタープライズ・システム規模で展開するためには、すべてのアプリケーションとのデータのやりとりを行う基盤となる、メッセージング・インフラストラクチャを構築することが大切である。

　ネイティブにWebサービスのSOAP／HTTPのみをサポートしたMOM（Message Oriented Middleware）はESB（Enterprise Services Bus）と呼ばれ、このようなミドルウェアを利用することで、さまざまなアプリケーションは共通のSOAP／HTTPトランスポートを介してXMLメッセージの交換をすることが可能になる。このような製品としては、Sonic ESB、webMethods Fabricなどがある。Microsoftが次期WindowsであるLonghornにバンドルするIndigoと呼ばれるミドルウェアも、今後有力になるESBの1つである。

　Webサービスで標準化されているメッセージングは、リクエスト・リプライ方式のSOAPだけであるが、エンタープライズ・システムを構築するに当たっては、Asynchronous Messaging、Publish／Subscribe、Reliable Messaging、Transaction、Event Notificationなど、より複雑なメッセージング・モデルをサポートする必要が出てくる（先日、Publish／Subscribeモデルに関してWS-NotificationとWS-Eventingの2つの仕様が出てきたことは記憶に新しい）。OASIS、W3Cなどの標準化団体で各種仕様の検討は進んでいるが、統一仕様が決まり、ベンダ製品が枯れてくるまでにはまだ時間がかかりそうである。現段階のESBでは、このような高度な機能は独自の拡張機能でサポートしている状況である。

　また、既存のアプリケーションを簡単にWebサービス化する（外部アプリケーションとXML、SOAP、WSDLでの通信を可能とする）ためのツールも出てきており、webMethods、Software AG、Cape Clearなどがある。

　また、新規にWebサービスに準拠したカスタム・アプリケーションを開発する場合には、J2EEかMicrosoft .NETに準拠したアプリケーション・サーバを利用することになる。J2EEアプリケーション・サーバはBEA WebLogic、IBM WebSphere、JBossなどが該当する。

（5）サービス運用管理インフラストラクチャの構築

　このようにして、社内外にさまざまなサービスが存在し、XMLメッセージをやりとりすることで連携していくようになると、各サービスの稼働状況をモニタリングする、サービス運用管理が非常に大切になってくる。

　Webサービスでは、OASISからWSDM（Web Services Distributed Management）という標準規格を策定中である。この規格の作成には、Computer Associates、BMC Software、HP、IBM（Tivoli）、BEA Systems、Cisco Systems、Global Grid Forumなどが参加している。

　Webサービスベースのサービス運用管理は、大きく社内システムを管理するWebサービスBrokerと、BtoBでのサービス管理を行うWebサービスNetworkに大別される。Webサービス Brokerのベンダとしては、Actional、AmberPointが、Webサービス Networkのベンダとしては、Grand Central Communicationsがスタートアップ企業として、この分野を開拓している。

■情報システム部門、ITエンジニアの今後の役割

　最後に、今後SOAやEAに基づくシステム構築が主流になっていくと思われる状況の中で、情報システム部門やITエンジニアに求められる役割について、考えておきたい。ここで再び、当記事の冒頭に引用したSOAとオフショア・アウトソーシングに関する言葉を思い出してほしい。

The move to SOAs and the offshore outsourcing trend are a true double whammy for developers in the next few years. （サービス指向アーキテクチャおよびオフショア・アウトソーシングへの動きは、今後数年にわたってソフトウェア開発者たちにとって2つの大きな脅威となるであろう）[5]

　企業が情報システム部門、システム・インテグレータ、そこで働くITエンジニアに対して求める期待は、SOAとオフショア・アウトソーシングの流れが加速する中で大きく変わってくるであろう。この文章を載せているSOA、Webサービスの代表的リサーチ機関であるZapThink社のアナリスト、ジェイソン・ブルームバーグ（Jason Bloomberg）氏は、「（プログラミングやサポートといった）下流工程のスキルが海外に行けば行くほど、今日の開発者はアーキテクチャ、とりわけ企業全体のビジネスの視点からITを設計できる、エンタープライズ・アーキテクトとしてのスキルを磨く必要性が増してくるであろう」と述べている^[5]。筆者もこの見解に同感である。

　情報システム部門、システム・インテグレータは、企業全体を見据えたエンタープライズ・アーキテクチャを構想・設計する役割においてさらなるスキルを求められ、これらの設計に基づく各サービスの実装は、既存ASPを採用したり、あるいはオフショア・アウトソーシングを利用した外注生産で行われていくと思われる。

　現在、プログラム開発を中核においている中小システム・インテグレータは、今後、インド、中国発のオフショア開発会社との間で熾烈なコスト競争に巻き込まれて、淘汰されるだろう。これは、製造業においてグローバルに見られている、下請部品工場の海外移転と同じ経済原理に従った動きである。

　このような二極分化は、他方では企業経営における情報システム部門の価値を高めていくだろう。情報システム部門は、従来バックオフィス部門として上層部から与えられた開発プロジェクトをこなしたり、システム・インテグレータが開発したシステムを運用・保守していくといった受け身の立場であった。

　しかし、今後は経営層が提言する経営戦略やビジネス・モデルを理解し、企業全体のエンタープライズ・アーキテクチャを見据えたうえで、最適なサービスの導入を迅速に実現していくことが求められてくる。システム・インテグレータも同様に、このような情報システム部門のニーズに対等の立場でこたえられるように、経営に対する深い理解と全体最適なシステム提案を視野に入れて、SOAやオフショア開発を利用した、迅速で安いシステム化提案を行う能力が求められてくる。（完）

前編　SOAはエンタープライズ・システムを変革するか？

Index
［IT Architect連動企画］ サービス指向アーキテクチャの未来を考察する
	前編 SOAはエンタープライズ・システムを変革するか？ SOAとは何か? エンタープライズ・システムにおけるSOAのメリット 　（1）モノリシック・アプリケーション・モデルの特色 　（2）SOAの特色 　（3）モノリシック・アプリケーションのオープン・サービス 　　　化戦略
	後編　 SOAを成功させるテクノロジ要件とは？ エンタープライズ・システムでのSOAの実現方法と課題 　（1）経営戦略とEA（Enterprise Architecture）の融合 　（2）セマンティック統一、情報統合の重要性 　（3）BPMによるサービスの実装 　（4）メッセージング・インフラストラクチャの構築 　（5）サービス運用管理インフラストラクチャの構築 情報システム部門、ITエンジニアの今後の役割

筆者プロフィール

安田　正義（やすだ まさよし） 株式会社Agathon（アガトン）代表取締役兼コンサルタント。SOAを中心に業務プロセスを支えるシステム統合基盤の要件定義・分析・設計・開発に従事しているITコンサルタント。 連絡先はmasayoshi.yasuda@agathon.co.jp

＜この記事へのご意見は、「XML & Web Services 会議室」へお寄せください＞

　

サービス指向アーキテクチャの未来を考察する

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