問題タブ [xop]

このエリアについて他にもいくつか質問がありますが、今は少し冗長です。それらへの回答もいただければ幸いですが、この質問は現時点での私の主な関心事です。

私は、WSE 3.0 で MTOM/XOP がどのように機能するかを示す多くの例に従い、必要と思われるとおりにプロジェクトをセットアップしました。DataType:-base64Binary として指定された Byte 配列フィールドがあります。この中に、追加したい添付ファイルの Byte 配列を入れます。アプリケーションを実行してリクエストを確認すると、データはインラインで base64 としてエンコードされます。つまり、XOP の Include 要素と関連する MIME 部分はありません。

WSE 3.0 内の MTOM についての私の理解では、エンコード時に base64Binary として指定された任意のフィールドを取得し、それをバイナリとしてエンコードして MIME パーツに移動し、XOP の Include 要素に置き換えます。つまり、それはうまくいきました。しかし、参照ファイルでサービスを継承するMicrosoft.Web.Services3.WebServicesClientProtocolように設定し、RequireMtomフラグを true に設定しましたが、まだ正しくエンコードされていません。

ここで何かを見逃しましたか？これが機能するために実装する必要がある他の手順はありますか?

編集: 100 回目のコードを調べた後、ProcessMessage メソッドを実行する前にペイロードをシリアル化する必要があるためではないかと考えています。これは問題になる可能性があるように聞こえますか？シリアル化した理由は、使用する必要があるメソッドが、コンテンツ プロパティを持つ「ペイロード」パラメーターを受け入れるためです。このコンテンツ プロパティは XMLElement プロパティであり、これを取得できる唯一の方法は、必要なクラスをシリアル化することです。しかし、これにより、MTOM が base64 フィールドのデータ型を認識しなくなり、MIME パーツと XOP でバイナリに変換されなくなりますか? 今は本当にストローをつかんでいます。

編集 2: 以下に解決策がありますが、サードパーティの会社は、名前空間のプレフィックスが間違っていると言っています! のようなものが<q1:Attachment xmlns:q1="http://whatever" />あり、彼らはそれを要求しています<s:Attachment xmlns:s="http://whatever" />。私は怒っていますか、それとも問題ではありませんか？名前空間プレフィックスを割り当てる方法を教えてくれる方法はありますか?

Web サービス メソッドを呼び出しているときにこのエラーが発生すると、

要求は空の応答で失敗しました。」

私は今、厳しいですが、どのように応答"application/soap+xml"を得ることができますか?."application/xop+xml"

この問題を解決しなければならないのですが、

アドバイスをありがとう...

JAX-WS-RI または Metro を使用すると、com.sun.xml.ws.api.server.AsyncProvider インターフェイスを使用して WebService を作成できます。

SOAP ヘッダーを含むメッセージ全体を取得することを選択できます

次に、メッセージを解析してそれに応じて処理するものを書くことができます

ただし、これを行う理由の一部は、既存の XML ベースのアプリケーションを SOAP スタックに適合させるためです。アプリケーションは、受け取るメッセージの完全なスキーマ セットを定義し、サービスを定義するための WSDL を簡単に生成できます。

小さな XML メッセージの場合、これはすべて正常に機能します。

ただし、メッセージがかさばる一部の操作で、よりストリーム指向の方法で XML を処理したい場合、MTOM 添付ファイルを使用すると 2 つの問題に遭遇します。プロバイダーの設定を次のように変更します。

適切な MTOM ポリシーを WSDL に追加します。

そして、この操作のメッセージ スキーマを適切に宣言します。

必要に応じてバインディングを設定します。

クライアントを生成し、コードを修正します

http ダンプは、データが「メッセージ本文」に適切な xop:include 要素を持つマルチパート MIME として送信されていることを示しています。

サーバー内で添付ファイルを受け取ります。

次に、着信メッセージを解析し、一括添付ファイルのコンテキスト (たとえば、それを囲む要素の名前) を取得しますが、一括添付ファイル自体は取得しません。

うまくいけば、添付ファイル パーサーは受信側の HTTP ストリームのその部分をまだすべて読み取っていないか、ファイルに分割されている場合は、チャンクごとに読み取ることができます。問題は、受信メッセージを添付ファイルの base64 でエンコードされたデータに変換しないメッセージを解析する方法が見つからないことです。要素の開始を示す SAX/StaX イベントを取得した後、base64 でエンコードされたデータである文字イベントが続きます。StreamMessage のコードを見ると、メッセージが既にバインドされている既存の XMLStreamReader の「前」に、XMLReader や XMLStreamReader などを「挿入」する方法はありません (メッセージ処理の途中なので驚くことではありません)。しかし、その XMLStreamReader 実装は com.sun.xml.ws.encoding.MtomCodec$MtomXMLStreamReaderEx で、常に ' の添付ファイルをインラインでメモリにアンパックします。com.sun.xml.ws.encoding.MtomCodec クラスをパラメータ化して、添付ファイルをインラインでアンパックする内部 MtomXMLStreamReaderEx クラスに最初にイベントを渡さないようにする方法はありません。

添付ファイルを一時ファイルに読み取ってから、メッセージ コンテキストの添付ファイルを FileDataSource に置き換えようとしましたが、Metro はこれらを無視するため、元の DataSource に ReadOnce タイプのエラーをスローさせる効果しかありませんでした。

アノテーションを無効に設定して、プロバイダーで MTOM をオフにしてみました。

