通常のWebアプリケーションとWebサービスの違いは何でしょうか。 それは、通常のWebアプリケーションがWebブラウザを介してユーザに利用される一方，Webサービスはシステム間において利用されるということです。 (図 1)

他のテーマにおいて紹介されているように、WebサービスはSCM(Supply Chain Management)のような企業間連携システムを、迅速に構築するための重要な技術になっています。では、Webサービスは通常のWebアプリケーションの構築には、なんら影響を与えない技術なのでしょうか？ もちろん、そのようなことはありません。 Webサービスはシステム間で利用される技術ですが、Webサービスを利用するシステムは最終的にはユーザによって利用されます。　現在Webアプリケーションは、企業を超えたビジネスプロセスを実行し、ビジネスモデルの変化に対して柔軟にロジックの変更が出来なければなりません。また、ユーザの嗜好や環境に応じて、カスタマイズされたコンテンツを提供する必要もあります。そのような要求から、Webアプリケーションの構築において、提供するデータの作成や処理のロジックをWebサービスによって分散し、必要に応じて結合するという手法が導入されていくと考えられます。 さらに、データやロジックだけではなく、Webブラウザに対するプレゼンテーションやユーザの入力に対する処理もWebサービスと同じ仕組みで扱えるようにし、それらのWebサービスを”組み合わせる”だけでWebアプリケーションを構築できる仕組みができないかと考えられるようになってきました。

そのような要請から、Webサービスのコンポーネント化とプレゼンテーションレイヤに対するWebサービスの適用を行う技術的仕様を定めるため、OASIS(the Organization for the Advancement for Structured Information Standards)において結成された技術コミッティがWSIA(Web Services for interaction applications)とWSRP(Web Services for Remote Portals)です。 この二つのコミッティは別のコミッティですが、解決すべき問題が似ており，多くのベンダが両方のコミッティに参加しているため、協力して標準化を進めていくことになっています。

※ WSIA, WSRPともに現在標準化が進行中であるため、この説明は2002年5月時点での情報を参照しています。 その点にご注意ください。

OASISのWSIA技術コミッティは、もともとWSCM　(Web Services Component Model)という名前で、DataChannel (現在はNetegrityに買収されています)、HP、 IBM、 Epicentricなどのベンダを中心に2001年の10月に結成されました。WSIAは一言で言うと、「Webアプリケーションを構築する部品としてWebサービスを利用することを目的とし、Webサービスをコンポーネント化するための標準」ということが出来ます。 例えば、企業コードからその企業の株価チャート画像やデータを返却するような「株価チャート表示」Webサービスを考えて見ます。 このWebサービスをユーザにWebアプリケーションとして提供するには、直接的にこのようなサービスをブラウザで提供する場合もあれば、ユーザがあらかじめ企業コードを設定し、設定されたチャートを表示するようなポータルサイトのページに埋め込まれて表示される場合もあれば、企業名から企業コードを検索し、そのチャートを表示できるように拡張したアプリケーションのバックエンドで利用される場合もあるでしょう。

このようなWebアプリケーションは、どれにしても、「株価チャート表示」Webサービスを扱うコードを記述することにより開発することになりますが、DOMを用いたXMLの操作やHTMLの作成など、非常に冗長かつ手間のかかる作業になります。そこで、このような手間を軽減し、さらにはコーディングの経験が少ない開発者でも、グラフィカルなツールを用いWebサービスを"組み立てる"ことにより新しいアプリケーションを開発出来るようにできないかと考えられるようになりました。たとえればVisual Basic、Delphi、 JavaBeansを用いるGUIアプリの開発などの、コンポーネントプログラミングと同じ考え方です。 WSIAはこのようにWebサービスをコンポーネント化するため標準技術ということになります。

2002年5月時点でWSIAの仕様は公開されていません。 しかし、WSIAはIBMの提案しているWSXL(Web Services eXperience Language)をベースにすると考えられていますので、このWSXLを簡単にご紹介しましょう．

WSXLでは，WebアプリケーションをMVC(Model-View-Controller)モデルで構築することを前提としています．また、Webサービスをコンポーネントとして扱えるようにするために必要な基本的なインタフェースを、WSXL Base Componentとして定義しています。さらに、このWSXLベースコンポーネントからModel(WSXL Data Component)、View(WSXL Presentation Component)、Controller(WSXL Control Component)に相当するコンポーネントのインタフェースを定義しています。

そして、これらで定義されたWSXLコンポーネントを組み合わせることによって、Webアプリケーションを構築できるということになります．

なお、WSXLのインタフェースは，すべてWSDLによって記述されます。

WSXL Base Componentでは、コンポーネント化を実現するために、以下のポートタイプ(ポートタイプはWSDLの用語であり、オブジェクト指向言語におけるインタフェースのようなものと考えてください) を定義しています。

1. コンポーネントの持つサービス形式に関する問い合わせ(WSXLServiceDescription)
   このポートタイプは、WSXLのクライアントに、このコンポーネントが持つサービス定義をWSDLの形式で提供し、また、あるポートタイプをこのコンポーネントがサポートしているかどうかを通知する役割を持っています。
2. コンポーネントのライフサイクル管理 (WSXLLifeCycle)
   このポートタイプはコンポーネント化されるWebサービスのインスタンス化とインスタンスの破棄を行うためのものです。
3. プロパティ管理 (WSXLProperties)
   このポートタイプは、コンポーネントのプロパティの設定/取得を行うものです。
