|
Oracle BPEL PM プロジェクトは、コマンド ラインや Oracle JDeveloper から、または Ant タスクを使用して Oracle Enterprise Repository に送信できます。
Harvester では、以下のようなアーティファクトをスキャンし、それらを収集して相互の依存関係を検出します。
Harvester では、Oracle Enterprise Repository でこれらのアーティファクトのエンティティを作成し、そのエンティティ間の関係を作成します。
図 3-1 は、Harvester で作成されるアセットの種類とそれらの関係を示しています。

BPEL アーティファクトが Oracle Enterprise Repository に送信されると、Oracle Enterprise Repository では以下の処理が行われます。
WSDL アーティファクトが Oracle Enterprise Repository に送信されると、Oracle Enterprise Repository では以下の処理が行われます。
XSD アーティファクトが Oracle Enterprise Repository に送信されると、Oracle Enterprise Repository では以下の処理が行われます。
XSL アーティファクトが Oracle Enterprise Repository に送信されると、Oracle Enterprise Repository では以下の処理が行われます。
Oracle BPEL PM プロジェクトが Oracle Enterprise Repository に送信されると、Harvester では以下に関する具体的な情報を検索します。
Oracle BPEL PM では、次の形式を使用して具体的な WSDL URI を作成します。
<host>:<port>/orabpel/<BPELDomain>/<processName>/<version>/<ServiceName>?wsdl
Harvester では、プロパティ ファイルの値を使用して URI を作成します。作成された具体的な WSDL URI の例を次に示します。
http://localhost:8888/orabpel/default/OrderBooking/1.7/OrderBooking?wsdl
bpel.xml にある具体的なバインディングにバインドされます。このファイルは収集されるため、依存関係のあるサービスの実行場所に関する具体的な情報は Oracle Enterprise Repository で更新されます。
Harvester では、WSDL、BPEL、XSD などのファイルをアーティファクトとして Oracle Enterprise Repository に格納します。同じアーティファクト ファイルを 2 回格納しないようにするために、Harvester では、各アーティファクトの格納時にそのアーティファクトのソフトウェア ファイル ID (SFID) を計算します。新しいアーティファクトを送信する前に、SFID をリポジトリ内の既存の SFID と比較して、重複がないかどうかを確認できます。
計算される SFID は MD5 ハッシュです。SFID を計算する前には、いくつかのレベルの正規化が行われます。特にアーティファクト ファイルが XML の場合、そのファイルは Apache XML セキュリティ ライブラリの Canonicalizer クラスを使用して正規化されます。この正規化は W3C の「Canonical XML」標準 (www.w3.org/TR/xml-c14n を参照) に従って行われ、テキスト エンコーディング、改行、ホワイトスペース、コメント、および属性の順序の正規化が含まれます。これ以外にも、W3C 標準には指定されていないいくつかの正規化が行われます。これには、ネームスペース プレフィックスの正規化、WSDL の要素の順序の正規化、ドキュメント要素の削除、インクルード/インポートされるファイルのインライン化が含まれます。
Harvester では、「ビジネス プロセス」、「インタフェース」、および「エンドポイント」からダウンロード可能なアーティファクト バンドルを作成します。これらのアセットのアーティファクト バンドルは zip ファイルに格納されます。たとえば、「エンドポイント」の場合、WSDL ファイルとそれに関連付けられた XSD ファイルが zip のペイロード内の相対的な場所に格納されます。
あるアーティファクトが別のアーティファクトをインポートする (例 : WSDL が XSD をインポートする) 場合、親アーティファクトは自身を基準とした相対パスにある子アーティファクトを必ず参照します。たとえば、MyWSDL.wsdl が c:\temp にあり、インポートされる子の XSD が c:\temp\schemas\MyXSD.xsd にある場合、親の MyWSDL.wsdl は相対パス「./schemas/MyXSD.xsd」を使用して子をインポートします。バンドルがダウンロードされる場合は、親アーティファクトを基準とした相対パスにある「schemas」というフォルダに子アーティファクトを作成して、親が子を解決できるようにする必要があります。
Harvester の実行後は、次の手順に従ってアセット バンドルをダウンロードできます。
| 注意 : | アーティファクト バンドルにペイロードとして含まれているアーティファクトが 1 つだけの場合、ペイロードは zip ファイルで提供されるのではなく、直接提供されます。 |
一連のファイルを収集し、そのうちのいくつかを変更してから、もう一度バンドルを収集する場合は、ダウンロード ページで複数のペイロード (順序は収集日の新しいものが先になります) をダウンロードに使用できます。
次の手順は、Oracle JDeveloper でサンプルの BPEL プロジェクトを作成して BPEL エンジンにデプロイし、アーティファクトの依存関係とデプロイメントの情報と共に Oracle Enterprise Repository に送信する方法を示しています。
{http://xmlns.oracle.com/TestBPELProject}BusinessProcess/TestBPELProject
Harvester では、各アセットに、クエリに使用できるプロパティがタグ付けされます。
図 3-5 は、「書き込み (Write)」操作を呼び出す「ビジネス プロセス」に対するクエリの方法を示します。検索画面を表示するには、Oracle Enterprise Repository Web コンソールのメイン ページにある [More Search Options] をクリックします。
![Oracle Enterpise Repository の [More Search Options] ダイアログ ボックスの表示](wwimages/query.gif)
この節では、Harvester のベスト プラクティスについて説明します。
アセットを収集する必要があるのは、レジストラまたは Oracle Enterprise Repository のすべてのアセットを表示する権限を持つユーザだけです。リポジトリ内のすべてのアセットを表示するパーミッションがユーザにない場合は、既存のアセットおよび誤って作成された重複アセットを収集できます。
ユニークなインタフェース、サービス、およびエンドポイントにはユニークなネームスペースを使用することをお勧めします。
Oracle Enterprise Repository の既存のアセットとの相関は QNames 経由で行われるため、インタフェース、サービス、またはエンドポイントの各アセットを大幅に変更し、QNames を変更しない場合は、変更されたアセットで既存のアセットを上書きします。
表 3-1 は、Oracle Enterprise Repository のアセットと WSDL 構造との相関を示しています。
完了した作業またはもうすぐ完了する作業のみ収集することをお勧めします。デプロイメント環境からの収集を定期的に行うと、Oracle Enterprise Repository が古いバージョンのアセットでいっぱいになる可能性があります。
一部のスキーマ開発パターンにはスキーマの「メンテナンス リリース」が含まれます。このリリースでは、障害を修正して若干の構造を追加しますが、スキーマのネームスペースは変更されません。若干の変更があったスキーマのアーティファクトをその後に収集すると、リポジトリ内に大量の新しいアーティファクト アセットを作成する場合に影響を与える可能性があります。Oracle Enterprise Repository では、アーティファクトのコンテンツのハッシュ (ソフトウェア ファイル ID (SFID)) に基づいてアーティファクト アセットを関連付けます。SFID は、すべてのインポートとインクルードがインライン化された後に、各アーティファクトのコンテンツで計算されます。したがって、WSDL によってインポートされる XSD で変更を行うと、新しい XSD アーティファクトと新しい WSDL アーティファクトが作成されます。
これは、企業全体で幅広く使用されるスキーマを検討する場合に特に重要です。たとえば、他のスキーマ、WSDL、XSLT、BPEL などによって広くインポートされる下位のスキーマ (例 : customer.xsd) があるとします。customer.xsd に対する重要な変更を行い、その後に企業のすべてのアセットを再収集する (何らかの定期的なバッチ収集など) と、customer.xsd を直接または間接的に参照する同様の大量のアーティファクト アセットがリポジトリ内に作成されます。
この節では、Harvester で確認済みのいくつかの問題について説明します。
Harvester の機能を使用するための前提条件として、システム内にアセットの種類が存在する必要があります。必要なアセットの種類は、Harvester Solution Pack と共にインストールされます。
Oracle Enterprise Repository の一部の既存のアセットの種類の名前が Harvester Solution Pack と共にインストールされたアセットの種類と同じである場合、Harvester のアセットの種類の名前にはバージョン番号が追加されます。これは、Harvester のアセットの種類の機能に影響を与えません。
Harvester では、収集プロセスでアセットを作成する場合に、internal.inspector.store および internal.introspector.manifest.store という種類のメタデータ エントリをアセットに追加します。これらのメタデータ エントリは変更または削除できません。メタデータ エントリを変更または削除すると、システムの予期しない動作が生じる可能性があります。
Oracle Enterprise Repository のユーザ インタフェースを使用してこれらのメタデータ エントリを削除することはできません。
|