ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ
11g リリース1(11.1.1.3)
B61433-01
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

4 サービス構成

この項では、Oracle Service Busが提供するサービス構成とリソース編成機能について説明します。サービス検出と変更管理をサポートしている機能を取り上げます。この項は、SOAにおいてサービスの構成を担当するITデプロイメントのスペシャリストを対象としています。この項では、以下のトピックについて説明します。

4.1 リソース編成

Oracle Service Busにはリソースの作成と編成、構成を行うための堅牢なリソース構成および編成フレームワークがあり、リソース依存関係間でのセマンティクスの整合性が保たれています。リソースを迅速にテストおよびデプロイし、必要に応じてリソース構成の更新を元に戻す機能が備わっています。

4.1.1 プロジェクト・エクスプローラ

Oracle Service Busに組み込まれているプロジェクト・エクスプローラでは、Oracle Service Busエンティティの論理的なグループ化ができるので、開発者や管理者は大きな開発プロジェクトにおいて関係のある部分をより適切に編成できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のプロジェクト、フォルダおよびリソースの使用に関する項を参照してください。

4.1.2 プロジェクトとフォルダ

Oracle Service Busのリソースは独立したプロジェクトに編成することができます。プロジェクトは階層化されない、独立した最上位のグループ構造です。すべてのリソース(サービス、WS-Policy、WSDL、XQuery変換など)は、重複することなく1つのプロジェクトのみに含まれます。

リソースはプロジェクトの直下に作成することも、整理用にフォルダを作成したうえで、フォルダ内に作成することもできます。フォルダはプロジェクトの中に作成されることも、他のフォルダの中に作成されることもあり、プロジェクト・レベルをルート・ディレクトリとするファイル・システムのディレクトリに似ています。すべてのプロジェクトおよびフォルダには、ナビゲーションをさらに容易にするために、説明を追加することができます。図4-1は、Oracle Service Busコンソールのプロジェクト・ビューとフォルダ・ビューです。

図4-1 Oracle Service Busプロジェクトとフォルダのプロジェクト・エクスプローラ・ビュー

図4-1の説明が続きます
「図4-1 Oracle Service Busプロジェクトとフォルダのプロジェクト・エクスプローラ・ビュー」の説明

リソースをプロジェクト間またはフォルダ間で移動したり、リソースの名前を変更することができます。Oracle Service Busのすべてのリソース、プロジェクト、またはフォルダは、クローンを作成して、指定されたターゲットIDを使用してリソースのコピーを作成できます。プロジェクトまたはフォルダのクローンを作成すると、そのプロジェクトまたはフォルダのすべてのアーティファクトが別の場所にコピーされます。

プロジェクト内のリソースから、別のプロジェクトで定義されたリソースを参照および使用できます。リソースの名前を変更したり、リソースを移動したりしても、依存関係は維持されます。名前を変更されたリソースまたは移動されたリソースに対するすべての参照は自動調整されます。プロジェクト・エクスプローラには、現在のフォルダの外側にあるどのリソースが、フォルダ内にあるリソースから参照されているかを追跡する追加の機能があります。この参照を表示することで、参照されているリソースがある場所(<project name>/<folder name>/<resource name>の形式)と、参照されているリソースの種類の両方を知ることができます。参照されているリソースの詳細は、4.2.5項「依存関係の追跡」を参照してください。

4.1.3 リソース・キャッシュ

Oracle Service Busには、リソース・キャッシュ内の大量のリソースを整理するためのいくつかの機能があります。Oracle Service Busリソース・キャッシュに保持されるリソースには、WSDL、XMLスキーマ、XQuery、XSLT、MFL、WS-Policy、ビジネス・サービス、プロキシ・サービスなどがあります。Oracle Service Busでは、メッセージの処理方法を決定する際に、リソースおよびサービスに関するユーザー構成メタデータに依存します。

Oracle Service Busは、リソース・キャッシュ内のリソースやサービスの管理を担当する信頼あるIT部門スペシャリストを支援することに重点を置いています。このようなユーザーはすべてIntegration AdministratorまたはIntegration Deployerとして定義され、リソース・キャッシュ内のすべてのリソースを変更するための完全なパーミッションが与えられます。Integration Monitorユーザーにはリソース・キャッシュに対する完全な読込みアクセス権が与えられますが、リソースの変更はできません。通常、Integration Monitorユーザーはリソースやサービスの検索や参照を行います。Integration Operatorユーザーには、リソース・キャッシュに対する完全な読込みアクセス権が与えられ、サービスの動作特性だけを変更できます。

