今回は、
ビジネスレイヤ
ビジネスレイヤにはプレゼンテーションレイヤとのデータ受け渡し、
ビジネスレイヤは2階層、
- サービスインターフェイス
ビジネスレイヤのビジネス機能をサービスとして公開する場合、
クライアントからの呼び出し用に （プレゼンテーションレイヤだけではなく、 Webサービスとして公開した場合やビジネスレイヤからの呼び出しも含みます） 内部機能を抽象化したエントリポイントを公開する必要があります。 これらはファサード
（複雑な処理の呼び出しを単純化するためのパターン。GoF [1] によって定義されました） と呼ばれ、 Javaやほかのデザインパターンでも一般的なものです。 - ビジネスワークフロー
ビジネスワークフローは業務の流れやデータの流れに沿ってビジネスコンポーネントや使用されるビジネスエンティティの流れをコントロールするコンポーネントです。.NET Framework3.
0以降ではWindows Workflow Foundation （以降WFと略します） を使用して構築するのが効率のよい手法だと思います。 - ビジネスコンポーネント
ビジネスコンポーネントはビジネスレイヤの核ともいえるコンポーネントです。ビジネスコンポーネントではさまざまな業務ロジックを組み合わせ、
必要であれば、 ほかのビジネスコンポーネントと連携しながら業務ロジックを実行します。この連携の際、 サービスとして公開されたビジネスレイヤと連携する場合はビジネスエンティティと複数のビジネスレイヤの呼び出し、 実行権限などのアクセスライセンス （デジタルID） を管理するWindows CardSpace （以降WCSと略します） を経由して連携します。同じビジネスレイヤ内であればWindows Communication Foundation （以降WCFと略します） でデータ連携し、 ビジネスワークフローで定義された流れに沿って業務ロジックを実行していきます。 - ビジネスエンティティ
ビジネスエンティティはサービスインターフェイスを通してサービスとして公開する場合、
データレイヤとのデータのやり取り、 ビジネスレイヤ内で共通して保持するデータなどを表します。ここで、 定義されるデータの形式には以下のものがあります。 - XML
- DataReader
- 型なしDataSet
- 型付きDataSet
カスタムビジネスエンティティコンポーネント
このデータ形式では、
サービスとして公開したビジネスレイヤがほかのアプリケーションからの呼び出される際に、 構造化データをやり取りする際に作成されます。これにより、 データレイヤからのデータレイアウトや型を気にすることなく構造化データを作成することが出来ます。これにより、 サービスとして公開されたビジネスレイヤの独立性を保てるとともに、 アプリケーション内部構造を隠蔽することにも役立ちます。これらを保つためにもカスタムビジネスエンティティコンポーネントでは直接データレイヤにアクセスするような構造化データの作成は避けるようにします。
ビジネスレイヤの各コンポーネントは、
それでは各コンポーネントの設計についての注意点およびノウハウについて解説します。
① サービスインターフェイス設計の注意点およびノウハウについて
ビジネスレイヤの機能を公開する場合、
セキュリティ境界
サービスインターフェイスはアプリケーションのセキュリティの境界となります。つまり、
サービスインターフェイスの不変性
サービスインターフェイスを設計する場合に最も気を付けなければいけないことは、
サービスインターフェイスの多様化
1つのビジネスロジックはさまざまなクライアントから呼び出される可能性があります。そのため、
サービスインターフェイスの実装内容
サービスインターフェイスにはキャッシング、
サービスとしての公開方法
サービスインターフェイスを通してビジネスレイヤをサービスとして公開する場合、
- XML Webサービスとして公開
ASP.
NET Webサービスとして構築して公開するか、 プロトコルとしてSOAPとHTTPを使用した.NET Remittingを用いたサービスとして公開するか選択することができます。 - メッセージキューまたはEnterprise Services
（以降COM+と呼びます） キューに対してサービスを公開 この場合、
メッセージキューのトリガを実装し、 呼び出しに対して実行、 応答するようなサービスインターフェイスとしてきのうするコンポーネントを実装します。 - 独自サービスとして公開
ビジネスレイヤ自体を一つの関数として公開することもできます。この場合は、
サービスインターフェイス内で通信プロトコル、 通信手順、 承認方法、 データ受け渡し手順などすべてを定義する必要があります。しかし、 社内等の限定的な範囲の公開であればこれらを明確に規定することができるため、 サービスとして利用される場合は多いと思われます。
サービスインターフェイスでのトランザクションの扱い
サービスインターフェイスでは、
メッセージキューに対してサービスを公開する場合はトランザクションの宣言が必要となります。この場合、
XML Webサービスとしてサービスを公開する場合はトランザクションの宣言ができません。この場合はサービスインターフェイスからトランザクションルートとなるビジネスコンポーネントの呼び出しが必要となります。本方式ではトランザクション処理中にエラーが発生した場合は、
WCFの利用
.NET Framework 3.
② ビジネスワークフロー設計の注意点およびノウハウについて
ビジネスレイヤはさまざまなビジネスコンポーネントで構成されています。そして、
BizTalk Serverはビジネスプロセスが終了するまでの制御・
しかし、
また、
それではそれぞれのタイプのワークフローについて例も交えて説明します。
シーケンシャルワークフロー
シーケンシャルワークフローは、
それでは前回取り上げた旅行代理店の店舗向けのアプリケーションのシナリオで、
まず、
これをフローチャートとVisual Studio 2005 ワークフローデザイナで記述した結果は以下の図のようになります。
このようにWFでビジネスワークフローを作成することができます。
本例ではエラーコード編集を入力データチェックとデータレイヤ呼出で別に作成しましたが、
ステートマシンワークフロー
次にステートマシンワークフローについて説明します。ステートマシンワークフローは、
それでは上記の旅行代理店の店舗向けのアプリケーションのシナリオで考えてみましょう。このシナリオでは、
A社とB社のそれぞれの座先予約アプリケーションにはオンラインで接続できます。しかし、
この場合でも、
まず、
次にC社です。これは操作者が電話で問い合わせを行い、
問題はD社です。これは葉書を使うことからロングトランザクションになることが分かります。また、
これをVisual Studio 2005 ワークフローデザイナで記述した結果は以下の図のようになります。
今回の例でもエラーコード編集を入力データチェックとデータレイヤ呼出で別に作成しましたが、
WFの設計時の注意点
そのほかにも設計上の注意点は下記のようなものがあります。
- 長時間永続化されたワークフローはできるだけ少なくする
長時間永続化されたワークフローは実装に多くの時間がかかります。また、
実行時にシステムに負担をかけます。そこで、 可能であれば、 start-to-finishワークフローでの設計を検討します。 - カスタムアクティビティは少なくする
カスタムアクティビティは最小限にします。特に、
WCFやその他のコンポーネントで作成されたカスタムアクティビティは通常のstart-to-finishワークフローと比較してシステムに負担をかけます。 - 1つのアプリケーションドメインにはワークフローランタイム1インスタンスのみ
WFのアーキテクチャを見て頂くとわかるのですが、
1つのアプリケーションドメインには1つのワークフローランタイムしか稼働しません。そのため、 設計時からそれを意識して設計する必要があります。 - WFの開発にはVisual Studio 2008を使用する
Visual Studio 2008では簡単なワークフローであればウィザードで作成ができます。そのため、
工数の削減ができます。
③ ビジネスコンポーネント設計の注意点およびノウハウについて
ビジネスコンポーネントには以下のような機能が含まれます。
入力チェック
サービスインターフェイス経由もしくは直接ビジネスコンポーネントが呼び出された場合でも、
ビジネスファサード
いくつかのビジネスコンポーネントを纏めて実行する場合やインターフェイスを纏める場合などで作成されます。ここにはビジネスロジックは実装しません。
業務ロジック
業務ロジックそのものです。これらも機能単位でカプセル化され、
業務ロジックのデータの入出力はできるだけ一貫性を保つようにし、
トランザクション管理
ビジネスコンポーネントはトランザクションを開始できます。そのため、
トランザクション開始後、
また、
バッチ処理的にビジネスコンポーネントが設計・
また、
④ ビジネスエンティティ設計の注意点およびノウハウについて
ビジネスエンティティはサービスインターフェイスを通してビジネスレイヤがサービスとして公開されている場合およびデータレイヤとのデータの受け渡しにおいて、
- XML
W3C
（World Wide Web Consortium） 標準の準拠のため、 プラットフォームに依存しません。 しかし、 厳密な型の指定のエンティティを作成知るためにはXML スキーマ定義言語 （以降XSDと略します） で定義する必要があります。 XMLを作成するためには専用のエディタもしくはVisual Studio等を用いて作成するとタイプミスなどが少なくなります。
また、
.NET Language-Integrated Query （LINQ） to XMLを用いることで、 メモリ内に読み込んだXMLの構文解析・ ソート・ ツリー構造化・ 操作が行えるようになりました。 - DataReader
ADO.
NET （ActiveX Data Objects for .NET Framework） を利用してデータベースに同期型で接続しデータを取得します。データの型は基本的にデータベース内のデータ型に依存します。 - 型なしDataSet
ADO.
NETを利用して非接続型で接続し、 データのやり取りを行います。 型なしDataSetはシリアル化に対応しており、
ユーザインターフェイスコンポーネント （DataGrid、 GridViewなど） への表示が容易にできます。 また、 データ・ 項目の並べ替え、 フィルタリングができ、 DataSetの内容をXMLとして入出力することができます。この場合はXSDがないため、 厳密な型指定はできません。 しかし、
型なしDataSetのインスタンス生成やデータの出し入れ、 検索の際に実行環境に負荷がかかります。 型なしDataSetは厳密な型指定がされていないため、
コンパイル時に型のチェックがされず、 エラーの原因となりやすいです。 - 型付DataSet
ADO.
NETを利用して非接続型で接続し、 データのやり取りを行います。型付DataSetはシリアル化に対応しており、 ユーザインターフェイスコンポーネント （DataGrid、 GridViewなど） への表示が容易にできます。 また、 データ・ 項目の並べ替え、 フィルタリングができ、 DataSetの内容をXMLとして入出力することができます。この場合はXSDがあるため、 厳密な型指定がされます。 しかし、
型付DataSetのインスタンス生成やデータの出し入れ、 検索の際に実行環境に負荷がかかります。 型付DataSetは厳密な型指定がされてるため、
コンパイル時に型のチェックがされます。 この際、 DataSetのデータ操作などのメソッド等も自動的に生成されるので、 容量が大きくなります。 型付DataSetはXSDで厳密に型指定されているため、
データの受け渡し側に変更が発生した場合は再作成する必要があります。 - カスタムビジネスエンティティコンポーネント
カスタムオブジェクトは個別に型指定されたプロパティやメソッドを作成するため、
プライベートロジック、 個別の操作や検証用ロジックを実装することができます。 カスタムオブジェクトは厳密な型指定がされてるため、
コンパイル時に型のチェックがされます。 Visual Studioを用いてソースを作成する際には、
インテリセンスを使用してカスタムオブジェクト内のプロパティやメソッドを呼び出すことができます。 カスタムオブジェクトは個別に作成するソース内で厳密に型指定するため、
開発工数が大きくなります。 また、 厳密に型指定されているため、 データの受け渡し側に変更が発生した場合は再作成する必要があります。 しかし、
.NET Framework 3. 5でサポートされたLINQ to Objectを用いることで、 メモリ内に読み込んだカスタムオブジェクトの構文解析・ 検索・ ソート・ ツリー構造化・ 操作が行えるようになりました。
サービスインターフェイスを通してビジネスレイヤがサービスとして公開されている場合は、
データレイヤとのデータの受け渡しにおいては、
- XML
XMLは下記に紹介するLINQ to XML技術を使用しない限り、
検索・ ソート等は低コストでは実装できません。しかし、 軽量であることと値の読み出しなら低コストで実装できます。 - DataReader
ビジネスコンポーネントでデータを加工し、
データレイヤ経由でデータベースを更新する場合、 DataReaderでは、 Arrayなどへの値の入れ替え、 更新前に型付きDataSetでのデータの確認後、 更新となるので、 非効率となります。しかし、 接続したデータベースからの値の読み込みだけであれば高速で、 低コストで実装できます。 - 型なしDataSet
複数のTableやデータ以外のオブジェクトを扱うのであれば型なしDataSetを選択するのが低コストで実装できます。
- 型付きDataSet
厳密な型指定がされているので、
ビジネスコンポーネントでデータを加工し、 データレイヤ経由でデータベースを更新する場合はそのままデータを渡すことができるので、 低コストで実装できます。 - カスタムビジネスエンティティコンポーネント
カスタムビジネスエンティティコンポーネントに関しては、
上記の手法では実装が難しい場合などに選択することとなります。
LINQの登場
LINQが登場するまでのXMLおよびカスタムビジネスエンティティコンポーネントでは、
また、
さらにXMLドキュメントの操作や各種Webサービスなどそれぞれのデータソースに対してクエリ言語を習得する必要もありました。
しかし、
LINQ技術はデータレイヤで扱うデータソースやサービスへの接続・