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

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

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

今回は,ビジネスレイヤの設計についての注意点およびノウハウについて解説していきます。

ビジネスレイヤ

ビジネスレイヤにはプレゼンテーションレイヤとのデータ受け渡し,渡されたデータに対するチェック,操作,加工,データレイヤとのデータの受け渡し,例外処理,そしてアプリケーションの中心となる業務ロジック機能が実装されます。

ビジネスレイヤは2階層,4コンポーネントから構成されています。

画像
サービスインターフェイス

ビジネスレイヤのビジネス機能をサービスとして公開する場合,クライアントからの呼び出し用に(プレゼンテーションレイヤだけではなく,Webサービスとして公開した場合やビジネスレイヤからの呼び出しも含みます)内部機能を抽象化したエントリポイントを公開する必要があります。

これらはファサード(複雑な処理の呼び出しを単純化するためのパターン。GoF※1によって定義されました)と呼ばれ,Javaやほかのデザインパターンでも一般的なものです。

ビジネスワークフロー

ビジネスワークフローは業務の流れやデータの流れに沿ってビジネスコンポーネントや使用されるビジネスエンティティの流れをコントロールするコンポーネントです。.NET Framework3.0以降ではWindows Workflow Foundation(以降WFと略します)を使用して構築するのが効率のよい手法だと思います。

ビジネスコンポーネント

ビジネスコンポーネントはビジネスレイヤの核ともいえるコンポーネントです。ビジネスコンポーネントではさまざまな業務ロジックを組み合わせ,必要であれば,ほかのビジネスコンポーネントと連携しながら業務ロジックを実行します。この連携の際,サービスとして公開されたビジネスレイヤと連携する場合はビジネスエンティティと複数のビジネスレイヤの呼び出し,実行権限などのアクセスライセンス(デジタルID)を管理するWindows CardSpace(以降WCSと略します)を経由して連携します。同じビジネスレイヤ内であればWindows Communication Foundation(以降WCFと略します)でデータ連携し,ビジネスワークフローで定義された流れに沿って業務ロジックを実行していきます。

ビジネスエンティティ

ビジネスエンティティはサービスインターフェイスを通してサービスとして公開する場合,データレイヤとのデータのやり取り,ビジネスレイヤ内で共通して保持するデータなどを表します。ここで,定義されるデータの形式には以下のものがあります。

  • XML
  • DataReader
  • 型なしDataSet
  • 型付きDataSet
  • カスタムビジネスエンティティコンポーネント

    このデータ形式では,サービスとして公開したビジネスレイヤがほかのアプリケーションからの呼び出される際に,構造化データをやり取りする際に作成されます。これにより,データレイヤからのデータレイアウトや型を気にすることなく構造化データを作成することが出来ます。これにより,サービスとして公開されたビジネスレイヤの独立性を保てるとともに,アプリケーション内部構造を隠蔽することにも役立ちます。これらを保つためにもカスタムビジネスエンティティコンポーネントでは直接データレイヤにアクセスするような構造化データの作成は避けるようにします。

ビジネスレイヤの各コンポーネントは,配布されたPC上のOSのサービス権限で実行されるように設計される場合がほとんどです。しかし,ビジネスレイヤがサービスインターフェイスを通して公開されており,異なるドメインに所属するPCなどからサービスとして呼ばれる場合,呼び出し側の実行権限により実行できないことが想定されます。このような場合,WCFを用いて連携することで,より広範囲にサービスを公開することができるようになります。

それでは各コンポーネントの設計についての注意点およびノウハウについて解説します。

① サービスインターフェイス設計の注意点およびノウハウについて

ビジネスレイヤの機能を公開する場合,クライアントからの呼び出し用に内部構造,呼び出し方法を定義する必要があります。この定義をサービスインターフェイスとして実装します。

セキュリティ境界

サービスインターフェイスはアプリケーションのセキュリティの境界となります。つまり,サービスインターフェイスを経由して呼び出すクライアントは適切なアクセス権限を有する必要があります。つまり,サービスインターフェイスからビジネスコンポーネントの間でファサード作成し,アクセス権限チェックを行う必要があるということになります。しかし,このアクセス権限チェックはできるだけ単純なものとし,プラットフォーム非依存型の認証方法を採用する必要があります。これは,さまざまなプラットフォームやサービスとの相互互換性を確保し,より汎用性のあるサービスとして公開するためには必要なことです。

サービスインターフェイスの不変性

