問題タブ [messagecontract]

私は、Java で実装されているように見える外部ベンダーの Web サービス (Apache Axis だと思います) を使用しており、WCF クライアントでそれを使用しています。いくつかの操作では、列挙型の入力パラメーターが必要です。問題は、特定の場合に渡される列挙型のみが必要なことです。要素は、WSDL で nillable としてマークされていません。ただし、それらは列挙型であるため、指定されていなくても、私の WCF クライアントは常に既定値を渡します。この動作により、サービスで内部エラーが発生しています。

この問題に対処する方法について何か考えはありますか? できれば、プロキシを手動で変更する必要のないソリューションであることが望ましいです。これは、将来、別の開発者がプロ​​キシを個別に生成した場合に混乱を招く可能性があるためです。

特定の要素は、WSDL で次のように指定されます。

Svcutil はこれを次のように変換します。

編集:もう少し調査した結果、svcutilは通常、 bool fieldNameSpecifiedパラメーターを追加してオプションのパラメーター (minOccurs=0) を生成し、呼び出し元がフィールドをシリアル化する必要があるかどうかを示す必要があるようです (これについては、こちら、こちら、およびここで）。

ただし、この場合、パラメーターは次のように参照されます。

適切なfieldNameSpecifiedメソッドを手動で追加しようとしても、シリアライゼーションに何の影響もないように見えます (つまり、パラメータはまだ SOAP メッセージに存在しています)。

この時点で、私は疑問に思っています

1. svcutil にfieldNameSpecifiedパラメータが含まれていないのはなぜですか?
2. パラメータを手動で追加しても機能しないように見えるのはなぜですか?
3. この問題に利用できる他の回避策はありますか?

編集:さらに調査した結果、問題の一部は WSDL の記述方法にあると判断しました。ベンダーの WSDL は、DataContractSerializerのスキーマ リファレンスに準拠していません。このため、svcutil は XmlSerializer にフェールバックしています。

問題は、メソッドのメッセージ コントラクトはまだ生成されていますが、データ コントラクトは生成されていないことです。これは、メッセージから除外できないという点で、デフォルトで nullable でない型に問題をもたらすようです (誰でもこれを確認できますか?)。何らかの理由でXmlSerializerのparameterNameSpecifiedMessageBodyMemberAttributeメソッドが無視されるように見える場合、パラメーターに

この動作を回避できた唯一の方法は/wrapped、svcutil でオプションを使用することです。これにより、メッセージ コントラクトが実際のシリアル化されたパラメーター自体から分離されます。この場合、svcutilはparameterNameSpecifiedメソッドを生成し、XmlSerializer はそれらに準拠します。

MessageContract を使用して OnDeserialized イベントを処理するにはどうすればよいですか?

メッセージを受信した後 (ただし、メソッドを実行する前) にデータの検証と変換を行う必要があります。

DataContract は宣言属性で解決しました。

しかし、MessageContract では機能しません。

これを行う方法はありますか？

WCF には 2 つの個別のメッセージ コントラクトがあります。

これは正常に動作しますが、GetBarRequest で MessageHeader のタイプを変更するとすぐに、サービスは動作しなくなります。

現在、GetFooRequest と GetBarRequest の両方に ResponseType という MessageHeader がありますが、タイプが異なります。サービスが機能しなくなりました。2 つの完全に異なるメッセージ コントラクトで同じ名前/異なる型の MessageHeader を使用できないのはなぜですか?

私が得るエラーはかなり不可解です：

MessageContractsでSOAP/XMLを使用していて、次のような指定された形式を返す必要があります。

検証が成功した場合：

失敗した場合：

たとえば、次の方法を考えてみましょう。MyResponseのタイプを返します。では、成功または失敗のXML要素を返すようにMyResponseを定義するにはどうすればよいですか？

このように、成功メッセージを問題なく返すことができます。ラップが解除され、成功のXML要素があります。ただし、FailureのXML要素も返すことができる必要があり、同じMyResponseタイプを使用してそれを行うことはできません。

ストリームを含む別のMessageContractを含むMessageContractでWCFを使用してファイルをストリーミングすることは可能ですか？答えはノーだと思いますが、いわば「ルート」メッセージ内にファイルをパッケージ化したいと思います。

言い換えれば、私のセットアップは次のようになります。

リクエストはサービスに正常に送受信されますが、ストリームが適切に逆シリアル化されておらず、null参照として返されているようです。ストリーミングを使用したMessageContractで、StreamはMessageContractの本体でなければならないというルールをどこかで読んだことがありますが、それが現在違反していると思います。FileTransferMessageがBodyであり、次にStreamがBodyであることが受け入れられることを期待していました。

私がここで何ができるかについて誰か提案がありますか？Stream / FileName/FileLengthをTransportオブジェクトに追加したくありません。

これが私の契約です：

OperationRequest1とOperationRequest2はどちらもBaseOperationRequestから継承します。これは、サービスに着信するすべての要求の資格情報を保持します。

OperationResponse1とOperationResponse2はどちらも基本クラスから継承します。

ErrorCodeは列挙型です。

リクエストでわかるように、2つのメッセージヘッダーと、SOAPメッセージの一部として逆シリアル化されない1つの内部オブジェクトがあります。これは、サービス実装で処理される前に、このオブジェクトをリクエストに挿入したいためです。すべての単一の操作の実装はこのオブジェクトを使用します。各操作でデータレイヤーを2回呼び出す必要はありません。

（属性を介して）WCF拡張性を使用して、次の2つのタスクを実行したいと思います。

1. 要求しているユーザーを認証します。
2. すべての操作で使用するために、着信要求クラスの「User」に複合/複合ビジネス・オブジェクトを移入します。

IOperationInvoker、IDispatchMessageFormatter、およびIDispatchMessageInspectorを調査しましたが、これらのいずれも十分に適しているとは言えません。

参考までに、これが私のサービスの基本的な実装例であり、WCFの拡張性（またはリポジトリ/データレイヤーの呼び出し）はありません。

IOperationInvokerが最も適切な拡張ポイントのようですが、操作を「キャンセル」してクライアントへの応答をオーバーライドする方法を完全に理解することはできません。これが私が到達した場所です：

私はWCFサービスを持っています。そのサービスでは、MessageContract 属性としてマークされたクラスを定義しました。

MessageHeader 属性とマークされたフィールドに問題があります。WPF アプリ (クライアント) ではすべてのフィールドが表示されますが、Windows Phone アプリでこのサービスを使用すると、MessageHeader とマークされたフィールドは表示されません。body フィールドのみが使用可能です。ヘッダーフィールドも利用できる可能性はありますか?

Microsoft が提供する WCF 'Stream' サンプル アプリケーションを、共有アセンブリで設定され、MessageContract属性で装飾された Request オブジェクトを使用するように調整しました。UploadStreamRequest()次に、これをサービスのメソッドに渡す必要があります。

問題は、サービス参照をクライアントに追加してメソッドを呼び出そうとすると、MessageContractオブジェクトの各プロパティが個別のパラメーターに変換されてしまうことです。

また、詳細設定内で「常にメッセージ コントラクトを生成する」オプションを試してみました。これにより、リクエスト オブジェクトが渡されるようにメソッドが変更されますが、オブジェクトの独自のプロキシ表現が再生成されます (「再利用」があるにもかかわらず)。参照されているすべてのアセンブリの型がチェックされています)。

