これらの設問ではあらかじめ設定されたIT技術をチェック式で複数回答する。その結果、それぞれの技術に関しての習得済みのエンジニアのパーセントと、習得したいエンジニアのパーセントが出る。例えば「XML/Webサービス」では、既に習得済みとする人が約12%、これから習得したいとする人が約47%である。そして、この２つの数字をマトリクス化すると現在それぞれの技術がエンジニアにとってどのようなポジションにあるのかが見えてくる。図３を見て欲しい。縦軸に、これからの身につけたいスキルだと思う人のパーセンテージ、横軸に既に保有しているスキルであるという人のパーセンテージをとってそれぞれの技術をプロットする。これを４つの象限に区切ることで各技術をポジショニングすることができる。
まず左下のポジションは、習得意向も少なく現役エンジニアの習得者も少ない「レガシー技術」であり、ここには「汎用機系開発」や「COBOL」が入っている。そして右下のポジションは習得者は多いが新規の習得意向は低い「成熟技術」で、「C/C++」「Visual Basic」などが入っている。右上が習得者も多く習得意向も高い「花形技術」で、「Java」「ネットワーク」「データベース」などが入っている。そして、左上がまだ習得者は少ないが習得意向が非常に高い「注目技術」で、「XML/Webサービス」「セキュリティ」などが入っている。
理由2：10年以上使える技術
また、これまで複数のXMLマスター取得者に「なぜXML技術を習得しようと考えたのか」をヒアリングしたところ「間違いなく長期間使える技術だから」という答えが目立った。
XMLは、数多くあるITの新しい技術の中でも、全てのベンダーが賛同し推進しているという特色を持つ。他の技術、例えばJava, Linuxは対抗勢力があるし、OracleやMSなどのベンダー資格はその製品の盛衰に依存する。その点、XMLは、さらに新たな技術の基盤技術となっていることもあってこの先10年間を考えても有効な技術だということが分かる。つまり習得のための時間、コストを投資してもかなり長期でリターンを見込むことのできる技術ということができるのだ。
理由3：学習コース・教材が充実
また、いくら習得意欲が高くてもそれを勉強する手段が乏しいのでは実際に習得することはできない。また、実際のシステム開発、ソフトウェア開発においてXMLに触れOJTでスキルを磨くことは最も重要であるが、OJTにおいてはどうしても技術の習得が断片的になってしまう。そこで、本当にXMLの技術を身につけるには実際の経験とともに体系的な学習も必要となる。
大手ソリューションベンダーの場合は、社内教育体制も整い、XMLの体系的学習も比較的容易であろう。しかし、それ以外の場合は、社外に頼らざるを得ない。その場合に役立つのが、一般の教育コースや教材である。XMLマスター向けには全国13社の大手教育ベンダーが認定トレーニングコースを持ち、また数多くの書籍や学習ツールも出版されている。これらの学習コース・教材の充実によって、実際の経験に加えてXML技術を体系的網羅的に学習する機会をニーズに合わせて選ぶことができるのだ。
| XMLマスター認定 教育コース開催社 ⇒詳細 |
■ 株式会社ウチダ人材開発センタ ■ NRIラーニングネットワーク株式会社 ■ NEC ■ NECソフト株式会社 ■ NECソフトウェア九州 ■ 株式会社大塚商会 ■ グローバル ナレッジ ネットワーク 株式会社 ■ 株式会社CSK ■ 株式会社東芝OAコンサルタント ■ 日本ヒューレット・パッカード株式会社 ■ 株式会社富士通ラーニングメディア ■ 株式会社日立システムアンドサービス ■ リナックスアカデミー |
| XMLマスター認定 学習用教材 ⇒詳細 |
＜プロフェッショナル＞ ■ XMLマスター教科書 プロフェッショナル（翔泳社） ■徹底攻略XMLマスター教科書 プロフェッショナル編（インプレス） ■ iStudy for XMLマスター プロフェッショナル（システム・テクノロジー・アイ） ＜ベーシック＞ ■ 徹底攻略XMLマスター問題集 ベーシック編（インプレス） ■ XMLマスター教科書 ベーシック（翔泳社） ■XML技術者認定試験「XMLマスター ラーニングブック」（技術評論社） ■ 完全合格 XMLマスター試験対策テキスト&模擬問題集（アスキー） ■ iStudy for XMLマスター（システム・テクノロジー・アイ） ■ XML MASTER テキスト XMLマスター（ソフトバンクパブリッシング） ■ XML認定資格取得講座（富士通オフィス機器） ■ XML技術者認定資格 XMLマスターハンドブック（リックテレコム） |
| XML技術者育成推進委員会理事 |
|
■ NEC ■ NECソフト株式会社 ■ 株式会社大塚商会 ■ グローバルナレッジネットワーク株式会社 ■ ソニーグローバルソリューションズ株式会社 ■ 日本アイ・ビー･エム株式会社 ■ 株式会社日立システムアンドサービス ■ 株式会社日立製作所 ■ 株式会社ＰＦＵ ■ 富士通株式会社 ■ インフォテリア株式会社 ■ XMLコンソーシアム（会員企業約237社） ■ 外資系情報産業研究会（会員企業38社） |
近年、業務のスピード向上や、素早い意思決定・企業経営を実現するために、社内の異なる業務アプリケーションの連携が必要となってきた。アプリケーション間の連携を行うには、個別にその接続をコーディングして作りこむこともできるが、この方法では連携の数だけプログラム開発を行わなければならない。そこで、このアプリケーション連携を中心的につかさどり連結の数を大幅に減らすことで開発期間の短縮と柔軟性の確保を両立させるパッケージソフトウェアが現れ、これをEAIと呼んだ（図１）。
この定義上、EAIに求められる最低限の機能は、各アプリケーションとの結合を実現する「アダプタ」、アプリケーション同士のデータの関連付けや加工を行う「マッパー」、そしてそれらの処理の制御を行う「フロープロセッサ」となる。（図２）
第１世代EAIと第２世代のEAI
最初にEAIが脚光を浴びた1998年当時、XMLをはじめとしたインターネットテクノロジーは企業情報システムにおいてはまだ普及の途上だった。そのため、その時点で既に存在したプラットフォームとして、メッセージキュー、TPモニタ*1、DBMSなどをベースとしたEAI製品が多く生まれ、連携テクノロジーとしてはベンダー独自のMOM*2やCORBA*3が使われた。
その後、XMLやインターネット標準技術の普及が進み、企業におけるインターネット活用が当たり前となった。また一方で、グローバル化や構造不況の影響を受けて企業情報システムのビジネスの変化への迅速な適応への要求は加速度的に増してきた。そして、2002年頃から、インターネット標準技術をベースとした新しいEAIソフトウェアが生まれてきたのだ。この新しい世代のEAIの特徴を典型的な例で整理すると次のようになる。
第２世代EAIの特性は、規模にとらわれず、オープンな標準技術を使い、社内外にかかわらずアプリケーション統合ができる、つまり様々な意味でオープンであることである。そこで、本稿では第２世代EAIを「オープンEAI」と呼ぶことにする*4。ここに整理したような特性によって、オープンEAIで構成するEAIは構造的にも特徴をもつ。つまり、オープンEAIでは、モノリシックな単一ハブ構造を強要せず、必要に応じて複数のハブを持つことも可能となっているのだ（図３）。その意味でオープンEAIは、「アプリケーション統合」というよりは「アプリケーション連携」の意味合いが強い。英語で言えば、IntegrationというよりはFederationといったところだ。本稿で定義した「オープンEAI」はEnterprise Application Federationのためのパッケージと言うこともできるだろう。オープンEAIの構造によって、局所的に始めて、必要な応じたツールを組み合わせ、システム連携を成長させていくことができる。しかも、特定のベンダーや技術だけに依存する必要もない。オープンEAIの登場により、もはやEAIは、年間に何十億もIT投資ができる大企業だけのものではなくなったのだ。あらゆる企業でシステム連携のニーズは高まっているが、現実的には、EAIを最初から大規模に導入できる企業は少ない。しかも大企業であっても、そのシステムの多さと複雑さゆえに、全社的なシステム連携基盤を一斉に構築することができることは稀である。このような現在のビジネスの状況やニーズを分析すると、現在のEAIに求めらてている姿＝条件が浮かび上がってくる。
オープンEAIとしての５つの条件
さて、ここまでEAIパッケージについて解説してきた。しかし、ガートナーの調査（図４）にも示されるとおり、企業アプリケーション統合においてはまだEAIパッケージが適用されず個別に作りこまれているケースが多い（図中、赤枠の部分）。つまり、実はEAIのパッケージ選定などという前に、EAIのパッケージすら使っていないケースが多々あるということだ。これは、企業アプリケーション統合の形態がまだ図1の左辺のような構造で作りこまれているものが多いということを示している。このようなケースは、「まず1対1だからEAIパッケージを使うほどでは・・・」というように、とりあえず目の前の問題を解決するためだけに採られたり、または悪いケースでは開発ベンダーの工数を稼ぐために採られることさえあるが、１対１の接続であれ、これからのことを考えて導入をしなければ「常に火を消して回っている」後追い型の企業システムから抜け出すことはできない。実際、「オープンEAI」はこのようなニーズをも満たすために「スモールスタート」ができるような構造になっているわけであり、最初の１対１の接続からEAIパッケージを適用していくべきなのである。
ASTERIAとオープンEAI
さて、最後に筆者の所属するインフォテリアの製品ASTERIAは、さきほどの「オープンEAI」5つの条件においてどうであろうか？興味のある方は、別表にまとめたので是非参照してほしい。手前味噌にならないように事実だけを検証してみた。他のEAIパッケージを検討されている方は、同様の検証をしてみてはどうだろうか。
まとめ
ホスト連携を中心として大企業から始まった企業アプリケーション統合=EAIは、いまや企業規模を問わず必要となってきている。そして、さまざまなEAIパッケージが登場している。システム連携を行う際には、(1)1対1の接続であっても短視眼的に手作りで作り込む事を止めEAIパッケージを適用すること、(2)EAIパッケージの選定においては本稿「オープンEAI」の5つの条件を考慮すること、の2点を強く推薦する。
【注釈】
図で示すとおり、全ての企業に関わる財務情報だけにXBRLの用途は幅広い（具体的事例については後述）。まずXBRLを外部へ提供する用途としては税務申告、証券取引所や投資家への情報開示、金融機関への融資申請がある。また企業の内部的な用途としては、子会社の自動連結処理、会計士、監査法人などとの間でのデータ処理の自動化などが挙げられる。さらに、財務情報を二次利用した企業信用情報サービスなどにも活用される。
この図でわかるように、XBRLが普及すれば、企業情報のサプライチェーンといえるものが出来上がる。このことによって第一義的には、銀行や税務署、証券取引所といった、企業の財務情報を収集・分析する立場にある企業や団体が恩恵を受ける。例えば監査法人は、顧客企業からXBRL形式の財務情報をインターネット経由で入手すれば、監査のためのデータ集計・分析業務の手間を大幅に軽減できる。現在はほとんどの場合、紙で財務諸表を受け取り、それを手作業で集計したりコンピュータに入力するなどの手間がかかっている。
一般企業にとっても、XBRLの利点は大きい。まずは証券取引所や投資家への情報開示、法人税の申告、銀行への融資申請などといった事務処理が簡素化されることである。また、処理の迅速化によって早期に的確な情報開示が可能となり企業信用の向上にも役立てることが可能である。さらに、グループ企業の財務情報をXBRL形式で送受信することができれば、連結決算処理の事務作業のスピードアップに貢献できるだろう。昨今では合併や買収に伴い、関連会社であっても異なった会計システムを使用しているケースも多い。統合する企業の会計システムがXBRL形式でデータを管理していれば、会計システム統合の手間を軽減できる。
さらに、企業信用情報も現在は紙やPDFで提供されるケースがほとんどだが、XBRLでデータが提供されることで、手元での統計、比較、分析が容易になり判断の迅速化を助けることになる。
XBRLの構造について
１）企業情報開示：東京証券取引所
東京証券取引所は、2003年4月から同取引所の運営するTDnet（適時開示情報伝達システム）にXBRLを採用し、東証の上場企業には決算短信の１枚目（決算概要情報）がXBRLでの提出が義務付けた。従来TDnetでは、PDFおよびCSVの提出を受け付けていた。しかし、PDFではデータの加工、二次利用はできず、またCSVの提出はPDFと情報の整合性が取れなかったりなど、実用性に乏しかった。XBRLによって提出されたデータは自動的に加工され、翌朝には東証のWebサイトで閲覧可能となっている。このシステムは、XBRL 2.0を採用した世界で最初の実稼動システムである。
２） 納税申告：国税庁
多くの企業では、納税申告は会計ソフトから出たデータを基に税理士が作成した紙のデータ（これ自体は専用ソフトで印刷される）を、税務署に提出している。また、税務署では提出された資料を職員が一件一件手作業で処理を行っているのが実情であった。
国税庁では、2003年7月の電子政府の促進を目指すIT戦略本部の決定を受け、2004年3月から名古屋地区でXBRLによる法人税申告を始めた。このシステムは「e-Tax」と呼ばれ、企業が社内のパソコンから申告や申請を送信できるようになっただけでなく、銀行や税務署の窓口に納付書を持参しなければならなかった納付手続きも、パソコンを利用して行えるようになった。このことによって、企業側の処理効率が向上するだけでなく、これまで手作業で行っていた国税側のデータ入力も自動化される。
国税庁の発表によると2003年5月末現在の利用件数は、既に300件近くとなっている。そして、この6月からは全国で「e-Tax」による法人税申告が可能となっている。国税局では、さらに手続き開始の煩雑さや、一部書類について電子化されていない部分があることを解消していき、2006年度には「e-Tax」での申告件数として130万件を目標としている。
３）企業信用情報サービス：東京商工リサーチ
株式会社東京商工リサーチは2003年10月より、「X-BIS」という企業情報サービスを開始している。このサービスでは、XBRLをベースに「企業属性情報 ： Entity Information (EI) 」、「企業財務情報 ： Financial Information (FI)」、「企業分析情報 ： Financial Ratio (FR) 」の３種類情報が提供される。従来は、同社の顧客企業はこのような情報をPDFやFAXで得ていたため、企業分析や比較などの場合にはそのデータを再入力する必要があったが、XBRL形式で提供されることにより、加工、分析を容易に行うことができる。
XBRL Japanにおける実証実験
上記以外の用途として、XBRL Japanでは、銀行の融資申請・審査におけるXBRL仕様の実証実験を行っている。この実験の狙いは、企業の融資申請をXBRLを使いオンライン化するにあたっての問題を把握し解決を図ることである。この実証実験では、最終的には財務情報提供企業の会計システムから融資金融機関の審査システムに人手を介さずにデータを届けることを目指している。XBRL Japanでは、2004年4月に第1回の実証実験を完了し、様々な課題を確認した。第1回の実証実験では、情報提供会社から金融機関がXBRLデータをオフラインでもらい、そのデータを各社のシステムやツールに読み込む実験を行った。
この実証実験には、データ提供会社として帝国データバンク、東京商工リサーチ、日本経済新聞の３社、ソリューション提供会社として、インフォテリア、ＮＴＴデータ、日本オラクル、日立システム、日立製作所、日立ハイテクノロジーズ、富士通の8社、銀行側としての東京三菱銀行、三井住友銀行、UFJ銀行の3行、監査法人およびコンサルティング企業として、シナンシャルシステム、新日本監査法人、中央青山監査法人、べリングポイントの4社が参加した。現在、第2回目の実証実験を進めているところであり、オンラインでのデータの受け渡しと実際のアプリケーションへのデータの活用に関する実験を行う計画である。（文中社名50音順）
XBRL実装に必要な機能とソフトウェアベンダーの対応
一言に「XBRLの実装」といっても、用途によって必要な機能は異なる。表ではXBRLの実装にあたっての機能を整理した。XBRLのための機能は9つに整理される。またこれらの機能は、XBRLデータの提供側と受領側で必要となるものが異なる。さらに、その中での用途によって必要な機能を実装するわけだ。これまでの、XBRLの実装事例では、ほとんどの機能を作りこみで実現しているが、最近ではこれらの機能をパッケージ化して提供する製品も出始めており、インフォテリアの「ASTERIA」もその一例である。
XBRLの仕様の充実と普及に伴い、インフォテリア以外の各ITベンダーも着々とXBRL対応を進めている。財務データを直接扱うパッケージベンダー、例えば、SAPの「SAP R/3」、NTTデータシステムズの「SCAW」、PCAの「PCA会計」などは、XBRLデータを生成できるよう機能拡張を施している。日立、富士通、日本ユニシスといった大手システムインテグレータも、XBRLのツール製品やXBRLを軸としたシステム構築サービスを発表済みである。
「ASTERIA」では、XBRL Encoder、 XBRL Decoder、 XBRL Splitterの3つのコンポーネントを備えることで、従来から「ASTERIA」が扱うことのできる多彩なデータソースをXBRL化したり、また、XBRLで得たデータを社内用に加工したり、データベースに格納したりすることができる。そして、これらの処理を「ASTERIA」の特長である「ノン・コーディング」で行うことができるのだ。（図）
このように、XBRLは仕様だけでなく、実装環境も整いつつある。究極的には、XBRLはすべての企業に関係のある仕様であるため、自社でどのようにXBRLの対応を進めていくかを今から考えておく必要があるだろう。]]>
Webサービスを一つの側面から簡単に説明すれば、人間を対象としてサービスしていたWebサイトの対象をコンピュータに代えたものということができる。例えば、物品販売のWebサイトは、ブラウザを使った人に対するサービスであるが、物品販売のWebサービスは、他のコンピュータが自動的に発注を行ってその結果をデータとして返すサービスである。WebサイトとWebサービスの違いを整理すると図1のようになるが、ここで重要なことはWebサービスではプログラムによって自動的に処理されるという点である。Webサイトの場合に人が行なっていた様々な行為、例えば「相手を信用するのかどうかの判断」、「同じ請求書が2回来ていないかかどうかの確認」、「別の処理（例えば購入処理と資産管理）との連携」などを、Webサービスではコンピュータ自動で処理することになる。つまり、これまで人が行っていた様々な処理をコンピュータが行うのであり、それらの処理を自動で行なうための約束事が必要で、それこそが現在数多く提案されている「WS-標準化」である。
「WS-標準化」を整理する
図2は、表1に示した「WS-標準化」の中で主要なものを整理しWebサービス関連仕様の標準化の全体像として示したものである。
図2では、各仕様を示すボックスの色はその仕様を標準化している団体を示す。灰色については現時点でまだ標準化団体に提出されていない標準案である。この色分けからまず、Webサービスに関連する標準化に団体は4つあり、それぞれが大まかな役割分担ができていることがわかる。つまり、IETFはインターネットプロトコルなど通信基盤の分野、W3CはXMLやSOAPを初めとする基本的なデータ記述の分野、OASISはそれら基本技術をベースとした応用技術の分野、そしてWS-Iはそれらの技術の実装における相互接続性の分野という役割分担である。
上下方向は技術のレイヤーを示しており、上下に重なっている仕様はそれぞれ基本的に組み合わせて使うことができる。同じレイヤーで左右に間隔を空けて配置してあるものは、類似の仕様が対立していることを示している。
競合仕様の状況
図を見ると仕様が対立した部分が3箇所ある。これらは、全体を理解する上でも重要なので、以下で具体的に見ていこう。
(1) 信頼性メッセージング：WS-Reliability 対 WS-ReliableMessaging
この2つの仕様は、どちらもWebサービスのメッセージの信頼性を確保するためのものである。信頼性を確保するというのは、(1)メッセージの到達を確実にする、(2)重複到達を排除する、(3)到達順番を保証するという3つの大きな役割を意味する。インターネットのメッセージングは不特定のサーバーを介して行われるものであり、途中でどこかのサーバーのダウンによってメッセージが失われることもあり、また到達の順番も保証されていない。しかしながら、実際のビジネスにおいては個々のドキュメントは、確実に、重複なく、正しい順序で相手に到達しなければならない。例えば、注文書が2回届いたり、キャンセル通知が元となる注文書の前に届いたりしてはいけない。
WS-Reliabilityは、富士通、日立、NECなどが提案し、現在OASISで標準化が進められている仕様である。これは、ebXMLのmessaging Serviceをルーツとした実績のある実装である。特徴としては、他のセキュリティ技術に対して非依存であることロイヤリティフリーを宣言していることなどが挙げられる。MS-Reliabilityは、WS-ReliableMessagingは、IBM, Microsft, Tibcoなどが提案したもので、現時点では標準化団体にはまだ提出されていないが、提案各社の製品に実装されている。
WS-ReliabilityとWS-ReliableMessagingはどちらとも同様の目的のために開発されたものであり、あきらかに対立している。そのためOASISでは、両仕様の統合をに呼びかけており、年内には何らかの調整が行われるであろう。
(2) サービスの連携：BPEL4WS 対 WS-CL (Choreography Language)注
この2つの仕様は、どちらも複数のWebサービスを連鎖させビジネスフローとして使うための仕様であり、例えば、Webサービスの起動、データの操作、障害の通知、またはフローの終了などのアクティビティを作成し、それらを組み合わせることで複雑なプロセスを組み立てることができます。またアクティビティを、順番に実行するのか、並列して実行するのか、特定の条件に基づいて実行するのかなどを定義することも可能だ。
BPEL4WSはOASISで標準化が進み、WS-CLはW3Cで標準化が進んでいるため、標準化団体同士の争いと見られている側面がある。しかしながら、Webサービスの応用領域は、W3Cが従来カバーしてきた基礎技術領域とは違うためW3Cで標準化することが適切かどうかという疑問の声も多い。実際、図2を見てもWS-CLが他のW3Cの標準化レイヤーと異なり飛び地のようなポジションなっていることがわかる。
また、MicrosoftがWS-CLを離脱するなどの行動や、WS-CLでのディスカッションが進展していないなどのことから、私はこの2つの仕様はBPEL4WSを中心に収斂していくものと考えている。
(3) トランザクション：WS-Transaction 対 WS-CAF
この2つの仕様は、どちらもWebサービスを使ってトランザクション処理を行う基盤となる仕様である。Webサービスでトランザクション処理を実現するためには、複数の異なるコンピュータ環境をまたがって、処理のコミットやロールバック処理を行なうため、様々な取り決めと厳密な実装が必要となる。WS-Transactionと関連仕様のWS-CoordinationはIBM、Microsoftなどにより提案されているWebサービスによる分散トランザクションを可能にするための標準仕様案である。従来のクローズドな環境やベンダーで行なわれていたトランザクション処理を、不特定多数でWebサービスで結合した環境で可能にする。
そしてWS-Transactionの発表から約1年後の昨年8月にIONA, Oracle, Sun MicrosystemsなどがWS-CAFを発表した。WS-CAFは、3つの仕様から構成され（表1参照）、WS-Transaction + WS-Coordinationのカバー領域と重複している。これらは主として各社が提供する製品における実装の都合に起因している。
WS-CAFはOASISでの標準化が始まっており、IBM, Microsoftといった実力派対標準化団体という構図になっている。Webサービス連携に関する仕様が複数存在すると、Webサービスを連携させるために複数の仕様を実装しないといけないことになるため、Webサービス構築側もWebサービス利用側も余計にコストがかかってしまうこととなる。
その他の注目「WS-標準化」
次に、対立しているわけではないが、Webサービスの実用化にあたり注目すべき仕様をピックアップする。
(1) セキュリティ：WS-Security
セキュリティに関しては、多くの仕様が提案されており競合があるように見えるかもしれないが、基本的にはそれぞれが補完的になるものである。ベースになるデータセキュリティの仕様であるXML Signature（XML署名）、XML Encryption（XML暗号化）は特にWebサービスにかかわらずXMLデータ全般に適用できるデジタル署名と暗号化の仕様であり、WS-Securityはこれらを使用し、その上で、WS-Securityでは、デジタル署名、暗号化、セキュリティトークンの付加を提供する。
さらに、サービスによって必要なセキュリティを付加するしくみとして、WS-Policy(※)、WS-Privacy(※)、WS-Trust(※)、WS-SecureConversion(※)、WS-Federation(※)、WS-Authorization(※)などが開発中である。（※の概要については表1参照）
(2) サービスの管理：WS-Manageability
OASISのWS-Distributed Management TCで標準化が進められているWS-Manageabilityは、Webサービスを管理するWebサービスを規定する仕様である。従来はシステム管理ツールが独自の技術によってそれぞれのシステムを監視、管理していた。WS-Managabilityは、複数のWebサービスによって組まれたシステムについての可用性、状態、パフォーマンス、使用状況、構成などをWebサービスによって管理するための仕組みである。
「WS-標準化」の今後
Webサービス周辺の標準化仕様提案は未だに衰えを見せない。例えば、2004年1月8日には、Microsoft, BEA, Tibco社がWS-EventingというWebサービスにおけるイベント処理のための新仕様を提案した。Webサービスをあらゆる場面で適用していくためには、今年いっぱいはまだ新しい仕様の提案や標準化が続くであろう。しかし、先に紹介した3つの対立する仕様に関しては、仕様が対立したままでは各ベンダーの実装の障害にもなるため、各社何らかの決着を付けたいという思惑が働いており、近いうちに何らかの形で統合され実用的な仕様となるに違いない。
混乱しているように感じられる「WS-標準化」も、このように整理すれば、たいして混乱しているわけではないことがわかる。Webサービスをビジネスに使う場合には数々の約束事が必要で、その仕様が揃ってきているということだ。対立している3つの領域の統合もそう遠いことではない。今年から来年にかけて、一般的な企業でもWebサービスを一つの技術基盤として検討する年となるだろう。
以上]]>