n階層システム設計の考慮点

第5回 ビジネスレイヤの設計について

この記事を読むのに必要な時間:およそ 7 分

② ビジネスワークフロー設計の注意点およびノウハウについて

ビジネスレイヤはさまざまなビジネスコンポーネントで構成されています。そして,それは単体で稼働するもの,複数のコンポーネントで連携して稼働するものなどさまざまです。それらがビジネスルールに従って順序よく,同期または非同期で呼び出されます。これらは複数の手順,ルールに沿って実行され,ビジネスプロセスが終了するまで,状態を保持しながら実行される必要があります。レガシーシステムの汎用機の時代であればJob Control Language(以降JCLと略します)を使用して制御・実行・管理されていました。しかし,Windows OS標準ではJCLに相当する機能はありますが,機能的に貧弱です。そのため,Microsoft社ではこれらの機能を補完する製品としてBizTalk Serverをリリースしてきました。

BizTalk Serverはビジネスプロセスが終了するまでの制御・実行・管理を行うことができますが,.NET Frameworkとの親和性という観点ではあまりよくなく,やはり別製品であるという感じは否めませんでした。

しかし,.NET Framework 3.0以降ではWFを利用できるようになりました※4⁠。これにより,BizTalk Serverを使用することなく,ビジネスプロセスが終了するまでの制御・実行・管理を行うことができます。

また,WFではバッチアプリケーションで使用されるような単純なシーケンシャルワークフローから複雑なステートマシンワークフローを作成・管理・実行・制御することができます。また,WCFと連携してワークフローをWebサービスとして公開することもできます。これについては後述します。

それではそれぞれのタイプのワークフローについて例も交えて説明します。

シーケンシャルワークフロー

シーケンシャルワークフローは,ワークフローが開始されてからさまざまなステップ,条件式などが次々に実行され,最後のアクティビティが完了するまで途切れることなく続行される処理に適しています。しかし,シーケンシャルワークフローはその中で定義された外部接続,外部イベントからの接続,条件により複数の処理の同時実行などにより,内部に定義された実行順序が異なる場合があります。

それでは前回取り上げた旅行代理店の店舗向けのアプリケーションのシナリオで,ビジネスワークフローの部分のみを考えてみす。このシナリオでは,ある旅行商品の見積もり業務で複数の交通機関を使用する旅行商品があるとします。まずは顧客の要望する旅行プランの旅行コードが存在するかを検索します。その際にビジネスレイヤのビジネスワークフローが使用されます。この場合はシーケンシャルワークフローで実現できます。

まず,プレゼンテーションレイヤから渡された入力データ(操作者のIDや旅行コードなど)をチェックします。エラーがあった場合はエラー処理でエラーデータを返します。入力チェックでエラーがない場合,入力データ内の旅行コードの問い合わせの準備をします。次にデータレイヤを呼び出します。呼び出しでエラーが帰ってきたらエラー処理でエラーデータを返します。データレイヤから問い合わせ結果データが帰ってきたらデータを返します。

これをフローチャートとVisual Studio 2005 ワークフローデザイナで記述した結果は以下の図のようになります。

フローチャート

フローチャート

Visual Studio 2005 ワークフローデザイナ

Visual Studio 2005 ワークフローデザイナ

このようにWFでビジネスワークフローを作成することができます。

本例ではエラーコード編集を入力データチェックとデータレイヤ呼出で別に作成しましたが,本来であれば共通関数化し,エラーコードなどもアプリケーションで一元管理するように設計します。

ステートマシンワークフロー

次にステートマシンワークフローについて説明します。ステートマシンワークフローは,一連の状態,遷移,および動作で構成されます。1つの状態を開始状態とし,その後は,イベントや動作により,別の状態へと遷移していきます。また,ステートマシンワークフローには,ワークフローの終わりを特定する最終状態を指定できます。

それでは上記の旅行代理店の店舗向けのアプリケーションのシナリオで考えてみましょう。このシナリオでは,ある旅行商品の見積もり業務で複数の交通機関を使用する旅行商品があるとします。シーケンシャルワークフローで顧客の要望する旅行プランの旅行コードが決定されました。この旅行プランは複数の交通機関を利用し,すべての交通機関で利用する座席が確定することで成立するものです。そこで,顧客の希望の日程で旅行ができるかそれぞれの交通機関に対してオンラインもしくは電話などで予約をすることになります。今回の旅行プランはA社の電車でα駅からβ駅に移動します。その後,B社の電車でB-β駅からθ駅に行きます。そこからはC社の専用車両(定員制)でD社が運営する観覧施設に入ります。しかし,この観覧は事前抽選制で観覧日付,入館時間と退館時間を指定し,観覧者が葉書で申し込みする必要があります。その後,往路の逆の経路で帰ってくるプランです。

A社とB社のそれぞれの座先予約アプリケーションにはオンラインで接続できます。しかし,C社は電話での問い合わせが必要です。また,D社は葉書,かつ抽選です。

この場合でも,ジネスレイヤのビジネスワークフローが使用されます。この場合はステートマシンワークフローが使用されます。

まず,A社とB社はオンラインアプリケーションをデータレイヤのサービスエージェントから接続し,結果を取得します。取得した結果は操作者のクライアントPCもしくはワークフローの状態保持機能を使用してサーバやデータベースに格納します。

次にC社です。これは操作者が電話で問い合わせを行い,画面から問い合わせ結果を登録します。

問題はD社です。これは葉書を使うことからロングトランザクションになることが分かります。また,抽選式ですので,A社,B社そしてC社の予約が取れても結果によってはすべてキャンセルになる可能性もあります。

これをVisual Studio 2005 ワークフローデザイナで記述した結果は以下の図のようになります。

Visual Studio 2005 ワークフローデザイナ

Visual Studio 2005 ワークフローデザイナ

今回の例でもエラーコード編集を入力データチェックとデータレイヤ呼出で別に作成しましたが,本来であれば共通関数化し,エラーコードなどもアプリケーションで一元管理するように設計します。

WFの設計時の注意点

そのほかにも設計上の注意点は下記のようなものがあります。

長時間永続化されたワークフローはできるだけ少なくする

長時間永続化されたワークフローは実装に多くの時間がかかります。また,実行時にシステムに負担をかけます。そこで,可能であれば,start-to-finishワークフローでの設計を検討します。

カスタムアクティビティは少なくする

カスタムアクティビティは最小限にします。特に,WCFやその他のコンポーネントで作成されたカスタムアクティビティは通常のstart-to-finishワークフローと比較してシステムに負担をかけます。

1つのアプリケーションドメインにはワークフローランタイム1インスタンスのみ

WFのアーキテクチャを見て頂くとわかるのですが,1つのアプリケーションドメインには1つのワークフローランタイムしか稼働しません。そのため,設計時からそれを意識して設計する必要があります。

WFの開発にはVisual Studio 2008を使用する

Visual Studio 2008では簡単なワークフローであればウィザードで作成ができます。そのため,工数の削減ができます。

※4

WFの詳細については下記のMicrosoft社のURLをご参照願います。

http://msdn.microsoft.com/ja-jp/library/ms735967.aspx

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。