それを削除してから StreamingAttachment アノテーションを削除しても無駄です。また、sun-jaxws.xml ファイルの endpoint 要素に enable-mtom="false" 属性を設定しましたが、やはり無駄でした。xop:Include の解析が組み込まれているようです。可能であればクライアントに MTOM を使用してもらいたいので、wsdl を変更したくありません。（ただし、以下のswaRefの回答を参照してください）

swaRef を使用すれば、Metro でやりたいことを実行できますが、サポートされているプロトコルは MTOM であると理解していますか? swaRef を使用して WSDL を編集する必要があります。

また、新しいクライアントを生成し、sendBulk メソッドを別の方法で呼び出す必要があります。

しかし、データ要素を解析すると、対応するcidが取得され、それを使用して必要に応じて添付ファイルを取得できます。

したがって、MTOM と Metro を使用すると、データ要素を解析する時点まで添付ファイルが読み取られていないか、実際にチャンクで効率的に一時ファイルにストリーミングされていない可能性がありますが、入力メッセージの「残り」を読み取る方法がありません。愛着の全体をメモリに読み込まずに、自滅しているように見えますか? Metro のダンプとは別に - 提案 re: Axis、CXF を歓迎します - 誰かが発見したこれを回避する方法はありますか?

機能リクエストを記録しました。

次の問題があります。
いくつかの命令を使用して、xop チェックに関連するいくつかのテストがありBulldozer (xop)ます。
そして、このテストはBulldozerプロセッサ上でのみ実行する必要があります。プロセッサがコンパイル時に命令を
サポートしていることを確認するにはどうすればよいですか?xop

言語: C、OS: Linux ;

Java WS との通信に問題があります。認証にクライアント証明書を使用した「wsHttpBinding」バインディングを使用しています。メッセージ エンコーディングは「テキスト」に設定され、.net フレームワークは 4.0 です。サーバー側はJavaであり、私はそれを制御できません。接続は Fiddler を介してプロキシされています (これは、「System.Net」をトレースするよりもはるかにユーザーフレンドリーな、ネットワーク上の要求を確認する方法です)。

私が得る例外は次のとおりです。

コンテンツ タイプ application/xop+xml; 応答メッセージの type="application/soap+xml" がバインディングのコンテンツ タイプ (application/soap+xml; charset=utf-8) と一致しません。

メッセージのエンコーディングを「Mtom」に変更すると、例外が変更されます。

コンテンツ タイプ application/xop+xml; 応答メッセージの type="application/soap+xml" がバインディングのコンテンツ タイプ (multipart/related; type="application/xop+xml") と一致しません。

サーバーはリクエストに対して「テキスト」と「Mtom」の両方のメッセージ エンコーディングを受け入れ、レスポンスは常に同じです。これは、サーバーから取得している生の応答です。

私が読んでいるすべてのドキュメントから、返されている応答は、通常の SOAP メッセージと MTOM メッセージの間のどこかにあります。私がこれを言っているのは、私が見たすべての例で、MTOM 要求と応答が通信のエンベロープとして MIME を使用していると言っているからです。通常の SOAP メッセージは XOP パッケージにエンベロープされ、この XOP メッセージは MIME でエンベロープされます。W3C 勧告でさえ、XOP パッケージに MIME を使用しています: W3C: XML-binary Optimized Packaging。このリンクからの抜粋:

ツール「soapUI」(Java で記述され、「www.soapui.org」から入手可能) を使用して Web サービスを呼び出してみると、サービス呼び出しは正常に実行され、応答は問題なく解析されます。

参考までに、これはMSDN WCF フォーラムからのクロスポストですが、まだ応答はありません。

どんなアイデアでも大歓迎です、事前に感謝します、

アレックス

ここで見つかりましたUpload file via Soap messageの詳細。しかし、Soap に大きなファイルがあると別の問題が発生し、Soap メッセージ経由で送信するためにメモリにファイルがロードされるというメモリの問題が発生します。

MTOM (Message Transmission Optimization Mechanism) について読みました。「MTOM/XOP を使用してSOAP メッセージを最適化すると、XOP処理はそれを MIME Multipart/Related メッセージにシリアル化します。XOP 処理は、base64BinaryデータをSOAP メッセージから抽出し、 MIMEメッセージ内の個別のバイナリ添付ファイルとしてパッケージ化します。電子メールの添付ファイルと同様の方法」

Javaでこのアプローチを使用する方法を見つけました here Soap with Attachments and MTOM in Java

今、私は2つの質問があります:-

1. iOSでMTOM/XOPアプローチを使用することにより、上記で説明したメモリの問題を軽減または解決できます。
2. プログラミングでiOSでMTOM/XOPアプローチを使用する方法。

事前に感謝します。

base64 テキストまたは xop:Include 要素のいずれかである要素を定義する XML スキーマがあります。現在、これは base64Binary タイプとして定義されています。

代わりに xop:Include 要素を挿入すると、次のようになります。

しかし、これにより XML 検証エラーが発生します (私は .NET バリデーターを使用しています)。

親要素のコンテンツ モデルがテキストのみであるため、要素 'mds:xml-schema:soap11:PackageBinary' に子要素 ' http://www.w3.org/2004/08/xop/include:Include ' を含めることはできません。

これはbase64コンテンツではないので理にかなっていますが、これは一般的な方法だと思いました...? スキーマでこれをサポートする方法はありますか? (この構文をサポートする既存の製品がありますが、現在検証を追加しています。)