Busをデプロイする際に使用できるベスト・プラクティスと手順について説明します。このドキュメントは、デプロイメント用に自動化スクリプトやプログラムを記述する開発者ではなく、デプロイメントやトポロジをプランニングするデプロイ担当者または管理者を対象としています。詳細は、付録A「デプロイメントAPIの使用」を参照してください。APIリファレンスを参照してください。この章では、次の項について説明します。デプロイメント・トポロジ次の項では、一般的なデプロイメント・トポロジについて説明します。開発システムとQAシステム本番システムには、複数の開発システムが存在することがあります。エンタープライズESB本番システムの各部門がそれぞれ別個のプロジェクトを持ち、そのプロジェクト・チーム用の開発システムがある場合などです。一般に、開発システムにはQAシステムが関連付けられています。2つのシステムの関係は、1対1です。ステージ・システムと本番システム一般に、ステージ・システムは本番システムに関連付けられています。2つのシステムの関係は、1対1です。ステージ・システムはできるだけ本番システムを反映するようになっています。通常、開発システム(またはQAシステム)と本番システム(またはステージ・システム)の関係は多対1です。共有プロジェクトより複雑なデプロイメント・トポロジでは(大規模組織で部門ごとに開発システムがある)、スキーマ、変換、共有サービスなどの全社的な標準を共有プロジェクトに入れることができます。このシナリオに対処するには、共有プロジェクト用の別個の開発システムを作成し、各部門の開発システムに共有プロジェクトの読取り専用コピーを用意します。共有リソースが変更された場合、必要なリソースをインポートおよびエクスポートすることで、すべての部門システムが更新されます。リソースをステージ・システムまたは本番システムにデプロイする際は、デプロイメントの失敗を招く可能性のあるセマンティク・エラーを回避するために、共有プロジェクトとともに、影響を受けるすべての部門プロジェクトをデプロイする必要があります。時として、共有プロジェクトが複数の本番システムで共有されていることがあります。各部門に別個の本番システムがあり、それが企業のESBネットワークに相互接続されていて、スキーマなどの全社的なアセットがすべての本番システムで共有されている場合などです。デプロイメント・タイプデプロイメントの標準的な単位は、プロジェクトと呼ばれます。プロジェクト・デプロイメントには2つのタイプがあります。プロジェクト全体がデプロイされます。最後のデプロイメント以降のプロジェクトへの変更、または明示的に選択されたリソースのサブセットのみがデプロイされます。増分デプロイメントは付加的なデプロイメントで、新規リソースおよび更新されたリソースのみがターゲット・システムにデプロイされます。プロジェクトで削除されたリソースは、ターゲット・システムからは削除されません。完全プロジェクト・デプロイメント時に削除されたプロジェクト・リソースは、ターゲット・システムからも削除されます。注意:この動作は、インポート時にカスタマイズできます。アラート宛先は本番システムで本番システム・オペレータによって定義されますが、開発システムにはこれらのアラート宛先が存在しません。このため、プロジェクトの完全デプロイメントを行う際に、アラート宛先を削除する必要がありません。このドキュメントでは、主として、基本的なデプロイメント・タイプについて説明します。共有プロジェクトを使用するユースケースは、基本的なユースケースを拡張したものです。このドキュメントでは、スクリプトやプログラムによってリソースのエクスポートとインポートを自動化するユースケースについても説明します。デプロイメントの役割エクスポート、インポートおよび環境のカスタマイズは、システムに応じて、および企業のポリシーに応じて、デプロイ担当者、オペレータまたは管理者によって行われます。開発システムからのエクスポートは、一般にデプロイ担当者によって行われます。管理者、オペレータまたはデプロイ担当者は、ステージ・システムから本番システムへのリソースのエクスポートとインポートを担当できます。Bus管理コンソールや、スクリプトまたはプログラム(開発者が作成可能)を使用して実行できます。オペレータがシステムからのリソースのエクスポートを担当する場合、定義済の自動化スクリプトまたはプログラムを実行して、プロジェクト全体またはプロジェクト内の特定リソースをエクスポートできます。同様に、オペレータがシステムへのリソースのインポートを担当する場合、定義済の自動化スクリプトまたはプログラムを実行して、インポートを行うことができます。カスタマイズ・ファイル管理者はカスタマイズ・ファイルを使用して、環境値やリソース内の参照を変更します。カスタマイズ・ファイルには、選択したリソース内で使用されているすべての環境値に対するカスタマイズを含めることができます(たとえば、EnvValueTypesclass内で定義された複合型の環境値)。リソース内での依存関係を持つリソース参照を変更するための、参照型のカスタマイズも含めることができます。Busインストールの次の場所にあります。Bus管理コンソールからサンプル・カスタマイズ・ファイルを作成できます。カスタマイズ・ファイルには、プロジェクトまたはプロジェクト内の個々のリソースを含めることができます。Bus管理者ガイド』のカスタマイズ・ファイルの作成に関する項を参照してください。エクスポートまたはインポート・プロセスで環境の実際値を指定することで、作成したサンプル・カスタマイズ・ファイルを、必要な変更を加えるための開始点として使用できます。環境値の置換デプロイメントの一環として、エクスポート・プロセスまたはインポート・プロセスで、ターゲット・システムで適用される値にあわせて、ソース・システム内のリソースの環境値を変更する必要があります。環境値とは、多くの場合ドメイン間での構成の移動(テスト環境から本番環境への移動など)に伴って変化する値で、構成データに含まれる特定の事前定義されたフィールドです。環境値は、URL、URI、ファイル名、ディレクトリ名、サーバー名、電子メールなどのエンティティを表します。環境値は、アラート宛先、プロキシ・サービス、ビジネス・サービス、SMTPサーバーおよびJNDIプロバイダのリソース、UDDIレジストリ・エントリで検索できます。Bus管理コンソールの「検索置換」オプションでは検索と置換を実行できません。スクリプトからALSBConfigurationMBeanを使用して、これらの環境値を直接設定できます。APIリファレンスを参照してください。複合型の環境値は、APIで設定するほか、カスタマイズ・ファイルを使用して設定できます。カスタマイズ・ファイルはXMLファイルで、任意のエディタで開いて、必要な環境値を置換できます。Bus管理コンソールまたカスタマイズ・ファイルで特定の環境値(複合XMLタイプでない)を検索して、新しい値と置換できます。これらの環境値を変数タイプまたはプロジェクトに基づいてフィルタリングして、検索範囲を調整できます。Bus管理者ガイド』の環境値の検索と置換に関する項を参照してください。注意:環境値の置換後、カスタマイズ・ファイルを実行する必要があります。Bus管理者ガイド』のカスタマイズ・ファイルの実行に関する項を参照してください。環境値の置換は、インポートまたはエクスポート・プロセスの一部として行うことができます。リソースのエクスポートエクスポート担当者は、増分デプロイメントを実行できるかどうかを確認する必要があります。実行できる場合、特定の時間以降(最後のデプロイメント後など)に変更または作成されたすべてのリソースを検索するスクリプトを記述して、リソースをエクスポートできます。Bus管理コンソールを使用して、選択したリソースのみをエクスポートする場合(増分デプロイメントで)、リソースの最終更新時のタイムスタンプを確認して、エクスポートが必要なリソースのみを選択できます。Bus管理者ガイド』のリソースのエクスポートに関する項を参照してください。エクスポート時のリソースのカスタマイズリソースのインポートまたはエクスポート時には、リソースをカスタマイズできます(環境値の置換を含む)。リソースのエクスポート時に、次の手順を実行します。セッションを開始します。リソースをカスタマイズして、カスタマイズ・ファイルを実行します。必要なリソースをエクスポートします。セッションを破棄して、元の値がソース・システムに保持されていることを確認します。エクスポートしたファイルには更新後の値が含まれるため、更新後の値がターゲット・システムに反映されます。Bus管理コンソールからインポートするか、またはスクリプトを使用してインポートできます。Bus管理者ガイド』のリソースのインポートに関する説明を参照してください。スクリプトを使用する場合、スクリプトによってインポートJARがステージングされます。その後、ステージングされたインポートJARのデプロイ・プランをシステムから取得します。デプロイ・プランにはプロジェクト内のすべてのリソースを含める必要があります。これらのリソースをターゲット・システムで作成、削除、更新するのか、またはそのままの状態にするのかを指定する必要があります。一般にデプロイメント・プランは、環境固有のリソース(サービス・アカウントなど)をオーバーレイしないように、またはオペレータが管理するリソースをオーバーレイまたは削除しないように、スクリプトによってカスタマイズされます。インポート時のリソースのカスタマイズリソースのインポートまたはエクスポート時には、リソースをカスタマイズできます(環境値の置換を含む)。リソースのインポート時に、次の手順を実行します。セッションを開始します。必要なリソースをインポートします。リソースをカスタマイズして、カスタマイズ・ファイルを実行します。セッションをアクティブ化します。インポート時に、環境変数を保持して、インポート時に作成されたリソースの環境値のみがカスタマイズ・ファイルでカスタマイズされるようにできます。Busには、グローバル操作設定と、プロキシ・サービスとビジネス・サービスの操作値とアラート、の2つのタイプの操作値があります。グローバル操作設定は、システム・プロジェクト・フォルダの下にあるリソースです。グローバル操作設定リソースは、他のリソースと同じようにエクスポートできます。インポート時に、このリソースは更新のみ可能で、作成または削除はできません。Bus管理コンソールで「操作値の保持」オプションを選択して、ターゲット・システムで操作値を保持できます。注意:時として、オペレータがSLAアラートのアラート宛先を定義することがあります。これらはオペレータが管理するリソースであり、デプロイメント時にオーバーレイまたは削除することはできません。アクセス制御ポリシーのインポート一般に、アクセス制御ポリシーは環境ごとに異なります。この場合、インポート時にアクセス制御ポリシーをオーバーレイしないオプションを指定して、インポート時にアクセス制御ポリシーが失われないようにします。正しいアクセス制御ポリシーがステージング環境で設定され、本番環境に適用されることもあります。このような場合、アクセス制御ポリシーはサービスとともにインポート/エクスポートされます。Serverアーティファクトが不足している場合、デプロイメントは失敗すべきです。インポート時にチェックされるものもあれば、インポート時にチェックされず(ビジネス・サービスのリクエスト・キューなど)、実行時エラーが発生するものもあります。Serverにあるかどうかをチェックすることです。ない場合、デプロイメントは失敗します。管理者は、オペレータがスクリプトを再実行する前に、これらのリソースを定義する必要があります。限定的な方法として、アーティファクトをセッションにインポートし、セマンティク・エラーを探すこともできます。Serverリソースの存在をチェックする場合に発生します。グローバル・リソースの移行グローバル・リソースにはUDDIレジストリ・リソース、JNDIプロバイダ・リソース、およびSMTPサーバー・リソースがあります。これらのリソースは、通常、テスト環境では、ステージング環境や本番環境とは異なる値を使用します。テスト環境から本番環境にデプロイメントを移行する場合、次の方法のいずれかを使用します。本番ドメインで、テスト環境と同じ名前で新しいグローバル・リソースを作成します。テスト環境からグローバル・リソースを直接インポートして、カスタマイズします(手動で作成するよりも時間がかかりません)。同一環境リソース(SMTPサーバーなど)の名前が環境内で異なる場合があります。これは、インポート・スクリプトによって、インポート・プロセスの一部としてこれらのリソースへの参照をマッピングすることで対処できます。テスト環境からアーティファクトをエクスポートするときに、グローバル・リソースを除外します。次にconfig.jarファイルだけインポートします。アラート宛先、JNDIプロバイダ、またはSMTPプロバイダを参照するconfig.jarファイルにリソースが含まれている場合、インポートが完了すると、これらの参照は所定の場所に配置されます。ターゲット・システムに資格証明が上書きされないように、インポートに資格証明を保存するオプションを選択します。すべてのアーティファクト(グローバル・リソースを含む)をエクスポートし、config.jarファイルをインポートするときに、グローバル・リソースを除外します。Busリソースのデプロイメントで推奨される基本的なベスト・プラクティスの概要を、次に示します。プロジェクトの名前は変更しないようにします。名前の変更が必要な場合は、次のデプロイメントを行う前に、デプロイメント、QA、ステージおよび各本番システムで同時に変更します。環境固有のリソースの操作は、インポート時にフィルタで適切に除去されます。管理者はインポート・プロセスを開始する前に、このようなリソース(インポート・ファイルで参照される)をターゲット・システムで定義できます。新たな環境固有のリソースをデプロイして、インポート後に環境にあわせてカスタマイズすることもできます。オペレータが管理する操作リソースが、インポートの影響を受けないようにします。インポート時にこうしたリソースを識別するために、ネーミング・ルールまたは専用フォルダを使用できます。単一のカスタマイズ・ファイルにすべてのプロジェクト・リソースのカスタマイズが入っている場合、インポートされたリソースにのみカスタマイズを適用します。インポート時に環境値を保持して、インポート時に追加されたリソースにのみカスタマイズを適用することもできます。エクスポート時に、エクスポート担当者は、リソースが削除、名前変更または削除されているかどうか、および最後のエクスポート以降、アーティファクトのプロジェクト再編成があったかどうかを確認する必要があります。これらの作業が行われていた場合は、完全デプロイメントを行う必要があります。行われていない場合、エクスポートが必要なリソースのみを選択して、増分デプロイメントを行うことができます。環境間でグローバル・リソース(UDDIレジストリ、JNDIプロバイダ、SMTPサーバーなど)を移行するのに適した方法を使用します。UDDIUDDIレジストリにデプロイされたサービスを使用する際には、特別に考慮すべき事項があります。この項では、UDDIにパブリッシュされた、またはUDDIからインポートされたプロキシ・サービスおよびビジネス・サービスに関する情報を説明します。UDDI本番レジストリを使用すると、本番システムへのインポートが複雑になるため、十分な注意が必要です。UDDIデプロイメント・トポロジ環境に応じて、次のUDDIデプロイメント・トポロジを使用できます。開発専用レジストリ最も簡易なUDDIデプロイメントでは、リソースのパブリッシュと検出の両方を行う、単一の開発(設計)時レジストリを使用します。このレジストリは、承認コントロールを使用したガバナンスに使用されます。別個の設計時パブリッシュ・レジストリおよび検出レジストリを持つこともできます。設計時パブリッシュ・レジストリでの承認後、リソースを検出レジストリに昇格させることができます。本番専用レジストリ本番レジストリ・トポロジでは、単一の本番UDDIレジストリにすべての本番ビジネス・サービスとプロキシ・サービス、およびその場所(URL)が含まれます。本番レジストリは、すべての本番サービスの検出に使用されます。別個の本番パブリッシュ・レジストリおよび検出レジストリを持つこともできます。本番パブリッシュ・レジストリでの承認後、リソースを本番検出レジストリに昇格させることができます。本番レジストリを持つ主な理由は、動的なエンドポイント管理が可能であることです。Bus本番システムに自動的に反映させることができます。Bus管理者ガイド』のUDDIを使用したサービスの自動同期に関する項を参照してください。一般に、プロキシ・サービスはパブリッシュ・レジストリに自動的にパブリッシュされます。UDDIでの承認手順でサービスが却下された場合、UDDI承認者はそれを開発者に手動で通知します。開発者は適切な変更を行って、ステージ・システムおよび本番システムでサービスを再エクスポートする必要があります。Bus管理者ガイド』の自動パブリッシュの使用に関する項を参照してください。本番ビジネス・サービスは本番検出レジストリからインポートされます。Busに自動的に反映されるようにできます。ビジネス・サービスを本番レジストリから開発レジストリに手動でインポートする場合は、開発システムの値に準拠するように環境値を変更する必要があります。開発ビジネス・サービスはUDDIレジストリと自動的には同期されません。開発環境値は多くの場合、本番レジストリとは異なるためです。開発および本番レジストリもう1つのアプローチは、別個の開発および本番UDDIレジストリを持つことです。このトポロジでは、開発レジストリで承認手順を実行できます。追加の開発UDDIレジストリにより、サイクル内で承認が早めに行われるようになります。個別ドメイン別レジストリプロキシ・サービスは、POJOコールアウトを使用してUDDIレジストリの動的な検索を実施し、必要な検索基準を満たすサービスを選択して、動的ルーティングのURLを取得することがあります。BusでダミーURLを持つダミー・サービスが定義され、このURLが検索後に実際の値と置き換えられます。このシナリオでは、環境ごとにUDDIレジストリが必要です。Busのダミー・ビジネス・サービスはどのUDDIサービスにもリンクされません。このシナリオは、パフォーマンスと可用性に影響を及ぼします。Busとの自動同期を有効にするアプローチが適しています。Bus管理者ガイド』の動的ルーティングの使用に関する項を参照してください。UDDIデプロイメントのベスト・プラクティスの概要UDDIレジストリにデプロイされたサービスの使用で推奨されるベスト・プラクティスの概要を、次に示します。特定のUDDIレジストリに関連するビジネス・サービスを特定のフォルダにまとめて、インポート時にこれらのリソースを容易に識別できるようにします。そのUDDIレジストリを使用するすべてのシステムで、同じUDDIサーバー・リソース名を使用します。別個の開発および本番UDDIレジストリがある場合、別個のUDDIレジストリの開発および本番インスタンスに同じリソース名を使用します。これにより、サービスによるサーバーへの参照が、インポート中に自動的に解決されます。開発および本番UDDIレジストリを使用する場合、2つのレジストリ間で同じサービス・キーを保持します。一般に、本番プロキシ・サービスに対して自動パブリッシュ・オプションが有効化され、ビジネス・サービスに対して自動同期オプションが有効化されます。サービスをUDDIレジストリから開発システムに手動でインポートする場合、サービスには引き続きソース・レジストリのUDDIキー情報とレジストリ・リソースへの参照が含まれます。開発サービスはステージ・システムまたはQAシステムに通常の方法でインポートされます。ステージ・システムおよびQAシステムのサービスにも、UDDIキーおよびサービスのソース・レジストリへのレジストリ参照が含まれます。このため、これらのシステムで、「サービスが同期されていない」または「サービスを削除する必要がある」などのUDDI関連ステータス・メッセージが表示された場合は、無視してください。2つのレジストリを使用する場合、開発レジストリと本番レジストリ内の同一サービスのキーが同じでないことがあります。同じキーを保持することが推奨されます。ビジネス・サービスの形状が変化した場合は、新しい形状で新たなUDDIサービスを作成します。Busで使用可能なUDDI関連リソースは、システム間でインポートまたはエクスポートできます。この項では、様々なUDDIデプロイメント・トポロジで考慮すべき情報を示します。すべてのトポロジにおいて、すべてのシステムで同じUDDIレジストリ・リソースが構成されています。ステージ・システムとQAシステムでは自動同期は有効化されません。本番UDDIレジストリを使用する場合、いくつかの考慮事項があります。UDDIには、サービスの情報のサブセットのみが含まれます。このため、サービスに関する情報の中には、通常のインポート、エクスポート・プロセスを通じて本番システムに移動するものもあれば、UDDIレジストリとの同期から本番システムに移動するものもあります。この情報は、インポート時に注意深く管理する必要があります。サービスが設計時UDDIレジストリから開発システムに移動する際、本番UDDIレジストリ内の同等サービスを識別する方法があることが理想的です。これにより、インポート時に、サービスの情報を本番UDDIレジストリ内の同等サービスに確実にマージできます。開発専用レジストリこのシナリオでは、システム間で移動する際に、次の手順を実行する必要があります。ビジネス・サービスをUDDIレジストリからデタッチします。プロキシ・サービスの自動パブリッシュ・オプションを無効にします。Bus管理コンソールを使用して行います。必要に応じて、サービスに変更を加えます。リソースを現在のシステムからJARに手動でエクスポートして、次のシステムにインポートします。本番専用レジストリおよび開発および本番レジストリリソースを本番システムにインポートする場合、次のいずれかのシナリオを使用できます。新しいサービスをシステムにインポートする(インポートJAR内のサービスのUDDIキーとUDDIレジストリは同じ)。新しいサービスをシステムにインポートする(インポートJAR内のサービスのUDDIキーとUDDIレジストリは異なる)。既存のサービスをシステムにインポートする新しいサービスを本番システムにインポート。インポートJAR内のサービスのUDDIキーとUDDIレジストリは同じこのシナリオでは、サービスをシステムにインポートし、次のいずれかを実行します。インポート・スクリプトを使用し、APIコールにより、現在のセッションで明示的にサービスのUDDI再同期を施行します。Busによるバックグラウンド再同期のために、インポートしたサービスにマークを付けます。このオプションの欠点は、再同期が完了するまで、UDDI関連サービスのフィールドが不正確な可能性があることです。自動同期が有効化されている場合、不正確な時間は短くなります。新しいサービスを本番システムにインポート。インポートJAR内のサービスのUDDIキーとUDDIレジストリは異なるこのシナリオでは、サービスをシステムにインポートし、次のいずれかを実行します。インポート・スクリプトで、APIコールにより、現在のセッションでサービスのUDDI再同期を明示的に施行します。サービスは、セッションがアクティブになった後で「同期保留」として表示されます。UDDIレジストリで一致するUDDIサービスが見つからなかったという理由で、サービスに削除マークを付けます。リソースを適切にカスタマイズしてから、カスタマイズ・ファイルを実行します。Bus管理コンソールを使用して、UDDIレジストリからサービスをデタッチします。このアプローチの欠点は、UDDIの他に、本番環境値もカスタマイズ・ファイルに含める必要がある点です。レジストリからサービスをデタッチした後、UDDIレジストリからUDDI関連情報をダウンロードし、必要に応じて自動同期を有効にできます。既存のサービスの本番システムへのインポートこのシナリオでは、次のいずれかを実行します。UDDIレジストリ(またはサービス・キーの面で同一のUDDIレジストリ)を使用する場合、インポート時に本番UDDIサービスをオーバーレイします。その後、APIコールにより、現在のセッションでサービスのUDDI再同期を施行できます。インポート・スクリプトを使用して、このサービスの本番システムへのインポートをスキップします。これは、UDDI本番キーが異なる場合のみのオプションです。サービスのインポートをスキップすると、サービスの非UDDIソース・データが不正確な可能性があります。このため、最新のサービスをインポートするかわりに、本番サービス定義でこれらの情報を直接更新する必要があります。Bus構成をデプロイする手順の概要を示します。Builderをインストールおよび構成します。VMをインストールおよび構成します。Busデプロイメント・トポロジがサポートされています。Suiteドメイン・トポロジもサポートされています。Busデプロイメント・トポロジ」を参照してください。クラスタ・トポロジについては、名前参照に失敗しないように、静的IPアドレスでホストを構成します。Bus構成を作成またはデプロイします。Busドメインで構成ファイルのアーカイブを有効にします。Server管理コンソール・オンライン・ヘルプの構成ファイルのアーカイブに関する説明を参照してください。Serverに関する側面を構成します。必須のデータ・ソースを作成および構成します。構成されていることをテストします。構成をエクスポートおよびバックアップします。Bus構成を削除します。単なるアンデプロイはしないでください。それを削除する必要があります。Serverで信頼ストアを構成します。注意:現在サポートされている信頼ストアのタイプは、「デモIDとデモ信頼」のみです。Serverの信頼ストアがカスタムIDまたはカスタム信頼の場合は、イントロスペクションの前にデモIDとデモ信頼に戻し、正しいキーストアまたは信頼ストアのタイプを各デプロイメント後に再構成する必要があります。Busドメイン・ディレクトリから名前にスラッシュまたはバックスラッシュが入った一時ファイルを削除します。次のいずれかを実行します。構成の前提条件への準拠」を参照してください)。Coherenceクラスタを使用し、仮想マシンが静的IPアドレスを使用する場合、ユニキャスト・アドレスに既知のアドレス(WKA)を構成します。詳細は、付録C「静的IPアドレスを使用した仮想環境の構成」を参照してください。Busプロジェクトをエクスポートします。Busプロジェクトおよびリソース(UDDIレジストリ、JNDIプロバイダ、SMTPサーバーおよびプロキシ・サーバー・リソース)を削除します。Busコンソールを使用する場合)を参照してください。Serverアセンブリを作成します。Builderユーザーズ・ガイド』を参照してください。コマンドライン・インタフェースを使用する場合、次の手順を実行して、アセンブリを作成します。:introspectWLSコマンドを使用して、ドメイン情報を取得します。createAssemblyコマンドを使用して、空のアセンブリを作成します。addToAssemblyコマンドを使用して、イントロスペクトされたアセンブリを新しいアセンブリに追加します。createExternalResourcesコマンドを使用して、外部参照を外部リソース・エンドポイントにマッピングします。(OHS)およびWLS間でのエンドポイント接続を作成します。VMにアーカイブを登録して、アセンブリをデプロイします。このプロセス中に、データベースおよび認証プロバイダなどの外部リソースへリンクする必要がある場合があります。Builderユーザーズ・ガイド』を参照してください。Bus構成を手動でデプロイします。Serverインスタンスは、localhostではなく、仮想マシンのIPアドレスのみをリスニングしている可能性があります。Bus構成でlocalhostを使用するURIを変更する必要がある場合があります。Busプロジェクトをインポートして、必須のリソースを再作成します。reserved.法律上の注意点ライブラリ。