バージョン2.1で13サービスを定義
Parlay X Web Servicesの現在の最新バージョンは2.1であり，共通部分のメッセージ・フォーマットなどの仕様を定めるCommonを除くと，13種類のサービスが定義されている（表1）。パーレイ・グループでは既に2.2と3.0の仕様の検討段階にある。2.2は2.1の一部を更新する見込みで，3.0では6サービスが追加される予定だ。
 |
| 表1●Parlay X Web Services（2007年4月現在） バージョンは2.1，2.2，3.0の三つがある。網掛けは本文で説明しているもの。 [画像のクリックで拡大表示] |
Parlay Xは，インタフェースを定義しているだけであり，その実装は提供ベンダーに委ねられている。複雑な通信技術にかかわる部分はサービス実装の中に隠蔽されるため，ユーザーには平易なAPIの利用に関する知識だけが要求される。
このような「関心の分離」は，WebサービスやSOAの特徴である。利用者，提供者ともに標準インタフェースだけに依存しているので，例えば提供側の実装方法に変更や拡張があっても，利用者側には影響を与えない。利用者はよりよいサービス提供者を選ぶことができ，プラットフォーム技術が変化してもインタフェースが変わらない限り，インパクトを受けない。このように，お互いのアプリケーションのライフサイクルが別々に管理されるため，より柔軟なエコシステムが形成される。この柔軟性により，少ないリスクでビジネス参加ができるのが，SOAの一つのメリットである。
このようなエコシステムでは，提供者はよりよいサービスを提供しようとして，利用者は自分に合ったリーズナブルなサービスを利用しようとする。もちろん提供側にはそれなりの競争原理が働く。Parlay Xのサービスの機能は提供ベンダーによって多様化する。
要件によって変わる実装方法に注意
Third Party CallのIMSへの実装に当たっては，RFC3725を参照しているベンダーが多い。そこではThird Party Call を実現する数多くのSIPプロトコルを紹介しており，使用環境や要件による推奨を記載している。
図4左に示した例は，makeCallを実現するためのもっともシンプルな例で，着信側Bが自動応答システムなどの機械である場合に限り有効だ。着信側Bが遅延の可能性のある人間を想定するとうまくいかない。発信側Aは設定時間以内にACKを受信しないと呼の設定が失敗したとみなしてしまうからだ。その点を考慮したのが図4右で，基本的なmakeCallのフローとして推奨されている。
 |
| 図4●RFC3725 Flow I（左）と同Flow IV（右） Flow Iは着信側のBが自動応答システムなどの場合を想定。 Flow IVは着信側が人間であることを想定し，遅延の可能性を見込んでいる。 [画像のクリックで拡大表示] |
しかし，これでも十分ではない場合がある。3GPP/3GPP2のアクセス網では，呼ごとにリソースの動的確保を必要とする無線区間の存在が前提のため，リソース確保が終わるまで端末呼び出しが行われないようにする必要がある。これを実装するには，SIPにpreconditionオプション（RFC3312）を適用し，リソース確保を確認する手順を追加しなければならない。この手順についてはRFC3725の9.2に詳細な実現プロトコルが記載されている。
このように，要件によって実装方法やその複雑さは変わってくる。この例ではIMS端末だけを想定したが，既存の固定/移動通信網と接続する場合には，ゲートウエイを介した接続が必要となる。実装方法としては，Parlay APIやJAINの機能を利用するほか，ほかの固有技術を駆使する必要がある。本来機能の一部の実現方法だけでも，これだけバリエーションがある。しかし，商用サービスでは機能だけでは不十分であり，ビジネスモデルや非機能要件のサポートが必要となる。
変わる通信事業者のビジネスモデル
サードパーティにサービスを提供するということは，通信事業者のビジネスモデルと密接に関わる。当然，認証や認可を含むセキュリティ機能は必須であり，顧客企業や加入者ごとにサービスのレベルを変えたいとか，重要な顧客には手厚い保証を提供したいと考えるかもしれない。こういったビジネスモデルをサポートするために，SLAを保証する機構が必要となる。
またユーザーとの契約形態によって，提供する機能やサービスの振る舞いを変えたいと考えるかもしれない。あるユーザーが，あるサービスの，あるオペレーションを利用するという事象を考えると，それぞれの挙動を変えるポリシー設定と制御が必要になる。
こういった多岐にわたるビジネスモデルをサポートするには，提供するサービスやそのオペレーション・レベルでのシステム管理が必要になる。特に，コア・ネットワークに対する急激な輻輳（ふくそう）を制御する機能や，サービスレベルに応じたリソース優先確保機能，全体を把握するためのリアルタイム・ネットワーク・リソース統計情報の把握，課金のための記録，許可ユーザーにのみ情報開示をするプライバシー設定などが重要な機能になる。
通信機能を提供する基盤も登場
Parlay Xやそれ以外の通信機能をWebサービスとしてサードパーティに提供するためのプラットフォームも登場している。その一例としてSDPを提供する基盤ミドルウエアであるIBMの「WebSphere Telecom Web Services Server」（TWSS）を紹介しよう。図5にTWSSの論理システム・コンポーネントを表した。アクセス・ゲートウエイ，ポリシー・マネージャー，サービス・プラットフォームという三つの主要コンポーネントで構成する。
 |
