ビジネスエンティティとビジネスエンティティ定義言語の導入

作者 Boris Lublinsky , 翻訳者 南 伸二 投稿日 2010年12月5日

セクション

エンタープライズ・アーキテクチャ,

プロセス/プラクティス

トピック

Business Process Modeling ,

Business Process Management ,

SOA ,

ビジネス ,

IBM ,

Architecture ,

エンタープライズアーキテクチャ ,

developerWorks

共有 |

原文(投稿日：2010/04/28)へのリンク

新しい記事Data4BPMにおいて、IBMのPrabir Nandi、Dieter König、Simon Moser、Richard Hull、Vlad Klicnik、Shane Claussen、Matthias Kloppmann、John Vergoの各氏はデータのビジネス視点の表現方法の1つとしてビジネスエンティティの概念を導入している。彼らは2つの新しい標準、ビジネスエンティティを伴うプロセスの総体的設計と実行に対するBusiness Entity Definition Language（BEDL）およびBPEL4Dataを提案している。

著者たちによると：

ほとんどのビジネスプロセスマネジメントツールスイートにおいて、データは後づけのものとして扱われている。アクティビティとそのフローが主要な抽象であり、プロセスで扱われるデータは本質的にプロセスの変数として隠蔽されている。データの表現と集約はプロセス定義の外で扱われ、一般的なサービスコールを通して実装されている。このプロセスだけからのアプローチはビジネスオペレーション分析において重要なデータ視点を無視し、オペレーションの主要な側面を曖昧にすることも多い。そして、ソリューションライフサイクルを通じてのリファクタリングをコスト高にする。

彼らは、記事の中でデータエンティティをプロセス設計の主要な要素とすることを導入し、ビジネスエンティティを次のようなものとして紹介している：

... キーとなるビジネスに関係する動的かつ概念的オブジェクトであり、エンタープライズオペレーションの中で手渡される間に、生成され、展開され、（一般には）アーカイブされるもの。ビジネスエンティティは、ライフサイクル全体におけるビジネスオブジェクトのデータに対する情報モデルと、これらのオブジェクトに関するタスクを起動、実行しうる方法やタイミングを記述するライフサイクルモデルの両方を含んでいる。

記事では、ビジネスエンティティ定義言語（Business Entity Definition Language, BEDL）を、BEDLメタモデルと文法を定義するものとして提案し、BEDL仕様をサポートし得る実行アーキテクチャについて議論している。さらに記事では、BPEL4Dataの概要を発表している。これは、BPEL標準をBEDLコンポーネントとの明示的な相互運用をサポートするように拡張するアプローチである。

提案されたBEDLはビジネスエンティティ（BE）の記述をベースにしていて、それは4つの主要構成要素を持っている：情報モデル、ライフサイクルモデル、アクセスポリシー、通知である。BE型の情報モデルは属性/値のペアの群として仕様化されていて、そのXMLスキーマはそれぞれ値の構造を管理するような属性に関連づけられている。すべての属性がどんな時でもBE上で表現されている必要はない。BEのライフサイクルモデルは有限状態マシンとして仕様化されている。ライフサイクル仕様それ自体はアクティビティに関する詳細を提供しない。与えられたBEインスタンスがある与えられた状態のときに実行されうるアクティビティについても、BEインスタンスがある状態から別の状態への遷移の一部として実行されるアクティビティについても同様である。それらはたいていBE定義を補うために使われるBPELを使って表現されている。BEのアクセスポリシーは二つの主なポリシーに焦点を当てている：BE情報モデル（つまりこのモデルの一部）の変更に対するポリシーを定義するCRUDと、ライフサイクルモデルの遷移に対するポリシーを定義するExecutionsである。BE仕様の最後の部分は通知であり、外部パーティ、例えば他のプロセスにとって関心のあるBEのアクティビティ（変更）を定義してる。

BEDLをサポートするソフトウェアコンポーネントは、外部コンポーネントが次のような能力をもつことができるようなインターフェースを提供する。