Oracle Service Busのユーザーとロールの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のセキュリティ構成に関する項を参照してください。

4.2 変更管理

この項では、Oracle Service Busの変更管理について説明します。

4.2.1 チェンジ・センター

チェンジ・センターは、Oracle Service Busの最も重要な機能の1つであり、サービス・バス内で構成の変更を行うための鍵となります。チェンジ・センターには、変更を行っている最中に現在の構成をロックするというユニークな機能があります。この機能により、サービス・バスでサービスについてのリクエストの受信と処理を継続しながら、コンソールから構成の変更を行うことが可能になっています。

さらに、変更中の構成が「アクティブ化」されるまで、現在のシステムの構成は影響を受けません。アクティブ化が行われると変更は即座に有効になり、サービス・バスでは直ちに新しい構成が使用されます。このようにして、進行中の変更はサービスに影響を与えることなく実行することができます。チェンジ・センター機能の詳細は、

アクティブ化された変更によって、予期しない不都合なイベントが発生した場合に備えて、チェンジ・センターには任意のセッションで行われた変更を取り消す機能も用意されています。「タスクの詳細」には、変更されたリソース、変更を行ったユーザー、および変更が行われた時間についての情報が表示されます。セッション全体またはセッション内の個別の変更をロール・バックすることが可能なので、Oracle Service Busでは影響を受けた構成を以前の状態にロール・バックできます。

チェンジ・センターの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

4.2.2 セッション

Oracle Service Busでリソースを変更する前に、セッションを作成する必要があります。Oracle Service Busコンソールでのすべての変更は、特定のセッション内で行います。

図4-2 チェンジ・センターでのセッション管理

図4-2の説明が続きます
「図4-2 チェンジ・センターでのセッション管理」の説明

セッションは、変更を行っているユーザー以外にはその変更内容が公開されないサンドボックス環境と考えることができます。つまり、変更内容は、変更を行っている他の同時ユーザーからは見えません。セッション内で行われた変更は、セッションがアクティブ化されるまではサーバーにデプロイされません。一度にアクティブ化できるセッションは1つに限られるため、Oracle Service Busコンソールへのログインは1つのブラウザのみで行ってください。

特定のセッションで変更されたリソースとランタイムにデプロイされているリソースを比較するには、一度セッションを終了し、デプロイされているリソースを参照してからセッションを再開し、変更されたリソースを参照します。セッション内のすべてのリソースを見ることができます。セッション内のすべてのリソースを表示するビューをセッション・ビューと呼びます。セッション・ビューは、デプロイされている未変更のリソースのビューと現在のセッションで変更されたリソースのビューを結合したビューです。セッションがアクティブ化されていれば、セッション・ビューには常に構成の状態が示されます。セッションの外部のリソースのビューは、デプロイされているリソースのビューです。

セッションの個々の変更、アクティブ化、およびセッションの取消し操作はトランザクションとして行われ、障害時のデータ消失を防ぎます。セッションは永続的で長時間継続でき、サーバーを再起動してもアクティブなセッションは失われません。そのため、必要に応じて、1つのセッションでの構成の変更を、数日間にわたって継続できます。その間、サーバーを停止および再起動してもかまいません。ユーザーごとに固有のセッションを持ち、他のユーザーをシステムからロック・アウトする必要もなく、独立して操作を行うことができます。

別のユーザーがセッションのアクティブ化を実行しているときにセッションをアクティブ化することはできません。別のユーザーがセッションのアクティブ化を実行していると、「アクティブ化」ボタンが無効になり、そのセッションのアクティブ化が完了するまでは、セッションをアクティブ化できません。ページを更新していない場合や直接MBeanを使用している場合には、「アクティブ化」ボタンが無効にならないことがあります。この場合はやがてタイムアウトします。

管理者には、他のユーザーのセッションにアクセスし、変更中の内容を参照して、セッションを更新または破棄する権限があります。

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

