| エンタープライズ：ニュース | 2003/05/13 01:29:00 更新 |
Webサービスをよりフレキシブルにするためには (4/6)
SOAPヘッダーの中でWS-Securityヘッダーを使っている点には注意をしてほしい。AsynchBabelFishサービスは、XMethodsのID/Passwordデータベースに対する認証を要求する。この要素は、リクエスタの証明書として転送されるものだ (WS-Securityの詳細に関しては Resouces を参照)。translation resultのエンベロープのボディは、SourceText と TranslationTextの2つの子エレメントを保持するのだ。例として、次のようなソースを挙げよう。
<?xml version="1.0" encoding= "UTF-8"?> <soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/ soap/envelope/"> <soap:Body> <SourceText xml:lang="en" xmlns:xml=http://www.w3.org/ XML/1998/namespace xmlns="http://xmethods.net/ babelfish">hello</SourceText> <TranslationText xml:lang="fr" xmlns:xml= "http://www.w3.org/XML/1998/ namespace" xmlns="http://xmethods.net/ babelfish">bonjour </TranslationText> </soap:Body> </soap:Envelope> |
上記のソースコードは、リクエストとして何が受け渡されたかのを示す単なる表示プログラムである。TranslationTextは、翻訳されたテキストと言語を示すxml:langを保持する。もし、リクエストを達成できないような問題がrequest envelopeにあると、translation results documentに換って標準のSOAP fault envelopeが返信される。次の例は、SOAP fault envelopeであり、リクエストメッセージで要求されるテキストメッセージが、not well-formed XML だった場合に、クライアントに返信される。
AsynchBabelFishのようなJMSベースのWebサービスを使い、クライアントとサーバはダイレクトにインタラクトすることはできない。その理由は、SOAPリクエストが、クライアントとサーバ間でメッセージキューを使い、時間に依存しない方式でやり取りされるためだ。
どのようにメッセージがクライアントからサーバに移動するか見てみよう。クライアントはtranslation request envelopeを作成し、サービスのリクエストキューに置く。このよく知られたパブリックなキューは、HTTPのエンド・ポイントURLとして認知される。フィックスされたHTTPベースのサービスと同じ方法であり、すべてのクライアントとサーバにより利用される。クライアントもreply-to JMSヘッダーを付加させる。このヘッダーは、どこにレスポンスを戻すかをサービスに知らせるリクエストメッセージに対し、レスポンスキュー名に保持する。 AsynchBabelFishサービスプロセスは、その際に稼動していなくても、無関係に入力オペレーションが達成できる。
サービスはキューからリクエストを取得する。 クライアントがリクエストを配置した後、直ちにアクションを起すことができるのだ。もしくは、しばらくの経過後にサーバリクエスト受信可能になった際、アクションを起す場合もある。そしてサーバはリクエストを処理するのだ。例えば、request documentが有効と思えない場合、また、言語コードがサポートされていない不適切なものであった際、もしくはリクエストが何らかの理由で無効であった場合には、問題点を明確にするSOAP fault envelopeが生成される。 この条件以外であれば、サービスは変換処理を完了し、適切なresult documentを生成することになる。 もしも変換プロセスの途中で何かが起き、リクエストをまったく実行できないようなエラーの場合、リクエストはキューに保持される。定期的にサービスをリトライするのだ。最終的には、サーバはレスポンスをresponse queueを通じて返信する。
[David Chappell, Tony Hong，XML Magazine]
