3.2 プロジェクト・スコープでのプロジェクトの定義

定義および設計プロセスは、プロジェクト・スコープ内で開始します。このスコープでは、システムの実行目標、システムの要件（ビジネス要件と技術要件の両方）、およびそれらの要件を満たすために必要となるアプリケーションとサービスを評価します。このフェーズの最後には、このフェーズの結果を詳述するソリューション仕様を開発し、アプリケーション・スコープでの各アプリケーションの設計および実装に必要な情報を提供します。

プロジェクトのソリューション定義を設計する手順は、次のとおりです。

サービス・ポートフォリオ計画を作成します。

技術的にはエンタープライズ・スコープの一部分であるサービス・ポートフォリオ計画は、エンタープライズが現在所有しているすべてのサービスまたは今後必要となるサービスの集まりです。このポートフォリオを作成して維持することによって、エンタープライズは既存のサービスを再利用できるため、ソフトウェアおよびデータの冗長性を削減できます。詳細は、第3.2.1項「サービス・ポートフォリオ計画の作成」を参照してください。
ビジネス目的およびシステム目的を設定します。

ビジネス目的を設定するときは、現状に関係なく、最終的に求められる結果を決定します。つまり、ビジネス問題のソリューションに重点を置きます。ビジネス目的を設定した後は、その目標を使用して要件を導き出します。詳細は、第3.2.2項「ビジネス目的およびシステム目的の決定」を参照してください。
主要なビジネス要件および操作要件を決定します。

SOAプロジェクトに対する要件を収集するためのベスト・プラクティスは、すべてのタイプのアプリケーションまたはアプリケーション統合プロジェクトの場合と同じですが、SOAの利点を完全に実現するには、いくつかの追加ステップが必要です。たとえば、プロジェクト内の各サービスまたは機能に対する要件では、プロジェクト全体を考慮する必要があり、さらに、サービス自体のみでなくプロジェクト・スコープ外のサービスも考慮する必要があります。

これを実現するには、SOBA（サービス指向ビジネス・アプリケーション）のユースケースを設計します。このユースケースは、特定のビジネス・プロセスを含む大まかなユースケースです。たとえば、登録プロセスはSOBAとみなすことができます。 SOBAのユースケースを定義した後は、SOBAのプロセス内の各ステップに対するユースケース、および各ステップで使用するサービスについて重点的に作業を行います。詳細は、第3.2.3項「ビジネス要件および操作要件の決定」を参照してください。
検出フェーズを実行します。

このフェーズでは、最初に、前のステップで決定した要件を分析し、ソリューションに含まれている実際の製品やサービスは識別せずに、ソリューションの高レベルな設計を決定します。次に、実際のサービスを検出します。ここでは、必要な機能を提供できる既存のサービス、変更が必要な既存のサービス、および作成する必要があるサービスを決定します。詳細は、第3.2.4項「検出フェーズの実行」を参照してください。
ビジネス・プロセスのオーケストレーション層および起動するサービスを定義します。

ビジネス・フローおよび実装する必要があるサービスを決定した後は、それらを統合する方法を定義します。前のステップでは、高レベルのビジネス・ニーズに重点を置きました。このステップでは、技術的なニーズに重点を起きます。たとえば、このステップでは、ビジネス・プロセスのモデル化ロジック、プロセス変数定義、および詳細な例外処理を定義します。サービスについては、サービスの責任を、必要な粒度とともに定義します。この定義によって、要件をより正確に把握し、システムの内部作業の詳細を提供できます。詳細は、第3.2.5項「プロジェクトの定義」を参照してください。
プロジェクトのアプリケーション・スコープで使用可能なソリューション仕様を作成します。詳細は、第3.2.6項「ソリューション仕様の作成」を参照してください。

3.2.1 サービス・ポートフォリオ計画の作成

新規のソフトウェア・アプリケーションの取得または開発を合理化するためには、サービス・ポートフォリオ計画を作成します。この計画を作成して維持することによって、可能な場合はいつでも、既存のサービスとアプリケーションを再利用または再計画できます。また、この計画によって、必要な機能の作成時間を削減できます。

サービス・ポートフォリオ計画を作成する手順は、次のとおりです。

エンタープライズに必要な機能（既存および計画済の両方）のトップダウン分析を実行します。

これを行うには、高レベルなビジネス・ドメインの見地からエンタープライズを再述して、ドメイン分解を実行します。次に、各ドメイン内のサービスとその操作を定義します。