4. アウトプット(WSXLOutput)
   このポートタイプはユーザに渡すHTMLなどのマークアップを取得する場合に利用するものです。
5. イベント処理(WSXLEventSource, WSXLEventSink)
   これらのポートタイプはWSXL Base Componentの拡張インタフェースとして定義されており、WSXL Base Component間でイベントの転送が出来るようにイベントソース(WSXLEventSource)とイベントリスナ(WSXLEventSink)を定義するものです。

WSXLを用いたアプリケーションをここでご紹介しましょう。

図2を見て下さい。これは、株価チャート表示のWebアプリケーションプロバイダとそのプロバイダのサービスを自社の形式で表示しているビジネスパートナーアプリケーションです。　両WebアプリケーションともWSXLで構築されているものとします。

この例ではビジネスパートナのアプリケーションは、表示だけを変更しているため、自サイトでWSXL Presentation Componentのみ開発し、それ以外の部分はアプリケーションプロバイダと接続することによってWebアプリケーションが構築できることになります。また、異なる検索条件をサポートするといったロジックの変更や追加を行う場合は、そのためのWSXL Control Componentを追加して接続すればよいということになります。 また、アプリケーションプロバイダの立場から見ると、アプリケーションプロバイダは�@のように直接ユーザのアクセスを受けるWebアプリケーションだけではなく、2のようにビジネスパトーナがこのアプリケーションプロバイダをバックエンドに利用する形式も簡単に構築できるようになるため、より多くのユーザに利用されることを期待できます。

OASISのWSRP技術コミッティはBowstreet, 富士通、 HP、IBM、 IONA、 オラクル、 SilverStream Softwareなどのベンダを中心に2002年1月に結成されました。計画としては2002年12月に最初の仕様を公開する予定となっています。

WSRPは、Webサービスによって提供されるポートレット(HTMLなど表示ためのマークアップの断片であり、サービスやコンテンツにアクセスするためのウインドウにあたるものと考えてください)をプラグ&プレイでポータルサイトに埋め込み、ユーザの嗜好や環境に応じたポータル画面を簡単に構築できるような仕組みを目指しています。 ポートレットがWebサービスによって提供されることにより、インターネット上に存在するあらゆるWSRPポートレットがポータルサイトにおける利用の対象になり、さらにUDDIのもつ検索機能を用いて必要なポートレットをすばやく見つけ出すことができるということになります。(図3)

WSRPは、まだ仕様が公開されていません。ですので、どのようなことが検討されているのかご紹介しましょう。

まず、このようにプラグ&プレイのポータルサイトを簡単に構築するための要件をあげてみましょう。

1. インタフェースの標準化
   ユーザからの入力の扱いとHTMLなどのマークアップへの出力の制御を行うインタフェースの標準が必要です。また、ポートレットとしてのインスタンス管理のためのインタフェースの標準が必要です。
2. ポータル設計ツールへの対応
   ポータルサイトの設計の際にはコーディングの労力なしに設計できるようにすることが期待されます。例えばユーザがブラウザ上で動作するツールによって、自分専用のポータルサイトのページを設計できると良いでしょう。
   1、２の要件はWSIAと同じ要件といえるでしょう。
3. ポートレットの検索ディレクトリへの対応
   ユーザやポータルの設計者が必要とするポートレットを、柔軟に検索できるような検索エンジンを利用できるということも重要です。検索条件のためのメタデータの定義も必要でしょう。
4. WSRPポートレット以外のポートレットとの共存
   ポートレットはWSRPポートレットだけではないので、WSRP以外のポートレットとの共存が可能なアーキテクチャが望まれます。
5. ポータルサイトのページ自身のポートレット化
   WSRPポートレットなどにより構成されたポータルサイトのページを、さらにWSRP ポートレットとして外部に公開できるようにすると、ポータルサイトの設計が再利用され、開発の手間が削減されるでしょう。

WSRPを利用するポータルサーバのアーキテクチャを図４に示します。

WSRPは既存のWebサービスの技術やWebアプリケーションの技術をベースとしています。

図４において、ポートレットプロキシはWSRPサービスを利用する際にSOAPを用いてアクセスします。 また、WSRPサービスは、WSDLによってインタフェースが記述され、Webサービスのコンポーネント化においてWSIAのポートタイプを用いています。 さらにWSRPサービスはUDDIに登録することができるため、ポータルサイトはUDDIを利用し、必要なWSRPサービスを発見することが出来ます．

WSRPではユーザが利用するさまざまなマークアップ(HTML, WML, VoiceXMLなど)を利用することが可能です。さらに，ポータルサイトの提供するコンテンツ自身をWSRPとして公開することも可能です。

また、WSRPサービスはポートレットプロキシを用いて、ポータルサーバの採用するPortlet APIを介して利用することが想定されています。 そのため、ポータルサーバからみればWSRPポートレットであるか、ローカルに配置されているポートレットであるかを意識することなく利用することが出来るようになるわけです。

ここではOASISで標準化活動が進んでいる、WSIAとWSRPに関して簡単に紹介しました。 このどちらの標準も現在策定中の仕様です。 しかし、二つの技術コミッティが目指している、ユーザクライアントを含むトータルなシステムをWebサービスの技術によって構築しようという取り組みは、今までのWebサービスにおける取り組みにはなかったことでした。 WebサービスもSOAP、WSDL、UDDIという基本が浸透し，次の取り組みへと進化していることを示しているという意味で非常に興味深いものです。 その意味でこれら二つの標準の動向には目を離すことが出来ないといえるでしょう。