» 【158号】3階層通信場アーキテクチャにおけるSOA

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【158号】3階層通信場アーキテクチャにおけるSOA

■サービスはE2/E3通信場にある
POAでは、当該スコープのプロセスの設計を先行させ、他のプロセスとの連携/
通信はこの後で考えるため、その通信は必然的にスパゲッティ構造を作ります。
DOAはこれを避けるべく、まずプロセス間で通信されるべきデータを抽出し、これ
を標準化して通信場(DH:Data Hub)を設計し、これを前提にプロセスを設計し
ます。実装独立の通信場ですから、その素材は現状ビジネスでやり取りされている
帳票等から入手できます。通信場を規定する標準そのものは、値についてはリソー
スDB、形式についてはリポジトリDBに規定されるべきと考えます。

3階層通信場アーキテクチャでは、このDHを個別アプリ内(E1)、アプリ間
(E2)、企業間(E3)に用意し、プロセスは直接的でなく、必ずDHを介して
通信するものとします。SOAはSILO化したレガシーやパッケージを活用して、
安く速く連携しようというもので、当該DB/E1のデータは対象外ですから、S
OAを考えるときは、E2およびE3だけが対象になります。この場合、ユーザ/
AP(アプリケーションプログラム)の要求するサービスは、E2、E3設計時に
識別され、すでに存在していることになります(注1)。

(注1)リソースDBへの検索-顧客住所の検索、部品の電気特性検索など-や
   リポジトリDBへの検索-顧客番号の形式の検索、部品属性の一覧表作成
   など-は、ここではサービスから除いて考えます。

■E2/E3のデータの形式
E2、E3内のデータの形式は、次の2つと考えられます。
 ・エンティティレコード:正規形、形式はリポジトリに記述、宛先なし
 ・メッセージレコード :非正規形、形式、宛先はレコード内に記述

エンティティレコードとしては、製品在庫、売掛残高、今期実績利益(E2)や予
約座席(E3)などがあるわけですが、メッセージレコードとしては次のような-
近年XMLなどでの実装が話題となっている-ものが含まれます。
E2:①営業→生産、生産依頼
   ②生産→営業、納期回答
   ③生産→営業、出荷案内
E3:④バイヤー→サプライヤー、発注
   ⑤サプライヤー→バイヤー、納期回答
   ⑥サプライヤー→バイヤー、出荷案内

受取側にとってはこれがサービスになりますから、生産にとっての①、営業にとっ
ての②、③、またサプライヤーにとっての④、バイヤーにとっての⑤、⑥がサービ
スになります。

サービスとしては、エンティティレコードについては必要な結合処理を行う必要が
ありますが、メッセージレコードについては、そのままでサービスとして提供でき
ると考えます。

ただしSOAミドルウエアとしては、そのE1の形式や値に関する標準が、レガ
シーやパッケージなどで、E2やE3と異なっている場合の変換を行い、またメッ
セージレコードについては、そのユーザ/APへの送信を行うことになります。こ
の変換を行うミドルウエアをサポートするために、リポジトリとして属性対応テー
ブル、またリソースDBとしてコード変換テーブルを用意する必要があります。

■アプリ間データには何があるか
SOAの主題は企業内アプリ横断の通信ですから、3階層データ通信場アーキテク
チャにおいてはE2が主役となります。E2として扱うべきデータの種類はかなり
限定され、かつ安定しているのではないか。たとえば経営、購買、生産、販売、経
理、などを連携するデータが10年経ってもさほど変わるわけがない。したがって
これを可視化することによって、CIOの戦略立案が合理化できるはず、と考えま
した。

そこでE2のデータとして何があるかを考えました。考察だけなので仮説に過ぎま
せんが、筆者の仮説「3種類のアプリ間データ」
 ①計画・追跡データ
 ②在庫・引当データ
 ③要求・回答データ
について、以下述べることにします。

①は月、期、年などで立てた計画を、タイミングに応じて追跡するデータです。た
とえば年間利益計画(E2)について、「6ヶ月経ったが、半分行っているか」を
見る、などです。追跡には多くのアプリ(E1)のデータの反映が必要となります。
またプロジェクト業務の場合は、月、期、年でなく、構成作業単位ごと、進捗ステ
イタスごとにコスト計画(E2)を立てますので、これをアプリ(E1)のデータ
で追跡する、などとなります。

②は、在庫管理です。部品在庫は購買がプラスし、生産がマイナスします。製品在
庫は生産がプラスし、営業がマイナスします。売掛残は営業がプラスし、経理がマ
イナスします。このように、見込生産・販売などに多く見られるアプリ横断の在庫
データは-各E1アプリが重複して持つのでなく-E2で一元管理すべきと筆者は
主張します。