たとえば、Global Companyはコンシューマに電子機器を販売しています。従来は、通信販売によってビジネスを行っていました。顧客は顧客サービス担当に電話をかけ、担当は顧客情報と注文情報をシステムに入力していました。与信検証、注文に対して管理者の承認が必要かどうかの判断など、注文プロセスのほとんどで手動によるタスクが必要でした。 Global Companyは、現在、顧客がWebベース・アプリケーションを使用して、製品を直接購入できるようになることを望んでいます。これは、手動のタスクの多くを自動化することを意味します。さらに、Global Companyは、自動化された受注記帳の機能をWebシステムと社内の担当が使用するシステムとの間で共有することも望んでいます。

これを実現するために、Global Companyは、図3-1に示すようなドメイン分解を実行します。この図には、製品、操作、受注記帳および顧客など、いくつかの高レベルなビジネス・ドメインが示されています。受注記帳ドメインについては、発注に必要ないくつかのサービス（商品の調達、与信検証、注文の承認、受注管理、注文品の出荷を含む）が確認されています。さらに、受注管理サービスには、注文情報の取得と設定、およびステータスの取得と設定が含まれることが確認されています。

図3-1 Global Companyのドメイン分解（一部）

各ドメインに対するサービスのリストが、サービス・ポートフォリオの最初のバージョンになります。

既存のアプリケーションとサービスのボトムアップ分析を実行します。

これを行うには、現在使用している既存のすべてのデータと機能を確認し、特定タスク用に機能を提供するグループに集約し、そのグループにサービス記述を割り当てます。通常、このステップを実行すると、トップダウン分析では捕捉されなかった追加サービスが検出されます。

たとえば、図3-2に、Global CompanyがSOA Order Bookingアプリケーションを作成する前の、集約された既存サービスのリスト（一部）を示します。

図3-2 Global Companyのボトムアップ分析（一部）

与信検証サービスはこの分析で検出されたことに注意してください。多くの場合、社外システムを含むプロセスは、トップダウン分析時に見落とされ、ボトムアップ分析で検出されます。

ヒント:

ポートフォリオには、社外のアプリケーションとの通信に必要なサービスを含めてください。たとえば、受注記帳プロジェクトには、Global Companyの外部にある与信検証サービスとの通信が必要です。このサービスは、Global Companyのポートフォリオに含める必要があります。

ビジネス・プロセスのトレースを実行します。

このステップでは、エンタープライズ内で現在使用しているか、必要なビジネス・プロセスをメモします。そのためには、高レベルなビジネス・プロセスをトレースして、プロセスを実行する環境内での相互作用を識別します。次に、このビジネス・プロセスで生成される主要なイベント、およびそれらのイベントが原因でこのビジネス・プロセスが環境から受信するレスポンスを収集します。これらのレスポンスによって、サービスが提供する操作の基礎が形成されます。

たとえば、図3-3に、Webベース・ポータルでのショッピングに関するビジネス・プロセス、およびサービスが提供する関連操作を示します。注文を作成するには、ユーザーは登録が必要です。これで、ユーザーは製品を参照し、その詳細を表示し、注文に追加して発注できます。この注文プロセスには、必要な機能を提供するための特定なサービスが必要です。 1つのドメインに含まれるサービスは、多くの場合、同じプロセス内では使用されないことに注意してください。

図3-3 注文の作成に関するビジネス・プロセスのトラッキング

このトラッキング・プロセスで、カート機能が必要であることが検出されました。この機能は、概念的なサービスとしてポートフォリオに追加されます。
ステップ1、2および3を繰り返して、サービスのリストを調整します。現在あるサービス、およびポートフォリオの完成に必要なサービスをメモしてください。

プロジェクトが完了するたびにポートフォリオ計画に戻り、プロジェクトで作成したすべての機能がポートフォリオに含まれていることを確認します。

3.2.2 ビジネス目的およびシステム目的の決定

プロジェクト目的を実現することで、ビジネス問題が解決します。適切に定義された目的は測定可能で、多くの場合ビジネス・プロセスに直接関連しており、配布可能です。たとえば、Global Companyのビジネス目的の一部を次に示します。

顧客の80%がWebサイトを使用して自分で注文を作成できること
顧客サービス担当の従業員が注文入力に要する時間を50%削減すること
顧客サービス担当が注文ステータスをリアルタイムで表示できるようにして、レスポンス時間を75%短縮すること

