電気通信大学

(1)

分野横断アプリケーション統合に向けた Web サービスのプリミティブ化に関する研究

佐々木靖彦

電気通信大学

２００７年３月

(2)

分野横断アプリケーション統合に向けた Web サービスのプリミティブ化に関する研究

博士論文審査委員

主査多田好克教授

委員村山隆彦助教授

委員田野俊一教授

委員渡辺俊典教授

委員本多弘樹助教授

委員吉永努助教授

(3)

著作権所有者佐々木靖彦

２００７

(4)

A Study on Web Service Primitive Technology Aiming for Application Integration over

Broad Industry Fields.

Yasuhiko Sasaki Abstract

A high-performance web service engine (primitive) suitable for resource-constrained computers has been proposed. The engine has been developed for the use of web services in broad industry fields such as plant operations, environmental measurements, and automobile controls.

The proposed engine features the hardware-mapped

hierarchical Aho-Corasick machine (H-ACM) and programmable

hierarchical Aho-Corasick machine (PH-ACM). Based on the

simulation results, the proposed approach, H-ACM and PH-ACM,

demonstrated a large speed up compared to the conventional

software approach on processing messages using SOAP, XML, and

HTTP. Also the system expansion for PH-ACM has become

possible by using only the web service interface, SOAP. The

expansion can be performed in a very short time less than 10 ms

for a sample plant monitoring system.

(5)

The engine was implemented on a FPGA (Field Programmable

Gate Array) board that was assumed to be used in a plant

monitoring system. The advantages of the engine with respect

to the small gate size, the low power consumption, and the small

on-chip area were confirmed through the evaluation of the

implementation.

(6)

分野横断アプリケーション統合に向けた Web サービスのプリミティブ化に関する研究

佐々木靖彦

概要

Webサービスは，XML（eXtensible Markup Language）をベースとした拡張性の高さや，SOAP（Simple Object Access Protocol）をはじめとする

W3C(WWW consortium)規定の仕様準拠による標準性の高さを特徴として，次

世代サービス統合技術（SOA: Service Oriented Architecture）の中核技術として注目されている．しかしながら，その利用範囲は，情報・ソリューション分野を中心とした高性能なサーバ等をベースとしたビジネスシステムに留まってきた．

そこで本研究では，Webサービスを，上記のような限定された分野に留まらず，産業プラント，環境計測，自動車といった，より広い分野へ展開していくことを可能とすることを目的として，多様な分野で用いられる超小型のコンピュータシステムに対しても活用可能とする“Web サービスのプリミティブ化”

に関する技術提案を行う．すなわち，本技術は，性能やリソースが著しく制限されたコンピュータ群を使っても，XMLやSOAPなどを用いたメッセージを高速に処理することを可能とする基盤技術である．

本研究では，まず最初に，Webサービスのプリミティブ化を実現する上での主たる問題点を明らかにするために，比較的リソースが限定された組込みボー

(7)

ド上に既存の技術（汎用CPU上のソフトウェア処理）を用いて Webサービス単独の機能を実装する．そして，この実装における処理量やメモリ使用量等の定量的な解析を行う．その結果として，Web サービス処理は，超小型コンピュータにおいては相当に負荷が大きく，実用的でないこと示す．特に，このような問題は，Web サービス特有のテキストレベルでのプロトコル処理がボトルネックとなって生じていることを明らかにする．

次に，上記の問題点を解決するために，超小型のコンピュータを対象とした Web サービスの高速処理エンジンを提案する．これは，オンチップのハードウェアとして実装される“階層型Aho-Corasickマシン”と呼ぶ専用モジュールであり，テキストレベルでのプロトコル処理を効率的に処理する．同モジュールは，テキストレベルでのプロトコル処理において，従来のWebサービスの一般的な処理方法であるソフトウェア実装に比べて，２桁以上の高速化を達成することが可能となる．また,本処理エンジンは，必要な論理ゲート規模が90Kゲート以下と著しく小さいため，オンチップの占有面積，消費電力についても，90nm プロセスの条件で，それぞれ，600 µm角，1mW程度となり，従来方式に比べて大きく削減することが可能となる．

さらに，上述のハードウェアモジュールに対して，ネットワークを介して外部から機能拡張ができるような仕組みを付加した“プログラマブル階層型

Aho-Corasickマシン”を提案する．これは，ハードウェア化により場合によっ

ては欠点ともなりうる“システム拡張の困難さ”を解決するための技術である．

本来のサービス処理を行う階層型Aho-Corasickマシンとは独立に，機能拡張メッセージ処理専用の階層型Aho-Corasickマシンを用意することで，完全にWeb サービスのメッセージルールに準拠した上でシステム拡張が行えるという利点をもたらす．

最後に，提案技術の応用例として，仮想プラント計測システムに対してFPGA

（Field Programmable Gate Array）を用いた実装を行った結果を示す．8-bit

(8)

級以下で動作周波数も数十MHz以下の超小型コンピュータと組み合わせて，高速にWebサービス処理が行えることを示し，本提案技術の有効性を確認する．

(9)

第 1 章序章

１．１はじめに

