XMLデータをSOAP-RPCで引き渡す
 |
| 図3●DTDで検証したXMLデータをSOAPで伝送する PayCounterでは，ECサイトとやりとりするXMLデータのスキーマをDTDで定義する。これにより，システム間インタフェースを共通化するとともに，実際にデータを伝送する前に正しいスキーマに従っているかどうかを検証することができる |
本来，XMLデータをやりとりするだけなら，単純にSOAPで伝送すればよい。KDDIもその予定であった。しかし，日本語部分が文字化けしてしまうという問題が生じたため，採用は見送った。PayCounter側で使用するSOAPサーバー「Apache SOAP2.2」と，GAZOO側で使用するSOAPクライアント「Microsoft SOAP Toolkit2.0」では，デフォルトでやりとりするメッセージの内容に微妙な違いがあったからだ。その後，SOAP Toolkit2.0のオプション設定で回避できることが判明したが，開発当時はそこまで調査することができなかった。
代わりに，XMLデータを単純にSOAPで伝送する場合とほとんど同じように動作する仕組みを，SOAP-RPC上で実現した。具体的には，XMLデータを文字列型（string）の引数として受け取り，処理するJavaプログラムをPayCounter側に配置し，SOAP-RPCで呼び出している。
DTDでスキーマを検証
Webサービス化するうえでポイントになったのは，エラーが発生したときの取り扱い。Webサービスの世界では，従来のように接続先のシステムや処理内容を正確に把握/管理していない。システム間のインタフェースを合わせるだけで連携するため，エラーの取り扱いが今まで以上に重要になる。
KDDIは特に，（1）やりとりするXMLデータのエラーをチェックする方法，（2）エラー発生時に自動的にロールバックするかどうか――を検討した。
まず，（1）やりとりするXMLデータのエラー・チェックの方法である。「やりとりするXMLデータの構造，型定義，値の範囲などを確実にチェックする必要がある」（IP事業統括本部 eビジネスシステム部 アプリケーショングループリーダーで次長の阿部 正吉氏）。
こうしたチェック処理は，アプリケーションとは分けて実装したほうが効率的である。アプリケーションの開発が容易になり，XMLデータのスキーマ形式とは独立させられるため，アプリケーションの再利用性が高まるからだ。
KDDIは，XMLデータのスキーマ・チェックを，DTD（文書型定義）を使って実装することにした。XMLパーサーのスキーマ検証機能を使い，GAZOO側から受け取ったXMLデータと，GAZOO側に送り返すXMLデータのスキーマをチェックしている。ただしDTDで検証できるのは，XMLデータの構造や型定義のみ。値の範囲は検証できないので，この処理はアプリケーション側に実装した。
スキーマ定義にXML Schemaを使えば，DTDと異なり，XMLデータの構造や型定義に加えて値の範囲も検証できる。それにスキーマ定義自体をXMLデータとして扱える。しかし，対応ツールが少ないことなどを考慮し，GAZOOとの間ではDTDを使用した。
ロールバックは手作業で
もう1つのポイントは，エラー発生時に自動的にロールバックするかどうか。ロールバックとは，トランザクション処理の最中にエラーが発生した場合に，一連の処理をなかったことにして元の状態に戻すこと。
SOAPは，トランザクション処理を前提とする通信手段ではない。メッセージの到達を確認する機能や到達順序を保証する機能などは備えていない。そのままでは自動的にロールバックさせるのは難しい。ロールバックさせるには，SOAPヘッダーなどを活用して複雑な制御を実装するか，あるいはHTTPエージェントを拡張する必要がある。しかし，それでは開発に時間がかかるし，プログラムの処理速度も低下する。
KDDIは，まだ標準化されていない手法でロールバック処理を実装するのは現実的ではないと判断し，運用で解決することにした。問題が生じた場合には，互いのシステム上で処理を1つずつ手作業で追いかけて個別に解決する。
問題発生時に手作業で処理を追いかけるような実装で大丈夫なのか――という点は社内的な議論になった。その結果，XMLデータのエラーをチェックして入出力エラーを排除すれば，ロールバック処理が必要になるようなエラーの発生頻度は低く，運用で十分に解決できるという結論に至った。「運用面で解決できるところは運用面で解決し，システム自体はシンプルに保った方が，ECサイトからも利用しやすいと判断した」（阿部氏）。
エラーの切り分けを容易に
このほか，アプリケーション・レベルのエラーをどのように通知するかも検討した。SOAPの仕様書で規定しているエラー処理は，あいまいな部分が多い。例えばSOAP1.1では，エラーが発生したときにFaultCodeを設定する決まりになっている。しかし，アプリケーション・レベルのエラーを含むかどうかは明確になっていない。
KDDIは，アプリケーション・レベルのエラーは，XMLデータに格納して通知することにした。エラーが発生したときに，SOAPレベルなのか，アプリケーション・レベルなのかを切り分けるためである。
パフォーマンスを改善
パフォーマンスの改善も，ポイントであった。Webサービス利用時には，XMLデータへの変換やSOAPによる通信というオーバーヘッドが避けられない。このオーバーヘッドは，サーバーのプロセッサ性能を上げる，SOAP通信やXML変換に使うソフトウエアをより高速なものに置き換える――などで多少は改善できるが，限界もある。
KDDIは，オーバーヘッドを削減するのではなく，社内システム側をチューニングし，パフォーマンスを改善した。例えば，売り上げ情報更新処理のところで，厳密だった入力のエラー・チェックを簡略化し，処理速度を稼いでいる。決済要求を受け取ってから処理結果を返すまで，当初は2～3秒もかかっていたのが1秒程度に短縮した。
こうしてKDDIは9月26日，KDDIスーパーワールドカードの決済機能をWebサービス化し，GAZOOとの間でXMLとSOAPを使った決済を開始した。今後KDDIは，ECサイト向けのWebサービス・インタフェースを拡充する。年内をめどに，クレジット・カード決済，コンビニ決済，代引き決済も，Webサービス化する計画だ。
