» 【128号】「DOAにおけるSOAを考える」

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【128号】「DOAにおけるSOAを考える」

■分かりにくいSOA
SOA大全(日経BP)によると、SOAの定義は「SOAとはアプリケーシ
ョンフロントエンド、サービス、サービスリポジトリ、サービスバスという主
要な概念により構成されるソフトウエアアーキテクチャである。

サービスは規約、ひとつ以上のインターフェース、そして実装から成り立って
いる。」と紹介されています。またM.ファウラーは「アーキテクチャという言葉
は多くの人が定義を試みているものの、ほとんど合意が得られない。・・」との
ことです。
ユーザの要求に基づいて、短期・個別最適化をねらってアプリケーションを開
発してきたら、孤島システムがいくつもできてきた。全体最適のためこれらの
連携が必要だといって、従来法でこれらを繋ぐと、ほとんど保守のできない大
規模スパゲッティシステムができてくる。これを避けるほとんど唯一の方法が
SOAだ、と期待が大きく関心が高まっているわけですが、そのイメージは抽
象的で各人各様、方法論もはっきりせず、はかばかしい進展が見られないかの
ようです。
すでにDRI通信126号で言及しましたが、A2A(Application to
Application)レベルにDOAを適用して得られるフェデレーションアーキテクチ
ャを前提にすると、SOAも非常に分かりやすくなるように思われます。We
bサービスを前提としたものでないため、伝統的なSOAの議論とはかなり違っ
ているかとも思われますが、以下記述して見ましょう。
■ DOAの本質
プロセスP1とP2の間の通信方式には、これらを直接繋ぐものと、通信場経
由間接に繋ぐものとの二つに大別できます。筆者は40年も昔FORTRAN
プログラムを作る時、アーギュメント方式とCOMMON方式をどう使い分け
るべきか議論したことを思い出します。直接連携の前者はローカルな通信に、
通信場経由の後者はn個のプロセスのからむ全体的通信に向く、そして後者の
場合はあらかじめすべての通信ニーズを洗い出し調整する必要がある、と考え
ました。
一方40年前、COBOLプログラムの世界には、プログラムP1の出力した
順ファイルF1をプログラムP2が読み込む直接通信方式しかありませんでし
た。いわゆるバケツリレー方式です。順ファイルの形式DD1はデータディビ
ジョンとしてプログラムP1とP2の中に記述されます。やがてDBが登場し
間接通信方式が可能になり、ファイル形式がプログラムから分離されて、ディ
レクトリとして自立し始めます(真の独立はリポジトリとなってからです)。
これは次のように図示することができるでしょう。
(a)直接通信方式         (b)間接通信方式
P1・DD1−→F1        P1−→DD1−F1
         |             |
P2・DD1 ←−┘        P2←−┘
DD1はP1およびP2のニーズを調整して決められますが、(a)ではこれ
がP1やP2に隠蔽されており、(b)では公開されているところが大きく違
います。DD1を読むことによって、別のP3、P4などもF1に自由にアク
セスすることができます。
またP3、P4のニーズによって、DD1を変更する必要が発生する場合、
(a)ではP1・DD1やP2・DD1を変更する(少なくともリコンパイル
の)必要が発生しますが、(b)ではP1、P2はそのままで変更の必要が発
生しません。したがってセキュリティの面では(a)が優れているといえます
が、変更への対処では(2)が有利といえます。一般にはプログラムはF1だ
けでなくF2、F3ほか、多くのファイルにアクセスしますので、これらに対
するファイル仕様を独立させるメリットは極めて大きいといえます。
ファイル仕様DD1、DD2等が、いわばシステム広辞苑としてP1、P2等
の通信場の仕様/コミュニケーションルール/文化を決めています。これをシ
ステムの中心に位置づけ、これを先行して決める(b)の方式がDOA、デー
タ中心アプローチの本質といえます。1980年以降のシステム化の大部分は、
このDOAの実現を狙うものであったかと思われます。
■DOAの限界とその突破
当初は指摘されることが少なかったのですが、このDOAにはひとつの限界が
ありました。システム広辞苑のカバーする範囲が個別アプリケーションの範囲
になって、孤島システムができてしまうことでした。ちょうど日本語、英語、
中国語などができて、容易に世界語ができないようなものです。アプリケーシ
ョン間のコミュニケーションが、比較的少なく定型的でゆっくりで良い時代は
さほど大きな問題ではなかったのですが、SCM、CRMの時代になってこれ
は大きな問題となってきました。
そこで広辞苑の範囲を広げる解決が試みられました。SAPやORACLEな
どのERPです。各国語をやめにして世界語を使いましょうという壮大な実験
が行われたわけです。開発や保守の労をベンダーが一括してとるというメリッ
トを提供して、ある程度の成功を収めたのですが、やはり無理があったのでは
ないでしょうか。NetweaverやFusionが登場せざるをえなくなりました。
プロセス間通信を根本的に解決するのは、DB通信場経由の間接通信、すなわ
ちDOAであることを、プログラムとプログラムのところで学びました。しか
し一回り大きなアプリケーションとアプリケーションの場合にこれを応用する
ことは必ずしも容易ではなかったかのように見えます。
まだ十分実証されていませんが、アプリケーションをまたがってやり取りされ
るデータ−これをハイレベルデータと呼ぼう−とは、品物やお金の在庫(先日
付を含む)およびこの更新にかかわるイベントデータだと考えられます。たと
えば原材料は購買と生産、製品ならば生産と販売や物流、お金は販売とコスト
を発生させる各システムおよび経理が関係するはずです。一方製造過程の中間
品などは生産システムの中だけで処理され、他システムとの関係は発生しない
と考えられます(工場が別で工場間でやり取りされるケースは除外)ので、そ
の在庫やこれにかかわるイベントデータ−これをローレベルデータと呼ぼう−
は対象外となります。
これらをストアする(バーチャルを含む)DB通信場を設け、各アプリは発生
したハイレベルデータを自らのDBに書き込むと同時にログファイル経由送り
込み、準リアルタイムに更新するものとします。このときパッケージやレガシー
システムとしてはハイレベルデータをいわゆる「サービス」として生成するも
のがあるかと思われます。
各アプリは必要なデータを、5分ごと、あるいは半日ごとなど適宜−この頻度
は各アプリが自覚しているはず−読み取るものとします。通信場でデータが保
持されていますから、バスのようなプッシュ型配信でなく、プル型アクセスが
基本と考えます。命名はまだ固まっていないようですが、この通信場を私はN
CRにならってEDW(Enterprise Data Warehouse)と呼び、またこのハイ
レベル、ローレベルの2階層の通信場を持つアーキテクチャを、フェデレーシ
ョンアーキテクチャと呼んでいます。Data Warehouseと呼ぶ理由は各アプリと
しては参照アクセスに限られるからです(従来の時系列データからなる分析用
のData Warehouseは主にこれから作られる別物と考えます)。実装独立に考え
ていますので、大量かつアクセス頻度の小さいハイレベルデータは元のDBに
あるものをバーチャルに位置づけただけかもしれません。そのイメージはおお
よそ次のように書けると考えます。
EDWによるA2AレベルのDOA
AP1 ←−┐
      |