Webサービス[1]は，XML（eXtensible Markup Language）[2]，SOAP（Simple Object Access Protocol）[3,4]，WSDL （Web Services Description Language） [5]といった要素技術をベースとして，ネットワーク上に分散する様々なサービスの統合を可能とする技術として注目されてきた．これは，各要素技術が持つ高い柔軟性（XMLによる任意タグやWSDLによるインタフェース定義）や高い標準性（W3C¹規定のSOAPによるエンベロープやスキーマ）を活用することにより，組織の壁を超えたオープンな次世代サービス統合技術（SOA: Service Oriented Architecture）として，新しい応用を生み出す可能性があるからである．

このようなWebサービスであるが，これは従来から使われてきた一般のWeb アプリケーションとは大きく異なる特徴を持つ．従来から使われてきたWebアプリケーションは，HTMLをデータのフォーマットとして利用する．しかし，

HTMLフォーマットは情報を見ることを目的に開発されたものであり，データ

messages with SOAP on XML

サービス利用者サービス

提供者登録

発見検索

利用 UDDI WSDL messages with

SOAP on XML

サービス利用者サービス

提供者登録

発見検索

利用 UDDI WSDL

図１.１ Webサービス

1 World Wide Web Consortium（W3C）は，Webの長期的な発展のために，Web技術に関わるプロトコルやガイドラインを制定し標準化を行う公的な国際組織である．

(13)

を明確な構造とともに受け渡しすることを不得手としていた．さらに，HTML を利用する情報システムは，ブラウザの利用をベースとしたものであり，基本的に人間が情報を理解して利用することが前提となっていた．その結果，マシン（プログラム）同士での情報のやりとりを苦手とし，広い範囲の機能統合を自動で行わせるといった応用には向いていなかった．

これに対しWebサービスは，XMLをベースとしたSOAPを用いることで，コンピュータ同士がメッセージの交換を行うことができるようにされた仕組みであり，W3Cにより標準化されたものである．構造化されたデータの受け渡しが行えるだけでなく，ブラウザも不要であるため，人間を介さないマシン間での高い情報交換能力を備えることが特徴である．また，Webサービスでは，データのエンコーディング方法のみを規定しておりプラットフォームは問わないため，オープンなシステム開発にも有効である²．XMLやWSDLといった技術によって，構築者の都合に合わせてデータの構造やタグを決定できるため，柔軟性のあるシステム設計が行えることも大きな魅力である．

さらに，Webサービスでは，サービスを登録したり検索したりすることを容易にするために，UDDI（Universal Description, Discovery and Integration） [6]と呼ばれる仕組みが設けられている．UDDIは，どのようなWebサービスがどこに存在するかといったことを示すものであり，各サービスのWSDLが登録されている．すなわち，いわゆるイエローページと同様のディレクトリ・サービスに相当する．このような仕組みを利用すれば，同等の機能を有するサービスを，目的や状況に応じて使い分けるといったことが可能となる．

以上に示したような複数の利点によって，Webサービスは，広範囲のシステム連携を可能とする基盤技術として活用することが期待されるようになってい

2 Webサービスは，従来の分散処理アーキテクチャであるCORBA(Common Object Request Broker Architecture)やDCOM(Distributed Common Object Model)に対して，プラットフォーム非依存性やファイアウォール透過性を高めた，より先進性の高い分散アーキテクチャと言える．

(14)

る．しかしながら，Web サービス技術の現状を捉えると，実際には当初期待されたほど普及している状況にはない．例えば，UDDI へのサービス登録数は頭打ち状態にあり，事実上うまく機能しているとは言えない[7]．また，応用事例を見ても，技術提案当初からの定型的かつ固定的な例が多く，やはり技術の普及がうまく進んでいないことを示している．

このような状況の中，Webサービスに関わる技術を従来以上に活用していくためには，新しい展開を検討する必要がある．そうした検討には多様なアプローチが考えられるが，その中でも我々は特に，サービスの粒度に着目したアプローチを検討している．すなわち，提供するサービスの粒度を従来よりも著しく細かくするような基盤技術として，Web サービスのプリミティブ化を検討している．

従来のようにサービスの粒度が大きいと，現在すでに存在しているサービスに対し，インタフェースだけをWebサービスに準拠させることで活用できるというメリットがある．既にビジネスアプリケーションとして蓄積されてきたサービス群を，比較的短い時間でまとめあげるといった場合には都合がよい．実際，情報ソリューション分野（あるいは，IT 分野）を中心として，そのような実装例が多く存在する[8-11]．

その一方で，サービスインテグレータにとって，組み合わせて利用できるサービスの数が限定的となりがちで，かつ統合後のコストが上昇しがちであるという問題がある．本技術は，このような問題を解決しようとするものである．

すなわち，サービス粒度を細かくすることで，インテグレータにとって冗長性が低いサービスだけを低コストに組み合わせることを可能とする．その結果，

採算性の高い統合サービスを提供しやすくなる．

このような状況は，Webサービス技術において頻繁に引き合いに出されるような旅行業務の統合といったような粒度の大きいアプリケーションの統合とは大きく異なるものである．これは，従来の情報・ソリューション分野における

(15)

WS

（宿予約）

WS

（飛行機予約）

WS

（課金）

AS

ｸﾗｲｱﾝﾄ

SOAP

UDDI SOAP

SOAP: simple object access protocol, AS: application server, WS: web service

車内外制御ユニット環境計測

Ｃ

ＣＣ

Ｃ