SOAプロジェクトでは、ビジネス上の利点に重点を置く必要があります。このため、システム目的（機能に基づかない目的）は、1つ以上のビジネス目標をサポートすることで、ビジネス上の利点を提供できる場合のみ定義する必要があります。たとえば、Global Companyには、セルフ・サービスWebサービスの目標をサポートする次のシステム目標があります。

システムは、週に7日、24時間使用可能であること
顧客との相互作用中に、システムのレスポンス時間によってユーザーの操作に遅延が生じないこと
入力されたすべてのデータが後日に取得可能であること

特定のビジネス目的やシステム目的を実現するには、多くの場合、高レベルな目的を示すことから始めて、特定の目的を決定するまで継続して調整する必要があります。

目的を決定する手順は、次のとおりです。

高レベルな目的を示します。

多くの場合、目的は非常に漠然としており、量的に測定できません。たとえば、Global Companyには、次の高レベルな目的があります。
- 顧客がWebサイトを介して製品を注文できること
- 可能な場合は、既存のシステムを再利用すること
- 現在の手動プロセスを自動化されたプロセスに置き換えること
これらの目的を具体化します。

目的を具体化するには、その目的が測定可能、達成可能、現実的およびタイムリであることが必要です。さらに、目的を測定可能にすると、完了したプロジェクトが目的に合致しているかどうかを容易に判断できます。

たとえば、Global Companyの高レベルな目的は、次のような具体的な目的に調整できます。
- 顧客の80%がWebサイトを使用して自分で注文を作成できること
- 既存の機能の50%を再利用すること
- 既存の手動タスクの50%を自動化すること
システム目的を決定します。

システム目的は、いくつかのビジネス目的から導き出されます。システム目的は、ビジネス目的と同じ方法で処理する必要があります。つまり、システム目的は具体的、測定可能、達成可能、現実的およびタイムリであることが必要です。
目的に優先順位を付けます。

優先順位を付けることによって、プロジェクト開発の開始時に、優先順位の最も高い目的を達成するために必要な事項に集中できます。たとえば、次のカテゴリを使用して優先順位を付けることができます。
- 必須: プロジェクトの成功に不可欠
- 必要: 不可欠ではないが、必須とみなす必要がある
- 推奨: 推奨するが、それがなくてもプロジェクトは成功する
- 適用外: 制限があるため、将来のプロジェクト用に繰り延べた目標

3.2.3 ビジネス要件および操作要件の決定

ビジネス要件および操作要件を決定するには、ユースケース・モデルを作成します。このモデルを作成するときは、定義したビジネス目的への取組みに重点を置きます。ユースケースには、システムとの間で相互に作用するアクターとその内容、およびその相互作用の目標を定義します。ユースケースによって、検出フェーズで使用するビジネスの相互作用ダイアグラムが完成します。このダイアグラムによって、ユースケースの履行に必要なサービスを決定し、既存のサービスと開発が必要となるサービスを識別します。

ユースケース・モデルを作成する手順は、次のとおりです。

システムとの間で相互に作用するアクターを決定します。

アクターは、ユーザーおよびプロジェクトのシステムとの間で相互に作用する他のシステムを表します。 Global Companyの受注記帳アプリケーションの場合は、次のアクターを定義できます。
- 顧客: Webサイトで登録、発注、および過去の注文の確認を行うユーザー
- 顧客サービス担当: 顧客のかわりにシステムにアクセスして、発注や注文の確認を行う社内の従業員
- マネージャ: 注文を承認する社内の従業員
- CRMアプリケーション: 顧客情報を格納する既存のアプリケーション
- 与信検証システム: 顧客の与信情報を検証するシステム
- Rapid Manufacturer: 注文に対して見積りを提示し、製品を提供する会社
- Select Manufacturer: 注文に対して見積りを提示し、製品を提供する会社
各アクターに対してユースケース・パッケージを定義します。

ユースケース・パッケージは、各アクターに対する高レベルなユースケースです。

たとえば、図3-4に、Global Companyの一部のアクターに対する高レベルなユースケースを示します。顧客と顧客サービス担当は発注と登録を行う必要があり、マネージャは顧客分析の確認と注文の承認を行う必要があります。

図3-4 SOAプロジェクトの高レベルなユースケース
各ユースケース・パッケージを検討し、実際にSOBAとして定義できるかどうかを判断します。