• BEタイプのメタデータの要求 - サポートするBEタイプのスキーマを得ることを可能にする問い合わせインターフェース。
• ビジネスエンティティインスタンスのデータへのアクセス - BE属性の操作を可能にするCRUDインターフェース。このインターフェースはCRUD権限を必要とする。
• BEインスタンスの問い合わせ - 問い合わせ条件を満たす全BEインスタンスへの参照の取得を可能にする問い合わせインターフェース。
• BEの状態遷移の実行 - BEを別の状態にすることを指示する制御インターフェース。このインターフェースはBEインスタンスの生成も含んでいる。状態遷移はBEライフサイクルと実行権限を必要とする。
• BEインスタンス（の一部の）ロック／アンロック - BEインスタンスの並行制御をサポートするインターフェース。
• あるクラスのBEインスタンスのデータや状態の変更の登録 - BDのデータや状態変更についての通知を受けることができるよう登録するインターフェース。このインターフェースはBEの変更を読み取ろうとする場合、CRUD権限を必要とする。

記事では、Courier Shipment BEタイプのデザインの例も提供されている。

記事の著者たちは複数のBEタイプに関連づけられたインスタンスを管理する能力をもつ、特殊なBEランタイムについて想像を巡らしている。彼らはそのようなランタイムを2種類議論している。

• "グリーンフィールド"の場合、BEランタイムは（属性値とインスタンスの状態を含む）実際のBEインスタンスデータを特別なデータストア - BEコンテンツストアで管理する。この場合、BEランタイムはデータアクセスポリシーを守らせ、BE登録者に通知を送ることに責任を負う。
• "ブラウンフィールド"の場合、BEデータのほとんどがすでにレガシーアプリケーションによって保持されていることを仮定している。この場合、データを複製する代わりに、BEランタイムはデータのBE情報ビューとレガシーアプリケーションビューをリンクしたり接続したりするために利用されるデータを保持する永続的なストアとともに増大しうる。

BEランタイムにはBEデータや状態を扱う準備があるけれども、状態遷移の実行を定義するためのサポートをまったく提供していない。それはBPEL/BPMNベースのプロセスのような外部プロセス、2層Webアプリケーション、一般のパッケージアプリ＜Pーション、マスターデータマネジメント（Master Data Management、MDM）管理ワークフローやXPDLベースのアプリケーションに依存している。

・

記事ではBEを使う利点を次のように概観している。

• 顧客満足

  • BEアプローチはビジネスオペレーションの領域を要素分解するための伝統的なトップダウンのプロセス中心手法を補完する...大きく包括的なスコープを持つビジネスプロセスにとっては、少ない数の主要なビジネスエンティティから設計活動を開始することにより、かなり早い段階での洞察や明瞭さを得ることができる。それは複雑な複数レベルのプロセス分解からはほとんどの場合達成できないものである...
  • BEアプローチはある企業の異なるサイロをまたいだコミュニケーションを大いに改善することを可能にする。その理由は、多くの場合、BEタイプは複数のサイロに広がっていて、それらの異なるサイロのステークホルダーにとって共通の語彙を提供するからである。

  簡潔さ、柔軟さ、価値創造の時間

  • BEアプローチを使うことで、大きく複雑なシステムに対してでも、主要エンティティ、状態、状態を変更するタスクを把握することをずっと早く行うことができる...
  • このアプローチによって、シンプル（だが、完全な）スタートが行われることになり、そして、すべての要求が追加的に、つねに一貫した形でモデル化されるので、螺旋状のデザインが進化が求められることになる。
  • ビジネスエンティティライフサイクルの状態はプロセスのマイルストーンを表現し、ビジネスの目標を反映する。

  コスト削減

  • より多くの要求が前もってモデル化されるため、要素の再分解やその波紋が流れることが少なくなる。その結果、ソリューション開発のライフサイクル後半や、デプロイ、メンテナンスライフサイクルでのの変更要求が少なくなる。
  • プロセスはエンティティのライフサイクルを考慮して分解されている。このことによって、プロセス定義の再利用のスコープが増す。また、変更がプロセスのごく小さな部分に局所化され、他のデザインの部分に影響することがなくなることにより、デザインでの俊敏さが生まれる。

データモデリングはプロセス定義の重要な部分であるが、概して企業の意味的データモデルのレベルで使われている。その記法を記事で定義されたようなBEに拡張することがプロセスのデザインや実装をよりよくするかどうかは、いまだわからないままだ。