PC ｻｰﾊﾞ

従来のWebサービス

新しいWebサービス

C: small/embedded computers

ＣＣ

SOAP SOAP

産業プラント

WS

（宿予約）

WS

（飛行機予約）

WS

（課金）

AS

ｸﾗｲｱﾝﾄ

SOAP

UDDI SOAP

SOAP: simple object access protocol, AS: application server, WS: web service

車内外制御ユニット環境計測

Ｃ

ＣＣ

Ｃ

PC ｻｰﾊﾞ

従来のWebサービス

新しいWebサービス

C: small/embedded computers

ＣＣ

SOAP SOAP

産業プラント

図１.２ Web サービスのプリミティブ化とそれに伴うサービス統合形態の変化

Webサービス技術に留まらず，産業プラント，環境計測，自動車，ビルオートメーション，ホームセキュリティ，ヘルスケア，デジタル家電，物流，防災，

ロボットといった分野におけるアプリケーション（以下，フィールドアプリケーションと呼ぶ）に対しても横断的に関わるWebサービス技術として展開可能となることを意味する（図１.２）．従来，フィールドアプリケーションにおいては，各分野ごとの独自の低レベルのインタフェースが使われてきたために，分野を超えてサービスが協調するといったことは困難であった³．しかし，Webサービスという共通のメッセージインタフェースが利用できるようになれば，従

3 例えば，産業プラントの分野ではPROFIBUS，DeviceNet，MODBUS等，多くの種類のフィールドバスが利用されている．また，車内ネットワークではパワートレイン系，ボディ系，セーフティ系，情報メディア系のそれぞれにおいてCAN，FlexRay，LIN，MOST，

IDB1394といった様々なインタフェースが利用されている．また，ビルオートメーション

では，LonWorks，BACnetなどが利用されている．このように，種類の異なるネットワークに接続される機器の上では，Webサービスなどのより高位の共通データ転送方式なくしてアプリケーションが横断的に協調動作することは非常に困難である．

(16)

来は不可能であった分野横断的なサービス統合が可能になる⁴．

さらに，本技術の狙いの一つには，上述したような粒度の細かいサービス群が従来はクローズドな形で提供される傾向があった状況を変化させることもある．例えば，現在では，産業プラント内にあるような特定の目的のシステムは，

単一の事業者により構築されるといった傾向がある．これは，専用システムとして一定の性能基準を満たすために冗長性の低い実装を余儀なくされるからである．もし，このようなシステムに対してWebサービスを適用しようとしても，

既存の技術では性能面で満足のいくものが作れないこととなる．従って，Web サービスを産業プラント，環境計測，自動車といった分野に対しても利用するという考えは現実的でなくなる．

しかし本来は，現在の情報・ソリューション分野におけるシステム構築で見られるようにオープン化が進むことによって，複数の事業主体が提供する要素部品を最適に組み合わせることより，低いコストでシステム構築が行えるようになる可能性がある．例えば，産業プラント内のシステムが複数の部品より構成されるといった場合，その各要素部品ごとに性能やコストなどにおいて優れたベンダ（部品提供者）は異なることが一般的である．従来はこのような細かい部品ごとの最適ベンダを活用してシステムを組み上げるといったことは困難であった．しかし，それらの部品が全てWebサービスというオープンなインタフェースを（十分な性能とともに）備えることができるようになれば，もはや特定の事業主体が提供する包括的なシステムに頼る必要はなく，真に最適なものを組み合わせるといったことが行えるようになる．

本研究は，オープンなシステム構築において実績のあるWebサービスという技術を，従来はクローズドなシステム開発が当たり前であった分野にまで浸透させた上で，サービス間の連携を可能とすることを狙うものでもある．このよ

4 多様な分野に浸透したサービス間の連携を意味するため，我々はこれをPervasive Syndicationと呼んでいる．

(17)

うな状況では，もはや単一の事業主体の創造性だけに依存する必要はなくなり，

多数かつ多様な第三者的サービスインテグレータの創造性を活用して，より新しい統合アプリケーションが開発されることを期待できるようになる．

さて，Webサービスのプリミティブ化にとって，まず最初に解決しなければならないことは，処理性能の低いコンピュータを用いてもWebサービスのテクノロジを利用できるようにすることである．これは，現在のWebサービスで利用されているようなサーバやPCのように数GHzの周波数で動作するCPUやマルチプロセッサのような高性能なコンピュータではなく，それらより２桁以上も低いの性能のコンピュータであっても，SOAPやXMLといった技術を用いてサービスの提供が行えるようにすることを意味する⁵．

本研究では，まず，このようなWebサービスのプリミティブ化を実現しようとする際に，何が問題となり，今後何を開発する必要があるかについて分析を行う．次に，その結果を踏まえて，現状の技術が有する問題点を解決することが可能な，新しいアーキテクチャに基づくテキストレベルメッセージの高速処理エンジンを提案する．これは，ハードウェア階層型Aho-Corasickマシンとその拡張版であるプログラマブル階層型 Aho-Corasick マシンという２つの方式に基づく処理エンジンである．最後に，提案技術をプラント計測を想定した仮想システムに適用し，その有効性を確認する．

１．２本論文の構成

本論文は，以下のように構成される．

第２章では，Webサービス技術の構成要素について階層的に整理し，各階層