SOBAは、特定のビジネス・プロセスを含むユースケース・パッケージです。発注パッケージは、実際には2つの異なるSOBAとして定義できます。 1つは製品のショッピングと注文の作成、もう1つは注文の履行プロセスです。

たとえば、Global Companyでは、次のSOBAが必要と判断できます。
- 顧客の管理
- 製品のショッピングと注文の作成
- 注文の記帳
- 注文の確認
次のステップでは、高レベルなユースケース・パッケージ、つまりSOBAをさらに詳細なユースケースに分解します。これによって、各SOBAによって公開されるサービスの識別を開始できます。
各SOBAに対してユースケースを定義します。

ユースケースでは、各SOBAのステップについて、下位レベルのビューが提供されます。たとえば、受注記帳SOBAには、図3-5に示すように、注文の発行、与信の検証、注文の承認、サプライヤの決定、および顧客への通知に関するユースケースを含めることができます。

図3-5 ユースケース
各ユースケースについて、事前条件および事後条件保証を定義します。

事前条件とは、ユースケースの開始前に満たす必要がある要件です。事後条件保証とは、ユースケースが正常に完了した場合に発生する処理です。

たとえば、与信検証ユースケースの場合、事前条件は、顧客のクレジット・カードの種類と番号が判明していることです。事後条件保証は、外部の検証システムが検証メッセージを戻すことです。
各ユースケースについて、メインの成功シナリオを記述します。

このシナリオには、ユースケースを満たすために必要なステップが含まれています。たとえば、与信検証ユースケースには次のステップが含まれます。
1. クレジット・カード情報を取得します。
  
  ヒント:
  この時点では、この情報の出所や取得方法は識別しません。
2. 検証のためにカード情報を送信します。
3. クレジット会社から検証を受信します。
シナリオ内の各ステップについて、失敗条件と拡張を識別します。

失敗条件とは、ユースケースの成功を妨げる事象が発生する可能性のある箇所です。ユースケースが別のパスで成功できるかどうかを判断することによって、失敗を回避できる場合があります。このような別のパスを拡張と呼びます。 SOAプロジェクトの例外および拡張では、ユースケースに含まれるすべてのアクター（セカンダリ・システムを含む）を考慮する必要があります。

たとえば、クレジット・カードが検証をパスしなかった場合は、与信検証ユースケースのステップ2で失敗条件が識別されます。
各失敗条件に対してリカバリ・ステップを定義します。

リカバリ・ステップは、小規模なユースケースとして処理する必要があります。つまり、リカバリ・ステップは、関連する失敗条件が記述された成功シナリオである必要があります。この処理方法は、すべての失敗条件が検出されるまで継続されます。

たとえば、検証に失敗した場合のリカバリ・ステップは次のようになります。
1. 注文ステータスをcanceledに設定します。
2. 顧客に、注文が取り消された理由を説明する電子メールを送信します。
このリカバリ・シナリオの2番目のステップには、電子メールが配信不能で戻ってきた場合の失敗条件もあります。
追加要件を追加します。

ユースケースには、完全に記述されない追加要件がある場合があります。たとえば、再利用と自動化はGlobal Companyのビジネス目的です。このため、与信検証ユースケースに対する追加要件は、クレジット会社との通信プロセスが完全に自動化され、顧客と社内担当の両方が同じプロセスを使用できることです。

さらに、プロセスを自動化するという追加要件があるため、クレジット会社との通信プロセスに関して別の追加システム要件を追加できます。
デプロイ制約を検討します。

SOAプロジェクトにはエンタープライズ外部のアクターが多数存在するため、これは特に重要です。

ユースケースの作成方法と使用方法の詳細は、Oracle Technology Networkにある次のドキュメントを参照してください。

「Defining Business Requirements using UML Use Case Diagrams in JDeveloper 10g」
```
http://www.oracle.com/technology/obe/obe9051jdev/Modeling/UML_UseCase.htm
```

「Design First, Code Next」

http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk3.html

3.2.4 検出フェーズの実行

検出フェーズでは最初に、既存の機能を考慮せず、前のフェーズで定義したユースケースに基づいてソリューションの高レベルな設計を作成します。次に、既存のサービスを、サービス・ポートフォリオからこの高レベルな設計にマップします。このマッピングによって、作成が必要なサービスと機能、現在のサービスと機能、および存在しているが要件を満たすには変更が必要なサービスと機能を決定します。