4.2.3 同時変更

セッションでは、競合にオプティミスティック方式を使用します。セッションをアクティブ化すると、そのセッションで行ったリソースの変更が他のセッションにすぐに表示されます。別のユーザーのアクティブなセッションで開いている、変更されたリソースをデプロイすると、そのユーザーのセッションでは、変更の開始以降にデプロイされているリソースがランタイムで変更されたことを示すメッセージをチェンジ・センターで受信します。ここで、アクティブなセッションのユーザーは次の操作を実行できます。

  • 現在のセッションでのそのリソースに対する変更を破棄します。セッションのリソースは、新しくデプロイされたリソースで更新されます。

  • 現在のセッションをアクティブ化します。これにより、実行時のリソースは現在のセッションの変更内容で上書きされます。これはデフォルトの動作です。

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。

4.2.4 構成の変更の追跡

セッションをアクティブ化したすべてのユーザー、およびセッションで変更されたリソースと変更日時のログがシステムで保持されます。このログは、特定のリソースまたはプロジェクトの変更履歴となるだけでなく、企業における監査および追跡にも使用できます。ログは、Oracle Service Busコンソールのチェンジ・センターで参照できます。

4.2.5 依存関係の追跡

大量のリソースを管理するうえで重要な要素として、リソース間の依存関係の設定と調査があります。たとえば、サービスが実装するWSDLや、メッセージ・フローの構成で使用されるXQueryが識別されると便利です。Oracle Service Busにはリソース間の参照を自動追跡し、依存関係のグラフを作成する機能があります。Oracle Service Busコンソールのセッション・ビューおよびデプロイされたビューでは、特定のリソースに関する次の情報が表示されます。

  • 参照先リソース

  • 参照元リソース

また、Oracle Service Busコンソールでは、プロジェクトおよびフォルダごとに、選択されたプロジェクトまたはフォルダ内のリソースを参照する外部リソースが表示されます。Oracle Service Busコンソールは特定のプロジェクトまたはフォルダが参照するリソースも表示します。これらの情報が依存関係の追跡に役立ちます。Oracle Service Busコンソールで参照されているリソースの名前をクリックするだけで依存関係のグラフを簡単に辿ることができます。

この機能を使用して、リソース・キャッシュ内の部門プロジェクト間の依存関係や、部門プロジェクトと全社的な共有プロジェクトとの依存関係を識別することができます。

リソースの名前を変更したり、リソースを移動したりしても、依存関係は維持されます。名前を変更されたリソースまたは移動されたリソースに対するすべての参照は自動調整されます。

4.2.6 セマンティクスの整合性

Oracle Service Busでは、セッション・ビュー内のすべてのリソースの整合性が保護されます。セッション・ビュー内のすべてのリソースの現在の検証エラーのすべてを一覧表示するには、チェンジ・センターで「競合の表示」リンクをクリックします。参照先リソースを変更すると、参照元のリソースで検証エラーが発生する可能性があります。

Oracle Service Busでは、多くの場合セマンティクス・エラーがあるリソースを作成できますが、これらのエラーをすべて修正するまでセッションをコミットできません。

検証エラーの一部のクラスは一切許容されません。許容されない検証エラーがあるリソースを更新しようとすると、更新は失敗します。たとえば、構成でXQueryの使用が指定されている箇所で、XQueryのかわりに任意のテキストを入力することはできません。任意のテキストを入力すると、更新は失敗します。Oracle Service BusコンソールのXQueryエディタおよびXPathエディタには、式を検証する機能があります。設計時にXQuery式およびXPath式を検証するには、「検証」をクリックします。検証により、無効な構成が原因となる実行時エラーが発生する可能性が低くなります。

4.2.7 リソースとセッションに対する変更の取消し

現在のセッションのOracle Service Bus構成で実行したタスクを取り消したり、セッションの外部で行った、セッションのアクティブ化を取り消すことができます。

4.2.7.1 リソース変更の取消し