5 近年，グリッドコンピューティングの世界においてもWebサービスをRPCとして利用するものが見られる．OGSA(Open Grid Service Architecture)がそのような例である．こういった応用においても，なお，利用されるコンピュータは非常に性能が高く，リソースも十分に大きなものが中心である．本研究は，これらとは異なり，非常に性能が低く，リソース制限が厳しいコンピュータで，Webサービスを利用するというところに特徴がある．

(18)

での主要処理についてレビューする．そして，現在の既存技術を組み合わせることで実現可能な，比較的コストを低く抑えたWebサービスについて，実装および評価した結果について考察する．さらに，これらの評価結果をもとに，現状のWebサービス技術が有する主要な問題点についてまとめる．

第３章では，第２章で明らかとした問題点を解決するために，特に重要となるテキストレベルのメッセージ処理を高速化する方法について述べる．まず，

Web サービス技術の処理上の課題について説明し，これに対する本研究のアプローチを概説する．次に，具体的な高速化手法として，リソース制約の厳しいハードウェアにマッピング可能な階層型 Aho-Corasick マシンを用いた方法を提案し，その基本構造と最適化の方法などについて示す．特に，階層型の構造を持つハードウェアを用いる点や，複数の最適化の種類とそれぞれの効果について詳説する．さらに，上述の提案方法を実装した場合の結果を，高位のシミュレータにより評価した結果について示す．最後に，評価結果から得られる結論についてまとめる．

第４章では，第３章で提案した技術が持つ限界，すなわちシステム変更/システム拡張能力の問題を解決するための方法について述べる．新しいアーキテクチャに基づくハードウェアを導入することで，性能や電力といった面での従来技術に対する大きな優位性を得られる反面，いったんインタフェース仕様を決定した後の変更は難しくなる．そこで本研究では，このような問題を解決するために，第３章で述べたアーキテクチャを最大限に活用しつつも，そのインタフェース仕様をシステム製造後でも変更可能とする技術として，プログラマブ

ル階層型Aho-Corasickマシンを提案する．ここでは，その基本構造と，プログ

ラマブル化に関係する各種の特性について評価する．

(19)

第５章では，階層型Aho-Corasickマシンをシステム適用した結果について考察する．プラントモニタリング用のデータ収集システムを想定し，SOAP メッセージをやりとりする超小型ノードの開発を行った．ここでは，8bit 級で動作周波数が数十 MHz以下の CPU と組み合わせることが可能な Webサービスプリミティブエンジンの実装を行った．提案技術は，本来，ASIC(Application Specific Integrated Circuit)やSoC(System on Chip)といった形で半導体チップ上に実装されるものであるが，その機能的な検証を行うために，実際にチップ作成をしなくてもほぼ同様の機能が実現できる FPGA(Field Programmable

Gate Array)を用いて実装を行い，諸特性について評価を行った．その結果，本

技術が従来の技術に比べて性能や電力など複数の項目に関して，大きな改善が見られることを確認した．

第６章では，結論として， Webサービスのプリミティブ化について明らかとなった問題点や，それらを解決するために開発した技術およびその評価の結果についてまとめる．

参考文献

[1] http://www.w3.org/2002/ws/

[2] World Wide Web Consortium, “Extensible Markup Language (XML) 1.0 (Third Edition),” http://www.w3.org/TR/2004/REC-xml-20040204/, 2004.

[3] World Wide Web Consortium, “Simple Object Access Protocol (SOAP) 1.1,”

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, 2000.

[4] K. Scribner and Mark C. Stiver, “Understanding SOAP: The authoritative solution,”

Pearson Education 2001, 邦訳 “SOAP 技術入門 Simple Object Access Protocol の概念，活用技法，可能性”，ピアソンエデュケーションジャパン，2001.

(20)

[5] World Wide Web Consortium, “Web Services Description Language (WSDL) Version 2.0,” http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327/

wsdl20-primer.txt, 2006 [6] http://www.uddi.org/

[7] GMO 総合研究所，“Web サービス最新動向調査”，シードプラニング編，2003．

[8] 村山隆彦, 藤崎恵美子, 由良俊介, 畑島隆, 簗栄司, 唐沢裕明, 加藤順,

“Web サービス技術によるファンクラブサービス構築の試み”，電子情報通信学会総合大会, D17-7, 2003．

[9] 松山憲和，大場みち子，“道路交通情報サービスを使った複合 Web サービス実証実験”，情報処理学会，デジタル・ドキュメント研究会，研究報告 DD51-6，

2005．

[10] http://www.google.com/

[11] http://www.amazon.com/

(21)

第 2 章 Web サービスと既存技術による実装

本章では，Webサービスのプリミティブ化を行うにあたり生じる問題点を明らかにする．このような目的のため，まずWebサービスを構成する複数の技術を個別にレビューする．その後，既存技術を組み合わせてWebサービスの実行環境を作成し，その評価結果をもとにプリミティブ化に対して問題となる項目を明らかにする．

２．１ Webサービスを実現する技術階層２．１．１３大階層

Webサービスは，多くの技術を階層的に積み上げることにより実現される（図２.１）．これらの階層は，その処理の特徴から，大きく３つの階層として括ることが可能である．すなわち，（１）Web サービス階層，（２）通信プロトコル階層，（３）物理階層である．Webサービスのプリミティブ化を検討するにあたっては，これらの階層のどの部分が性能やリソースの観点から問題となるかについて明確にする必要がある．そして，その結果に基づき，問題の大きい部分から順に対処していくのが望ましい．