このフェーズを開始するには、第3.2.3項「ビジネス要件および操作要件の決定」で定義した各SOBAについて、検出プロセスを実行します。たとえば、Global Companyでは、発注と登録の各SOBAについて個別の検出フェーズを実行できます。ただし、計画を開始する前に、パッケージ間のすべての依存関係に注意することが重要です。

検出フェーズを実行する手順は、次のとおりです。

ビジネスの相互作用ダイアグラムを作成して、各SOBAのプロセス・フローを定義します。

前のフェーズで定義した各SOBAを検討すると、ほとんどのSOBAがプロセス中心であることがわかります。つまり、これらのSOBAは、基本的には、いくつかのサービス・レベルのエンドポイントから組み込んだ高レベルなビジネス・プロセスのまとまりです。この場合は、SOBAに関するビジネスの相互作用ダイアグラムを作成する必要があります。このダイアグラムは、プロセス内の各ステップがサービスと相互に作用して目標を達成する方法、および複数のサービスを1つのプロセス・フローに組み込む方法を示します。このダイアグラムは、サービスの起動に必要な方法は、同期か非同期かも示します。

たとえば、Global Companyでは、注文の承認プロセスが手動タスクのままであることが判明しているため（マネージャは注文を手動で確認して承認する必要があります）、非同期で起動する必要があります。

受注記帳SOBAに関するビジネスの相互作用ダイアグラムは、図3-6のようになります。プロセス・フロー内の各ステップは、あるサービスを指し示しており、これによって、プロセスが次のステップに進みます。

図3-6 受注記帳SOBAに関するビジネスの相互作用ダイアグラム（一部）

Global Companyは、このダイアグラムを作成することによって、受注記帳SOBAには次のサービス（一部）が必要であることを検出します。

注文
顧客
与信検証
デシジョン
承認

ヒント:

このSOBAのCustomerサービスは、登録SOBAのCustomerサービスとほとんど同じです。このため、サービスを定義および設計するときは、すべてのサービスがプロジェクト全体の複数SOBA間で再利用されることを考慮することが重要です。

検出したサービスを定義します。

すべてのサービスを検出した後は、各サービスを定義できます。詳細は設計フェーズで決定するため、ここでの定義は高レベルのままです。各サービスについて、次の内容を定義します。

サービス名: サービスの一意の名前。
サービスの説明: サービスの概要。
サービス・タイプ: 同期または非同期。
機能ドメイン: サービス・ポートフォリオ計画のドメイン分解で定義した、このサービスが属するビジネス・ドメイン。
サービス分類: サービスは次のいずれかに分類できます。
- コンポーネント・サービス: 単一のエンタープライズ・リソースに対して機能する可能性がある単純なアトミック・サービス。この例には、データベースやコードなどがあります。
- データ・サービス: 複数のデータ・ソースに対するデータ問合せまたは問合せとトランスフォーメーションの組合せ（あるいはその両方）を提供するサービス。
- ビジネス・サービス: コンポーネント・サービスとビジネス・ルールの組合せで構成されるアトミック・サービス。たとえば、集計サービスやビジネス委任などです。
- ワークフロー・サービス: 他のサービスとの調整を行い、外部との相互作用がある長期間のビジネス・プロセス。
サービス・プロセス・ルール: サービス処理ロジックの詳細。
メッセージの書式: インバウンドおよびアウトバウンド・メッセージの書式。同期サービスに関するフォルト・メッセージの書式の詳細も含みます。
セキュリティ要件: クライアントの認証、認可およびデータの暗号化に関するセキュリティ。
アプリケーション: このサービスが機能を果たすために相互に作用するデータ・ソース（例: アプリケーション、データベース）。通信インタフェースの詳細も含みます（使用可能な場合）。
サービス依存性: このサービスが機能に関して依存している他のサービス。
ヒューマン・ワークフロー: ヒューマン・ワークフロー機能。
パフォーマンスの目標とメジャー: サービスに関する特定のパフォーマンス・メトリック。これには、サービス処理時間、同時ユーザー数、メッセージ・データのサイズなどが含まれる場合があります。
例外処理: 例外および例外処理ロジック。サービスでフォルトが生成される条件も含みます。

たとえば、受注記帳SOBAのCreditValidatingService定義は、表3-1に示すようになります。

表3-1 CreditValidatingServiceサービス定義

