特集：変貌するリッチクライアント（3）
企業のWeb2.0活用はSOAとの融合から

野村総合研究所
技術調査室　
田中　達雄
2006/8/4

解決策の1つ： 　ビジネスプロセス＆ビジネスルールの連動

　今後、この問題を解決する方法は、いくつも提案されるだろうが、本編では以下の2つの方法を示した。特にビジネスプロセスとビジネスルールの定義情報をクライアント側とサーバ側で連動させる2つ目の方法が有力と筆者は考えている。

ポータルサーバですべてのユーザーインターフェイスをコントロールする方法 クライアント側に、サーバ側と同等の柔軟性を高める機能を装備する方法

　1つ目の方法は、クライアントとWebサーバがリクエスト／レスポンスを頻繁に繰り返す従来型のWebアプリケーションであり、リッチなユーザーエクスペリエンスといえないものとなってしまう。Ajaxで部分的にリクエスト／レスポンス量を抑え、ユーザーエクスペリエンスを幾分か向上することも可能だが、ビジネスプロセスやビジネスルールに変更があった場合、Ajaxではプログラムの変更を必要とするため、利用できる範囲は限定的となる。

　つまりシステム全体の柔軟性を考慮した場合、Ajaxは株価をリアルタイム表示するような部分には使えるが、画面遷移や入力制御をするような部分には使えない（使うこと自体は可能だが、使うとシステム全体の柔軟性が低下する）。柔軟性を取るか、高度なユーザーエクスペリエンスを取るかのトレードオフとなってしまう。

　これに対し、クライアント側にサーバ側と同等の柔軟性を高める機能を装備する方法では、クライアントにリッチクライアントを利用でき、かつシステム全体の柔軟性が高まる。現在、サーバ側では、ビジネスプロセスの変更に対して高い柔軟性を実現する製品が提供されている。クライアント側でも同等の機能が装備されれば、ビジネスプロセスの変更に関するシステム全体の柔軟性は高まる。

　ただし、現在、このリクエストに答えられるクライアント技術はほとんど存在しない（Windows Workflow Foundation（参照記事：Windows Workflow Foundation概説「巷で話題のWFの可能性を探ろう！」）やBiz/Browser（参照記事：リッチクライアントベンダ・インタビュー）がクライアント側にようやくビジネスフローの機能を持たせてきたが……）。

　 またサーバ側では、ビジネスプロセスと並行してビジネスルールの変更に対して高い柔軟性を実現しようとする動きもある。ILOGなどに代表されるBRMS（Business Rule Management System：ビジネスルール管理システム）製品がそれだ。

　クライアント側とサーバ側の製品を常に同一ベンダにできない場合、異なる製品間の相互接続性が問われるが、残念ながらいまのBRM製品の多くは、BPM製品のBPELのようにビジネスルールを標準的な仕様で定義できる製品は皆無である。

　現在、RuleMLやSWRL（Semantic Web Rule Language）の標準化も進んでおり、将来的には製品化されるだろう。そうなれば、ビジネスプロセスだけでなく、ビジネスルールの定義情報も標準化されたマークアップ言語で定義可能となり、異なる製品のサーバとクライアント間で、ビジネスプロセスとビジネスルールを同期させることも可能になるだろう。

「サービス」という言葉で共通、 　そして融合するSOAとWeb2.0

　SOAとWeb2.0は両者とも「サービス」という言葉の軸上にあり、エンタープライズ側がSOAであり、コンシューマ側がWeb2.0となる（表1参照）。

“サービス”としてのソフトウェア   業務機能を“サービス”単位に分解し、再構築するシステム・アーキテクチャ ← サービス → コンシューマ側 エンタープライズ側 Web2.0   SOA インターネット世界の潮流ならびにその潮流にあったコンシューマ向けネットビジネスの総称 機能概要 ビジネスに柔軟性を与えることを目的としたエンタープライズ・システムのアーキテクチャ 主にクライアント技術 Ajax、RSS、SNS、Wiki、IM、etc.. 技術領域 サーバ技術 ESB、BPM、BPEL、WS-Security、etc.. Rest、SOAP 接続領域 SOAP 小型 接続案件規模 大型 主としてクライアント／サーバ間接続 接続対象 主としてサーバ間接続

表1　サービスを軸にしたSOAとWeb2.0「出所野村総合研究所」

　SOA対応を標榜する多くの製品は、インターネット技術を利用しながらもトランザクション性や信頼性、セキュリティなどを実現するさまざまな仕様（WS-*など）を重装備しミッションクリティカルな企業システムへの適用を目的としている。

　それに対しWeb2.0では、あくまでも脆弱なインターネット環境を想定したうえでのコンシューマへのサービス提供が主たる目的となっている。そのため、REST、RSSなど軽量で緩やかな接続技術を許容しており、ミッションクリティカルなシステムには不向きである。

　このように目的や適用範囲に違いがあるものの、コンポーネント化されたサービスを共有し利用する点は共通する。そしてWeb2.0的な特徴や技術を企業システムへ適用しようという試みも始まっている。

　企業システムという枠の中では、両者はいずれ「サービス指向」という名の下に融合し、いままでのSOAは「狭義のSOA」とされ、「広義のSOA」ではWeb2.0も包含する。

Web2.0の企業活用

　広義のSOAの中でWeb2.0的な特徴や技術が適用可能な分野はどこだろうか。先にも述べたがWeb2.0の場合、REST、RSSなど非常に緩やかな接続技術を許容しているため、ミッションクリティカルなシステムへの適用には向かない。

　とはいえ、企業システムのすべてがミッションクリティカルなシステムとは限らない。Forresterでは、ミッションクリティカルなシステムは企業システムの20％にすぎず、80％は非ミッションクリティカルなシステムと分析する。つまり80％の非ミッションクリティカルなシステムにWeb2.0の適用の可能性がある。例えば、グループウェア、ナレッジマネジメント、オフィスツール、勤怠管理、交通費精算、給与、福利厚生システムなどが挙げられる。

　筆者はWeb2.0の適用には、コラボレーション（人と人のコラボレーション、サービスとサービスのコラボレーション）がキーワードとなると考えている。Web2.0は、もともとコラボレーション性のあったシステム（グループウェアやナレッジマネジメントなど）への適用はもちろん、これまでコラボレーション性のなかったもしくは低かったシステム（オフィスツール、勤怠管理、交通費精算など）へも高いコラボレーションを提供するようになると考えている。代表的な例ではOffice Live（参照：Windows Live Ideas）やWritely、Google Calendarなどが挙げられる。

　そして、そこにはリッチクライアントの適用も同時に考えられる。

図3　Web2.0、SOAにおけるリッチクライアントのロードマップ「出所：野村総合研究所」

　リッチクライアントは、SOAがカバーするミッションクリティカルなシステムにもWeb2.0の適用可能性のある非ミッションクリティカルにもその適用分野を広げることになる（図3参照）。

　最終回となる次回は、変貌するリッチクライアントがセマンティックウェブへと続いていく将来像をお伝えする予定だ。

2/2

INDEX
企業のWeb2.0活用はSOAとの融合から
	Page1＜SOA環境におけるユーザーインターフェイス＞ SOAの課題：ビジネスプロセス変更へのUI変更は手作業
	Page2＜解決策の1つ：ビジネスプロセス＆ビジネスルールの連動＞ 「サービス」という言葉で共通、そして融合するSOAとWeb2.0／Web2.0の企業活用

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