|
|
WLI は、プロセス駆動型のサービス指向アーキテクチャ (SOA) アプリケーションの実装に使用できる、エンタープライズ クラスの製品です。図 3-1 は、サービス指向アプリケーションに関する BEA の参照アーキテクチャを示しています。
WLI アプリケーションでは、サービス指向アプリケーションに関する BEA の参照アーキテクチャを使用することをお勧めします。
参照アーキテクチャは汎用的なものであり、スタンドアロンの WLI や、複数の製品の組み合わせで実装できます。参照アーキテクチャの主なコンポーネントは次のとおりです。
ビジネス プロセスおよびサービスのモデリングには以下の手順があります。
以下の手順に従うことで、優れたビジネス プロセスを定義できます。
ビジネス プロセスの自動化という決断の背景にある主な目的を理解しておくことが重要です。ビジネス プロセスを定義する目的は次のとおりです。
KPI はプロセスのパフォーマンスを把握するための主要指標です。プロセス KPI の例は次のとおりです。
プロセスを定義する前に、プロセスのアクターまたは参加者を特定します。人間のアクターやアプリケーションのほか、データ ソースやパートナもビジネス プロセスのアクターまたは参加者になることができます。
パブリック プロセスとプライベート プロセスは、B2B ドメインでは特に重要です。パブリック プロセスは外部ユーザから見えるプロセスです。プライベート プロセスは、アプリケーション内の外部ユーザには見えないタスクをバックグラウンドで実行するプロセスです。プライベート プロセスはパブリック プロセスにリンクしています。パブリック プロセスをプライベート プロセスのフロント エンドとして使用する場合、パブリック プロセスのクライアントを妨害することなく、プライベート プロセスを変更することができます。
パブリック プロセスはモジュール形式にすることをお勧めします。パブリック プロセスには、セキュリティ、スケーラビリティ、可用性に関して、より高度な要件が課せられます。通常、パブリック プロセスにはメッセージング、プロトコル、標準に関する特殊な要件がありますが、そうした要件は事前に特定しておく必要があります。図 3-2 は、パブリック プロセスとプライベート プロセスのパターンを示しています。
パブリック プロセスとプライベート プロセスを統合するには、WLI のメッセージ ブローカ コンポーネントを使用して、これらのプロセス間で緩やかに結合されたパブリッシュおよびサブスクライブ アーキテクチャを使用する方法があります。
パブリック プロセスとプライベート プロセスを統合するもう一つの方法は、パブリック プロセスとプライベート プロセスの間でプロセス コントロールを使用し、パブリック プロセスのフロント エンドとして Java Web サービス (JWS) を使用する方法です。パブリック プロセスとプライベート プロセスが同じドメインにある場合は、プロセス コントロール (PC) を使用する方が適しています。詳細については、「JPD 間の通信」を参照してください。
特に B2B ドメインにおいて、多くのビジネス プロセスは会話型の性質を持っています。たとえば、見積り要求サービスでは、数回のメッセージ交換の後に、見積り価格が合意に達します。開始者は開始者プロセスを使用して、ビジネス会話を開始します。参加者プロセスは開始者プロセスからの要求に応答します。開始者プロセスでは次のことを行います。
小さなモジュール形式のプロセスを定義することをお勧めします。モジュール形式のプロセスは特定のビジネス ニーズに対応します。モジュール形式のプロセス定義は、ビジネス プロセスの再利用につながります。数個の長いプロセスよりも、多数のモジュール形式のプロセスを管理する方が容易です。
特定のビジネス目的を達成するために、エンド ツー エンドのクロス ファンクショナル プロセスを使用すると、ビジネス プロセス管理 (BPM) から最良の結果を得ることができます。
エンド ツー エンドのクロス ファンクショナル プロセスの例は次のとおりです。
エンド ツー エンド プロセスの理想的な使用方法は、多数のモジュール形式のビジネス プロセスの間で緩やかに結合された統合を使用することです。
主要なプロダクション プロセスはモニタ プロセスから常に分離しておくことをお勧めします。プロダクション プロセスには、スケーラビリティ、パフォーマンス、および可用性について、モニタ プロセスよりも高い要件があります。主要なプロダクション プロセスの一例は発注書遂行プロセスです。モニタ プロセスの例としては、監査プロセス、準拠プロセス、KPI 計算プロセスなどがあります。
メッセージ ブローカによるパブリッシュおよびサブスクライブ アーキテクチャを使用して、プロダクション プロセスとモニタ プロセスの間で緩やかに統合された結合を実現することができます。詳細については、「緩やかに結合されたサービスの設計」を参照してください。
| 注意 : | プロダクション プロセスからモニタ データを取得して、特定のチャネルにパブリッシュするのもよい方法です。モニタ プロセスはそのチャネルをサブスクライブできるようになります。その後で、モニタ プロセスはビジネス ニーズに応じてモニタ データを処理できます。 |
サービスを設計および開発するときには、以下の手順に従う必要があります。
表 3-1 は、サービスを大まかにカテゴリに分類したものです。
サービス設計の最初の手順は候補となるサービスを特定することです。ビジネス サービスはビジネス イベントに基づいて特定できます。表 3-2 に、ビジネス イベントと関連するサービスの例を示します。
関連するビジネス イベントからサービスを特定する場合は、イベント駆動型のサービスとなります。イベント駆動型のサービスは、実行時間の長いビジネス プロセスに簡単に統合できます。
サービスを特定したら、次の手順はサービス規約の定義です。サービス規約では、サービス コンシューマが簡単に理解できる形式で、サービスが提供する機能を指定します。サービス規約では、サービスの使用方法を定義し、サービスの品質 (QoS) パラメータを指定します。ただし、サービス規約には実装レベルの詳細は含まれません。
サービス規約を定義したら、次の最も重要な手順はサービス メッセージを定義することです。サービスはサービス コンシューマから入力メッセージを受信し、必要な場合はコンシューマにメッセージを返します。サービス メッセージごとに適切なサービス メッセージ スキーマを定義します。
次の手順は各サービスの事前条件と事後条件の定義です。事前条件は、サービスを呼び出す前に満たす必要のある条件を表します。サービス コンシューマは、事前条件を満たしている場合にのみサービスを呼び出すようにする必要があります。サービス プロバイダは、サービスの呼び出しが完了した後で、事後条件が満たされていることを確認する必要があります。この方法に従ってサービスを開発すれば、サービスの例外管理を実行しやすくなります。
サービスが同期モードと非同期モードのどちらで呼び出されるのかを決定する必要があります。顧客の住所を取得するような小さなデータ指向のサービスは同期モードで設計できます。状態管理を必要とする実行時間の長いサービスは非同期サービスとして設計する必要があります。非同期サービスは同期サービスに比べて、より緩やかに結合され、スケーラブルになります。
サービスの粒度は、API の呼び出しよりも大きくする必要があります。各自の状況に基づいて、実際の粒度を決定してください。サービスの呼び出しにはネットワーク上の往復が含まれてます。パフォーマンス上の理由から、ネットワーク上の往復回数は最小限に抑える必要があります。粒度の細かいサービスが多数ある場合は、粒度の細かいサービスの軽量なオーケストレーションを実行することにより、粒度の大きなサービスを作成することをお勧めします。その結果、粒度の大きなサービスをユーザにエクスポーズできます。
サービスでは、可用性やパフォーマンスに関して、最小限の品質要件を満たす必要があります。サービス プロバイダはサービス コンシューマとの間で、サービス レベル アグリーメント (SLA) を用意しておく必要があります。QoS の要件を事前に理解して、規定しなければなりません。
QoS を向上する 1 つの方法は、サービスを多重呼び出し不変として定義することです。多重呼び出し不変のサービスでは、サービスが同じ入力メッセージによって複数回呼び出された場合でも、システムの状態は変更されません。多重呼び出し不変サービスでは、Web サービスの信頼性のあるメッセージングのような標準を簡単に使用可能であり、障害発生時でもサービスを再送信できます。読み取り専用サービスはすべて多重呼び出し不変です。
ただし、書き込みサービスを多重呼び出し不変として設計することもできます。このように設計すると、サービスの信頼性が高まり、QoS が向上します。たとえば、サービスがサプライヤから請求書を受信した場合に、請求書の金額を売掛金勘定の合計金額に追加するとします。このようなシナリオでは、最初にデータベース内で請求書にユニークな番号を割り当ててから、買掛金勘定の金額を増やすことができます。同じメッセージが再び送信された場合は、請求書番号のユニーク性制約によってデータベース例外が送出され、重複したメッセージは破棄されます。
プロキシ サービスをフロント エンドとして利用するサービスを設計すると、プロキシ サービスをメイン サービスとして使用する場合の利点がいくつか得られます。プロキシ サービスは認証、情報付加、トランスフォーメーション、バージョン管理に使用できます。プロキシ サービスを使用すると、サービス プロバイダとコンシューマの間に緩やかな結合が確立されます。
異なるドメインや部門間で再利用できるビジネス機能を特定する必要があります。そのような機能は、標準ベースのサービスとしてエクスポーズするための有力候補となります。
サービスは緩やかに結合されるように設計する必要があります。サービス コンシューマとサービス プロバイダの間の結合は最小限にします。緩やかに結合されたサービスを設計するためのベスト プラクティスは次のとおりです。
ドキュメント指向のサービスの場合、サービス コンシューマは、完全なエンティティとして処理されるドキュメントを送信することにより、サービスと対話します。これらのドキュメントは XML で記述され、サービス プロバイダとコンシューマの間で共通に合意されたスキーマで定義されています。ドキュメント指向サービスの一例として、発注書処理サービスが挙げられます。発注書処理サービスでは、発注書 (XML 形式) を受信し、処理してから、注文確認書 (XML ドキュメント) をクライアントに返します。JPD はドキュメント指向となるように設計されています。JPD ではドキュメントを使用し、ドキュメントをエンティティとして処理します。
|