項目	説明
サービス名	`CreditValidatingService`
サービスの説明	顧客のクレジット・カードが有効かどうかを判断します。
サービス・タイプ	同期。
機能ドメイン	注文履行。
サービス分類	ビジネス・サービス。
サービス・プロセス・ルール	クレジット・カードの種類と番号についてのメッセージが、外部の与信検証アプリケーションに送信されます。このアプリケーションは、カードが有効な場合は`true`を、無効な場合は`false`を戻します。
メッセージの書式	XML。
セキュリティ要件	クレジット・カード番号は暗号化されている必要があります。
アプリケーション	外部の与信検証システムとインタフェースします。このシステムでは、すべてのメッセージが準拠する`wsdl`ファイルが提供されます。
サービス依存性	`Customer`サービスでは、クレジット・カード情報を提供する必要があります。
ヒューマン・ワークフロー	なし。
パフォーマンスの目標とメジャー	週7日、24時間使用可能である必要があります。
例外処理	クレジット・カードが有効でない場合は、フォルトが起動します。これによって、注文のステータスが`canceled`に設定されます。

定義した各サービスを、第3.2.1項「サービス・ポートフォリオ計画の作成」で作成したサービス・ポートフォリオと比較します。

プロジェクトに必要なサービスが、実装済サービスまたは概念的なサービスとしてポートフォリオにすでに存在している場合があります。ポートフォリオに含まれていないサービス（実装済サービスまたは概念的なサービスとして）がプロジェクトで必要な場合は、そのサービスを追加する必要があります。サービスが概念的なサービスとしてポートフォリオに存在している場合は、そのサービスをプロジェクトの一部として作成する必要があります。

3.2.5 プロジェクトの定義

ビジネス・フローおよび実装する必要があるサービスを決定した後は、フローにサービスを組み込む方法を定義します。このフェーズでは、ビジネス・プロセスのモデル化ロジック、プロセス変数定義、および詳細な例外処理を定義して、複数のサービスをあわせて使用する方法を決定します。サービスについては、サービスの責任を、必要な粒度とともに定義します。

オーケストレーションを定義する手順は、次のとおりです。

ユースケースを分析し、すべてのユースケースをあわせて使用する方法を決定します。

たとえば、要件フェーズと検出フェーズで、Global Companyには、次のSOBAが必要であることが判明しています。
- 顧客登録: 社内の顧客サービス担当用に顧客登録機能が存在しますが、Global Companyは、顧客が自分自身を登録できるようなWebベースの登録プロセスを実装する必要があります。
- 注文の作成: 登録プロセスと同様に、Global Companyは、顧客用にWebベースのショッピング・サイトを実装する必要があります。
- 受注記帳: 現在、このプロセスは社内の顧客サービス担当用に存在しますが、Global Companyの要件には、手動プロセスを自動化し、社内の従業員と外部の顧客の両方がプロセスを使用するように記述されています。これは、プロセスとサービスが、Webアプリケーションと内部アプリケーションの両方からアクセスできる必要があることを意味します。
- 注文の確認: これは既存のプロセスで、マネージャは注文を手動で確認し、注文を履行するかどうかを決定する必要があります。このサービスも、Webサイトと社内の顧客担当システムの両方で使用できる必要があります。
登録プロセスは既存のCRMアプリケーションとインタフェースするため、Global Companyは、直前のフェーズで検出したCustomerサービスがCRMアプリケーションと直接インタフェースすることを決定します。登録プロセスのフローは、Webサイト用に定義します。

同様に、Webサイトは製品データベースに直接インタフェースして、顧客が製品を閲覧して選択できるようにします。このフローも定義します。登録プロセスとショッピング・プロセスは、いずれも単純なフローです。このため、Global Companyは、これらのフローにBPELプロセス・フローは不要と判断します。

Webサイトの詳細な定義と設計は、標準的なWeb設計プロセスに従うことができます。これには、Webサイト内の情報のフローをサポートするために必要なクラスの定義も含まれます。たとえば、Webサイト向けの製品表示を処理するエンティティ・クラスを定義する必要があります。

受注記帳と注文承認の機能には、社内の顧客サービス・アプリケーションと顧客Webアプリケーションの両方からアクセスする必要があるため、Global Companyは、Enterprise Service Bus（ESB）を使用してこのプロセスを起動することを決定します。さらに、このプロセスは実行時間が長く、多数の異なるサービスを組み込むため、ビジネス・プロセスの管理には、BPELプロセス・フローを使用することを決定します。

また、注文の承認プロセスでは手動のワークフローを残す必要があるため、このフローはそのまま維持するが、起動は自動化することを決定します。
各種のプロセス・フローおよびESBを定義します。

