 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 | ||||||||||||
|
||||||||||||
| サービス統合とデータ統合の両立 | ||||||||||||
|
SOA時代のシステム・アーキテクチャを考える場合、本来は「サービス統合」だけでなく「データ統合」も同じように意識する必要がある。しかし現状のSOAの概念や実装でクローズアップされるのは、ビジネスプロセス（BPEL）やサービス実装（Webサービス）などサービス統合に偏ったもので「データ統合」の拡張性や柔軟性を実現する概念や実装はほとんど語られていない。 今のままではサービス統合側が問題ない場合もデータ統合側の非拡張性／非柔軟性といった問題から、SOAが掲げるシステム全体の拡張性や柔軟性を真に実現することはできない。 エンタープライズ・セマンティックWebは、本来「サービス統合」と同じように意識する必要があった「データ統合」側を概念的にも実装的にも補完する技術であると筆者は考えている（図3）。企業システムの拡張性や柔軟性は、サービス統合とデータ統合の両輪が揃ってはじめて実現されるものである。  図3：サービス統合とデータ統合を両立した概念と実装技術 出典：野村総合研究所 （画像をクリックすると別ウィンドウに拡大図を表示します） 図4では、もう少し具体的なイメージを持ってもらうために、エンタープライズ・セマンティックWebを適用したSOA時代のシステム・アーキテクチャを例としてあげてみた。ここではエンタープライズ・セマンティックWebをESB（Enterprise Service Bus）の上位に位置付けている。ESBはあくまでも通信プロトコル変換やメッセージ伝送路として機能させ、アプリケーションに近いデータフォーマットやオントロジーの違いは、エンタープライズ・セマンティックWebに任せるといったアーキテクチャである。  図4：エンタープライズ・セマンティックWebを適用した SOA時代のシステム・アーキテクチャの例 出典：野村総合研究所 （画像をクリックすると別ウィンドウに拡大図を表示します） 将来的は、BPM製品に記述されているビジネスルール（現在、ベンダーや製品ごとに独自の仕様になっている）もRuleMLやSWRL（Semantic Web Rule Language）といった標準的な定義言語によってBPM製品から切り出され、セマンティック・リポジトリにて一元管理されるようになるだろう。 分散と集中という議論が繰り返されてきたが、その中で分散してもよいものと分散してはならないものがある。セマンティックWebは、過去に技術的な問題から分散せざるをえなかったデータ変換の定義やデータの取り扱いルールを局所化することを可能にした技術といってもいいだろう。 |
||||||||||||
| 最後に | ||||||||||||
|
これまで5回の連載に渡り、セマンティックWebについて解説してきた。筆者は、今のWeb世界（Web 2.0）やSOAが潜在的に抱える問題を解決する技術は、セマンティックWebだと考えている。 研究段階から実用段階の揺籃期後半に入った今、ベンチャー企業だけでなく、大手ベンダーからもセマンティックWebの有効性が語られはじめ、応用した事例やサービスが身近に感じられる時期も間近に迫っている。いつの日かThinkITの記事を通じてセマンティックWebを応用した日本の事例やサービスが紹介されることを期待したい。 |
||||||||||||
|
前のページ 1 2 3 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
