インターフェースのライフ・サイクルで説明しているように、通常、1 人が開発の責任を負うビジネス・プロセス・インターフェースは 1 つであり、各個人は専用のラップトップなどのコンピューターに準備した 開発環境で作業します。コンピューターに必要なソフトウェアをインストールし、構成するために必要な大部分の情報は「システム・インストール・ガイド (Windows 版)」に記載されていますが、このセクションでは、効率的かつ効果的な開発のための 環境の変更に関するヒントについて説明します。
IBM WebSphere InterChange Server は統合インフラストラクチャーを提供するために多くのエンタープライズ・クラス・ソフトウェアを必要としますが、システムから特に多くのトランザクションを処理しない限り、通常は必要なソフトウェアをすべてワークステーションまたは ラップトップ型コンピューターで実行できます。コンポーネントの開発および 単体テストをサポートするにはこのようなコンピューターが最適ですが、大量のフローをサポートすることはできません。以下のリストに、いくつかの必要なソフトウェアを示します。
InterChange Server はローカル・システムにインストールし、インターフェースを開発できるようにする必要があります。
インターフェースでアプリケーションと通信するために必要なアダプターをインストールし、コネクターの構成の検査および アプリケーションへの接続の検証が実行できるようにすることをお勧めします。一部のアダプターでは、アプリケーション・クライアントも インストールする必要があります。その他のインストール要件については、インターフェースに必要なアダプターのガイドを参照してください。
IBM ORB をインストールし、ツールやコネクターなどの クライアントが InterChange Server と通信できるようにする必要があります。
WSWB または WSADIE を使用すると、System Manager およ び統合テスト環境プラグインをサポートできます。WSWB はプラグインに必要なサポートをすべて提供し、WSADIE ほど高価なリソースではないため、WSWB の使用をお勧めします。
System Monitor は主に実動システムの管理者のために設計されていますが、コンポーネントの状態を管理する機能が豊富であり、開発段階でも役立ちます。通常、Tomcat の方がシステム・リソースに対する要件が低くなります。
プロジェクトの各開発者は、通常専用の開発環境を持ち、専用のリポジトリー・データベースを必要とします。サイトの単一のデータベース・サーバー・ホストに 開発者ごとにデータベースを作成することもできますが、データベース・サーバーを各コンピューターにインストールして そのコンピューターでリポジトリーに対するホスト・サービスを提供することをお勧めします。これにより、サイトのデータベース・サーバーにアクセスできない場合でも開発を継続できます。
コンポーネントはすべてローカル・ファイル・システムで開発するため、サーバー・リポジトリーにアクセスできない場合でも引き続き開発できます。ただし、テストは頻繁に行うことをお勧めしますが、リポジトリーがなければコンポーネントをテストできないため、リポジトリーを使用可能にしておくことをお勧めします。
WebSphere MQ はデータの効率的なパーシスタンスを提供するため、実稼働環境では WebSphere MQ をお勧めしますが、開発環境では必須ではなく、システム・リソースの消費が多くなる場合があります。個々の開発環境では、WebSphere MQ の代わりに IIOP を 使用することをお勧めします。 これを行うには、Connector Configurator を使用し、コネクターの DeliveryTransport プロパティーを 値 IDL に設定します。Connector Configurator および コネクターの標準プロパティーについては、コネクターの構成を参照してください。
必要なソフトウェアをインストールする場合は、以下の事項を考慮してください。
コンピューターの名前もネットワーク内で固有でなければならないため、インストール時にはコンピューターの名前を InterChange Server インスタンスの 名前として指定することをお勧めします。
さらに、サーバー名に他の情報も含めておくと便利です。例えば、InterChange Server および WebSphere MQ Integrator Broker タイプの ブローカーの両方を定期的に処理する場合は、サーバー名に WICS を含めておくと、ブローカーのタイプを識別できます。システムの異なるリリースから 複数のサーバー・インスタンスをインストールする場合は、数値 420 を含めてリリース・バージョンを示すことができます。DEV を含めておくと、サーバーがテスト環境や実稼働環境のサーバーではなく、開発サーバーであることを示すことができます。
例えば、以下のディレクトリーに InterChange Server をインストールするとします。
D:¥ProgramFiles¥IBM¥WICSInstallations¥WebSphereICS420DEV
WICSInstallations ディレクトリーを共用し、F: などのネットワーク・ドライブをマップし、PATH および CLASSPATH エントリーで F:¥WebSphereICS420DEV を使用できます。
ローカル InterChange Server は設計モードで開始することをお勧めします。これにより、統合コンポーネントを段階的に組み立てることができます。実動モードで実行した場合はこのような組み立ては不可能です。詳細については、InterChange Server のモードを参照してください。
ローカル開発環境で start_server.bat バッチ・ファイルを 以下のように変更してください。
デフォルトでは、start_server.bat ファイルは、InterChange Server の始動時にエラーが発生すると すぐに終了するように作成されます。多くの場合、サーバーのエラーは最初の始動時に発生しますが、問題を示すエラー・メッセージがコンソール・ウィンドウに表示されても、そのメッセージを読む前にコンソール・ウィンドウが終了してしまいます。バッチ・ファイルに pause コマンドを追加すると、InterChange Server を始動できないエラーが発生した後、コンソール・ウィンドウにエラー・メッセージが表示された状態になります。変更を行うと、ファイルの終わりは下の例のようになります。
%CWJAVA% -Djava.ext.dirs=%JRE_EXT_DIRS%;"%MQ_LIB%";"%DB2_LIB%" -Duser.home="%CROSSWORLDS%" -mx%CW_MEM_HEAP%m -DTEAgent=1200 -DCW_MEMORY_MAX=%CW_MEM_HEAP% %ORB_PROPERTY% -classpath %JCLASSES% ServerWrapper -s%SERVERNAME% %2 %3 pause endlocal
setlocal net start "IBM MQSeries" net start "DB2 - DB2-0" net start "DB2 License Server" net start "DB2 Remote Command Server" net start "DB2 Security Server" net start "DB2DAS - DB2DAS00"
WebSphere Application Server を System Monitor の ホストとする場合は、そのサービスおよび必要なサービスを開始し、モニター対象のアプリケーションの URL を自動的にブラウザーで開くバッチ・ファイルを作成できます。このようなバッチ・ファイルの例を以下に示します。
net start "DB2 - DB2-0" net start "DB2 License Server" net start "DB2 Remote Command Server" net start "DB2 Security Server" net start "DB2DAS - DB2DAS00" net start "IBM HTTP Administration" net start "IBM HTTP Server" net start "IBM WS AdminServer 4.0" start iexplore http://devserver/ICSMonitor
以下の理由により、サーバーのロギング出力は、コンソールと開発環境のファイルの両方に送信することをお勧めします。
InterChange Server のロギングおよびトレースの構成方法については、WebSphere InterChange Server の構成を参照してください。
ほとんどの開発者は、以下のセクションで説明するように環境をカスタマイズすると 作業が効率的になります。
ほとんどの開発者にとっては、頻繁に使用するショートカットを編成し、プログラム・メニューを使用する頻度を少なくすると便利です。デスクトップにショートカット用のフォルダーを作成するか、Windows のタスクバーにカスタム・ツールバーを作成できます。InterChange Server、必要なコネクター、WSWB (System Manager)、データベース・サーバー管理ツール、WebSphere MQ コンソール、System Monitor、テキスト・エディターなどへのショートカットを組み込むと便利です。
デフォルトでは、InterChange Server およびコネクターは、サイズおよび画面バッファーが小さく、読みにくいカラー・スキームの コンソール・ウィンドウで実行されます。それらのショートカットを変更するには、以下の手順を実行します。
これにより、コンソールに多くの情報がキャッシュされるため、システムがイベントを処理しているときにエラー・メッセージが置換されるのが遅くなります。
これにより、横方向に表示される情報が多くなり、縦方向のスペースが小さくなるように コンソールのサイズが設定されます。通常、高さが 25 のコンソールは 1 画面に 3 つ配置できます。これにより、通常インターフェースでテストに必要な InterChange Server および 2 つのコネクターの コンソール・ウィンドウを容易に並べて表示できます。
Eclipse ベースのワークベンチの使用で説明しているように、ツール設定を構成する必要があります。
ワークスペース (ワークベンチで作成したプロジェクトが デフォルトで格納されるディレクトリー) は、ニーズに最適なロケーションに設定することをお勧めします。ワークスペース・ディレクトリーを指定するには、以下の手順を実行します。
setlocal set WSWB_EXECUTABLE=%1 "%WSWB_EXECUTABLE%" -data "%CROSSWORLDS%"/Projects -vmargs -Xbootclasspath/p:"%CROSSWORLDS%"¥lib¥vbjorb.jar -Dorg.omg.CORBA.ORBClass=com.inprise.vbroker.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=com.inprise.vbroker.orb.ORBSingleton -DCWTools.home="%CROSSWORLDS%"¥bin
以下の統合コンポーネント・ライブラリーを作成することをお勧めします。
このタイプのライブラリーには、対応するサーバーに関連する方法で名前を付けることをお勧めします。例えば、サーバー名が WICS420DEV の場合は、ライブラリーに WICS420DEVICL と名前を付けます。同様の規則は、ユーザー・プロジェクトの作成のユーザー・プロジェクト に対してもお勧めします。
以下の統合コンポーネント・ライブラリーを作成することをお勧めします。
このタイプのユーザー・プロジェクトには、対応するサーバーに関連する方法で名前を付けることをお勧めします。例えば、サーバー名が WICS420DEV の場合は、ユーザー・プロジェクトに WICS420DEVUP と名前を付けます。同様の規則は、統合コンポーネント・ライブラリーの作成の 統合コンポーネント・ライブラリーに対してもお勧めします。
ローカル開発環境にコネクターをインストールして実行し、インターフェースの基本的なテストの一部を実行できます。このようにコネクターを活用するには、このセクションに記載されている推奨事項に従ってください。
必要なソフトウェアのインストールで説明しているように、ローカル開発環境で WebSphere MQ を実行しておく必要はありません (実行しておくと パフォーマンスが低下する場合があります)。代わりに、コネクター定義の DeliveryTransport プロパティーを 値 IDL に設定し、IIOP を使用します。
イベント通知に対して責任を持つコネクターがある場合は、コネクターがイベント・テーブルをポーリングして 新規イベントを検出する必要があります。ポーリングは必要ですが、コネクターのコンソール・ウィンドウに書き込まれたメッセージによって 重要なトラブルシューティング情報が画面から消えてしまう可能性があります。キー・ポーリングを使用すると、コネクターは指示があった場合にのみポーリング呼び出しを発行します。キー・ポーリングおよびコネクターの構成については、コネクターの構成を参照してください。