BPELフローの使用箇所を決定した後は、フローにサービスを組み込む方法を定義できます。図3-7に、Global Companyで登録プロセスと受注記帳プロセスを組み込む方法を示します。このダイアグラムは、システムがビジネス目標を達成する方法ではなく、システムが機能する方法に重点を置いていることに注意してください。

図3-7 Global Company用の高レベルな設計

 各プロセス・フローおよびESBについて、次の内容を定義します。
- フロー・ロジック: フローの役割、フローに含める必要のあるステップ、および複数のサービスとの相互作用方法を定義します。
  
  たとえば、履行情報のルーティングに使用するESBは、注文情報を郵政公社で使用されているバッチ・プロセスで処理可能なデータに変換したり、データを表に移入するデータベース・アダプタで処理可能なデータに変換する必要があります。
- サブプロセス: 詳細と同じレベルで、フローのサブプロセスを定義します。
- 変数定義: フロー全体で使用する情報の保持に必要な変数を定義します。
- ビジネス・プロセス・フロー・スコープ: フローのスコープを定義します。スコープは、特定のサービスの中心となるネストされたアクティビティの集まりをグループ化し、その動作を定義する主要なアクティビティを格納します。スコープには、独自のローカル変数、フォルト・ハンドラなどを含めることができます。
  
  たとえば、受注記帳フローにはCreditServiceスコープがあり、このスコープには、与信情報の検証に必要なすべてのアクティビティが格納されます。
- 例外処理: フローで発生する可能性があるすべてのエラーを定義し、そのエラーの技術的な処理方法を定義します。たとえば、タイムアウトの処理方法を決定します。
サービスを分析、定義および分類します。

サービスは、標準アプリケーションでクラスを分析および定義するのと同じ方法で定義します。たとえば、通常のクラス分析フェーズでは、分析クラスを識別し、境界/インタフェース・クラス、エンティティ・クラスおよび制御クラスに分類します。

ただし、SOAシステムに対してサービスを定義するときは、システム内の他のコンポーネントに対するサービスの責任に重点を置く必要があります。さらに、サービスの粒度を定義する必要があります。粒度を決定する際に重要な事項は次のとおりです。
- ビジネスの適合性: 1つサービスで、ビジネス・タスクの1つのアトミック操作をサポートするのが理想的です。これによって、特定のタスクに対して十分な機能が提供されます。サービスを簡潔にすると、そのサービスは一般化されるため、再利用の可能性が高まります。
  
  たとえば、受注記帳フローには、OrderサービスとOrder Statusサービスの両方が含まれます。 Orderサービスは、注文情報を維持するために使用されます。ただし、フロー中の様々なポイントで注文のステータスを更新する必要があるため、ステータスを更新する機能が分離しています。このように機能を分離することによって、個別の機能を再利用できます。
- パフォーマンスおよびサイズ: サービスはリモートでコールされるため（したがって、ラウンドトリップが必要）、パフォーマンスのオーバーヘッドが発生します。このオーバーヘッドを回避するには、サービスのコール回数をできるかぎり少なくします。そのためには、前述したように、サービスが適切なレベルの機能を持つように調整する必要があります。たとえば、サービスの粒度を細かくすると、1つのタスクを完了するために多数のサービスを頻繁にコールする必要があるため、望ましくありません。
  
  たとえば、注文を処理するサービスと、注文内の各注文品目を処理するサービスを別個に定義するのではなく、受注記帳システムでは、1つのサービスで注文と注文品目の両方を処理します。
  
  さらに、サービスの数は、それぞれのサービスが効率的に処理できるメッセージのサイズによっても制限されます。メッセージが大きくなり過ぎると、必要なリソースが多すぎて処理できなくなります。
- 状態管理: トランザクションおよび状態操作は、可能なかぎり自己完結型である必要があります。これによって、サービスが完了しなかった場合でも、状態が失われるリスクが軽減されます。サービスでデータを格納するときは、1つのトランザクション内で処理し、トランザクションの失敗がデータの損失や破損の原因にならないようにする必要があります。
- 位置の透過性: すべてのサービスは、リモートで起動する必要があります。このためには、サービスが存在する位置について依存関係がないことが必要です。
- 実装の独立性: すべてのサービスは契約ベースの設計を使用する必要があります。つまり、実装するインタフェースは安定して容易に拡張可能である必要があります。インタフェースの背後にある実装は、インタフェースを変更せずに、容易に変更可能であることが必要です。
これで、検出フェーズが完了しました。サービスの作成方法と使用方法を理解すると、各サービスをさらに分類できます。

