- - PR -
WebServiceについての質問
1
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2002-08-04 13:52
複雑なデータをWSDLのtypesで定義すれば、やりとりできる事はわかるのですが、実際の実装において、例えばserviceにバインドして実行した後に受け取ったデータがXMLSchemaで定義されたものであった場合など、どうやって受け取ればいいのでしょうか?javaを使っているのですが、実装のイメージが沸きません。複数のデータ型が混在する複合インスタンスを受け取る方法がわからないのです。サービス提供者とサービス利用者は知り合い関係にないという事が前提の場合です。どなたか教えていただけませんか?
|
|
投稿日時: 2002-08-05 23:10
> 受け取ったデータがXMLSchemaで定義されたものであった場合など、
現在は、Webサービスの仕組みがセマンティクスを規定することはないと思います。 デシリアライズされたオブジェクトをどう扱うかは、アプリケーションの仕事になります。 たとえば、SOAPで受け取った値が複合型で、2つの文字列型のフィールドをもっており、ひとつはサービスが提供するビジネスロジックの実行結果を収容するXMLで、他方はそのスキーマ記述であるような場合を想定してみましょう。 SOAPの実装(ユーザのカスタマイズを含めて)が提供する機能は、直列化されて送られてきたメッセージから、内容となる2つの文字列を抽出して、2つのStringオブジェクトとして扱えるように復元するところまでです。その後に2つの文字列の意味付けを判断して、それにふさわしい処理をコーディングするのは、今のところ人の作業です。 ですから、現在オーソライズされている規格の範囲内で、複雑で高度な構造をもったWebサービスを利用するためには、まずサービスプロバイダと知り合いになりましょう。 _________________ Paul K.Nakagome |
|
投稿日時: 2002-08-06 09:47
「サービス提供者とサービス利用者は知り合い関係にない」という前提が致命的なのですが、
SOAP Bodyの子孫要素にxsi:type属性を付加するという方法があると思います。 指定するデータタイプはユーザ定義型ではなく組み込みデータタイプであれば、スキーマの参照を行わなくともデータのバインディングができると思います。 ただし、サービスの提供者がこのようなメッセージを組み立ててくれるという前提が必要ですけど。 |
|
投稿日時: 2002-08-06 10:33
返答ありがとうございます。
WSDLのtype属性で指定するのはわかるんですが、受け取るサービスリクエスターの実装イメージが沸かないんです。 例えば <UserList> <User> <ID>1</ID> <Name>日本太郎</Name> <address>東京都</address> <tel>03-XXXX-XXXX</tel> </User> <UserList> といった情報をやりとりするには、どういう実装をすれば良いのでしょうか? org.apache.axis.clientのinvokeメソッドの返値はjava.lang.Object型ですが、どう実装したら受け取れるんでしょう?そもそもこういった複雑な情報を、typesで指定しても受け取れないなら、こういう複雑な情報はどういう風にWSDLで定義し、どういう風に実装で受け取る処理をするのでしょうか? 引数と違って、返値は結構複雑な情報を返す方が多いように思います。 今はWSDLファイルの中にコメントのような感じで、データ構造を書いて、送るのはXML文書を書いたjava.lang.Stringで返し、それをjava.io.Fileインスタンスに変換し、それをパースしてXMLインスタンスに変換して処理をする??とかいう話も出ていますが、スレッドセーフにするために、そこをsynchronizedにしなければならないなど、どんどん変な実装になってしまいます。 いい実現方法のWSDL定義部分とリクエスターの実装方法を教えてください。 |
|
投稿日時: 2002-08-06 13:04
> java.lang.Stringで返し、それをjava.io.Fileインスタンスに変換し、それをパースして> XMLインスタンスに変換して処理をする??とかいう話も出ていますが、
私の記述内容についていっていますか? だとしたら、とんだ曲解です。 私はjava.io.Fileなどとは一言も言っていません。 オブジェクト構造をXMLインスタンスに変換するプロセスを直列化(serialization)、 XMLからオブジェクト構造を再構成するプロセスが非直列化(deserialization)と呼ぶのです。 たとえば、ApacheSOAPでは、シリアライザー、デシリアライザーと呼ばれるフレームワークを 利用してこれらの処理を実行します。サポートされている標準のシリアライザ、デシリアライザで 対応できない複雑なオブジェクトを伝送するためには、そのオブジェクト専用のカスタムシリアライザー、 およびカスタムデシリアライザーを作成し、これにマッピングします。 ですから、そのような場合は、プロバイダとリクエスタは知り合いである必要があると申し上げたのです。 _________________ Paul K.Nakagome |
|
投稿日時: 2002-08-06 13:21
返答ありがとうございます。
>私の記述内容についていっていますか? だとしたら、とんだ曲解です。 私の説明が言葉足らずで、誤解をさせてしまったみたいですいません。出ている話というのは、私の共同開発者がjava.io.Fileに変換して・・というアイデアを出しているという話です。 >対応できない複雑なオブジェクトを伝送するためには、そのオブジェクト専用のカスタムシリ >アライザー、 >およびカスタムデシリアライザーを作成し、これにマッピングします。 プロバイダー側とリクエスター側で協力して、カスタムClientProxyを実装する必要があるという話ですね。 しかしこれではWebServiceの疎結合の利点が半減してしまいます。なのでカスタムClientProxyを実装する案以外で、例えばベンダーが提供しているClientProxyを利用して、データをやりとりするいい実装方法はないかなと思っています。そうでないと何のためにWSDLのtypesでデータ型の定義があるのかわかりません。WSDLでデータ型が定義できるという事は、受け取る実装方法もあるのではないかと思い、投稿したのがきっかけです。 |
|
投稿日時: 2002-08-06 15:19
>出ている話というのは、私の共同開発者がjava.io.Fileに変換して・・
そういうことでしたか。失礼致しました。 ところで、 > しかしこれではWebServiceの疎結合の利点が半減してしまいます。 > そうでないと何のためにWSDLのtypesでデータ型の定義があるのかわかりません。 確かにおっしゃるとおりだと思います。 > WSDLでデータ型が定義できるという事は、受け取る実装方法もあるのではないかと思い AXISのWSDL2java、GLUEのwsdl2java、ASP.NETのwsdl.exe、.NETリモート処理のsoapsuds.exeなどは WSDLを元にProxy(クライアントスタブ)の生成を行います。しかし、それぞれのツールがサポートする 範囲や解釈は必ずしも一致していません。インターオペラビリティ問題は常に付きまといます。 そこで、疎結合の利点を生かそうとする場合は、プロバイダはなるべく簡易なデータ型を採用すべき だと考えます。 _________________ Paul K.Nakagome |
1