さて，３大階層を，上位のレベルから順におおまかに記述すると，以下のように説明できる．なお，具体例については，情報・ソリューション分野における場合を中心に説明しているが，これに限定されるものではない．

（１）Webサービス階層： Webサービスに関係の深い機能を実現するために必要となる部分である．具体的には，SOAP 処理，XML 処理，HTTP 処理[1]

などがこれに該当する．

（２）通信プロトコル階層：汎用的な通信上のプロトコルを定義している部分である．具体的には，IP/ICMP，TCP/UDP，Socket などがこの階層に該当する．

(22)

Webサービス階層（テキストレベルメッセージ処理）

通信プロトコル階層物理階層

Phy API(socket)

到達確認と再送、フロー制御、アージェント処理ルーティング、エラー制御、チェックサム計算

ドキュメントのリクエスト・レスポンス処理

信号伝送、活性化制御、送信パワー制御エンベロープ処理、エンコーディング処理 WSDL, WS-Reliability

API提供

サービス定義、上位層信頼性確保

XMLパージング、ツリー作成

Link Network(IP) Transport(TCP)

HTTP XML SOAP

Webサービス階層（テキストレベルメッセージ処理）

通信プロトコル階層物理階層

Phy API(socket)

到達確認と再送、フロー制御、アージェント処理ルーティング、エラー制御、チェックサム計算

ドキュメントのリクエスト・レスポンス処理

信号伝送、活性化制御、送信パワー制御エンベロープ処理、エンコーディング処理 WSDL, WS-Reliability

API提供

サービス定義、上位層信頼性確保

XMLパージング、ツリー作成

Link Network(IP) Transport(TCP)

HTTP XML SOAP

図２.１ Web サービスを実現するための技術階層

（３）物理階層：有線や無線の各種の信号伝送媒体に直接的に関連する部分である．例えば，Ethernetのリンク層，ファイ層などが含まれる．

２．１．２サブ階層

次に，３大階層の各階層における処理の詳細を示す．図２.１には，各階層の処理概要についても示してある．

２．１．２．１ Webサービス階層

WSDL 処理，SOAP 処理，XML処理，HTTP処理などが含まれる．中心となるのは，SOAP処理，XML処理，HTTP処理である．全ての処理について共通に言えることは，いずれも扱っているデータはテキストデータであるということである．HTTP 処理では，サーバに送られてきたメッセージのヘッダの内

(23)

容に従い情報の取得や返送を行う．XML処理では，タグの解析を行いドキュメントの構造を決定する．SOAP 処理では，エンベロープ処理，エンコーディング処理を行う．また，WSDL 処理では，サービス定義の読み込み，プロトコルバインディング，ネットワークバインディングなどを行う．

２．１．２．２通信プロトコル階層

一般の情報・ソリューション分野におけるビジネス応用では，IP/ICMP層，

TCP/UDP層，Socket層がこれに対応する．各層における処理の詳細は多数の文

献[例えば，2]に記載されているため省略するが，主たる処理はルーティング，

到達確認と再送処理，フロー制御，チェックサム計算，上位APIの提供などである．通信プロトコル階層はアプリケーションにより大きく変化する可能性がある．特に，情報・ソリューション以外の分野では，物理階層においてEthernet 以外の通信が利用されることも多く，それに応じて通信プロトコル層の方式も変わることが多い⁶．その場合，処理内容によっては，Webサービス階層との間での最適な振り分けも考慮する必要がある．例えば，信頼性の確保などは，通信プロトコル階層で行うに限らず，より上位層で取り扱うアプローチも有り得る．このような場合，SOAPヘッダを活用したWS-Reliability [3]などを利用することが考えられる．

２．１．２．３物理階層

有線方式ではEthernetをはじめ，RS232C，CAN，SPI，I2C，USB，IEEE1394 など，また無線方式では，IEEE802.11系, IEEE802.15系，微弱無線，特定小電力無線，Bluetoothなど多様な方式が存在する．この階層では，物理的な信号

6 例えば，プラント応用では，産業用Ethernetの利用が始まりつつあるが，それ以外にも PROFIBUS，DeviceNet，MODBUS等多くの方式がフィールドバスとして存在している．

これらは，IEC61158として標準化が行われているが，統合的というより既存のものの集合的な位置づけである．

(24)

伝送はもとより，活性化制御や送信パワー制御などが含まれる．

２．２一般的なWebサービスにおける課題

情報・ソリューション分野で広く利用されているコンピュータ上では，Web サービスの機能（すなわち，上述のテクノロジスタック）を実行させることは比較的問題なく実現できた．その背景には，数GHzのプロセッサや容量の大きいメモリなどを装備したコンピュータを用いることができるという前提がある．

Web サービスの実装で広く使われる JAX-RPC[4]や.NET[5]などのフレームワーク上のソフトウェアは，当然ながら上記のようなリソースを十分に備えたコンピュータ上での動作を前提として作られている．

一方，Webサービスを，先に述べたような広い分野のアプリケーションに適用しようとすると，高性能かつ大容量のメモリといった，十分なリソースを有するコンピュータの使用は必ずしも当然の前提条件として規定できなくなる．