| 図5●IBMの「WebSphere Telecom Web Services Server」の構成 アクセス・ゲートウエイ，ポリシー・マネージャー，サービス・プラットフォームという三つの主要コンポーネントで構成する。 [画像のクリックで拡大表示] |
ポリシー・マネージャーはサービスや操作，ユーザーの階層に，あらゆるポリシーを設定できる。サービス・プラットフォーム内のサービスの挙動を動的に変更したり，SLAを強制したりするためのポリシーを管理するディレクトリ・サーバーである。
アクセス・ゲートウエイは，Webサービスのエンドポイントの公開やセキュリティ，ポリシー情報付加，SLA検証などをした後に，サービス・プラットフォーム上の実機能を呼び出す。Webサービスのアドレスを管理し，ルーティングを実行して，付加機能プラグインをサポートするSOAの中核となるESB上に実装されている。
ESBを利用するアーキテクチャ上の利点は，Webサービスで利用される実際のメッセージ・プロトコルやトランスポート・プロトコルの違いを吸収するだけでなく，カスタマイズが必要な非機能要件やビジネスモデル・サポート機能をプラグインとして，サービスの呼び出し前後に挿入できる柔軟性があげられる。
サービス・プラットフォームは，Parlay Xなどのサービスの機能の実装だけでなく，SDPとして共通な機能を標準装備している。具体的にはサービスの負荷集中を防止する機能やコアネットワークへの過剰負荷を抑える機能，課金のためのログ，コールバックの呼び出しなどで，ビジネスモデルと連動しながらシステムを制御できるようになっている。
詳しく見るとサービス・プラットフォームは，J2EEアプリケーション・サーバー上に実装されている（図6）。Parlay Xの各サービスは，J2EEアプリケーションとして実装されており，JAX-RPC（JSR101）でクライアントから接続可能なWebサービスとして公開される。
 |
| 図6●Parlay Xでサービス・プラットフォームを拡大 サービス・プラットフォームは，J2EEアプリケーション・サーバー上に実装されている。 [画像のクリックで拡大表示] |
このJ2EEアプリケーション・サーバーは，実際にはWEB/SIP統合コンテナをサポートする「WebSphere Application Server 6.1」である。WEB/SIP統合コンテナとは，JSR116で標準化されているSIPサーブレットと呼ばれるアプリケーションをサポートする。JSR116は，JAIN APIの一部をサーブレット・コンテナとして標準化したものである。
この技術は，Webアプリケーションを構築する主要技術であるHTTPサーブレットと同じスタイルでSIPプログラミングが可能な，Javaのサーバー・サイドの重要技術である。しかも，同じ稼働環境（コンテナ）がSIPもHTTPもサポートするため，例えばSIPのプロトコルからHTTPに変換したり，Webから入ってきたHTTPリクエストをSIPに変換してコアネットワークへ要求したりすることが可能になる。
SOAとWeb2.0の融合の接点に
NGNは，インターネット技術との親和性が欠かせない。そのキーとなるParlay XはIT開発者に通信技術を簡単に利用してもらうための重要な“オープン・スタンダード”である。今後，Parlay Xの普及が進み，多くのITベンダーがコミュニケーション基盤として通信機能を利用するようになり，たくさんのビジネスが生み出されるプラットフォームになることを期待したい。
ITの世界ではWeb2.0という言葉があるように，インターネットが巨大な情報プラットフォームとして認識されるようになってきた。SOAとWeb2.0の融合は，柔軟で迅速なビジネスサポート・システムの構築を可能とするだろう。
その接点として，Webサービスは重要な役割を担っていく。とりわけ，コミュニケーション基盤のオープンスタンダードとして，Parlay Xには大きな期待がかかる。
|