AP2 ←−DD−EDW←ハイレベルデータ(各APからのログ)
      |
AP3 ←−┤
       ・
なお、ハイレベルデータはAP1、AP2などの大きさに影響を受けます。こ
れを決めるサイエンスは難しいので、当面、過大・過小を避けるエキスパート
の判断にゆだねることになると思われます。
■ SOAの中心課題
EDW環境下では、リソースデータの一元化共有は大前提です。したがって、
リソースデータはこのリソースDBから、ローレベルデータは自らのDBから、
またハイレベルデータはEDWから入手できますので、個別アプリケーション
のニーズとしてSOAを考慮する必要はありません。結局SOAが必要になる
のは、リソースDBおよびEDWにおいて、非DOA的に作られたアプリケー
ションからバーチャルなデータを問合せする際、必要になるだけと考えられま
す。
ここでSOAの本質を捉えるために健康保険証チェックの事例を考えて見ましょ
う。いま病院では毎月初めに保険証を検査します。全額自己負担になるのを避
けるために患者は保険証を忘れないように努力しています。しかし本来は医療
費計算プログラムからSOAによって健康保険が有効であることを確認すれば
いいはずです。病院がm箇あり、健保組合がn個あったとき、直接病院から健
保組合に問い合わせるとm*nのパスを持つバンドエイドSOAとなって、保
守を難しくします。そこで健保組合を束ねたDB通信場/DWHを作ることを
考えます。ここに健保対応のステイタスを記録すれば、病院はここ1箇所に問
い合わせれば決済ができます。健保組合は健康保険証の異動を反映させなけれ
ばなりませんが、システム全体のパスはm+nで総合的には合理化になると思
われます。
この健保データは
 [保険者#.健康保険証#]−(保険対象者氏名、有効期限、・・)
のような形式かと思われますが、これは病院の会計システムのバーチャルなリ
ソースデータとして位置づけることができます。
このようなDWHの設置が難しければ、仲介のエイジェントを設けるだけでも
良いでしょう。SOAにより病院はエイジェントに問い合わせます。次いでS
OAによりエイジェントが健保組合に問い合わせます。これによりパスはm+
nになり単純化します。DWHかサービスバスかという技術的なことより、コ
ミュニケーションをコントロールする場−ファサードとも呼ばれる、いわば郵
便局−を用意するかどうかが問題になるわけです。サービスはデータの所在場
所が行うわけですが、データが本来どこにあるべきか、すなわちデータアーキ
テクチャを設計することが求められています。
したがって、私はツール以前にSOAで重要なことは
・ リソースデータの一元化
・ データアーキテクチャの設計(フェデレーションアーキテクチャを含む)
だと考えます。この発想はしかしデータを隠蔽するプロセス中心からは出てき
にくいでしょう。プロセス全体を視野に通信場を設定してコミュニケーション
するDOA的発想がベースになると考えます。
(注)以上の解釈は椿の私見にすぎません。SOAは元来OO系の方からの提
案と思われます。OO正統派からはSOAを摩り替える異端の見解と見えるか
もしれません。しかし従来個別アプリの問題−要件定義やDB設計など−に比
して議論が少なく、いちばん手薄だったところであり、またプロジェクト失敗
や保守コストアップの遠因となっているところかと思われます。ベンダー主導
のSOAだと「JUNK」システムの厚化粧になる、といった指摘もあり、別
の見方も多々あるかと思われます。ご遠慮なくお寄せください。