特集:変貌するリッチクライアント(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参照)。
|
|||||||||||||||||||||||||||
表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の企業活用 |
- GASで棒、円、折れ線など各種グラフを作成、変更、削除するための基本 (2017/7/12)
資料を作る際に、「グラフ」は必要不可欠な存在だ。今回は、「グラフの新規作成」「グラフの変更」「グラフの削除」について解説する - GET/POSTでフォームから送信された値をPHPで受け取る「定義済みの変数」【更新】 (2017/7/10)
HTMLのフォーム機能についておさらいし、get/postメソッドなどの内容を連想配列で格納するPHPの「定義済みの変数」の中身や、フォーム送信値の取り扱いにおける注意点について解説します【PHP 7.1含め2017年の情報に合うように更新】 - PHPのfor文&ループ脱出のbreak/スキップのcontinue【更新】 (2017/6/26)
素数判定のロジックからbreak文やcontinue文の利点と使い方を解説。for文を使ったループ処理の基本とwhile文との違い、無限ループなども併せて紹介します【PHP 7.1含め2017年の情報に合うように更新】 - Spreadsheetデータの選択、削除、挿入、コピー、移動、ソート (2017/6/12)
Spreadsheetデータの選択、挿入、削除、コピー、移動、ソートに使うメソッドの使い方などを解説する
|
|