これは自由回答形式の質問であり、かなりの量のテキストですが、しばらくお待ちください。
最初に背景を少し。昨年、私は Web サービスを作成してきました。この分野の知識ゼロから始めました。私の仕事は、WSDL を準備し (好きなように構造化できました)、それを実装することでした。私は XSD スキーマの準備方法に少し影響を与えましたが、それほどではありませんでした。2つのプロジェクトに参加しました。1 つ目は Web サービスが 5 つほどしかありませんでしたが、2 つ目は 20 以上あり、さらに増え続けています。両方とも、XSD スキーマの一定の変更を受けます。
さて、要点です。
WSDL 設計をどのように構築したかという点で、それぞれに 2 つの異なるアプローチを使用することにしました。最初のプロジェクトでは、WSDL ごとに 1 つの WS として WS を WSDL 間で分離していました。これは特に、使用される XSD スキーマが操作ごとに (めったに変更されない 1 つの基本的なスキーマを除いて) 異なるため、非常にうまく機能しました。ただし、5 つの異なる WSDL があり、無駄に思えました。
2 番目のプロジェクトには、はるかに多くの WS があり、はるかに多くの数とより複雑なスキーマがありました。ここでは、サービスを用途に応じていくつかの WSDL にグループ化することにしました。WS が呼び出されると、本体の主要な要素によって認識されることに気付くまで (私の知識が大幅に不足しています)、すべてが素晴らしいように見えました (実際には、なぜそうなのかはまだわかりません)。多くの WS には入力と同じ要素があり、それらは同じ WSDL にあるため、同じパスを持ちます。これにより、アプリケーション サーバー (Weblogic 10.3) から警告が発生しましたが、機能しました。SOAP 1.1 を使用しているので、SOAPAction ヘッダーを使用したと思います。エンタープライズ バス (OSB) にサービスを展開したときに問題が発生しました。SOAPAction が選択アルゴリズムとして選択されない限り、またはオラクル アドバイザーが提案したように、WS ごとに追加の一意の要素が作成されない限り、機能しません。
そして、ここに問題があります。WSDL の構造化方法。私が検討したオプションは次のとおりです。
- 選択アルゴリズムとして SOAPAction ヘッダーを選択します。個人的にはそのソリューションが気に入りましたが、SOAP 1.2 にはそれがなくなったので、(私の上司である) 権力者は、それを使用できないと言っています。SOAP 1.2にはオプションの「アクション」ヘッダーがあることは知っていますが、オプションであるため、再び使用できません（上司の推論：次のバージョンにはまったく含まれない可能性があります。クライアントはオプション機能を使用したくない場合があります。コスト、私にはわかりません、それはビジネスの問題です）。
- 各 WS に固有の要素を使用します。これは見苦しく不必要に見えますが、これまでのところ最高です。
- 前のセットアップに戻り、WSDL ごとに 1 つの WS を実行します。これは間違いなく最も好ましくない方法です。それは気分が悪く、私が読んだ限りではデザインが悪いだけです。しかし、それは機能し、かなりの柔軟性を提供します。
さて、誰かが他の解決策を持っているなら、私はそれらを聞いてみたい. 私はちょうどいいと感じる解決策を見つけることができません。
前もって感謝します。