特に，各種の産業プラント応用や環境計測応用などを考えた場合には，搭載できるコンピュータの性能やメモリなどは，現在のWebサービスが利用されているコンピュータにおけるものよりも２桁〜３桁も小さいものを想定する必要が生じる．そこで，本章では，そもそも適用が難しいJAX-RPCや.NET等のフレームワークではなく，リソース制約が幾分厳しい状況でも動作させることが可能な環境を実装し，その評価を行った．

２．３既存技術を用いたWebサービスの実装と評価

Webサービスのプリミティブ化を実現する上で，何が問題となるかを整理するために，現在のWebサービスを極力コンピュータリソースが限定された組込みボード上に実装して，評価を行った．

評価に先立って，組込みボード上にWebサービスの機能である３大階層の処理を実装した．表２.１にその構成を示す．本研究の目的は，Webサービスに関

(25)

表２.１ベースシステムの構成

CPU/RAM(server) SH4(240MHz)/32MB

OS CELinux (2.4.20)

HTTP 独自実装

XML XML::Parser (expat*)

SOAP 独自実装

ネットワーク TCP/IP, Ethernet, 10Mbps 参考：client

CPU/RAM

Pentium4(2.99GHz)/1GB

*expatはJames Clarkによる高速XMLパーサモジュール

するプリミティブ化を検討することであるから，大量のリソース（メモリやCPU 性能等）を前提としたHTTPサーバ（Apache等）や各種Webサービスを備えたフレームワーク（JAX-RPC，.NET 等）は利用できない．したがって，上記実装においては多くの部分で独自実装を行い，極力少ないリソースで動作するように工夫したものを用いている．例えば，従来の方式で見られるようなHTTP サーバから外部プログラム（XML処理，SOAP処理）を起動する際に生じる処理時間の増加や，別プログラムによるコードサイズの増加といった問題が起こらないようにした．すなわち，一般に用いられているようなHTTP処理とXML 処理やSOAP処理が別プログラムとなっている構成ではなく，HTTP処理から SOAP処理までの階層を一体化されたプログラムとして構成した．

２.３.１評価の概要

評価は，３つの項目に対して行った．すなわち，１）処理性能，２）メモリ使用量，３）通信量の３つである．処理性能の評価では，Web サービスを実行

(26)

図２.２ Web サービスのベースシステム

させた上で，これに対しプロファイラを用いたボトルネック解析を行った．メモリ使用量に関しては，Webサービスのプログラム実行中にpsコマンドを発行して，動作中の複数のタイミングでのメモリ使用量を測定した．また通信量に関しては，WebサービスをSOAPメッセージに載せて転送する場合のデータ量の肥大化について評価した．

２.３.２処理性能に関する評価２.３.２.１評価対象と方法

使用したRemote Procedure Call（RPC）は，最もプリミティブなWebサービスの処理時間（Web サービスの下限値としての処理時間）を知るために，単一のストリング型パラメータを受け取り，単一の実数データを返送するという最小限の構成のものを用いた（付録１）．ここでは，Webサービスの機能提供だけに着目した評価を行うために，実アプリケーションでは存在する各種の内部サービスとしては何も処理を行わず，予め用意された規定値を返すだけの実装

(27)

を評価した．

評価は，PCと組込みボードとをネットワーク接続し，クライアント側（PC）

からRPCを行い，サーバ側（組込みボード）の実行性能を計測した（図２．２）．計測では，Web サービスプログラムを走らせたマシン上でプロファイラを使って機能別の処理時間の比率を測定した．

実装した各処理の概要は以下のとおりである．

１）HTTP 処理：リクエストメッセージのサイズ分を読み込んだ後，リクエストヘッダを分離し，ボディ部をXML::Parserに渡す

２）XML 処理： XML::Parser は XML ドキュメントのパージングを行い SOAP処理へと結果を渡す

３）SOAP処理： SOAPのRPCメッセージを解釈した後，それに応答する適切なSOAPレスポンスを返信する

通信プロトコル階層以下の処理については，半導体チップと OS に搭載されている機能を利用した．また，計測にあたっては，ネットワークの状態などによるばらつきを抑え，またシステム起動時の準備時間を含めないようにするために，1000回のRPCを行い平均時間を取得した．

２.３.２.２評価結果と考察

計測結果を図２.３に示す．同図は，単一クライアントからのアクセスの場合を示したものである．計測結果の表の上位を占めているのは，HTTP処理，XML 処理，SOAP 処理であることがわかる．すなわち，３大階層の中で処理時間を大きく占めているのは，Web サービス階層である．通信プロトコル階層以下の処理時間は相対的に小さく，あまり問題とはならない．例えば，socket による socket/bind/listenなどの前準備（prepare_socketという関数になっている）は

(28)

User+System Time = 60.35653 Seconds Exclusive Times

%Time ExclSec Name

8.13 4.905 CHTTPProcessor::read_and_respond 5.69 3.435 XML::Parser::parse

5.25 3.167 XML::Parser::Expat::ParseString 5.24 3.161 CServer::check_open_connection 4.48 2.703 XML::Parser::Expat::setHandlers 4.08 2.465 XML::Parser::Tree::Start 3.97 2.396 CServer::open_new_connection

