コラボレーション・オブジェクトを作成して、そのトリガー・ポートを Web サービス・コネクターのインスタンスにバインドした後は、いつでも WSDL 構成ウィザードを使用することができます。このユーティリティーは、ユーザーがコラボレーション、ビジネス・オブジェクト定義、およびコネクターに関して指定した、バインディング、ポート名、操作、およびその他のデータを 使用して、WSDL インプリメンテーション・ファイル (*.impl.wsdl)、WSDL インターフェース・ファイル (*.wsdl)、および xml スキーマ・ファイル (*.xsd) を作成します。これらのファイルは、1 つの Web サービスとして公開されるコラボレーション複合体であり、このユーティリティーでは、これらを複数の別個のファイルとして生成するのか、1 つのファイルとして 生成するのかを指定することができます。このユーティリティーは SOAP over HTTP、HTTPS、および JMS の各プロトコル をサポートします。プロトコル・リスナー・フレームワークの構成情報は、コネクター固有プロパティー ProtocolListenerFramework から検索されます。このプロパティーはまた、リスナーのリストを使用できるようにします。
WSDL 構成ウィザードを実行するには、次のようにしてください。
構成ウィザードは、Web サービス・コネクターにバインドされるコラボレーション・オブジェクトの各トリガー・ポート用に、WSDL オペレーションを作成します。このオペレーションは、このコラボレーションの呼び出しに関連付けられているビジネス・オブジェクトに基づいて作成されます。
構成ウィザードは、オブジェクト・レベル ASI の ws_eventtlo を読み取って、そのビジネス・オブジェクトが TLO フォーマットであるかどうかを判断します。ASI プロパティーが true に設定されていれば、そのビジネス・オブジェクトは TLO です。TLO によって、以下の WSDL プロパティーが検出されます。
TLO に基づいて WSDL オペレーションを作成する場合、コラボレーションの構成には、マップを使用する方法と使用しない方法の 2 つの方法があります。
コラボレーションは、一般に、汎用ビジネス・オブジェクト (GBO) 要求を受け入れるように構成されています。つまり、コラボレーション・テンプレートのトリガー・ポートは、GBO にサブスクライブしています。このような状況で TLO を使用するには、コラボレーションが Web サービス・コネクターにバインドされていることと、コネクターがマップを介した GBO の TLO への変換をサポートしていることが必要です。図 59 に、この例を示します。
コラボレーションとコネクターがこの方法で構成されている場合、ウィザードは、WSDL 文書で記述されているオペレーションの作成に TLO ビジネス・オブジェクトが使用されると判断します。この判断は、コネクターでサポートしているビジネス・オブジェクトとそれに関連したマップをインスペクションすることによって行われます。Web サービス・コネクターのランタイム処理にとっては、構成されたマップが常にコラボレーションの GBO を 1 つの TLO だけに変換することが重要です。また、インバウンド・マップのソース・ビジネス・オブジェクトと宛先ビジネス・オブジェクトが、それぞれ、アウトバウンド・マップの宛先ビジネス・オブジェクトとソース・ビジネス・オブジェクトに変換されることも重要です。
ウィザードは、マップを使用しない TLO の処理もサポートしています。この場合、コラボレーション・テンプレートのトリガー・ポートは TLO に直接サブスクライブします。Web サービス・コネクターは TLO をサポートしているため、マップは必要ありません。図 60 は、この例を示したものです。
コラボレーションとコネクターがこの方法で構成されている場合、ウィザードは、コラボレーションで検出される TLO ビジネス・オブジェクトを使用して、WSDL 文書で記述されているオペレーションを作成します。ウィザードは、このポート用に構成されているマップは存在しないと判断します。
非 TLO のビジネス・オブジェクトがサポートされていれば、既存のコラボレーションおよびマップを使用して Web サービスとして公開することができます。このため、ウィザードは、TLO フォーマット以外のビジネス・オブジェクトの使用による WSDL オペレーションの作成もサポートしています。
TLO プロセスと同様、ウィザードは、オブジェクト・レベル ASI の ws_eventtlo を読み取って、そのビジネス・オブジェクトが非 TLO フォーマットであると判断します。 ASI プロパティーが存在しないか、存在しても true 以外の値に設定されている場合は、このビジネス・オブジェクトは非 TLO です。非 TLO は、Web サービスの TLO 構造に準拠していない任意のビジネス・オブジェクトです。 ウィザードは、非 TLO を使用して以下のプロパティーを検出します。
非 TLO に基づいて WSDL オペレーションを作成する場合、コラボレーションの構成には、マップを使用する方法と使用しない方法の 2 つの方法があります。
コラボレーションは、一般に、汎用ビジネス・オブジェクト (GBO) 要求を受け入れるように構成されています。また、GBO をコラボレーションから非 TLO ビジネス・オブジェクトに変換する既存のマップが存在する場合があります。図 62 に、この例を示します。
この場合、ウィザードは非 TLO のビジネス・オブジェクトを使用して、WSDL 文書に記述されている WSDL オペレーションを作成します。Web サービス・コネクターのランタイム処理にとっては、構成されたマップが常にコラボレーションの GBO を 1 つの非 TLO だけに変換することが重要です。また、インバウンド・マップのソース・ビジネス・オブジェクトと宛先ビジネス・オブジェクトが、それぞれ、アウトバウンド・マップの宛先ビジネス・オブジェクトとソース・ビジネス・オブジェクトに正確に変換されることも重要です。
高度に専門化されたケースでは、コラボレーションが、GBO 以外のビジネス・オブジェクトからの要求を受け入れるように構成されている場合があります。この場合、非 TLO はコラボレーション用の直接のビジネス・オブジェクトであり、マップは存在しません。図 63 に、この例を示します。
この場合、ウィザードは、このポートではマップが構成されていないと判断し、非 TLO のビジネス・オブジェクトを使用して、WSDL 文書に記述されている WSDL オペレーションを作成します。
以下のセクションで説明する WSDL 構成ウィザードの要件は、異なる指示が明記されていないかぎり、すべてのタイプのオブジェクト (TLO および非 TLO) に適用されます。Web サービス TLO に関するビジネス・オブジェクト要件の 詳細については、ビジネス・オブジェクトの要件を参照してください。
WSDL 構成ウィザードは、SOAP 構成 MO の Use プロパティーをサポートしますが、SOAP 要求 BO と対応する SOAP 応答 BO の Use 値が異なる場合はエラーをスローします。Use 値を literal または encoded に設定して、WSDL 文書を生成できます。Use プロパティーとその値に関する詳細については、SOAP メッセージに対する Style と Use の影響を参照してください。
コラボレーションを Web サービスとして公開する場合は、rpc スタイルのみがサポートされます。Style を SOAP 構成 MO の文書として指定すると、ウィザードはエラーをスローします。
SOAP 障害ビジネス・オブジェクト内の details 属性は、子属性を 1 つだけ備えることができます。それ以外の場合、ユーティリティーはエラーを生成します。
ユーティリティーは、障害ビジネス・オブジェクトを受け入れます。複数の障害ビジネス・オブジェクトを検出した場合、ユーティリティーは、最初の、あるいはデフォルトの障害ビジネス・オブジェクトのヘッダー・コンテナーを 処理します。処理は次のように行われます。
ヘッダー障害は、WSDL 文書のバインディング・セクションで、soap:header の 子要素である soap:headerfault として処理されます。ヘッダー障害の処理は、次のように、ヘッダー子ビジネス・オブジェクト内で 指定された headerfault ASI を使用して行われます。
SOAP ヘッダー・コンテナー・ビジネス・オブジェクト内では、SOAP ヘッダー子ビジネス・オブジェクト として複数のヘッダー属性が指定されます。ヘッダー・コンテナー・ビジネス・オブジェクトは、その ASI によって、soap_location=SOAPHeader のように識別されます。ユーティリティーによる処理の際に、バインディング・セクション内で、ヘッダー・コンテナー・ビジネス・オブジェクト内のそれぞれの属性ごとに soap:header 要素 が作成されます。この場合、以下の規則が適用されます。
このユーティリティーは、メッセージ・パーツ・レベルの elem_ns ASI を無視します。その代わりに、elem_ns は 2 次レベルおよび低レベルの属性で使用されます。elem_ns が指定される場合、2 次レベルのビジネス・オブジェクト属性を別個のネーム・スペース内で定義することができます。
WSDL 文書のポート・セクションにおける SOAP/JMS バインディングには、jms:address 要素 が含まれます。jms:address 要素の例を次に示します。("?" という接尾部が付いた属性はオプションです。)
<jms:address destinationStyle = "queue" jmsVendorURI = "http://ibm.com/ns/mqseries"? initialContextFactory = "com.ibm.NamingFactory"? jndiProviderURL = "iiop://something:900/wherever"? jndiConnectionFactoryName = "orange" jndiDestinationName = "fred"
jmsProviderDestinationName="trash" />
LookupQueuesUsingJNDI コネクター・プロパティーが true に設定されている場合、InputQueue プロパティーの値は、SOAP/JMS バインディングの jms:address 要素の jndiDestinationName 属性に対応します。jms:address 要素は、wsdl:port セクションで指定されています。LookupQueueUsingJNDI の値が false に設定されている場合には、jmsProviderDestinationName 属性の値は InputQueue に設定されます。InputQueue は、Listener_JMS 階層プロパティーの下で利用できるコネクター・プロパティーです。initialContextFactory、jndiProviderURL、および jndiConnectionFactoryName の各プロパティーは、同期処理用にのみ指定されます。
WSDL 文書のサンプル・ポート・セクションを以下に示します。
<service name="StockQuoteWebService"> <port name="StockQuoteWebServicePort" binding="intf:StockQuoteBinding"> <soap:address location="http://localhost:8080/wbia/webservices/stockquoteservice"/> </port> </service>
WSDL 構成ウィザードは、コンテキスト・パス内のホスト名とポートの値を使用します。コンテキスト・パスに含まれているのがホスト名もポートもない相対パスのみである場合は、Listener_HTTP 構成プロパティー下にあるホスト名およびポート・プロパティーの値が、soap:address xml 要素内で location 属性を指定するのに使用されます。