ここで何が欠けているのか誰か説明できますか?

どうもありがとう

顧客から、Webサービスクライアントがどのように機能するかについての仕様を受け取りました。仕様は、サービスおよび対応するXSDとの間で送受信される実際のSOAPXMLメッセージです。顧客は、クライアントに準拠したWebサービスを実装することを望んでいます。クライアントはaxis2ws-stackで記述されており、私がやろうとしているのは、クライアントからの要求を受け入れ、期待しているXMLに準拠した応答を返すWebサービスをWCFで作成することです。この質問では、リクエストに関連付けられたXMLとXSDのみを投稿します。これを機能させることができれば、同様の方法で応答が行われるためです。

私が受け取ったXMLは次のとおりです。

対応するXSDは次のようになります。

タイプをWCF/MessageContract形式で記述し始めましたが、リストなどが二重にラップされているため、苦労しています。

私のMessageContractsは次のようになります。

SoapUIを使用してWebサービスから次の応答を取得すると、次のようになります。

ご覧のとおり、クライアントが期待するXML形式に適合していません。MessageContractをクライアントが期待するXMLに準拠させるにはどうすればよいですか？どういうわけか、リストをダブルラップしないようにする必要があり、クラスのプロパティがクラス名に追加されているようです。

より多くの情報とコードを提供してほしい場合は、そうすることができます。質問に関係がないかもしれないもので投稿全体を埋めたくありませんでした。

編集：

提供されたXSDファイルは適切にフォーマットされていませんでした。これを解決するために、提供されたXMLファイルからXSDを再生成しました。次に、WSCF.blueツールを使用して、XSDのデータコントラクトコードを生成しました。

私は、サービス契約がaxis2soap1.1に準拠するためにドキュメント文字フォーマットを使用するように変更しました

また、操作コントラクトを変更して、入力メッセージと出力メッセージとしてSystem.ServiceModel.Channels.Messageを使用し、生成されたクラス（XSDから生成）を使用してxmlを手動でシリアル化および逆シリアル化しました。

次の wcf サービスがあります。

ただし、サービス参照の追加を介してwcfクライアントクラスを生成すると、次のようになります。

これの代わりに：

なんで？