3.61 2.177 CHTTPProcessor::analyzeRequestHeaderFields 3.60 2.172 CServer::clean_connection

3.30 1.994 CXMLSoapProcessor::process_SOAP_RPC 3.03 1.826 CXMLSoapProcessor::BEGIN

2.87 1.733 CHTTPProcessor::analyzeHeaderFields 2.76 1.667 CServer::recv_socket

2.62 1.581 CXMLSoapProcessor::process_SOAP_Body 2.54 1.531 CXMLSoapProcessor::process_SOAP

② ③

①

②全処理時間に占める該当処理の比率

③該当処理の絶対時間

①全処理時間（RPC1000回）

④HTTP文書のヘッダ、ボディ分離。ボディサイズ分の読み込み。リクエストラインの分離

⑤XML文書のパージング。ドキュメントツリーの作成

⑥開いているコネクションのチェック

⑦新しい接続要求に対して、acceptしてからHTTP処理オブジェクト（CHTTPProcessor）を生成

⑧HTTPリクエストラインの中のメソッド、URI、バージョンの分離

⑨RPCの終了したHTTP処理オブジェクトを消滅、コネクションクローズ

⑩SOAPのRPC処理。RPCパラメータの分離と処理結果のタグ生成

⑪SOAPとXMLの処理オブジェクトの初期化

⑫HTTPのヘッダフィールドの予約語チェック

⑬socket受信処理

⑭RPCメソッド名の取得、レスポンセスタグの生成

⑮SOAPｴﾝﾍﾞﾛｰﾌﾟ切出し、名前空間/ｴﾝｺﾃﾞｨﾝｸﾞの切出し

④

⑤

⑥

⑤

⑦

⑧

⑨

⑩

⑪

⑫

⑬

⑭

⑮ User+System Time = 60.35653 Seconds

Exclusive Times

%Time ExclSec Name

8.13 4.905 CHTTPProcessor::read_and_respond 5.69 3.435 XML::Parser::parse

5.25 3.167 XML::Parser::Expat::ParseString 5.24 3.161 CServer::check_open_connection 4.48 2.703 XML::Parser::Expat::setHandlers 4.08 2.465 XML::Parser::Tree::Start 3.97 2.396 CServer::open_new_connection

3.61 2.177 CHTTPProcessor::analyzeRequestHeaderFields 3.60 2.172 CServer::clean_connection

3.30 1.994 CXMLSoapProcessor::process_SOAP_RPC 3.03 1.826 CXMLSoapProcessor::BEGIN

2.87 1.733 CHTTPProcessor::analyzeHeaderFields 2.76 1.667 CServer::recv_socket

2.62 1.581 CXMLSoapProcessor::process_SOAP_Body 2.54 1.531 CXMLSoapProcessor::process_SOAP

② ③

①

④HTTP文書のヘッダ、ボディ分離。ボディサイズ分の読み込み。リクエストラインの分離

⑤XML文書のパージング。ドキュメントツリーの作成

⑥開いているコネクションのチェック

⑦新しい接続要求に対して、acceptしてからHTTP処理オブジェクト（CHTTPProcessor）を生成

⑧HTTPリクエストラインの中のメソッド、URI、バージョンの分離

⑨RPCの終了したHTTP処理オブジェクトを消滅、コネクションクローズ

⑩SOAPのRPC処理。RPCパラメータの分離と処理結果のタグ生成

⑪SOAPとXMLの処理オブジェクトの初期化

⑫HTTPのヘッダフィールドの予約語チェック

⑬socket受信処理

⑭RPCメソッド名の取得、レスポンセスタグの生成

⑮SOAPｴﾝﾍﾞﾛｰﾌﾟ切出し、名前空間/ｴﾝｺﾃﾞｨﾝｸﾞの切出し

④

⑤

⑥

⑤

⑦

⑧

⑨

⑩

⑪

⑫

⑬

⑭

⑮

図２.３ Webサービス実行処理のプロファイル

リストに登場せず，またrecv/send処理も3%以下である．

図２.４は，３大階層のそれぞれについて，その処理比率を示したものである．

Web サービス階層の処理が９割近くを占めていることがわかる．特に，リクエストメッセージの解析処理，すなわち，各種のテキストレベルのメッセージ処理（HTTP，XML，SOAPの解析）が，大きな負荷を占めていることがわかる．

(29)

0%

50%

100%

処理比率

通信プロトコル階層及び物理階層

Webサービス階層 WSリクエスト系

SOAP XML HTTP の解析 WSレスポンス系

通信系

0%

50%

100%

処理比率

通信プロトコル階層及び物理階層

Webサービス階層 WSリクエスト系

SOAP XML HTTP の解析 WSレスポンス系

通信系

図２.４ Webサービス処理の処理負荷構成

図２.５に，クライアント数を増加させた場合のサーバでの処理時間の変化示す．通信プロトコル階層の処理時間の増加はあるものの，その変化量は５％程度でありさほど大きくないため，Web サービス階層で処理時間の大きな比率を占めるという状況は変化しない．

処理時間の絶対値で見ると，１回あたりのサービス時間は約60m秒であることがわかる．組込み用CPUとしては比較的性能が良いもの（240MHz動作）であっても，大きな時間がかかっていることがわかる．先に記したように，現在は単一パラメータのSOAP-RPC 処理のみだが，より複雑なRPCの場合を想定すると，処理時間は一層増加することが予想される．また，メモリの必要量に関しては次節に述べるが，そこで示されるような大きな容量のメモリを確保できない場合には，データスワップなどにより処理時間はさらに大きくなると考えられる．