③は、要求・回答データをE2所属とするものです。特注品などは在庫しませんの
で、営業が生産に生産依頼し、生産が回答するような形式となります。宛先が決
まっているのだから、E2経由にするメリットがないようにも見えます-事実従来
は直接通信がほとんどです-が、リポジトリの内容だけで、1個のロジックにより
すべてを制御でき、またアプリ間の通信はすべてE2経由ということで、SOAが
分かりやすくなり、変更・管理がやさしくなると考えます。いま話題のESBは、
③からストレージ機能を除き即時配信としたものに一致する-したがって③はES
Bを包含する-ものと思われます。

「E2データとして、以上の①、②、③のほかに何があるか」は筆者の課題として
いますが、あってもさほど多くはない、したがって管理すべきメタデータも多くな
く、その追加・変更だけで、以後のアプリケーション連携の追加・変更に、いわば
「スパゲッティフリー」に対応できます。筆者は、保守の2大強敵は「個別リソー
ス」と「スパゲッティ通信」であり、前者はMDMによって、後者は3階層データ
通信場によって解決できるのではないか、「スコープの拡大には、スパゲッティは
必然」と考える従来のPOAに比べて、格段に保守が容易になるはず、と考えます。

■3階層データ通信場アーキテクチャのイメージ
さてこの3階層データ通信場アーキテクチャにおいて、どのようなミドルウエアが
位置づけられるべきかを考えます。紙面の制約から、リソース系DBとしてR3、
R2、・・、また3階層イベント系DHとしてE3、E2のほか、自社アプリ購買、
生産、営業などに対応するE1(n個)、また他社アプリとしてA、Bなどがある
ものとして考えます。ミドルウエアとして2種類、すなわち①自社アプリの生成し
たレコードを裁くACMGR-iDBMS(iDBMSを従えたAccess Manager)
および、②E2/E3にストアされたレコードを配信するWFMGR(Work Flow
Manager)を導入したイメージを図示します。

ACMGRはアプリケーションの生成したメッセージレコードおよびiDBMSの
生成したエンティティレコード(DRI通信154号参照)を受け取り、必要な変
換を行い、所定のDH、E1/E2/E3にストアするもの、またWFMGRはE
2/E3のデータに必要な変換を行い、所定のエントリーポイントに、所定のタイ
ミングで送信するミドルウエアです。リポジトリはこれらミドルウエアをサポート
し、変換、送信先識別、送信タイミング、iDBMSによる整合性データ生成など
に使われます。

図はもちろん検証されたものではありません。3階層データ通信場のイメージアッ
プのための議論のスタートが切れれば良いとして示しました。

 ┌――[WFMGR]←―――――――――REPO
 |    ↑   ↑                  |
 |┌-→E3 E2  E1 E1 E1・・・     |  R3 R2 ・・・
 ||   ↑   ↑   ↑  ↑  ↑       |   | |
 ||   ↓   ↓   ↓  ↓  ↓       ↓  ↓  ↓ 
 || [*******ACMGR-iDBMS*******]
 ||          ↑   ↑  ↑    ↑
 ||          ↓   ↓  ↓    ↓
 ||        購買  生産  営業 ・・・・・・自社アプリ(注2)
 ||          ↑    ↑   ↑   ↑
 └――┬――┬―┴――┴――┴――┴
  |  ↓    ↓
  |  A     B ・・・他社アプリ
  └―┴――┴―――
図-3階層データ通信場アーキテクチャへのミドルウエアの導入イメージ

(注2)入力チェックのために、各アプリもデータタイプ、桁数などメタデータを
利用しますが、コンパイル時(Compile 方式)なら直接、また実行時
(Interpreting方式)ならばACMGR経由入手するものとします。
アプリ機能は、加工データ整 合性をiDBMSに委託できるため、
ユーザからの入力を整えるだけと単純化 でき、自動生成/プログラム
レスが容易になっていると考えます。

■メタデータの全貌
リポジトリにストアされるメタデータの応用は、当初はエンティティタイプ、属性、
RDBテーブル、カラム、モジュールなどから始まったわけですが、その応用は従
来になく広がっています。ミドルウエアはメタデータの活用が前提です。仮説の域
を出ませんが、次号以降に、報告できればと考えます。先の仮説「3種類のアプリ
間データ」に対するコメントを含めて皆様の声を寄せていただければありがたいと
思います。