| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Integration > WebLogic Integration ソリューションの設計 > 統合ソリューションの要件の決定 |
|
WebLogic Integration ソリューションの設計
|
統合ソリューションの要件の決定
注意: cXML ビジネス プロトコルは、WebLogic Integration の本リリースより非推奨になりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
統合スペシャリストは、統合ソリューションのビジネスおよび技術的な要件を調べる必要があります。統合スペシャリストは、ビジネス アナリストおよびアーキテクトと共同で要件を明確にし、組織のニーズと優先順位について意見の一致を計ります。ビジネス アナリストとアーキテクトは、詳細な要件の定義を提供します。統合スペシャリストは、その定義を使用して WebLogic Integration で統合ソリューションのアーキテクチャを設計します。
以下の節では、統合ソリューションの要件を決める際の考慮事項について説明します。最後の節では、それらの事項がサンプルの WebLogic Integration アプリケーションとどのように関連するのかを示します。
統合ソリューションとビジネス プロセスの定義
統合ソリューションの要件を決めるときには、統合スペシャリストは以下のことを行わなければなりません。
これらのタスクがサンプルの WebLogic Integration アプリケーションでどのように行われるのかを確認するには、統合ソリューションとビジネス プロセスの指定 を参照してください。
各ビジネス プロセスは、必要なビジネス アクティビティを記述する単一のプロセス定義で構成されている必要があります。統合スペシャリスト、ビジネス アナリスト、およびアーキテクトは共同で各ビジネス プロセスを定義します。統合スペシャリストは、以下のような事項を確認する必要があります。
このタスクがサンプルの WebLogic Integration アプリケーションでどのように行われるのかを確認するには、統合ソリューションとビジネス プロセスの指定 を参照してください。
ビジネス プロセスのアクタとそのロールの定義
アクタとは、ビジネス イベントを生成および消費する利用者およびプロセスのことです。ビジネス プロセスでは、アクタ同士の関係、プロセスにおけるアクタのロール、およびプロセスとアクタによって交換されるビジネス イベントを定義します。統合スペシャリストは、以下の節で説明されているようにアクタとそのロールを識別します。
このタスクがサンプルの WebLogic Integration アプリケーションでどのように行われるのかを確認するには、アクタとロールの指定 を参照してください。
アクタの解析
各ビジネス プロセスについて、統合スペシャリストは以下のような事項を確認します。
ロールの解析
ビジネス プロセスの各エンティティのロールを定義するには、統合スペシャリストは以下のような事項を確認する必要があります。
タイプによるアクタの分類
統合スペシャリストは、ビジネス プロセスに関与するさまざまなタイプのアクタを識別および記述する必要があります。ビジネス プロセスのアクタには、WebLogic Integration Worklist などのクライアント アプリケーションを使用する人間とさまざまなソフトウェア エンティティの両方が含まれます。
注意: Worklist クライアントは WebLogic Integration リリース 7.0 より非推奨となりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
以下の節では、さまざまなタイプのアクタについて説明します。
次の図は、これらのアクタを示しています。
図2-1 ビジネス プロセスのアクタ
人間ユーザ 人間ユーザには以下の 2 つのカテゴリがあります。
注意: Worklist クライアントは WebLogic Integration リリース 7.0 より非推奨となりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
統合スペシャリストは、各ユーザが必要とするクライアントのタイプ（Swing GUI、HTML、電子メールなど）を識別する必要があります。
アプリケーション統合−アプリケーション統合で使用するエンタープライズ情報システム（EIS）アプリケーション
組織の技術インフラストラクチャは、従来のメインフレーム システム、クライアント/サーバ アプリケーション、パッケージ アプリケーション（ERP や CRM）など、さまざまなエンタープライズ情報システム（EIS）で構成されている場合があります。
統合スペシャリストは、統合ソリューションに直接関わる EIS アプリケーションについて、以下のような事項を確認します。
統合スペシャリストは、ビジネス プロセスに関与し、かつ上記の質問が「イエス」になる EIS アプリケーションを識別する必要があります。
さらに、統合スペシャリストは以下の事項を決める必要があります。
EIS アプリケーションの例
EIS アプリケーションとしては以下のものがあります。
EIS 統合要件の解析
統合スペシャリストは、以下のような事項を確認してアプリケーションの要件を評価します。
追加のカスタマイズが必要かどうかの判断
EIS アプリケーションには、統合ソリューションのサポートに必要なすべての機能を実装していないものもあり、したがって内部のカスタマイズが必要な場合があります。統合スペシャリストは、カスタマイズが必要かどうかを判断し、必要な場合は技術的な要件を定義する必要があります。
企業内の他のドメイン
統合ソリューションでは、リモート オフィスなど、企業内の他のローカル管理ドメインにアクセスする場合もあります。その場合、他のドメインの内部構造に統合ソリューションの管理は及びません。具体的に言うと、その他方のドメインでは WebLogic Integration が統合ソリューションとして使用される場合も、使用されない場合もあります。
ビジネス プロセスと他のドメインのインタフェース は、それらの間で交換されるビジネス イベントのセットです。このインタフェースは定義する必要があります。
1 つの方法は、B2B 統合機能を使用して情報を交換できるようにし、独立したドメインを企業内部 のトレーディング パートナとして表すことです。たとえば、ある企業がマレーシアに工場を持ち、その工場から日本にあるその企業の全額出資の組み立て工場に部品が供給されているとします。B2B 統合を利用すると、マレーシアのオフィスは日本のオフィス（バイヤ）に対する部品のサプライヤ（セラー）として機能できます。
B2B 統合を実現する外部トレーディング パートナ
統合ソリューションには、ビジネス プロセスが通信する必要のある外部トレーディング パートナが関与する場合があります。そのようなプロセスは企業のファイアウォールを経由します。トレーディング パートナの統合では、統合スペシャリストは以下の事項を定義する必要があります。
注意: XOCP および cXML ビジネス プロトコルは、WebLogic Integration の本リリースより非推奨になりました。代替機能に関する情報については、『BEA WebLogic Integration リリース ノート』を参照してください。
ビジネス イベントの定義
以下の節では、ビジネス イベントの定義方法について説明します。
このタスクがサンプルの WebLogic Integration アプリケーションでどのように行われるのかを確認するには、ビジネス イベントの指定 を参照してください。
ビジネス イベントについて
ビジネス イベントとは、ビジネス プロセスにおいてアクタ間で発生するメッセージまたはタスクの交換のことです。ビジネス イベントは、ビジネス アクティビティが発生し、それを遂行する必要があることを示します。たとえば、EIS では新規顧客作成 イベントをパブリッシュでき、注文管理アプリケーションでは新規注文 イベントをサブスクライブして新規注文を処理できます。各アクタは、ビジネス プロセスとビジネス イベントの交換を行えます。各ビジネス イベントには、ビジネス プロセスでそのイベントをユニークに識別する説明的な名前を付ける必要があります。
ビジネス イベントには、ビジネス データが格納されます。たとえば、新規顧客作成 イベントが顧客管理アプリケーションの実行時に発生したとします。新規顧客を作成する過程で、アプリケーションはビジネス プロセスの別のアクタから顧客の名前とアドレスを受信し、顧客の番号をそのアクタに返すことができます。
ビジネス イベントの特性の定義
アクタとプロセスの各会話について、統合スペシャリストは以下の事項を定義する必要があります。
ビジネス イベントのメッセージ フォーマットの定義
WebLogic Integration で、ビジネス イベントは XML メッセージまたはバイナリ メッセージとして送信されます。統合スペシャリストは、以下の事項を定義する必要があります。
ビジネス データ フローの定義
ビジネス プロセスでは、アクタ間のデータ フローを定義します。このデータ フローに基づいて、統合スペシャリストはビジネス データをどのように操作する必要があるのかを判断できます。たとえば、場合によっては、ビジネス データは複数のイベントに分割するか、複数のイベントからつなぎ合わせるか、またはフォーマットを変換する必要があります。
このデータ フローでは、処理上の決定を行うためにビジネス プロセスで使用するビジネス データも定義する必要があります。たとえば、5,000 ドルを超える発注は副社長の承認を得なければならないというアルゴリズムがビジネス プロセスに含まれている場合は、各発注の金額を必須のビジネス データとして定義しなければなりません。
以下の節では、データ フローの要件を作成する作業について説明します。
このタスクがサンプルの WebLogic Integration アプリケーションでどのように行われるのかを確認するには、データ フローの要件の指定 を参照してください。
データ フローの要件の定義
各データ フローについて、統合スペシャリストは以下の要件を定義する必要があります。
データ フローの解析
統合スペシャリストは、以下のような事項を確認してデータ フローの技術的な側面を解析する必要があります。
たとえば、注文管理アプリケーションから新規注文イベントが処理を目的として出荷アプリケーションに送信されるとします。また、出荷アプリケーションは 3 つの別々の地域のオフィス（東部、中部、および西部）で別々のインスタンスとして動作しているとします。この場合、注文管理アプリケーションでは、注文にある出荷先住所に基づいて適切なアプリケーション インスタンスに通知する必要があります。さらに、注文管理アプリケーションでは請求処理アプリケーションに新規注文を通知することも必要です。
この場合、データ フローの要件は次のようになります。
サービス品質の定義
統合スペシャリストは、以下のサービス品質特性をビジネスおよび技術的な観点で定義する必要があります。以下の節では、それらの特性について説明します。
パフォーマンス
統合スペシャリストは、以下のような事項を確認する必要があります。
たとえば、統合スペシャリストは最大の注文負荷を 5,000 としてシステムで 1 営業日（9 時から 17 時）に 20,000 の注文を処理できるように指定できます。
WebLogic Integration のパフォーマンスの詳細については、統合設計でのパフォーマンスに関する考慮事項 を参照してください。大規模な統合ソリューションでは、パフォーマンスの要件を満たすためにクラスタ構成が必要な場合もあります。クラスタの詳細については、『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration クラスタのコンフィグレーション」を参照してください。
可用性と信頼性
統合スペシャリストは、以下のような事項を確認してビジネス プロセスの可用性の要件を定義する必要があります。
一部のシステムではフェイルオーバが即時に機能して毎日 24 時間の可用性が必要とされ、その他のシステムでは可用性は営業時間内のみ必要とされ、営業終了後や週末にメンテナンスがスケジューリングされます。高可用性の統合ソリューションでは、信頼性の要件を満たすためにクラスタ構成が必要となります。クラスタ構成の詳細については、『WebLogic Integration ソリューションのデプロイメント』の「クラスタ デプロイメントのコンフィグレーション」を参照してください。
応答時間
統合スペシャリストは、ビジネス プロセスの応答時間の要件を定義する必要があります。たとえばサプライヤは、24 時間以内に入札要求に応答する必要がある場合や、60 分以内に落札の通知を受ける必要がある場合があります。応答時間の限界に達すると、イベントはタイムアウトになります。
セキュリティ
統合スペシャリストは、以下のような事項を確認してビジネス プロセスのセキュリティの要件を定義する必要があります。
スケーラビリティ
統合スペシャリストは、現在の仕事量と将来予想される仕事量に基づいてビジネス プロセスのスケーラビリティの要件を定義する必要があります。たとえば注文処理の統合ソリューションでは、サービスや追加のアプリケーション開発を妨げることなく、2 ヶ月以内に能力の 3 倍の注文数を処理できるようにしなければならない場合があります。スケーラビリティの要件を満たすために、統合ソリューションではクラスタ構成を利用できます。クラスタ構成の詳細については、『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration クラスタについて」を参照してください。
ロギングと否認防止性
統合スペシャリストは、以下のような事項を確認してビジネス プロセスのシステム ロギングの要件を定義する必要があります。
否認防止性とは、トレーディング パートナ間で特定のビジネス メッセージの送受信が行われたこと、または行われなかったことを証明する能力のことです。重要なビジネス メッセージについては、送信および受信の否認防止性を備えることが法律によって義務付けられている場合があります。
統合ソリューションのトポロジの定義
統合スペシャリストは、統合環境のさまざまなエンティティの物理的な位置を指定する統合トポロジを定義する必要があります。このトポロジでは、エンティティ間のネットワーク接続のタイプ（LAN、WAN、インターネット、ダイアルアップなど）についての情報も必要です。
統合スペシャリストは、統合ソリューションのすべてのエンティティが以下のどの形態で配置されるのかを確認する必要があります。
サンプル WebLogic Integration アプリケーションの要件の指定
以下の節では、サンプルの WebLogic Integration アプリケーションで要件がどのように定義されるのかを説明します。
統合ソリューションとビジネス プロセスの指定
サンプルの WebLogic Integration アプリケーションでは、General Control Systems（GCS）がサプライヤとのバリュー チェーンを管理しやすくするために単一の統合ソリューション（仕入れの統合）を定義します。同社の解析によると、以下の 2 つのビジネス プロセスで統合要件を定義する必要があります。
これら 2 つのプロセスにはつながりがあります（GCS がサプライヤを選んだ後、そのサプライヤに対して発注書が発行される）。これらのプロセスは、今後見込まれる販売または実際の販売によって EnergyMiser 76 製品の増産が必要になったときに開始されます。増産が要求されれば、さらに多くの部品を調達する必要性が高まります。
これらのビジネス プロセスの特性はサンプルのシナリオでは定義されていませんが、以下のような要素を解析することが望まれます。
価格と在庫の照会手順
サプライヤを選ぶビジネス プロセスは次の手順で行われます。
発注書の発行手順
選ばれたサプライヤに発注書を発行するビジネス プロセスは次の手順で行われます。
アクタとロールの指定
サンプルの WebLogic Integration アプリケーションでは、両方のビジネス プロセスでバイヤおよびサプライヤ（セラー）のロールを果たすトレーディング パートナが関与します。さらに、発注ビジネス プロセスでは EIS との統合が伴います。
アクタのタイプ
GCS のシナリオには、人間のアクタとソフトウェアのアクタが存在します。
サプライヤの選択におけるアクタとロール
GCS は、以下のタスクを行うバイヤのロールを果たします。
各サプライヤは、以下のタスクを行うセラー候補のロールを果たします。
発注書の発行におけるアクタとロール
GCS は、以下のタスクを行うバイヤのロールを果たします。
GCS の ERP システムは、発注の情報マネージャとしてのロールを果たします。その ERP システムでは、発注書の作成とサプライヤからの確認書の受信が処理されます。
選ばれたサプライヤは、以下のタスクを行うセラーのロールを果たします。
ビジネス イベントの指定
サンプルの WebLogic Integration アプリケーションでは、ビジネス イベントが両方のビジネス プロセスに関連付けられています。
サプライヤ選択プロセスのイベント
サプライヤの選択プロセスには、以下のイベントがあります。
発注プロセスのイベント
発注プロセスには、以下のイベントがあります。
データ フローの要件の指定
サンプルの WebLogic Integration アプリケーションには、以下の主要なデータ フローがあります。
これらのデータ フローについての特定の情報（予想されるデータ量、ピーク時と小康時のデータ量、周期的なパターンなど）は、サンプルの WebLogic Integration アプリケーションでは定義されていません。
要件のリスト
上記のデータ フローには、以下の要件があります。
注意: これらの条件でのトランザクションのロールバックは、サンプルの WebLogic Integration アプリケーションでは実装されていません。
価格と在庫の要求プロセスのデータ フロー
価格と在庫の要求のデータ フローには、以下の情報が含まれます。
価格と在庫の応答データ フローには、以下の情報が含まれます。
集約された応答のデータ フローには価格と在庫の応答のすべての情報が含まれますが、その情報は共通の要求識別子と要求の日付に基づいて収集されます。
発注プロセスのデータ フロー
発注要求のデータ フローには、以下の情報が含まれます。
発注のデータ フローには、以下の情報が含まれます。
発注確認のデータ フローには、発注のすべての情報に加えて販売注文の番号と日付が含まれます。
サービス品質の指定
サンプルの WebLogic Integration アプリケーションには、以下の項目のサービス品質（QoS）要件があります。
パフォーマンス
サンプル WebLogic Integration アプリケーションのシナリオにはパフォーマンスの要件、トランザクションの量、またはピーク時の負荷が含まれていませんが、送信する価格と在庫の照会の数や受信するサプライヤの応答の数に関係なく、常に許容レベルのパフォーマンスを提供するための統合ソリューションが GCS で必要とされることは十分に推測できます。
可用性と信頼性
サンプルの WebLogic Integration アプリケーションに可用性と信頼性の要件はありませんが、統合ソリューションで以下のことを実現しなければならないことは明らかです。
応答時間
サンプルのシナリオでは応答時間の要件が示されていませんが、ERP アプリケーションで新しい発注が作成されたときには、発注確認の要求を直ちに（たとえば 10 秒以内に）送信しなければなりません。
セキュリティ
GCS には、以下のセキュリティ要件があります。
スケーラビリティ
クラスタ環境で WebLogic Integration を使用すると、GCS ではシステムを拡張し、多数のサプライヤおよび大幅に増加した入札募集と発注を処理することができます。
ロギングと否認防止性
発注と発注確認はバイヤとセラーの適法契約を示すものなので、それらは否認防止性の基準に従っていなければなりません。
統合トポロジの指定
サンプル WebLogic Integration アプリケーションの両方のビジネス プロセスでは、GCS とそのトレーディング パートナの間で GCS のファイアウォールを介して通信が行われます。また、GCS のファイアウォールの内側では、ERP システムとの統合のために、統合ソリューションは ERP システムにネットワーク アクセスできなければなりません。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
