評価結果と考察

評価結果について表２.２に示す．表２.２では，テキスト数16のデータ（16 桁の数量データ16バイト相当）を送る場合に，各階層別に前節で示したデータ の積み上げを行い，最終的にデータがどの程度肥大化するかを示している．送 ろうとしているデータをコアデータと呼ぶことにすれば，データ数が１の場合，

コアデータの全体データに占める比率はわずか 1.9%に過ぎないことがわかる．

データの肥大化という見方をすれば，約53倍にデータがふくれあがる．

ただし，これは単一データだけをやりとりするRPCであって，最も効率の悪 い場合である．効率の向上を行おうとした場合に，複数のデータをセットの形

0.0 0.2 0.4 0.6 0.8 1.0

0 100 200 300

コアデータ占有率

セット内データ数 0.0

0.2 0.4 0.6 0.8 1.0

0 100 200 300

コアデータ占有率

セット内データ数

図２.７  コアデータ占有率とデータ数の関係）

でまとめてやりとりするケースも想定される．図２.７は，セット内データ数を

1〜256まで増加させたときの様子を示している．先の単一データの場合と比べ

て，データの肥大化率は大きく抑制されている．しかしデータ数が増加するに つれやがて飽和し，最終的に肥大化率は約3倍程度になる．

図２.７においてセット内データの数が小さい部分に着目した場合，データ数 が16以下ではコアデータの占有率は16%以下である．このようなケースは実際 によく利用される領域と考えられるが，これでも 6 倍以上に肥大化することが わかる．

図２.８は階層別に見たときにデータの肥大化がどこで著しく生じているか を示している．単一データレスポンスの場合には，SOAP，XML，HTTP 層で のデータ肥大化が著しい．また，セット内データ数256の場合にはSOAPとXML 層での肥大化が大きいことがわかる．いずれにしても，データ肥大化の原因の ほとんどはWebサービス階層であることがわかる．

0%

20%

40%

60%

80%

100%

単一データ 256データ

Ethernet IP TCP HTTP XML SOAP コアデータ コア

SOAP XML

HTTP

SOAP

XML

0%

20%

40%

60%

80%

100%

単一データ 256データ

Ethernet IP TCP HTTP XML SOAP コアデータ コア

SOAP XML

HTTP

SOAP

XML

図２.８  コアデータ占有率とデータ数の関係

以上をまとめると，次のようになる．

１）  システムを構築した場合にノード間のデータ転送量を削減するために は，できるだけ大きな単位をセットにしたレスポンスメッセージを構成する ことが望ましい．しかし，これでもデータは３倍に肥大化する．

２）  実際の応用で少量のデータでレスポンスメッセージを返送しなければ ならないケースも多々あると考えられるが，その場合にはデータの肥大化率 は6倍から53倍にもおよぶ．

３）  肥大化の主たる原因は Web サービス階層にある．したがってデータの 肥大化を抑制しようとした場合に，最も効果をあげられるのは Web サービ ス階層に対する改善である．

さて，データ肥大化率に関してかなり大きな結果となることを示したが，こ こでは注意も必要である．つまり，コアデータと呼んでいるものだけが SOAP メッセージの運んでいる情報ではないということである．例えば名前空間やエ

ンコーディングなどの情報（スキーマ情報）もSOAP メッセージの中には一緒 に埋め込まれている．つまり，上述の比較は，この情報が欠落しているコアデ ータとの比較を行っているために，このような程度の大きい肥大化として見え ている．また，本例では関係なかったが，SOAP ヘッダを用いる場合には，そ こにはアプリケーション固有の追加情報として，トランザクション情報（リク エスト・レスポンスの対の情報など）やセキュリティ情報なども含まれる．全 く同一条件で比較するには，これらを考慮しなければならない．

しかしながら，プロプライエタリ（クローズド）な専用システムの場合には，

このような名前空間やエンコーディングの情報があらかじめ理解済みとして不 必要である．したがって，このようなプロプライエタリな専用システムとの比 較といった見方をすれば，先の肥大化率の評価結果は妥当なものであると言え る．つまり，クローズドなシステムとも競争できるオープンな統合システムを Webサービスという手段を使って構築しようとすれば，上述の肥大化は大きな 課題であると言える．また，クローズドで短命なシステムと比較して，オーブ ンかつ長命なシステムのメリットは大きいため，データ肥大化率に関する課題 を解決することはやはり重要である⁷．

２．４  結論

Webサービスのプリミティブ化を実現する上での課題を整理するために，そ こで用いられるテクノロジスタックを整理した．さらに，比較的リソースが限 定された組込みボード上にWebサービス単独の機能を実装し，処理性能，メモ リ使用量，通信データ量について定量的な解析を行った．

その結果，処理性能に関しては，本研究の対象とするアプリケーションで利 用される超小型のコンピュータを用いた場合には，実用的な性能が得られない

7 XMLに関して通信されるデータサイズの縮小を含めてバイナリXMLの取り組みもW3C で行われている．ただし，バイナリ化してもデータの構造解析や処理では本質的になんら かの記号の解析が必要になる．

ことが明らかとなった．また，これら性能における問題の原因は，Web サービ ス階層での処理が主たる要因となっていることが明らかとなった．

次に，メモリ使用量に関しては，約 4M バイトの実メモリを下限として動作 可能であることがわかった．しかし，このような容量のメモリを搭載すること は超小型のコンピュータシステムでは難しいため，実装にあたって大きな問題 となることが明らかとなった．

最後に，通信データ量に関しては，一般に肥大化率は3〜50倍におよぶこと が明らかとなった．肥大化率を抑制するためには，できるだけ大きな単位でレ スポンスメッセージを構成することが望ましい．しかし，実際によく利用され ると考えられるセット数16以下の場合では，肥大化率は6倍程度より小さくは できない．データ肥大化に関して階層別に見た場合では，やはりWebサービス 階層での肥大化率が著しいことがわかった．

プリミティブ化に向けた総合的な意味での改善を考えると，処理性能や通信 データ量の観点からもWebサービス階層での対策が最も効果的である．したが って，各種の問題を解決するためには，Web サービス階層での新しい技術開発 が必要であると考えられる．

参考文献

[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Leee,

“Hypertext Transfer Protocol – HTTP 1.1,” RFC2616, W3C/MIT, 1999.

[2] K. Washburn and J. Evans, “TCP/IP: Running a Succesful Network,”

Addison-Wesley Publishing Company, 1993.

[3] OASIS WSRM TC, “WS-Reliability Ver1.1,” http://www.oasis-open.org/

specs/ index.php#wsrv1.1, 2004.

[4] Sun Microsystems, Inc., Java API for XML Processing, (JAXP1.3) specification, 2004.

[5] http://msdn.microsoft.com/XML/