ベンダーが触れたくないSOAの課題：SOAでつくる変幻自在の情報システム（1/3 ページ）

SOAをベースに情報システムを構築することにメリットがあることは明らかだが、実装が簡単かといえばそういうわけでもない。SOAは技術の違いは吸収してくれるが、アプリケーション設計の違いは吸収してくれないからである。

[栗原 潔，ITmedia]

SOAで企業の情報システムはどのように変化するのか。オンラインムック「SOAでつくる変幻自在の情報システム」で探る。

栗原 潔（テックバイザージェイピー代表取締役）

SOAによるメリットは明らか

　「SOAを採用するとどのようなメリットがあるのか？」という質問を受けることが多い。そんなときは、「SOAを使わずに、一枚岩型で外部インタフェースのないプログラムを作り続けたらどうなるかを考えてください」と答えることにしている。インタフェースを持った部品の組み合わせとしてソフトウェアを構築する、というSOAの考え方が自明であるのと同様に、そのメリットも自明であるといえるだろう。

　考え方が自明であるとはいえ、SOAを使ったシステムの実装が簡単かといえば、そういうわけでもない。SOAを使えば、ソフトウェア部品を自由に組み合わせて、コストをかけずに迅速にビジネス要件の変化に対応できる、という夢物語を提唱する人もいるが、本当にそのような夢が可能であるならば、SOAの登場を待たずともとっくの昔に実現されていたはずだ。

　SOAを使ったアプリケーション統合においても、過去におけるアプリケーション統合プロジェクトと同じ課題がある。その中でも重要なものは、セマンティクスとトランザクションに関するものだ。SOAに関するプレゼンテーションにおいて、これらの課題についてあまり触れられていないようだ。しかし、実際には、これらの課題を軽く見ることは危険である。

セマンティクス・ギャップによる課題

　ここでは、まずセマンティクスに関する課題について説明していこう。

　セマンティクスについては大昔に自分のコラムでも書いたことがあるが、簡単にいえばデータの持つ意味のことである。セマンティクス・ギャップとは企業内において、同じデータ項目であっても、セマンティクスが異なることが多いという問題を意味する。

　例えば、顧客コードを入力すると顧客情報を返してくれるというサービスがあったとしよう。一見、きわめて単純なサービスであり、特に難しい問題はないかのように思える。

　だが、現実の大企業における情報システムは、サンプルプログラムのように単純なものではない。顧客という一般的かつ自明なデータ項目であっても、セマンティクスが同じとは限らない。これは、単にフィールド名が異なる（例えば、あるシステムではCUSTOMERというフィールド名を使い、別のシステムではKOKYAKUというフィールド名を使っている）というような単純な問題ではない（このような単純な問題であればシステム的に容易に対応することができるだろう）。

　システムにより顧客コード体系が異なるというのもセマンティクス・ギャップの一つだ。しかし、これはテーブル引きの処理をすることにより、比較的容易に対応できるかもしれない。