(30)

50 55 60 65 70

0 1 2 3 4 5 6 7 8 クライアント数

実行時間（mSec）

9 50

55 60 65 70

0 1 2 3 4 5 6 7 8 クライアント数

実行時間（mSec）

9

図２.５クライアント数の増加に対する処理時間の変化

本研究が対象とする応用を考えた場合，上記の実装で用いたシステムより２桁〜３桁性能が低いコンピュータでWebサービスを実現しようとすれば，数百ミリ秒〜数１０秒という大きな時間を要してしまう．ノード本来のサービス処理を含めないWebサービスのためだけにかかる時間としては非常に大きく，実用に際して大きな障害となる．

２.３.３メモリ使用量に関する評価２.３.３.１評価対象と方法

メモリ使用量に関する分析の目的は，既存技術を用いて最低限のWebサービス機能を実行しようとする場合に，どの程度の容量のメモリを必要とするかの知見を得ることにある．現在のWebサービス提供環境として比較的自然な実装をした上で，できるだけリソースを減らした構成でのメモリ使用量が判断できる．

なお，メモリ使用量の測定に際しての実行条件は，先に性能分析のところで述べたものと同一の条件で行った．

(31)

２.３.３.２評価結果と考察

図２.６にメモリ使用量の計測結果を，時系列の形で示す．なお，socket処理でのバッファサイズは8Kバイトとしてある．

計測結果の要点を以下にまとめる．

１）プログラム起動直後の消費実メモリ量は，約2.5Mバイトである．

２）ネットワーク処理（socket）の準備に必要な実メモリ量は，約1.1Mバイトである．

３）一つのコネクションあたりに必要な実メモリ量は，約0.1Mバイトである４）サービスの提供に必要な総実メモリ量は，約3.7Mバイトである

メモリの必要量という観点で見ると，複数のクライアント（１０アクセス以下）からの接続がある状況でも，およそ 4M バイトがあればよいことになる．

この値は，Web サービスを提供するノード開発時のシステム設計における一つの目安として利用することが可能である．ただし，やはりこのようなメモリ容量は，本研究が狙っているアプリケーションに対しては，コスト的な制約からは搭載することが難しいものである（例えば，8bit 級以下の超小型コンピュータにおいては，最大でも数十Kバイト〜数百Kバイト以下のRAMが一般的である）．

(32)

2.544

3.600 3.604 3.736

0.0 1.0 2.0 3.0 4.0 5.0

ﾌﾟﾛｸﾞﾗﾑ起動直後

socket 準備完了後

ｺﾈｸｼｮﾝ完了後

サービス提供中 (MB)

2.544

3.600 3.604 3.736

0.0 1.0 2.0 3.0 4.0 5.0

ﾌﾟﾛｸﾞﾗﾑ起動直後

socket 準備完了後

ｺﾈｸｼｮﾝ完了後

サービス提供中 (MB)

図２.６メモリ使用量の時間変化

２.３.４通信量に関する評価２.３.４.１評価対象と方法

通信量に関する評価の目的は，データ量がどの程度肥大化するのか，また，3 大階層（さらにはより詳細な階層）のどの部分でデータの肥大化が著しいかについての知見を得ることである．データの肥大化は，複数のノードを持つシステム内でのノード間データ転送に影響を与え，システムの性能や運用性に大きく関係する．したがって，ここでは，その原因を探る．

先の性能/メモリ使用量評価で用いたRPCと同一のSOAPレスポンスメッセージを対象に，データの肥大化を分析した．最上位のSOAP 層から一つずつ降りていく形でデータを積み上げ，最終的にどの程度肥大化するかを調べた．

データの肥大化とは具体的には，SOAP 層，XML 層，HTTP 層まで（Web サービス階層）は，テキストによるドキュメントデータ構造の付加やヘッダの付加である．次に，TCP層，IP層まで（通信プロトコル階層）とLink層（物理階層）では，ヘッダとトレイラが付加されることを意味する．物理階層では，

高速系のインタフェースになどにおいては，実際にはビットスタッフィング，

8B/10B（4B/5B）変換，プリアンブルなどさらにデータ肥大化の要素が加わる

(33)

表２.２各階層におけるデータサイズの増大（単位：bit）

階層ヘッダサイズ

データサイズ

トレイラサイズ

SOAP 3232 128 0

XML 368 3360 648

HTTP 1992 4376 0

TCP 160 6368 0

IP 160 6528 0

Ether 112 6688 32

合計 6832（コア占有率128 / 6832 = 1.9%）

が，これらはここでの見積もりから除外してある．

２.３.４.２評価結果と考察

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

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

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

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

(34)

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サービス階層であることがわかる．

(35)

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 メッセージの運んでいる情報ではないということである．例えば名前空間やエ

(36)

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

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

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

２．４結論

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

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

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

(37)

ことが明らかとなった．また，これら性能における問題の原因は，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.

(38)

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

電気通信大学

分野横断アプリケーション統合に向けた Web サービスのプリミティブ化に関する研究

佐々木靖彦