| Oracle® Fusion Middleware Oracle Infrastructure Webサービスの開発 12c (12.2.1) E69973-01 |
|
 前 |
この章では、Oracle Infrastructure Webサービスとの相互運用性を確保するガイドラインを説明します。
この章の内容は次のとおりです。
Webサービス・アーキテクチャの目標は、異機種のビジネス・アプリケーションが円滑に連携することです。アーキテクチャは疎結合され、XML標準に基づいています。Webサービスは、サービス・コントラクトとしてWeb Service Description Language (WSDL)ファイルを定義することで、その背後にあるオペレーティング・システムや開発技術にかかわらず相互に連携するよう設計されています。ただし、サービス・コントラクトが複雑なため、WSDLやSOAPなどの標準の解釈が曖昧になっています。また、ベンダー固有の機能強化や拡張が全体的な相互運用性の妨げとなっています。
ビジネス・アプリケーションは互いのサービスを起動する必要があります。これらのサービスが異なるテクノロジで実装されていることもあります。Webサービスの複雑さが増すと、相互運用がうまくいかないケースも増える傾向にあります。一般に公開されているWebサービスを運用しているとしたら、様々なツールキットを使用している世界中のクライアントがそのWebサービスを起動できるようにする必要があります。同じように、ビジネス・アプリケーションにも、既存のレガシー・システム上に構築されていて、インタフェースの設計があまり一般的でない他ベンダーのWebサービスとの統合または連携が必要な場合もあります。
相互運用性の問題は、プロトコル・スタックのどのレイヤーからも生じる可能性があります。トランスポート・レベルでは、メッセージ交換における双方の当事者が特定の物理的なトランスポート・メカニズムについて合意している必要があります。たとえば、Java以外のプラットフォームを使用している相手にJMSトランスポートの使用を期待することはできません。基本的なHTTPプロトコルを使用した方が、相互運用性が高まる理由はここにあります。メッセージ・レベルでは、任意のデータ・エンコーディングの使用がSOAPで事実上許可されているため相互運用は難しくなります。たとえば、Javaプラットフォームの標準のArrayListは、.NETプラットフォームのSystem.collections.ArrayListには自動的には変換されません。また、相互運用性の問題は、基本的なWSDLやSOAPのレベルでも発生します。高度なWebサービスの開発者は、セキュリティ、信頼性、トランザクション・サービスなどのサービス品質(QOS)機能の実装を開始すると、その他にも様々な難題に直面することになります。
相互運用性の実現は難しい問題です。ただし、適切なガイドラインがあれば、Oracle Infrastructure Webサービスはその他のJava EEベンダーのプラットフォームや、Microsoft .NETプラットフォームなどのJava以外のプラットフォームとシームレスに連携できます。
Webサービスのコミュニティで相互運用性の重要度が増すにつれ、その目標を達成するために多くの組織が設立されました。
SOAPBuildersは、SOAP実装間の相互運用性のテスト・セットの確立に向けて活動する開発者の、緩やかに組織化されたフォーラムです。相互運用性は、このフォーラムの参加者によって共同で定義された一連の正規テストを実施することにより実証されます。
SOAPBuilderコミュニティによって開発されたテストは、全般的にベンダーの慣例に基づいています。ただし、慣例は時とともに変わります。Webサービス・ベンダー、Webサービス開発者およびWebサービスの利用者には、正式にまとめられた、不要なものの混じっていないはっきりとしたルールが必要です。SOAPBuilderのテストの詳細は、次のWebサイトを参照してください。http://java.sun.com/webservices/interop/soapbuilders/index.html
Web Services Interoperability (WS-I)は、Webサービス間の相互運用可能なメッセージ交換のための一般的なプロトコルの作成、普及、サポートを行う業界のオープンな組織です。WS-Iプロファイルは、標準の適用方法に関するガイドラインおよび推奨事項です。これらのプロファイルは、基礎となる仕様に制約を追加して曖昧さをなくすことを目的としています。
WS-Iの成果物は、プロファイル、一般的なプラクティスまたはベスト・プラクティス、シナリオ、テスト・ソフトウェアおよびテスト資料です。Webサービスは、WS-I Basic Profileに準拠するように設計する必要があります。WS-Iに準拠したサービスは明瞭なコントラクトに同意しており、相互運用性を実現する可能性が高くなります。
たとえば、WS-I Basic Profileに準拠しているWebサービスでは、次の機能を使用する必要があります。
トランスポート・バインディングとしてHTTPまたはHTTPSを使用します。HTTP 1.0よりもHTTP 1.1が優先されます。
literalスタイルのエンコーディングを使用します。SOAPエンコーディングは使用しないでください。
より厳密なフォルト・メッセージ構文を使用します。MESSAGEにsoap:Fault要素が含まれている場合、その要素の子は非修飾である必要があります。
XMLバージョン1.0を使用します。
サービスでは、規則ArrayOfXXXを使用した配列ラッパー要素の宣言はできません。
WS-Iプロファイル、およびプロファイル内に定義されているルールの詳細は、WS-IのWebサイト(http://www.ws-i.org/)を参照してください。
OracleはWS-I組織のメンバーで、顧客が相互運用性を実現する手助けとなるよう取り組んでいます。Oracle Infrastructure Webサービス・プラットフォームは非常に柔軟性が高く、相互運用性のあるWebサービスの作成を支援します。
Oracle JDeveloperでは、WSDLファイルの統合テストおよびWS-I Basic Profile準拠のWebサービスの実行をサポートしています。監視およびロギング用の拡張HTTPアナライザが用意されており、相互運用性の問題をより詳細に診断する組込みの分析およびレポート・ツールも提供されています。詳細は、Oracle JDeveloperのオンライン・ヘルプを参照してください。
一般的なガイドラインの1つ目は、可能な場合にはWS-Iに準拠したWebサービスを作成することです。ただし、WS-Iプロファイルですべての相互運用性の問題が解決するわけではありません。WS-Iプロファイルが存在する以前から、多くのWebサービスが実装されていました。また、Webサービスとして有効化しているレガシー・システムにより、設計が制限される場合もあります。そのため、可能な場合には、開発プロセスの初期段階からWebサービス設計の秘訣を取り入れることです。
この理由のため、相互運用性のあるWebサービスの作成時に次の一般的なガイドラインに従うことをお薦めします。
Webサービスをトップダウン方式で設計する
最初はXSDを使用してデータ型を設計する
データ型はシンプルにする
NULL値は慎重に使用する
WSDLの検証にコンプライアンス・テスト・ツールを使用する
各プラットフォームにネイティブの型の違いを考慮する
RPC-encodedメッセージ書式は使用しない
名前の競合を回避する
メッセージ・ハンドラ、カスタム・シリアライザまたはインターセプタを使用する
WS-*仕様は慎重に適用する
詳細は、次を参照してください。
WSDLからのトップダウン方式を使用することにより、プラットフォームや言語に固有の特徴に制限されないサービス・コントラクトからWebサービスを設計できます。コントラクトレベルの相互運用性は、Webサービスの実装前から確保できます。他のWebサービス・プラットフォーム・ツールでWSDLファイルを処理できるようになり、サービスが既存のレガシーAPIに影響される可能性も低くなります。
可能な場合には、XSDスキーマ・エディタを使用してスキーマ型を持つデータ型を設計します。.NETのDataSetデータ型やJavaコレクションなど、プラットフォーム固有のデータ型の使用は避けます。
xsd:choiceなどの不必要に複雑なスキーマ・データ型の使用は避けます。最高の相互運用性はシンプルなデータ型により実現され、パフォーマンスの向上という利点ももたらします。
詳細は、次を参照してください:
可能な場合は、1次元配列を使用します。多次元配列ではなく、配列の配列を使用します。
(RPCエンコード形式でのみ適用される)多次元配列は、.NETプラットフォームではサポートされていません。また、多次元配列の場合は、内部配列の長さが同じである必要があります。配列の配列を使用した方が、内部の配列の長さが異なってもかまわないという点で柔軟性があります。
|
注意: XSDではWSDLでの多次元配列の定義がサポートされていますが、Javaなどのプログラミング言語ではそれらが配列の配列にマッピングされ、ペイロードが多次元形式で表示されます。ペイロードが多次元形式に変換されるときに、Java VMによって各内部配列の長さが同じであることが確認され、その他のチェックも実行されます。 |
問題を回避するには、空の配列と配列へのNULL参照とを区別してください。
たとえば、minoccurs=0およびxsd:nillable=trueという属性を含む配列がある場合、サービス実装がこの配列へのNULL参照を返そうとすると、ペイロードの表示に問題が発生します。ペイロード内のminoccurs=0としてのこの要素を完全に無視されるような実装もあれば、ペイロード内のこの要素を属性xsi:nil=trueで指定するような実装もあります。
同じ問題が、配列をデシリアライズしようとした場合にも発生します。NULL参照にデシリアライズすることも、何も要素を含まない配列にデシリアライズすることもできます。この場合のガイドラインは、必ず長さチェックの前にNULLをチェックすることです。
XSDではスパース配列、可変サイズ配列および多次元配列がサポートされていますが、ターゲット・プラットフォームではサポートされていないこともあります。WebサービスをWSDLからトップダウン方式で作成する場合は、これらの配列タイプの使用を避け、通常の配列を使用してください。
通常、xsd:anyTypeはJavaプラットフォームでjava.lang.Objectにマッピングされます。これにより、個別のシリアライザおよびデシリアライザの登録を必要とするランタイムを通過することができます。ガイドラインは、ランタイムで使用可能なすべてのタイプを見つけて、それらをWSDLで定義することです。
次の例は、MyAnyTypeというクラスと、それを拡張するMyPossibleType1およびMyPossibleType2という2つのクラスを示しています。この場合は、Webメソッド内でxsd:anyTypeのかわりにMyAnyTypeを使用します。
public class MyAnyType {
//No member variable
}
public class MyPossibleType1 extends MyAnyType {
//member variable.
}
public class MypossibleType2 extends MyAnyType {
//member variable
}
..
WSDLでサポートされていないxsd:typeが1つあるだけで、相互運用性に影響を及ぼす可能性があります。簡単な回避策は、JAX-RPCマッピング・ファイルなどのマッピング・メカニズムを使用して、サポートされていないXSDタイプをSOAPElementにマッピングすることです。サポートはされているが実行時に失敗するような型も、SOAPElementにマッピングして、クライアントまたはサーバーの内部でSOAPElementを解析することができます。
NULL値を使用して行う処理を決定します。たとえば、配列型にNULL値を許可しますか。NULL文字列または空の文字列を使用しますか。プラットフォーム間でNULL値を送信すると、受信者側で例外の原因となりますか。
可能な場合は、NULL値を送信しないようにします。アプリケーションでどうしてもNULL値を使用する必要がある場合は、NULL値が許可されていることが明確にわかるようにスキーマ型を設計します。
WebサービスがWS-Iに準拠するよう設計されている場合は、WS-Iモニタリング・ツールを使用してメッセージを記録し、分析ツールを使用して準拠しているかどうかを検証します。WS-Iツールは、Webサイトhttp://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools/から無料でダウンロードできます。
xsd:unsignedshortやxsd:unsignedintなどの一部のスキーマ型には、必ずしもネイティブのデータ型のダイレクト・マッピングがあるわけではありません。たとえば、Javaプラットフォームに相当する符号なし型はありません。xsd:double、xsd:float、xsd:decimalなどのスキーマの数値型は、一度プラットフォームにネイティブのデータ型にマッピングされると精度が変わることがあります。
また、xsd:string型には制限があります。文字列には不正なXML文字を含めることはできず、\r(キャリッジ・リターン)文字は通常は\n(改行)文字にマッピングされます。
ソース・データで使用されている文字セットがわからない場合は、xsd:stringでなくbyte[]を使用してください。バイナリ・コンテンツの方がテキスト・コンテンツよりも運用性が高くなります。
Javaクラスからボトムアップ方式でWebサービスを作成する場合は、可能なかぎり最も近いデータ型を使用します。したがって、よりxsd:typeに近いJavaデータ型を使用してください。たとえば、日時を表すためにxsd:dateTimeを使用する場合は、java.lang.Dataやjava.util.Calendarではなくjavax.xml.datatype.XMLGregorianCalendarデータ型を使用します。XMLGregorianCalendarデータ型の方が、小数秒を格納できるため、より正確な時刻を返すことができます。
WSDLからトップダウン方式でWebサービスを作成する場合は、時刻の正確性が非常に重要であれば、マッピング・ファイルを使用してxsd:dateTimeをXMLGregorianCalendarにマッピングします。
|
注意: Java EE以前のプラットフォーム(J2EE 1.*など)ではすべてCalendarを使用していましたが、現在のJava EE準拠プラットフォームではXMLGregorianCalendarを使用しています。この方が長い小数秒を処理できるため、.Netの相互運用性が高くなります。 |
RPC-encodedメッセージ書式自体に、他のプラットフォームやクライアントとの相互運用性がないわけではありません。今日稼働しているWebサービスの多くは、RPC-encodedです。RPC-encodedメッセージ書式の使用を避ける理由は、基礎となる仕様の解釈や実装の選択の違いが相互運用性の妨げになるという問題を回避するためです。たとえば、スパース配列、多次元配列、カスタム・フォルト・コードQName、un-typedペイロードなどの処理がその例です。
Javaクラスからボトムアップ方式でWebサービスを作成する場合、クラス内に明示的なパッケージ名を使用することにより名前の競合を回避できます。WSDLからトップダウン方式でWebサービスを作成する場合は、一意のネームスペースURIを使用することにより名前の競合を回避できます。
|
注意: トップダウン・アプローチを使用しているほとんどのWebサービス・アセンブリ・ツールでは、デフォルトで、生成されたクラスのパッケージ名をネームスペースURIから導出しようとします。ボトムアップ・アプローチを使用しているツールでは、Javaパッケージ名を使用してネームスペースURIを導出しようとします。有効なパッケージ名の制限のため、この導出は1-1ではありません。したがって、ネームスペースURIの指定は、別のネームスペースURIにより生成されたパッケージと名前が競合することがないように行うことが非常に重要です。 |
メッセージ・ハンドラ、カスタム・シリアライザまたはインターセプタを使用すると、相互運用性の問題を簡単に修正できます。これは、デシリアライザで処理される前、またはシリアライザによりペイロードが生成されてからワイヤ書式になるまでに、ペイロードに関する問題を非常に細かいレベルで修正するという考え方です。
多くのWS-*仕様はまだ導入の初期段階であり、多様なスタックを持つ相互運用性の問題を浮き彫りにする可能性もあります。WS-*機能を適用する前に、それが本当に必要かどうかを確認することをお薦めします。あるいは、Webサービスの領域で最も一般的に使用されている機能を適用することをお薦めします。たとえば、セキュリティに対して基本認証、X.509またはKerberosを選択する場合など、使用可能なオプションが複数あれば、Webサービスの領域で最も一般的に使用されているオプションを選択してください。
