このファイルには、Web サービスに影響する制限 (永続的と一時的の両方) の広範囲のリストが含まれています。
Web サービスでの作業中に発生する可能性のある制限は、以下のセクションに分かれています。
サポートされるソフトウェアと仕様
Web サービス・エクスプローラーでは、以下の Web ブラウザーがサポートされています。
- Microsoft® Internet Explorer 6.0 以降
- Mozilla 1.2.1 以降
Mozilla を使用してワークベンチの外部から WORF テスト環境を起動している場合には、
少なくともバージョン 1.3.1 の Mozilla が推奨されています。
Mozilla ブラウザーの以前のバージョンの Web サービスの起動による出力と記述ファイルは、
適切にレンダリングされていない可能性があります。
Web サービス・ウィザードの使用時に発生する問題
- Web サービスを作成しているときに空の
EAR (モジュールを持たない EAR) を指定すると、例外またはエラーが発生することがあります。
したがって、少なくとも 1 つのモジュールを EAR に作成することをお勧めします。
EAR はウィザードを使用して Web サービスを作成しているときに選択するか、
またはウィザードで作成します。
- Web サービス用にパッケージする名前空間、
またはマッピングする名前空間へのパッケージをカスタマイズすることを選択して、
マッピングをカスタマイズできるウィザードのページで「終了」をクリックすると、
カスタマイズされたマッピングは使用されません。
このエラーは特定ページで「終了」をクリックしたときのみ起こります。
ウィザードの次ページに進むために「次へ」をクリックして、
「終了」をクリックすると、カスタム・マッピング処理は進行します。
-
Web サービス・ウィザードのどこかで終わるために「キャンセル」をクリックすると、
ウィザードで生成されたファイルがご使用のワークスペースに残されたり、
Web サービス・エントリーが J2EE デプロイメント記述子に残されたりすることがあります。
これらのファイルはウィザードを閉じてから手動で削除する必要があります。
WebSphere® ランタイム環境の使用時に発生する問題
- IBM®
WebSphere
Web サービス・ランタイム環境は、デフォルトの
Java™
パッケージを使用する
Java
Bean を処理することができません。
その結果、サーバー始動時に例外状態となり、実行時に Web サービスが作動しなくなります。
- WebSphere ランタイム環境を使用して、
Java
Bean または EJB から Web サービスを作成するときには、
Java
プリミティブ型 (int、float、double など) で始まるパッケージ名を持つ複合型 Bean を使用しないでください。
そうしないと、生成された WSDL ファイルのスキーマが複合型を
Java
プリミティブ型として正しく扱えない場合があります。
- RPC スタイルのメッセージに対しては、
SOAP エンコード方式とリテラル・エンコード方式を併用することはできません。
しかし、これは、DADX が生成する一種の WSDL 文書です。
したがって、RPC を使用する DADX Web サービス用に生成された WSDL ファイルから、WebSphere クライアントを正しく作成することはできません。
この問題発生を防ぐには、DOC スタイルを使用して DADX Web サービスを作成します。
WebSphere ランタイム環境は、
この WSDL からクライアントを問題なく作成できます。
DOC スタイルの DADX Web サービスを使用するには、DADX グループに対する
group.properties ファイルの useDocumentStyle パラメーターを、
true に設定します。この設定は、DADX グループの構成ウィザードを使用して行うこともできます。
- Web サービスを
Java Bean
または EJB から作成すると、Java または EJB 実装で異なるパッケージに配置されている Java クラスへの参照がある場合に、
生成された WSDL (特に WSDL ファイルの <schema> セクション) で <import> ステートメントが欠落する場合があります。
これが影響するのは WebSphere Application Server v5.x をターゲットとした Web サービスのみです - WebSphere Application Server v6 を使用する Web サービスには影響しませんので、
注意してください。
- WSDL ファイルから
Java
または EJB スケルトンを生成する時に、 使用する WSDL ファイルに標準 JAX-RPC マッピング
(例えば <choice> group) のない XML 型が含まれていると、
生成されたスケルトンの実装では、対応する javax.xml.soap.SOAPElement が正しく作成されません。
結果として Web サービスは、誤った形式の SOAP 応答を戻すことがあります。
以下は、この問題の修正方法です。
- 実装クラスを開く。
- SOAPElement のインスタンスが作成されている行に進む
(createSOAPElement("http://schems.ibm.com/wswrapper",">D" のようになっているはずです)。
- > 文字を取り除く。
- これを保管して EAR プロジェクトを再開する。
これが影響するのは WebSphere Application Server v5.x をターゲットとした Web サービスのみです - WebSphere Application Server v6 を使用する Web サービスには影響しませんので、
注意してください。
- Web サービスが
WebSphere
ランタイム環境にデプロイされた後で、Web サービスによって使用されるクラスの 1 つを変更すると、
変更が反映されず、サーバー・コンソールに ClassCastException が表示されることがあります。
この場合は「サーバー」ビューでサーバーを右クリックして、
「プロジェクトの再開」を選択してから、
クラスが変更されたプロジェクトを含む EAR を選択してください。
これが影響するのは WebSphere Application Server v5.x をターゲットとした Web サービスのみです - WebSphere Application Server v6 を使用する Web サービスには影響しませんので、
注意してください。
- WebSphere
ランタイム環境を使用して Web サービス・クライアントを作成する場合、
クライアントのデプロイメント記述子は Universal Test Client で使用できません。
その結果、クライアント・プロキシーの JNDI ルックアップは Universal Test Client では機能しません。
この UTC を使用するには、Locator クラスを構成して使用するか、
useJNDI を false にセットして生成された Proxy クラスを使用
(内部で Locator を構成して使用) する必要があります。
クライアント・サイドのデプロイメント記述子が処理されないと、
WS-Security やハンドラーなどの特定のメタデータが使用可能になりませんので注意してください。
このようなクライアント構成の例にセキュリティーがあります。
Universal Test Client の代わりに、サンプルの JSP を使用してプロキシーをテストしてください。
- RPC/リテラルで配列がサポートされない:
RPC/リテラル・サービスを作成する場合、メソッド・シグニチャーはそのサービスに配列を含めることはできません。
含まれている場合は、生成したクライアント・コードでこのサービスを起動できません。
この問題に対する予備手段は現在ありません。可能であれば、文書/リテラルまたは RPC/エンコードを使用してください。
これが影響するのは WebSphere Application Server v5.x をターゲットとした Web サービスのみです - WebSphere Application Server v6 を使用する Web サービスには影響しませんので、
注意してください。
- WSDL インポート:
WSDL インポート・ステートメントは、同一ディレクトリーでは絶対 URL または相対 URL しか持つことができません。
例えば、次の形式の相対インポートはサポートされません:
<import namespace="http://someNamespace/" location="../someFile.wsdl"/>
- WSDL ファイルからスケルトン EJB を生成するときは、
WSDL ファイルが JMS 上の SOAP をトランスポートとして使用している場合、
ルーター・プロジェクトが Web プロジェクトではなく EJB プロジェクトであることを確認してください。
Web プロジェクトにすると、Web サービス作成ウィザードの途中でエラー・メッセージが表示されます。
- EJB スケルトンの生成時に、
「サービス・デプロイメント構成」ページで J2EE レベル 1.2 Web プロジェクトをルーター・プロジェクトとして選択する場合は、
ウィザードで次に進む前に、Web プロジェクトと同じ EAR に含まれる既存のレベル 1.1 EJB プロジェクトが、
EJB プロジェクトとして選択されていることを確認してください。ウィザードで EJB プロジェクトを自動的に作成すると、
レベル 2.0 EJB プロジェクトが作成されます。
このプロジェクトは、レベル 1.2 EAR およびレベル 1.2 Web プロジェクトと互換性がありません。
- デフォルトの
JAX-RPC マッピングを使わない型を使用しない WSDL ファイルから EJB スケルトンを生成するときに、
ユーザーが Web サービスを起動しようとすると、ランタイム環境例外が戻されます。
この問題は、ランタイムでの javax.xml.soap.SOAPElement のデシリアライズに障害がある点です。
java.xml.soap.SOAPElement は、型に関連するマッピングがない状態で使用されるため、
文書のフラグメントとしてマップされます。
これが影響するのは WebSphere Application Server v5.x をターゲットとした Web サービスのみです - WebSphere Application Server v6 を使用する Web サービスには影響しませんので、
注意してください。
- 入出力パラメーターが指定された操作を使用して
WSDL ファイルから EJB スケルトンを生成する場合は、 EJB のデプロイメント・コードの生成時にエラーが表面化します。
この問題は、 入出力パラメーターが javax.xml.rpc.holders.Holder クラスにマップされる点にあります。
java.xml.rpc.holders.Holder は java.io.Serializable を実装しないため、EJB デプロイメント・エラーが起こります。
これが影響するのは WebSphere Application Server v5.x をターゲットとした Web サービスのみです - WebSphere Application Server v6 を使用する Web サービスには影響しませんので、
注意してください。
Apache Axis 1.0 ランタイム環境の使用に関する問題
IBM
SOAP ランタイム環境を使用する場合の永続的な制限
IBM
SOAP ランタイム環境は、主として後方互換性のために使用する必要があります。
どのような目的で実動させる場合にも、Web サービス・ウィザードは
IBM
WebSphere
ランタイム環境で使用することを強くお勧めします。
Web サービス・ウィザードを
IBM
SOAP ランタイム環境で使用する場合、ユーザーは、次のような永続的な制限にぶつかることがあります。
- Java Bean からの WSDL 文書の生成
- char または
java.lang.Character から
WSDL XSD へのデフォルトのマッピングが存在しないため、
char および java.lang.Character に対しては、
カスタム・マッピングを入力する必要があります。
- プリミティブ・ラッパー型である
java.lang.Boolean、java.lang.Byte、
java.lang.Short、java.lang.Integer、
java.lang.Long、java.lang.Float、
および java.lang.Double は、それらに対応する個々のプリミティブ型の
boolean、byte、short、
int、long、float
および double とは、サービス Bean のすべての入力パラメーターにおいて共存できません。
例えば、java.lang.Integer と
int の両方を入力パラメーターの型としていずれかの場所に持つサービス Bean を、
完全な Web サービスに変えることはできません。
Web サービス・ウィザードを使用してこの型のサービス Bean から Web サービスを作成しようとすると、
プリミティブ型またはラッパー型を含むメソッドがウィザードの Web サービス
Java Bean
メソッド・ページで選択されていない場合を除いて警告メッセージが出されます。
ただし、最初に「Web サービス Java Bean メソッド」ページが表示された時点では、
これらのメソッドが選択されていないようにする必要があります。
警告が表示された後で、このページに戻って問題のメソッドを消去しても、Web サービスが不完全になることがあります。
この場合、ウィザードを再始動して、
最初に「Web サービス Java Bean メソッド」ページが表示されたときに、
適切なメソッドを選択するようにする必要があります。
- 多次元配列はサポートされていません。
Java での代わりの方法は、Java Bean をディメンションの間に挿入することです。
例えば、MyType[][] の代わりに、パターン MyArray[] (MyArray は MyType[] 型のプロパティーを持つ)
を使用することで機能します。
- DOM エレメントと単純な Bean 型の混在した入力引数リストを持つメソッドに対しては、
1 つまたは複数のカスタム・マッピングのエントリーが必要です。
Web Services Definition Language (WSDL) バージョン 1.1 仕様は、
すべての入力部分 (パラメーター) に対して 1 つのエンコード・スタイルをサポートしています。
Simple Object Access Protocol (SOAP) バージョン 2.2 のランタイム環境は、
プリミティブ型について SOAP エンコード方式を使用する DOM エレメント、
および Literal XML エンコード方式を使用する Bean に対して、
デフォルトのマッピング・サポートを持っていません。
- カスタム・マッピングの構成時に、
SOAP ランタイム環境 (つまり、パッケージ
org.apache.soap.encoding.soapenc から使用するクラス)
からシリアライザー・クラスまたは デシリアライザー・クラスを使用する際に、
「選択されたシリアライザー/デシリアライザー・クラスはこのプロジェクトからロードできません」というエラーを受け取った場合は、
おそらく soap.jar が Web プロジェクトのビルド・パスにないと考えられます。
この問題を修正するには、ウィザードを取り消し、Web プロジェクト・プロパティー・ダイアログを使って
WS_installdir¥wstools¥eclipse¥plugins¥com.ibm.etools.webservice¥run-time environment¥soap.jar
を Web プロジェクトのビルド・パスに追加してから、Web サービス・ウィザードを再試行してください。
- カスタム・マッピングはネストされた複合型ではサポートされません。
ウィザードのマッピング・ページにはネストされた型が表示されますが、この型のカスタム・マッピングは無視されます。
- インターフェースに抽象
Java の型を含む
Java
クラスから Web サービスを作成するとき、Web サービス
Java から
XML へのマッピング・ページは抽象型のデシリアライザー・フィールドを
org.apache.soap.encoding.soapenc.BeanSerializer に間違って設定する場合があります。
これは、BeanSerializer クラスのデシリアライザー・コードが、抽象型のインスタンスを構成できないために、
ランタイム環境で失敗します。
これを回避するには、必要に応じて、この型にカスタム・マッピング・オプションを選択して、
デシリアライザー・フィールドで、抽象型をデシリアライズするために作成されたクラス名に変えてください。
- Web サービス・ツールでは、ネストされたインナー・クラス
(トップレベル・クラスに定義されたインナー・クラス) が含まれている
Java Bean を使用する Web サービスの作成について、
現在はサポートしていません。
この問題の次善策として、インナー・クラスを別の
Java
ファイルのトップレベル・クラスに移動してください。
- Vector、Hashtable、
または Map のプロパティーで他の
Java Bean を使用する
Java Bean から
Web サービスを作成する場合、XSD は、
「Vector」および「Map」型を含む complexTypes を使用して名前空間「http://xml.apache.org/xml-soap」から生成されます。
この名前空間には現在スキーマが存在しないため、XSD バリデーターは次のようなエラーと警告を生成します。
- Error src-resolve: Cannot resolve the name 'xsd2:Vector' to a(n) type definition component.
- Warning src-import.0: Failed to read imported schema document 'null'.
これらのエラーおよび警告は、Web サービス・ウィザードによる WSDL および XSD の現行の処理を妨害しません。
「Map」および「Vector」型は、
それぞれの Java
対応先に正しくマップされます。
他のベンダーでは、これらの型が含まれている WSDL または XSD の処理に困難が伴うことがあるということに注意してください。
それは、http://xml.apache.org/xml-soap が、WSDL 1.1 または SOAP 1.1 仕様によって認識された名前空間でないからです。
インターオペラビリティーを改善するには、
Java コレクション・クラスを配列と
Bean に適応させ、次に、アダプターから Web サービスをビルドすることを考慮してください。
- WSDL 文書からの Java 作成物の生成
-
入力エレメントまたは 出力エレメントにつき 1 つの
パーツのサポートに制限されています。
入力メッセージまたは出力メッセージでは、複数の論理パーツはサポートされません。
そのような最初のパーツは処理され、残りは無視されます。
- Web サービス・スケルトンまたはプロキシーを
xsd (http://www.w3.org/2001/XMLSchema) 名前空間の
base64Binary 型を使う WSDL から生成するとき、
Web サービス・ランタイム環境は実際には soapenc (http://schemas.xmlsoap.org/soap/encoding/) 名前空間の
xsi:type base64 を使用します。
通常、2 つの型は自由に交換可能です。
ただし、メッセージの型とスキーマの型の違いにより、
いくつかの SOAP プロトコル・ランタイム環境がメッセージをリジェクトする可能性があります。
この場合、シリアライザーを Apache SOAP の Base64Serializer のように手加工できますが、
soapenc:base64 の代わりに xsd:base64binary が書き込まれます。
- Java Bean スケルトンは、
有効な Java ID
でない操作名やパーツ名を含む WSDL 文書から作成されている場合、コンパイルしません。
Java Bean
スケルトンが正常に作成されるためには、WSDL 操作名とパーツ名は有効な
Java ID でなければなりません。
- Web サービス・ウィザードは、
WSDL を生成するときにデフォルトでは「HTTP」の URI を使用しますが、
他のツールの WSDL 文書では、Web サービス、SOAP アクション、またはターゲット名前空間の URI により、
「HTTP」以外の「urn」などの方式を使用する場合があります。
HTTP 以外の URI を含む WSDL からプロキシーまたはスケルトンを生成するとき、
Web サービス・ウィザードは URI をより意味のあるパッケージよりも
Java
パッケージ「com.example」にマップする可能性があります。
場合によっては、Web サービス・ウィザードがそのような URI を完全に処理できず、
「IWAB0234E 内部エラーが発生しました」というエラーになることがあります。
- WSDL を使用して
Java プロキシーおよび
Java
スケルトンを生成する場合は、XSD 組み込み型の boolean、byte、short、int、long、float、および double を
Java プリミティブ型 (int) ではなく、
「java.lang」ラッパー型 (java.lang.Integer) にマップするオプションが利用できるようになりました。
デフォルトでは、Web サービス・ウィザードは Java プリミティブにマップします。
ウィザードで「java.lang」ラッパー・クラスにマップするには、
「ウィンドウ®」->「設定」->「Web サービス」->「コード生成」と開いて、
「簡単な XML データ型を java.lang ラッパー・クラスにマップする」をチェックします。
- Java Bean または EJB から
Web サービスを作成するときにカスタム・マッピングを
Java の型から
XSD 型に指定する場合は、Bean クラス・フィールドが自動的に
Java
の型のフルネームに設定され、 編集はできません。
Java
配列をカスタム・マッピングする場合は、Bean クラス名が配列形式 (例えば、java.lang.String[]) になり、
その形式で「.isd」および「dds.xml」デプロイメント記述子ファイルに出力されます。
このクラス名のフォームは SOAP ランタイム環境によって正しく処理されず、
次のようなエラーが発生します。
SOAP サービス http://tempuri.org/webservice.AddressBook
でのデプロイメント・エラー: クラス名 java.lang.String[] を解決できませんでした
その結果、サービス・サイドの Java
配列に対してシリアライザーをカスタム・マップすることができません。
部分的な予備手段は、「シリアライザー・クラス」フィールドをカスタム・マッピング用に空にしておくことです。
これによって、デプロイメント記述子への配列クラス名の生成が抑制され、サービスが稼働します。
デシリアライザー・クラス、およびデシリアライザーをカスタム・マッピングする機能は、
この問題および予備手段による影響は受けないということに注目してください。
XSD Bean 生成プログラムには制限があります。
重複して指名されたエレメントは処理できません。
例えば、スキーマが次のフォームをもつ場合:
<xsd:schema>
<xsd:choice>
<xsd:element name="aElem" type="xsd:string">
<xsd:sequence>
<xsd:element name="bElem" type="xsd:string">
<xsd:element name="aElem" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:choice>
</xsd:schema>
XSD Bean 生成は、同じメソッド名をもつ複数の Setter で Bean を作成します。
シーケンス内で aElem の型が変化した場合も同様の問題が起こり、
2 つの Getter がそれぞれ異なる型を戻しますが、同じ引数をもつことになります。
- ランタイムについての考慮事項
- Web サービス・コード生成設定「エレメントを使用したマッピングを使用可能にする」を選択して、
WebSphere Application Server V4
へのデプロイを選択すると、ISD ファイルと dds.xml に以下のエントリーが作成されます。
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:x="" qname="x:some-name" xml2JavaClassName="some-serializer"/>
XML エディターは、次のエラーにフラグを立てることができます。
属性 "xmlns:x" の値が無効です。
接頭部付きの名前空間バインディングが空でない可能性があります。
WebSphere Application Server V4 の場合、これは問題ではありません。
ただし、Xerces 2.x (XML4J 4.x) 以降 (WebSphere Application Server V5 サーバーなど)
を使用する他のサーバーにこの dds.xml をデプロイしないでください。
そうでないと、サーバーが dds.xml ファイルをロードするときに同様の Xerces 構文解析エラーが発生します。
Web サーバーのシナリオに従って正しいサーバー・タイプを選択して、dds.xml を再生成してください。
これにより、そのサーバー・タイプに対して正しい dds.xml が生成されます。
また、ISD ファイルから Web サービスをデプロイしようとすると、同様の Xerces 構文解析エラーが発生します。
予備手段として、ファイルを手動で以下のフォーマットに編集します。
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" qname="some-name" xml2JavaClassName="some-serializer"/>
Java Bean
または EJB で作成された Web サービスを呼び出すときに、
次のような targetException による SOAPException を受け取る場合があります。
「java.lang.IllegalArgumentException: インスタンスを生成することができません ...」。
この問題は、Web サービスとして公開されたメソッドに、
パラメーターまたは戻りの型 (あるいはその両方) としてのパブリック・デフォルト・コンストラクターのない
Java Bean
が含まれていることが考えられます。
デシリアライゼーション・プロセスの一部として SOAP ランタイム環境が オブジェクトを構成するためには、
パブリック・デフォルト・コンストラクターが必要です。
- Web プロジェクトに現在デプロイされているセキュリティー・ファイルの
cl-ver-config.xml および sv-ver-config.xml は、
WebSphere バージョン 4.0
のファイルであり、DTD に正確に一致するとは限りません。
しかし、このファイルは、「xmlns:ds」または「xmlns:SOAP-SEC」が宣言されるべきであるとの検証エラーがあっても
WebSphere バージョン 4.0 と
WebSphere バージョン 5.0
の両方で有効です。
- 同じパッケージからの 2 つの異なる複合型を使用する Bean を作成し、
この Bean から SOAP ベースの Web サービスを作成する場合には、それぞれの複合型に XSD ファイルが作成され、
同じ名前空間を割り当てられます。
この結果、タスク・リストと Web サービス・エクスプローラーの両方で検証エラーが起こります。
- ISD Web サービス
- Java または EJB Web サービスを作成するときにカスタム・マッピングを入力した後、
XSD ロケーション URL 以外のカスタム・マッピング情報は ISD ファイルに保管されます。
Web サービスを作成するときに、その ISD ファイルから情報を検索します。
したがって、ISD ファイルから Web サービスを作成するときに、
ウィザードの「Web サービスの Java から XML へのマッピング」ページに
XSD ロケーション URL を手作業で入力する必要があります。
Web サービス・クライアント作成時の制限
Web サービス・クライアントを EJB プロジェクトにデプロイするとき、
プロキシー構成ページには、この Web サービス・クライアントがスコープされる EJB
を選択するためのコンボ・ボックスが含まれています。
これは、JSR-109 によって定義される要件です。
JSR-109 では、component-scoped-refs エレメントのコンポーネント名は、
モジュール内にある EJB の ejb-name と一致する必要があります。
少なくとも 1 つの EJB がプロジェクトにあれば、エラーは発生しません。
しかし、プロジェクトに EJB が 1 つもない場合は、プロキシー構成ページのコンボ・ボックスは編集可能で、
サフィックスが「EJB」である WSDL のサービス名に等しいデフォルト値を持ちます。
さらに、クライアント・ウィザードが警告ダイアログを表示し、
Web サービス・クライアントが既存の EJB にスコープされていないため、デプロイメントが不完全であることを示します。
ユーザーは EJB を webservicesclient.xml
で使用されているコンポーネント名と同じ名前で EJB を作成して、これを修正できます。
ただし、ウィザードでクライアントの作成を取り消して打ち切りにした場合、
ウィザードは、webservicesclient.xml から不完全な component-scoped-refs を除去しません。
再度デプロイを行う前に、手操作で不完全な component-scoped-refs を除去してください。
URL Web サービスに対して、
または HTTP GET および POST バインディング のみを含む WSDL に対して Web サービス・クライアントを生成するときは、
そのクライアントの
IBM SOAP ランタイム環境を使用します。
Axis または
IBM WebSphere
ランタイム環境を使用しようとすると、コードの生成が不完全になったり、
内部エラー (IWAB0234E An internal error occured) が発生したりすることがあります。
URL から Web サービスを生成する場合、生成された WSDL には HTTP GET および HTTP POST バインディングがありますが、
SOAP バインディングはありません。
Axis および
IBM
WebSphere
ランタイム環境は、WSDL において HTTP GET および POST バインディングをサポートしていません。
IBM
SOAP ランタイム環境のみが、HTTP バインディングをサポートしています。
WSDL バインディングについて詳しくは、http://www.w3c.org/TR/wsdl を参照してください。
Web サービス・エクスプローラーに関する問題
- Web サービス・エクスプローラーが、
複数のインライン・スキーマを使用する
WSDL ファイルをロードすると、これらのスキーマ全体で参照される型に対して、警告メッセージが生成されます。
「<qualified_type_name> 型の参照が解決されていません」という意味の警告メッセージです。
これらは警告であり、エラーではないため、安全であり無視できます。
- プライベート UDDI レジストリーを持つ
Web サービス・エクスプローラーを使用すると、ビジネス・ノードのパブリッシャー表明書式の管理は、
以下の状況ではロードを行いません。
- ビジネス・ノードを含むレジストリー・ノードにログインしていない。
- ビジネス・ノードを含むレジストリー・ノードにログインしているが、
そのビジネス・ノードは収容されているレジストリーに従来からログインしているユーザー ID/パスワードの所有ではない。
- 基本認証対応の UDDI レジストリーでは、
Web サービス・エクスプローラーを使用して照会または公開することはできません。
この種類のレジストリーの例としては、サーバー上にデプロイして基本認証をオンにしたプライベート・レジストリーがあります。
すべての共通レジストリー
(IBM、
Microsoft、SAP、NTT、
および XMethods) は、この問題の影響を受けません。
- Web サービス・エクスプローラーで拡張検索を使用して、
Cloudscape™
バックエンドで構成されている WAS プライベート UDDI レジストリー中のビジネスを検索する際、
1 つ以上のサービス・インターフェースがパラメーターとして指定されていると、検索が失敗して、
状況ウィンドウに次のように表示されます:
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: すべてのサービス・プロバイダーをリストできませんでした。
------------------------------------------------------------------------------
ネストされた例外:
E_fatalError (10500)
要求の処理中に致命的なテクニカル・エラーが発生しました
: Fault code=Client Fault string=Client Error Fault actor=null Detail=null DispositionReport:
ErrCode=E_fatalError ErrInfoText=E_fatalError (10500) 要求の処理中に致命的なテクニカル・エラーが発生しました。
- XMethods レジストリーには、公開済み Web サービスを検証するための手順が確立されており、
アクセス不能な Web サービスや動作していない Web サービスを削除します。
公開済み Web サービスが削除されないようにするには、WSDL ファイル内のすべての URL
参照先がインターネット上でアクセス可能になっていることを確認してください。
- SAP UDDI Business Registry は、
カテゴリー別ビジネス検索要求で findQualifier が「combineCategoryBags」の場合に
(tModelKey が UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2 と同じ)、E_fatalError を戻します。
以下のエラー・メッセージが状況ウィンドウに表示されます。これは SAP UDDI Business Registry に固有の問題です。
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: すべてのサービス・プロバイダーをリストできませんでした。
------------------------------------------------------------------------------
ネストされた例外:
要求の処理中に致命的なテクニカル・エラーが発生しました
: Fault code=Client Fault string=UDDI Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=要求の処理中に致命的なテクニカル・エラーが発生しました
at com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy.findAllServiceProviders(UDDIWSDLProxy.java:1626)
at FindBusWithQualifier.main(FindBusWithQualifier.java:35)
- SAP UDDI Business Registry が戻すパブリッシャー表明レポートには、
状況が含まれません。
このため、Web サービス・エクスプローラーの Manage Publisher Assertion Form のパブリッシャー表明状況列は、
SAP が戻したレポートでは空白になります。
これは SAP UDDI Business Registry に固有の問題です。
- ビジネス、サービス、またはサービス・インターフェースを
XMethods UDDI レジストリーに公開しようとすると、「SSL ハンドシェーク障害」に関するエラー・メッセージが表示されます。
これは既知の問題であり、IBM
と XMethods が調査中です。
Web サービス・エクスプローラーは、
SAP UDDI (テスト) レジストリー、NTT コミュニケーションズ・レジストリー、
および XMethods レジストリーとのセキュア SSL 接続を確立することができません。
その結果、
ユーザーからのクリデンシャルを必要とする操作は、以下の例外により失敗します
(ディスカバリーなど、クリデンシャルを必要としない操作は、引き続き機能します)。
レジストリー |
エラー |
NTT コミュニケーションズ・レジストリー: |
NTT コミュニケーションズ・レジストリー:
IWAB0135E 予期しないエラーが発生しました。
UDDIWSDLProxyException
[ユーザー ID: <userid> ] の認証トークン取得エラー
ネストされた例外:
org.uddi4j.transport.TransportException: Error opening socket: javax.net.ssl.SSLHandshakeException: certificate expired
|
XMethods レジストリー: |
IWAB0135E 予期しないエラーが発生しました。
UDDIWSDLProxyException
[ユーザー ID: <userid> ] の認証トークン取得エラー
ネストされた例外:
org.uddi4j.transport.TransportException: Error opening socket: javax.net.ssl.SSLHandshakeException:
handshake failure
|
DADX Web サービス
以下の制限は、
DADX ファイルから WSDL 文書を生成するときに適用されます。
-
複数の出力パラメーターを使用した DADX 呼び出し操作のための Java プロキシーの生成は、サポートされていません。
- DADX Web サービスの作成時に、
「IWAB0177E DADX ファイルから WSDL 生成時にエラーが発生しました」というエラー・メッセージが表示されることがあります。
ほとんどの場合、このメッセージは何かのデータベース関連の問題を示すもので、
サーバー・コンソール・ログを点検して問題の詳細を調べてください。次の検査も行ってください。
- DAD (*.dad) ファイルは、DADX グループ・ディレクトリー内になければなりません。
WORF ランタイム環境はこの方法で DAD ファイルを配置します。
- DAD ファイルを RDB から XML マッピング・ファイル (.rmx) へ生成する場合、
DAD ファイルが DADX ファイルと同じフォルダーにあることを確認してください。
DADX グループでは、
JDBC Net ドライバーを指定できます。
DB2® の場合、
Net ドライバー・クラスは COM.ibm.db2.jdbc.net.DB2Driver です。
DB2 の以前のバージョンでは、
db2java.zip ファイルにドライバーが含まれており、
この Zip ファイルをサーバーのクラスパスに追加する必要がありました。
一方、
DB2 バージョン 8.1 以降では、
db2jcc.jar ファイルもサーバーのクラスパスに追加する必要があります。
このファイルは通常、db2java.zip ファイルと同じディレクトリーに配置されます。
必ず、ご使用のマシンの
DB2
クライアント・レベルを、接続先の
DB2
サーバーと同じフィックスパック・レベルにしてください。
DADX Web サービスにある複数出力: 通常は、Web サービス内の複数出力は弊社のツールではサポートされません。
しかし、DADX Web サービスの場合には、
「文書スタイル・グループ・プロパティーの使用」が「true」にセットされていれば、
複数出力が許可されます。
この場合、「文書スタイル」が「true」であれば、
複数出力は 1 つの XML 文書に結合されます。
DADX 生成サポート: ユーザー定義機能は、DADX の生成ウィザードに
リストされますが、現在ユーザー定義機能からの DADX の生成はサポートされていません。
DADX の生成は、DAD ファイル、ストアード・プロシージャー、および SQL ステートメントからのみサポートされています。
UDF を選択すると、単純な DADX スケルトン・ファイルが生成されます。
データ・ソース情報を持つ DADX グループのセットアップWebSphere Application Server を使用して DADX Web サービスをホスティングし、
DADX グループがデータ・ソースを介してデータベースにアクセスするよう構成されている場合、
DADX グループの group.properties ファイルは、次の initialContextFactory プロパティーを使用しなければなりません:
initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactory
また、DADX グループを含むプロジェクトの web.xml ファイルに、以下を追加する必要があります。
(データ・ソース JNDI 名が jdbc/hospital である場合)
<resource-ref id="ResourceRef_1058550453092">
<res-ref-name>jdbc/hospital</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
Universal Test Client の使用
AXIS ランタイム環境での Tomcat サーバーの使用
Linux にインストールされている Axis を使用する
Web アプリケーションがある Tomcat 4.1 および 4.0 サーバーを使用すると、
Web サービス・ウィザードでエラーになることがあります。
サーバーが開始済みで、Web サービス・ウィザードのある時点で再始動が必要な場合は、
Axis によって Tomcat サーバー の停止が妨害されるため、ウィザードがハングすることがあります。
次善策としては、サーバーを停止してから Web サービス・ウィザードを開始し、
Web サービス・アプリケーションのテストを生成して、
ウィザード・ページの「サーバーで実行」を選択解除します。
Web サービス・コマンド行を使用するときの問題
- スペースを含むディレクトリー:
ディレクトリー名にスペースを含むディレクトリーから WSDL2WebService を実行しないでください。
実行すると、生成される compile.bat (または Linux では compile.sh) はコンパイルしません。
- EJB Web サービスを作成するために EJB2WebService を実行した後、
splitWsdl オプションが使用されていると、
生成された EAR をユニット・テスト環境またはリモート・サーバーで実行できません。
これを回避するには、EJB プロジェクトの META-INF の下にある WSDL ディレクトリー全体を、
ルーター Web プロジェクトの WEB-INF にコピーします。
- ローカル・インポートを含む WSDL を使用して
EJB Web サービスを作成するために WSDL2WebService を実行した後、
生成された EAR をユニット・テスト環境またはリモート・ サーバーで実行できません。
これを回避するには、EJB プロジェクトの META-INF の下にある WSDL ディレクトリー全体を、
ルーター Web プロジェクトの WEB-INF にコピーします。
- コマンド行ツールで J2EE 1.4
を使用してワークスペースに生成された EJB クライアントを含む EAR をインポートした後は、
コンパイル・エラーが発生します。 このエラーをフィックスするには、
EJB プロジェクトを右クリックして、「プロパティー」を選択します。
「Java ビルド・パス」に進み、「ライブラリー」タブを選択します。
EJBClientProject/imported_classes(クラス・フォルダー) エントリーを除去します。
EJBServiceClient/imported_classes/Meta-inf/classess クラス・フォルダーを追加します。
「OK」をクリックします。
- コマンド行ツールで J2EE 1.4
を使用してワークスペースに生成されたアプリケーション・クライアントを含む EAR をインポートした後は、
ClassNotFoundException エラーが発生します。
このエラーをフィックスするには、アプリケーション・クライアント・プロジェクトを右クリックして、
「プロパティー」を選択します。
「Java ビルド・パス」に進み、「ライブラリー」タブを選択します。
ApplicationClientProject/imported_classes(クラス・フォルダー) エントリーを除去します。
ApplicationClientProject/imported_classes/Meta-Inf/classess クラス・フォルダーを追加します。
「OK」をクリックします。
HTTP 基本認証による WSDL ファイルのインポート
相対インポートを持ち、HTTP 基本認証が保護されている WSDL
からスケルトンまたはクライアントを生成すると、正しいユーザー ID とパスワードを入力した場合でも、
WSDL ファイルを解決できないことを示すエラー・メッセージが表示されます。
この問題は、インポートするファイルではなく元の
WSDL ファイルを取得するためだけにユーザー ID とパスワードが使用される点にあります。
この問題を解決するには、 ユーザーは、
まずワークベンチにインポートする WSDL ファイルとすべてのファイルをダウンロードして、
ダウンロードした WSDL ファイルからスケルトンまたはクライアントを生成します。
リソース設定が監視されない
Apache Axis 1.0 ランタイム 環境を使用している場合は、
Axis エミッターが常にすべてのサーバー/クライアント
Java
ファイル deploy.wsdd および undeploy.wsdd を再生成します。
サービス生成のシナリオでは、スケルトン実装ファイルがまだ存在しない場合、WSDL2Java は このファイルのみを生成します。
この実装が既に存在する場合は、上書きされません。
チーム開発環境で作業するときの問題
Web
プロジェクトが
ClearCase
®
チーム環境で共用されていると、選択された Web サービス・ランタイム環境が
IBM
WebSphere
または Apache Axis 1.0 である場合に、
Web サービスおよび Web サービス・クライアントの作成時にいくつかの「
ソース管理に追加」ダイアログが開きます。
これらのダイアログが表示されないようにするには、以下のことを行います。
- 「ウィンドウ」メニューから、「設定」を選択する。
- 左側のペインの「チーム」を展開する。ClearCase を選択する。
- 右側のペインで、
「新規リソースを追加する場合」というラベルの付いていたドロップダウンを「自動的にソース管理に追加」に変更する。
- 「OK」をクリックする。
- 「」に進む。
- オープンするダイアログでデフォルトのアクティビティーを選択する。
「OK」をクリックする。
Web サービスの参考文献
「WS-I 準拠 Web サービス説明書の作成、テスト、および妥当性検査」シート、
および「WSDL ファイル説明書からの Web サービスの作成」で、
wsad_install/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_ver/examples
の HelloService.wsdl ファイルを使用している場合は、以下のようにして、
それぞれのランタイム環境に従ってサービス・ポート・ロケーションを変更してください。
IBM SOAP:
location="http://localhost:9080/HelloWorldSample/servlet/rpcrouter"
Apache Axis または
WebSphere ランタイム環境:
location="http://localhost:9080/HelloWorldSample/services/Hello_Port"
所有する wsdl ファイルのインポート中には、
上記のとおりに選択したランタイム環境に合わせて、
ロケーションが正しく設定されていることを確認してください。
Supply Chain Management サンプルを実行できない
- サプライ・チェーン・マネージメントのサンプルでは、
ポートをデフォルトの 9080 ポートから変更する必要がある場合、
SCM-Sample プロジェクトの config.jsp ファイルを変更しなければなりません。
これには再コンパイルが必要です。
ビルド・パスで webservices.jar が欠落しているため、
タスク・リストに次の 2 つのコンパイル・エラーが表示されます。
- このコンパイル単位は、型の欠落 javax.xml.rpc.ServiceException を間接的に参照します。
- インポート javax.xml.rpc を解決できません。
webservices.jar を、SCM-Sample のビルド・パスに追加するには、 以下を行います。
「SCM-Sample」-> 「プロパティー」と進み「java ビルド・パス」を選択して、
「ライブラリー」タブをクリックし、「変数の追加」をクリックして、
WAS_50_PLUGINDIR を選択し、「拡張」をクリックしてライブラリーにジャンプし、
「webservices.jar」を選択して、
「OK」をクリック後、もう一度「OK」をクリックします。