1

カスタム ヘッダーを含む SOAP ベースの Web サービスの WSDL があります。

<message name="Request">
    <part element="common:Request" name="Request"></part>
    <part element="common:myHeader" name="Header"></part>
</message>

<operation name="processRequest">
    <soap:operation soapAction=""/>
    <input>
        <soap:body parts="Request" use="literal"/>
        <soap:header message="tns:Request" part="Header" use="literal"></soap:header>
    </input>
    <output>
        <soap:body use="literal"/>
    </output>
</operation>

ヘッダー タイプは、別のスキーマ ファイルで定義されます。

<xs:element name="myHeader" nillable="false" type="tns:myHeaderType"/>

<xs:complexType name="myHeaderType">
    <xs:sequence minOccurs="1" maxOccurs="1">
        <xs:element name="JobID" type="tns:JobIDType" minOccurs="1" maxOccurs="1"/>
        <xs:element name="TransactionID" type="xs:string" minOccurs="1" maxOccurs="1"/>
    </xs:sequence>
</xs:complexType>

さらに、必要な要素が存在すること、フォーマットの制約が満たされていることなどを確認するために、 の定義に対して検証を行っていますmyHeaderType。整形式のリクエストは受け入れられ、不適切なフォーマットのリクエストは拒否されるという点で、これはすべて正しく機能しているように見えます。

私の問題は、Apache Axis (プロプライエタリ ツールの背後に隠されている) を使用して Web サービス クライアントを生成するコンシューマで発生します。別の StackOverflow question hereで説明されているように、Axis は myHeader にいくつかのオプションの属性を挿入します。これは SOAP 標準で許可されています (私が知る限り):

<soapenv:Header>
    <com:myHeader soapenv:mustUnderstand="0" soapenv:actor="">
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
        <JobID>myJobId</JobID>
        <TransactionID>myTransactionId</TransactionID>
    </com:myHeader>
</soapenv:Header>

私の消費者が使用しているツールのため、他の場所で提案されているように、Axis によって生成されたスタブを変更してこれらの属性を省略することは現実的ではありません。さらに、石鹸サービスであると主張する場合、これらの属性は私のサービスで許可されているようです。私の質問は、これらのオプションの属性に対応するためにヘッダー定義をどのように変更し、理想的には予期しない可能性のある属性を計画できるかということです。ヘッダー型の定義に拡張できる標準型はありますか、またはこの状況の一般的なベスト プラクティスはありますか?

4

2 に答える 2

1

今日、私の問題に対するいくつかの解決策を見つけることができました。どちらも問題を解決しますが、どちらが本当に優れているかを判断する自信がないので、ここでは両方を紹介します。

どちらのソリューションもmyHeaderType、SOAP で定義された予期しない属性に対応できるように、 の定義を変更することに重点を置いています。

  1. SOAP WSDL スキーマ定義 ( http://schemas.xmlsoap.org/wsdl/tExtensibleAttributesDocumented ) 内には、次の非常に柔軟な属性定義を含むと呼ばれる型があります。

    <xs:anyAttribute namespace="##other" processContents="lax"/>

    この抽象型を拡張することで、予期しない属性に対する自由な許容範囲を自分の型に組み込むことができました。結果のコードは次のとおりです。

      <xs:complexType name="myHeaderType">
      <xs:complexContent>
          <xs:extension base="wsdl:tExtensibleAttributesDocumented">
              <xs:sequence minOccurs="1" maxOccurs="1">
                  <xs:element name="JobID" type="tns:JobIDType" minOccurs="1" maxOccurs="1"/>
                  <xs:element name="TransactionID" type="xs:string" minOccurs="1" maxOccurs="1"/>
              </xs:sequence>
          </xs:extension>
      </xs:complexContent>
  </xs:complexType>

    これはmustUnderstandorの内容をチェックせずactor、XML リクエストで定義した名前空間からのものである限り、完全なガベージを含む他の属性を許可することに注意してください。

  2. もう1つの方法は<xs:anyAttribute>、タイプに直接含めることでした:

      <xs:complexType name="myHeaderType">
      <xs:sequence minOccurs="1" maxOccurs="1">
          <xs:element name="JobID" type="tns:JobIDType" minOccurs="1" maxOccurs="1"/>
          <xs:element name="TransactionID" type="xs:string" minOccurs="1" maxOccurs="1"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>

    私が判断できる限り、これは基本的に同じ効果があります。

これらのソリューションの間に、私が気付いていない微妙な違いがある場合は、ぜひお知らせください。この状況に受け入れられている標準がある場合、私はそれを見つけることができませんでした. このソリューションのもう 1 つの弱点は、スキーマ内の定義に対して属性を検証することができなかったことです。processContents属性を に変更すると、明確に定義されたおよび属性strictでさえ処理されなくなりました。mustUnderstandactor

于 2012-08-03T21:16:05.280 に答える
0

はい、 AltovaXMLSpyエディターで変更できます。30日間機能的に使用してください。

于 2012-08-02T21:48:56.847 に答える