セッションでの作業時に、そのセッションで行った変更のリストを表示するには、チェンジ・センターで「変更の表示」をクリックします。特定のタスクをチェンジ・センターで取り消すことができます。取消し操作を実行すると、オブジェクトのセマンティクスが無効になる場合があります。たとえば、WSDLのオペレーション名の変更を取り消すと、そのWSDLを使用するサービスの該当オペレーションにルーティングするプロキシ・サービスのセマンティクスは無効になります。これらの検証エラーは、チェンジ・センターで「競合の表示」リンクをクリックすると、すぐに表示されます。

タスクの取消しはどのような順序でも(個々の取消し操作を行った結果のデータが有効である限り)実行できますが、取り消す順序によって最終的な構成が異なる場合があります。取消し操作によって、リソースの値が、そのリソースを変更する前の値に設定されます。取り消そうとしているタスクがオブジェクトを作成したタスクである場合、そのオブジェクトには戻すことができる前の状態がありません。つまり、このタスクを実行する前は、オブジェクトが存在しませんでした。実際には、取消し操作により、セッションから作成したオブジェクトが削除されます。この場合、削除されるオブジェクトを参照するオブジェクトにエラーが発生します。このようなエラーは、チェンジ・センターの「競合の表示」ページで確認できます。

4.2.7.2 セッションのアクティブ化の取消し

セッションで作業していないときに、セッションのアクティブ化のリストを表示するには、チェンジ・センターで「変更の表示」をクリックします。セッションのアクティブ化をチェンジ・センターで取り消すことができます。セッションを取り消すと、そのセッションのアクティブ化が取り消され、そのセッションで実行された操作がすべて取り消されます。セッションのアクティブ化を取り消す操作によって実行時構成にエラーが発生する場合は、セッションのアクティブ化を取り消すことはできません。

たとえば、デプロイメントを取り消すと他のオブジェクトによって参照されているオブジェクトが削除される場合は、このデプロイメントの取消し操作は実行できません。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のタスクの取消しに関する項を参照してください。

4.3 サービス検出

この項では、Universal Description, Discovery and Integration (UDDI)を使用するOracle Service Busのサービス検出機能について説明します。

4.3.1 UDDIレジストリ

UDDIレジストリは、企業でWebサービスを共有するために使用されます。UDDIサービスを使用することで、企業はこれらのWebサービスを整理およびカタログ化し、企業内または信頼できる外部のパートナと共有および再利用できます。

Web サービスのUDDIレジストリ・サービスは、http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3にあるUDDI仕様で定義されています。

UDDIレジストリは、この仕様に基づいています。この仕様には、UDDIを使用してWebサービスの情報をパブリッシュおよび検索する方法の詳細が記載されています。サービスの実行時の仕様は定義されません(単なるサービスのディレクトリです)。UDDIは、企業のビジネス、ビジネス・サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。

レジストリへサービスをパブリッシュするには、サービス・タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。レジストリ・エントリには、特定のプロパティが関連付けられ、これらのプロパティ・タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。

Oracle Service Busで開発されたプロキシ・サービスは、UDDIレジストリにパブリッシュできます。Oracle Service Busは、Oracle Service Registryを含めたUDDI 3.0準拠の任意のレジストリに対応しています。

図4-3 Oracle Service BusとUDDIの統合

図4-3の説明が続きます
「図4-3 Oracle Service BusとUDDIの統合」の説明

4.3.2 UDDIレジストリの利点

UDDIを使用することにより、コードの再利用が増えるなど、設計時にも実行時にもIT管理者にとって様々な利点があります。開発者にも次のような利点があります。

  • プロキシ・サービスの情報をレジストリにパブリッシュすることでインフラストラクチャの管理が向上し、サービスを検索しやすいように分類できます。そのため、サービス・ポートフォリオの増大と共に、サービス間の関係、コンポーネントのバージョン管理、および依存関係の把握および管理が容易になります。

  • UDDIサービスをレジストリからインポートして、Webサービスを呼び出すために必要なパラメータ、および必要な転送プロトコルとセキュリティ・プロトコルを構成できます。

  • 規格準拠のWebサービスの使用およびビジネス・アプリケーションでのビジネス・サービスの開発を促進し、Webサービス開発者にリソース・ライブラリへのリンクを提供します。これによって、開発のライフサイクルが短縮され、生産性が向上します。また、規格準拠のリソースを共有することで、ビジネス・アプリケーション間の相互運用性の実現の可能性が増加します。

  • Webサービスの検索と検出のためのユーザー・フレンドリなインタフェースを提供します。ユーザーが指定した条件で検索できます。

