WebSphere InterChange Server 開発モデル

このセクションでは、ビジネス・インテグレーション・システムを開発するために 従う、開発モデルについて説明します。

インターフェースのライフ・サイクル

多くの場合、1 人の人がインターフェース全体を開発することは理にかなった 方法です。"実装の段階" ページで 説明する実装の段階に従って、個々の統合コンポーネントが連動してインターフェース 要件を満たすように開発してください。

ローカルでのインターフェースの開発

統合コンポーネントを開発する場合、WebSphere InterChange Server Toolset を使用します。

まず始めに、開発環境を準備します。これには、WebSphere InterChange Server を ローカル・システムにインストールすることが含まれます。詳細については、環境の準備を参照してください。

次に、コンポーネント定義を保管する統合コンポーネント・ライブラリーと、インターフェースを表すユーザー・プロジェクトを定義します。インターフェース用の統合コンポーネントをライブラリーに作成および保管し、必要に応じて、それらのショートカットをユーザー・プロジェクトに追加します。詳細については、統合コンポーネント・ライブラリーの処理および ユーザー・プロジェクトの処理を参照してください。

ローカルでのインターフェースの配置

統合コンポーネントを開発している間、それらはローカル・ファイル・システム内に 存在しているだけにすぎません。インターフェースが完了したら、コンポーネント定義がリポジトリーに 保管されているローカルの InterChange Server インスタンスに、ユーザー・プロジェクトを 配置します。リリース 4.2.0 より前の InterChange Server では、リポジトリー内で コンポーネント定義を直接処理しましたが、本リリースでは、ローカル・ファイル・システム 内でコンポーネント定義を排他的に処理してから、それらをサーバーに配置するように なりました。この開発モデルは、「静的メタデータ管理」といいます。これは J2EE 開発モデル を反映しており、開発アクティビティーを実行時アクティビティーから分離します。ユーザー・プロジェクトの配置の詳細については、System Manager を使用したパッケージへのコンポーネントのエクスポートを参照してください。

ローカルでのインターフェースのテスト

インターフェースをローカルの InterChange Server インスタンスに配置したら、インターフェースをテストして、お客様の要件に一致するかどうか検証する必要があります。テスト の詳細については、Test Connector の使用および 統合テスト環境の使用を参照してください。

ローカルの InterChange Server インスタンスでインターフェースの保全性を 検証したら、プロジェクトを担当する他の開発者と協調して、そのインターフェースを 他の開発者のインターフェースにビジネス・インテグレーション・システムとして 結合します。詳細については、ビジネス・インテグレーション・システムのライフ・サイクルを参照してください。

ビジネス・インテグレーション・システムのライフ・サイクル

インターフェースのライフ・サイクルでは、ローカル・システムで インターフェースを開発する方法について説明しました。このセクションでは、他の開発者と協力してビジネス・インテグレーション・システムを送達する方法について説明します。

開発統合環境への配置

ローカル・システムでインターフェースの開発およびテストが終了したら、プロジェクト内で インターフェースを使用する他の開発者と協調して、ビジネス・インテグレーション・システム を作成する必要があります。どの開発者も、自身のインターフェースを共通環境 (開発統合 環境ともいわれます) に配置する必要があります。

これを実行するには、開発統合環境で統合コンポーネント・ライブラリーを作成し、次に各開発者が自身のインターフェース内のコンポーネントが含まれるパッケージを エクスポートし、そのパッケージを新規ライブラリーにインポートします。

すべての冗長度を解決し、変更を行ったら、インターフェースの集合を表すコンポーネント を、開発統合環境内のローカル・サーバー・インスタンスに配置します。

統合テストの実行

ビジネス・インテグレーション・システム (またはシステム実装の特定の段階) の インターフェースを結合したら、再度テストする必要があります。これによって、各インターフェースを他のインターフェースと一緒に実行するときに、お客様が定義した ビジネス要件を満たしているか確認します。ローカル開発環境から統合開発環境への 移行において問題や見落としがあった場合 (共用コンポーネントを適切に更新できないなど)、この段階の厳密なテストによって識別されます。

統合テストは、サイトに応じて、開発統合サーバーまたは専用テスト環境内で 実行されます。個別のテスト環境を保持している場合は、開発統合環境内の インターフェースをすべて結合し、その整合性を検証してから、テスト環境を変更する ことができます。このようにして、テスト環境で既存のインターフェースをテストすると同時に、開発統合環境で新規のインターフェースを作成できます。ただし、この方法では、お客様が別の環境をサポートするために必要な装置を購入し、環境を構成する必要があります。

パフォーマンス・テストの実行

統合テストを実行してインターフェースの集合が機能要件を満たしていることを 検証したら、負荷テストを実行して、ビジネス・インテグレーション・システムがお客様の パフォーマンス要件に一致するか確認できます。

実稼働環境に等しいパフォーマンス・テスト環境を構成している場合、シミュレートされる スループットは、実動パフォーマンスにより近い予測になります。ただし、実稼働環境 にコストがかさみ、実動に近づけてミラーリングするパフォーマンス・テスト環境の 作成に、お客様が投資できない場合があります。

ビジネス・インテグレーション・システムをパフォーマンス・テスト環境に移行 するには、開発統合環境に移行したときと同じ手順を実行します。

パフォーマンスが十分でない場合、一部のコンポーネントを変更または再構成する 必要があります。パフォーマンスに影響する構成および技法の詳細については、パフォーマンスの調整を参照してください。

実動の開始

ビジネス・インテグレーション・システムが機能要件およびパフォーマンス要件 を満たすことを検証したら、インターフェースの集合を実稼働環境に移行します。

ビジネス・インテグレーション・システムを実稼働環境に移行 するには、前の環境に移行したときと同じ手順を実行します。

図 1 に、一般的な環境における 統合コンポーネントの、統合コンポーネント・ライブラリーからユーザー・プロジェクト、サーバー・リポジトリー、およびエクスポート済みパッケージへのフローを示します。

開発チームは、サイト管理者がインターフェースの集合を管理するために必要な スキルや情報を取得するよう、知識を伝達する必要があります。これで統合実装を 完了するか、または次の段階の一部として新規インターフェースの開発を開始します。

図 1. WebSphere InterChange Server 開発モデル

この図は、開発環境、テスト環境、および実稼働環境という、3 つの異なる環境を表す 3 つの四角形を縦に並べて示しています。これらの 3 つの環境のそれぞれには、同じフロー設計が含まれています。フローは、統合コンポーネント・ライブラリーで始まり、ユーザー・プロジェクトへと続いています。ユーザー・プロジェクトから、パッケージが InterChange Server リポジトリーに配置されます。次に、フローは次の環境へと続きます。

Copyright IBM Corp. 1997, 2004