IBM の Kyle Brown 氏は、多くの人たちが「Web サービスおよび XML の不適切な使用によって自ら落とし穴にはまっている」という警告で彼の解説(リンク) を始めている。Kyle 氏は彼の解説の中で一般的な３つの問題点について言及し、なぜそれらが発生するのか、そしていくつかの代替手段について説明している。
メッセージがサーバを飲み込んだ！Kyle 氏は、しばしば Web サービスの開発者が "メモリ不足" エラーあるいは妙な "パフォーマンス問題" に直面し始めると、大抵サーバに極度に高い処理負荷がかかり、低いスループットと大きなネットワーク遅延に加えて CPU の使用率がほぼ 100% 近辺になっているのに気づくと指摘する。この症状の典型的な原因は、時には 50MB あるいはそれ以上という非常に大きなメッセージである。しかも、多くの場合これらの大きなメッセージは XML メッセージの本文の一部として Base64 エンコーディングを使用してエンコードされた非常に大きな埋め込みのバイナリ情報を含んでいる。一般にこれは以下のような場合に起こる。
.... 開発者が技術上の限界を理解していないということです。すなわち XML 処理は多くの問題に対してとても有用ですが、メッセージがパースされるということを自覚しなければなりませんし、そしてほとんどの ... 製品において、それはメッセージの大半あるいは全てがメモリ内に保持されるであろうということを意味します。
Kyle 氏は状況を改善するために以下のような選択肢を推奨している。
- 冗長的な情報は送信しない。バイナリデータを送信する際、多くの場合メッセージは非常に繰り返しが多いことに気がつくでしょう。もしそうであれば、ネットワーク遅延を改善するために HTTP レベルでの圧縮の利用を検討するとよいでしょう。これは処理負荷への助けにはならないでしょうが、問題の１つを軽減するには役立つでしょう。
- バイナリ情報を XML メッセージの本文には一切埋め込まない。これはより良い解決策で、またこれを実現するための方法がいくつか存在します。例えば、代わりに SOAP with Attachments あるいは Message Transmission Optimization Mechanism (MTOM) を利用してパースのオーバーヘッドを回避することができます。ただネットワーク遅延の問題の助けにはなりませんが。
- .... さらに良い選択肢は SOAP を使用して大きなバイナリの blob を一切送信しないことかもしれません。その代わりに、SOAP および HTTP 越しの巨大なバイナリファイルの送信を完全に避けるために、管理されたファイル転送システムを通じた "帯域外" 送信 ... あるいは "預かり証 (Claim Check)" パターンを使用します。
申し訳ありません、データは表示中です。 もう一つの典型的な Web サービスの "パフォーマンス問題" は、Kyle 氏によれば、使用されている Web サービスのレベルが非常に低く、時には各 Web サービスがそれぞれ１つの SQL 文に対応しているというものであるが、これは以下のようなことから生じる。
SOA の設計の原則に関する誤解です。良い SOA 設計の重要な原則の１つはサービスが再利用可能なくらい十分に高レベルであるべきということです。
Kyle 氏によると、これらの状況は一般的に以下のような場合に発生する。
... サービスが既存のコードから "ボトムアップ" に派生した部分の設計で表面化します。開発者はしばしば既存の設計図を見て、永続化レイヤを含むアーキテクチャの各レイヤをサービスの集合に仕立てることを決定するでしょう。
代わりに、SOA 設計における正しい場所に粗い粒度の Web サービスを適用したほうがよいでしょう。繰り返しますが、アーキテクチャの標準的な階層モデルを見てみると、大抵アーキテクチャ内に既にシステムのビジネスロジックをカプセル化するはっきりとした場所があります。適切な方法でモデルベースのサービスを提供するためにこれらのサービスを "リモートファサードパターン (Remote Facade Pattern)" を利用してラップすることができます。
スキーマは？スキーマなんか必要ない！
この問題の兆候は、見込まれる SOA の利点を組織が理解せず、Web サービスが導入される前よりもソリューションの保守がより難しく（簡単ではなく）なるように思えるということです。
この問題に対する単純な解決策は、Web サービスを記述する際はいつでも、WS-* 標準あるいは REST アプローチを使用して、文書の構造を表現する完全かつ正確な XML スキーマを確実に作成するようにすることである。
もし WS-* の Web サービスを構築しているのであれば、Web サービスを説明する WSDL の一部としてこの XML を含めるべきです。REST アプローチに従う場合でも、容易にアクセス可能な XML スキーマがあればサービスの再利用が促進されるでしょう。
Kyle 氏にって解説された落とし穴の回避は常識的なことにのように思える。残念ながら、SOA の実装が十分に理解されそして管理されない限り、我々は同じ過ちを何度も繰り返し続けるということを我々の業界が証明している。