Oracle Service Registry

Oracle Service Registryは、バージョン3に準拠したUDDIレジストリでOracle Service Busでの動作が認定されています。Oracle Service RegistryはOracle Service Busには付属していません。

Oracle Service Registryについては、Oracle Service Registry製品のドキュメントを参照してください。

Oracle Service Busコンソールを使用すると、Oracle Service Registryまたはバージョン3 UDDI準拠の任意のレジストリにアクセスでき、簡単に使用できます。Oracle Service BusをUDDIと組み合せて使用することにより、規格ベースのWebサービスの再利用が促進されます。この方法で、広範囲に分散したユーザーがOracle Service Busリソースを検索および検出し、利用できるようになります。すべてのWebサービスとUDDIは一連の規格に基づいて構築されるため、再利用により、テスト済みで受け入れ可能なWebサービスやアプリケーション開発の規格の使用が企業全体で促進されます。Webサービスとインタフェースは、タイプ、機能、または分類に応じてカタログ化すると、検索や管理がさらに容易になります。

Oracle Service Registryのパーミッションは、管理者がユーザーのパーミッションをOracle Service Registryで管理し、様々なユーザー・タイプのニーズに合わせたビューをレジストリに作成するために開発されました。Oracle Service Busに設定されたユーザー・パーミッションによって、レジストリへのアクセス、レジストリの内容、および使用できる機能が管理されます。

4.3.2.1 UDDIレジストリへのプロキシ・サービスのパブリッシュ

Oracle Service Busコンソールを使用して、プロキシ・サービスをOracle Service Registryにパブリッシュできます。すべてのプロキシ・サービスをUDDIレジストリにパブリッシュできます(サービスのタイプは、WSDL、メッセージング、すべてのSOAP、すべてのXMLです)。プロキシ・サービスをUDDIレジストリにパブリッシュする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIレジストリへのプロキシ・サービスのパブリッシュに関する項を参照してください。

4.3.2.2 UDDIレジストリからのサービスのインポート

レジストリにあるサービスをOracle Service Busビジネス・サービスとしてインポートできます。サポートされるサービスのタイプは、SOAP over HTTPバインディングのWSDLサービスおよびOracle Service Busプロキシ・サービス(主にマルチ・ドメイン・デプロイメントで使用される)です。ビジネス・サービスをOracle Service Busにインポートする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIレジストリからのビジネス・サービスのインポートに関する項を参照してください。

4.3.2.3 UDDIを使用したサービスの自動同期

Oracle Service Busのサービス定義は、UDDIのサービス定義と(双方向で)自動的に同期できます。Oracle Service Busで作成または変更されたサービスを、自動的にUDDIレジストリにパブリッシュできます。また、ビジネス・サービス定義をUDDIからインポートし、元のサービスがUDDIで変更された場合に自動的に更新できます。また、サービスがUDDIレジストリで変更された場合に同期の承認を求めるメッセージを表示するよう、Oracle Service Busコンソールを構成できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIレジストリの構成に関する項を参照してください。

4.3.3 関連トピック

  • 『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIに関する項

  • http://www.oasis-open.org/committees/uddi-spec/doc/tns.htmの技術ノート。特にUDDIレジストリでのWSDLの使用に関する記述を参照してください。

  • UDDI製品および開発ツールの情報は、http://uddi.org/solutions.htmlのOASIS UDDIソリューション・ページを参照してください。

  • UDDI仕様については、http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htmを参照してください。

    この仕様により定義される内容は以下のとおりです。

    • アプリケーションがUDDIレジストリに対して情報の照会やパブリッシュを行うために使用するSOAP API

    • レジストリ・データ・モデルのXML SchemaスキーマとSOAPメッセージ・フォーマット

    • SOAP APIのWSDL定義

    • UDDI登録の識別や分類に使用できる様々なIDやカテゴリ・システムのUDDIレジストリ定義(tModel)

  • UDDIレジストリを効率よくデプロイおよび使用するための、技術ノートとベスト・プラクティス・ドキュメントは、http://uddi.orgのOASIS UDDI Webサイトにあります。