サービスは通常次のように分類されます。
- サービスによって提供される機能
  - インフラストラクチャ。例: DNS参照
  - データ。例: フェデレーテッド問合せ
  - ビジネス・ロジック。例: 不正チェック・アルゴリズム
  - ユーティリティ。例: トランスフォーメーションやルーティング
  - 情報システム。例: ERP機能
  - プロセス制御。例: 承認プロセス
  - UI。例: ポートレット
- サービスの使用方法
  - 高レベルのビジネス。例: PO処理
  - サポート・ビジネス。例: PO承認ワークフロー
  - 高レベルのテクノロジ。例: ユーザー参照
  - サポート・テクノロジ。例: ロギング
- サービスの構成方法
  - 単純な構成。例: そのまま使用できる電子メール・アプリケーションで提供されるWebサービス
  - ラップされた構成。例: 既存CRMアプリケーションの機能を起動するWebサービス
  - コンポジット構成。例: 複数サプライヤからの見積りを組み合せるサービス
- サービスの起動方法
  - 同期/非同期。例: 特定のサービスへのリクエスト/リプライ
  - イベント・ベース。例: 対象のパーティが処理する通知
各サービスは通常、複数の分類に属しています。たとえば、最初に表3-1で説明したCreditValidationサービスは、サポート・ビジネス・ロジックを提供し、既存のアプリケーションに対するラッパーであり、同期して起動するユーティリティ・サービスとしてさらに分類できます。

このような分類によって、特定の分類に関する既存のベスト・プラクティスに容易に準拠できます。たとえば、Global Companyは、データ・サービスとして分類されたサービスに対して、データのアクセスとセキュリティに関する標準を設定できます。さらに、Global Companyは、コンポジット・サービスとして分類されたすべてのサービスでBPELフローを使用して構成を組み込み、フローは既存の標準に準拠する必要があることを記述した標準を設定できます。分類を使用してベスト・プラクティスおよび標準を導き出す方法については、第3.3.2項「サービスの設計」で説明します。
各フローおよびサービスに対する共通の要件（通常は機能以外の要件）を識別します。

ユースケースに記述された機能以外の要件を確認し、特定の要件に変換します。これらの要件から、構造的な設計プロセスが導き出されます。通常の操作上の要件は次のとおりです。
- スループット
- レスポンス時間
  - ラウンドトリップ
  - 待機時間
- 高可用性
- フォルト・トレランス
- セキュリティ
  - アクセス制御
  - 暗号化
- 監視
  - アラート
  - キー・パフォーマンス・インディケータ

3.2.6 ソリューション仕様の作成

この時点で、ソリューション仕様を開発すると便利です。ソリューション仕様によって、提示されたシステムをステークホルダが確認できるメカニズムが提供されます。このメカニズムの提供で、ソリューションによって当初のビジネス目的が実現されることを確認できます。

各会社にはソリューション仕様に対する独自の要件がありますが、SOAソリューションでは次の項目を検討する必要があります。

背景
- SOAに関するエンタープライズ・レベルの重要な目的
- SOAシステムが準拠する必要がある主要な管理原則
プロジェクト・スコープ
- 第3.2.2項「ビジネス目的およびシステム目的の決定」で定義したビジネスの目標と目的
- 第3.2.3項「ビジネス要件および操作要件の決定」で開発したビジネス要件
SOBA
- 第3.2.5項「プロジェクトの定義」で定義した必須サービスおよびプロセス・ポートフォリオ
高レベルのアーキテクチャ
- 第3.2.5項「プロジェクトの定義」で説明したサービスとしてのコンポーネント・ビュー
- 第3.2.5項「プロジェクトの定義」で説明したプロセス・フロー・ビュー
操作要件
- パフォーマンス、および様々な設計フェーズで説明して検出された機能以外のその他の要件
- 可用性、セキュリティおよび管理性に対する要件
標準およびプロジェクトの配布ベスト・プラクティスに関する高レベルな概要（詳細な標準については、設計フェーズで説明します）
ソリューション仕様が機能要件と操作要件を満たし、適用可能なすべてのアーキテクチャ、設計、実装および会社の規定のベスト・プラクティスにも準拠していることを確認するためのSOA管理準拠の確認