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