サービスインターフェイスを設計する場合に最も気を付けなければいけないことは,ビジネスレイヤの内部構造が変更になってもサービスインターフェイスに影響を及ぼさないようにすることです。サービスインターフェイスから呼び出されるビジネスコンポーネントは常に1つのサービスインターフェイスのみから呼び出されるとは限りません。ほかのサービスインターフェイスからや同じビジネスレイヤ内のビジネスコンポーネントからも呼び出される可能性があります。そして,業務仕様によってビジネスコンポーネントの仕様が現在の機能に影響がない程度に変更(内部のチェック関数の変更など)されるかもしれません。変更が行われてもサービスインターフェイスに影響しないように設計する必要があります。

サービスインターフェイスの多様化

1つのビジネスロジックはさまざまなクライアントから呼び出される可能性があります。そのため,そのクライアントごとにサービスインターフェイスが必要となる場合があります。しかし,この場合でもビジネスロジックの変更がサービスインターフェイスに影響を及ぼさないように設計する必要があります。

サービスインターフェイスの実装内容

サービスインターフェイスにはキャッシング,単純な型変換などの機能を実装しても構いませんが,ビジネスロジックは実装しないようにします。これはビジネスロジックへの仕様変更が発生した場合にこのサービスインターフェイスを呼び出しているクライアントへの影響が大きくなることを防ぐためです。

サービスとしての公開方法

サービスインターフェイスを通してビジネスレイヤをサービスとして公開する場合,以下のような方法で公開することができます。

XML Webサービスとして公開

ASP.NET Webサービスとして構築して公開するか,プロトコルとしてSOAPとHTTPを使用した.NET Remittingを用いたサービスとして公開するか選択することができます。

メッセージキューまたはEnterprise Services(以降COM+と呼びます)キューに対してサービスを公開

この場合,メッセージキューのトリガを実装し,呼び出しに対して実行,応答するようなサービスインターフェイスとしてきのうするコンポーネントを実装します。

独自サービスとして公開

ビジネスレイヤ自体を一つの関数として公開することもできます。この場合は,サービスインターフェイス内で通信プロトコル,通信手順,承認方法,データ受け渡し手順などすべてを定義する必要があります。しかし,社内等の限定的な範囲の公開であればこれらを明確に規定することができるため,サービスとして利用される場合は多いと思われます。

サービスインターフェイスでのトランザクションの扱い

サービスインターフェイスでは,トランザクションを宣言する場合と宣言しない場合の2つのパターンがあります。

メッセージキューに対してサービスを公開する場合はトランザクションの宣言が必要となります。この場合,サービスインターフェイスでトランザクションを宣言し,メッセージを受信・処理・応答してトランザクションを閉じるまでを行います。しかし,これらの過程のどこかでエラーが発生した場合はトランザクションをロールバックさせ,メッセージの受信自体を「未受信」とする必要がります※2)。

XML Webサービスとしてサービスを公開する場合はトランザクションの宣言ができません。この場合はサービスインターフェイスからトランザクションルートとなるビジネスコンポーネントの呼び出しが必要となります。本方式ではトランザクション処理中にエラーが発生した場合は,サービスインターフェイスはクライアントに対してエラー発生を通知します。ただし,非同期として呼び出された場合は通知する手段がないので,ログなどでエラー発生を通知する方式を検討する必要があります。

WCFの利用

.NET Framework 3.0以降ではこれらのサービスの公開はWCFを用いて簡単に公開できるようになりました※3)。WCFは上記のXML Webサービス,.NET Remitting,メッセージキューへの対応,COM+そしてWeb Services Enhancements 3.0(以降WSEと略します)に対応したWebサービスを公開することができます。

※1

Gang of Four; 4人のギャングたち(エーリヒ・ガンマ(Erich Gamma),リチャード・ヘルム(Richard Helm),ラルフ・ジョンソン(Ralph Johnson),ジョン・ブリシディース(John Vlissides)の四人組のです。彼らはオブジェクト指向のソフトウェアにおける23種類のデザインパターンを考案しました。

※2

しかし,ここで考慮が必要な場合があります。以前私が参加したプロジェクトではメッセージキューを用いたアプリケーションを構築していました。これは複数のレガシーシステムからの大量データのやり取りをするため,これらのプラットフォームの差異の吸収やDBへの負荷を軽減するために本方式が採用されました。このアプリケーションではトランザクション開始から終了までの間に業務的なデータの固まりでのデータの登録(コミット)が要件として含まれていました。そのため,エラー発生時はエラーが発生したメッセージ以降の再送を行う必要があり,再送メッセージの取り扱いや関連するレガシーシステムとの連携の実現に多くの工数がかかりました。

※3

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

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

著者プロフィール

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

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

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

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

コメント

コメントの記入