SOA環境の現実的な構築、 最も必要なのは「ガバナンス」

　今でこそ「経営とITの一体化」は当然といわれているが、経営層（ユーザー層）が基幹システムに求めるニーズは、実は従来から大きく変わっていない。例えば「短期開発ニーズ」や「運用しやすさ」は普遍的なニーズであるし、開発者はその期待に応えようとしてきた歴史がある。その手段として注目されたのが「ソフトウェアの部品化」だ。ソフトウェアをあたかも部品のように蓄積し、開発要求に応じて部品を組み合わせるようにソフトウェアを“組み立てる”という考え方である。

　この考え方も、実はそれほど新しいものではない。これまでも、SmalltalkやDCOM、CORBAといったプログラミングおよびミドルウェア技術によって“ソフトウェアの部品化”は試みられてきた。しかし、部品化を進めるには標準的な規格が必要となる。これまでソフトウェアの世界は、部品の粒度などさまざまな問題からなかなか標準の規格化が進まない状況だった。

　こうした状況に終止符を打ったのが、「サービス化」という考え方だ。これまでの部品化の試みが、技術ベースであるのに対し、サービスをベースにした考え方では、「業務」や「ビジネス」という観点でアーキテクチャを考えている。ビジネスプロセスを最適に、かつ短期間で連携しようというものだ。連携するサービス自体は、さまざまな技術で開発されていても、データフォーマットやインターフェース部分を整備することで、確実に「つなげる」ようにする。こうして誕生したのがSOA（Service Oriented Architecture）であり、まさにユーザーと開発者、両者の思いが一体となったところで生まれた技術といえる。

　既存システムをSOA化するためには、SOAをベースにシステム全体を整理し直し、効果の見込める所から優先的に再構築を図っていくのが効率的だ。そして、既存システムのSOA化に着手する時、重要な役割を担うのがミドルウェア層（ここでは便宜上「SOAミドルウェア」と呼ぶ）である。

　SOAミドルウェアを理解するには、業務システムの仕組みを俯瞰（ふかん）して考えると分かりやすい。まず、全体最適の観点から見れば、個々の業務システム（サブシステム）同士を連携することが求められる。既存サブシステムをSOA化し、インターフェースを標準化すれば、サービスを行き交うデータの可視化も可能になるだろう。もちろん、ここではミドルウェアが重要な役割を果たす。

　次に、業務システムを構成している個々のプロセスがある。最近では、多種多様なプロセスを定義ベースで自動化し、定義を変更することでプロセスも変更できるような柔軟性の高いシステム構造が求められている。プロセスで実行される個々の業務処理とサービスを繋げるのもミドルウェアの役割だ。

　そして、すべての業務システムにはユーザーインターフェース（画面）がある。バックエンドサービスには手を加えず、フロント側だけで情報加工ができる仕組みができたら便利だ。バックエンドサービスとフロントを繋ぐのがミドルウェア層である。

　富士通では、これら3点をSOAミドルウェア適用の代表的なパターンとして体系化している。では、ここから、SOAミドルウェア適用のための代表的なパターンを解説していこう。

［パターンA］　サービス間連携

　パターンAは、複数のサブシステムを連携させ、全体最適を実現する。かつて、システム間連携にはEAI（Enterprise Application Integration）が利用されていたが、EAIの場合、エンジンごとに固有の技術があったり、複数間連携が実現できないといった課題があった。SOAでは通称「サービスバス」と呼ばれるミドルウェアを用い、XMLフォーマットを通じてデータ連携を実現する。またサービスバスの導入により、個々のシステムのデータ形式が整備されるので、その後の連携や新規開発がより早く、確実に進むようになる。これはIT戦略を立てる上で、非常に大きなメリットとなるだろう。

［パターンB］　プロセスを起点としたサービス利用

　パターンBは、ビジネスプロセスフローエンジンなどを使い、複数のプロセスを定義して自動化処理をする。共通化できるプロセスと差異部分とを切り分け、共通化できるプロセスを再利用して定義を修正することで、短期開発が可能となる。新しい商品のリリースや、新サービスを開始した時、受け手となるシステムも即稼働が可能なので、ビジネスチャンスを逃さないというメリットも生まれる。

［パターンC］　フロント（画面）におけるサービス利用

　パターンCは、バックエンドの業務ロジックをXMLを通じて疎結合させることで、システムの柔軟性を保持する。かつてMVC（Model／View／Controller）モデルが注目されたとき、バックエンドの業務ロジックと画面（View）を分離することで、業務システムの柔軟性と変化対応力を促進させる考え方が一般的になったが、SOAでもこれを採用している。現在では、Ajax（Asynchronous JavaScript and XML）など画面側の機能や動作を向上する技術が一般化しており、メインフレームの専用端末でしか行えなかった入力操作（テンキーやファンクションキーの利用など）が、Webシステムで活用できるようになる。

　以上、SOAを現実化するには、これら3つのパターンに当てはめ、段階的にサービス化を促進すればよい。なお、パターンA、パターンBの実現により、ビジネスプロセスのモニタリングもしやすくなる。ユーザーの視点から見れば「ビジネスプロセスを見える化」できるわけで、ITによる業務統制などがずっと容易になる。

　パターンA〜Cまで一気通貫でSOAを実現するにはどうすればよいか？ Ajaxフレームワークやビジネスプロセスフローエンジン、サービスバスは、それぞれ各ベンダから個別製品が出ているので、それらを組み合わせる方法もあるが、最良の手段はやはり1つのミドルウェア群として完成された製品群を利用することだろう。

　富士通のビジネス インテグレーション プラットフォーム Interstageでは、SOAを支えるミドルウェアとして下図のような製品群を提供している。その特長は、単に“技術的”にSOAを実現するだけでなく、SOAをベースとしたITのガバナンスを実現していることだ。

SOAを支える富士通のミドルウェア

　SOAによるシステム再構築を展開するうえで、「フロント統合」「BPM」「サービスバス」は確かに重要なキーワードだが、さらにもう1つシステム全体を管理するコンポーネントが必要不可欠だ。富士通では、SOA環境で作成・運用されるサービスのインターフェース情報や管理情報といった情報を格納し、一元的に管理するレジストリ製品「CentraSite」をSOAミドルウェアのラインアップに加えている。この「CentraSite」は、リポジトリ機能も有しており、SOA環境全体を網羅する生産物（設計書、仕様書、サービス利用規約など）の系統立った管理も可能である。

◆

　以上、SOA環境を実現するための富士通独自のアプローチを紹介した。次回からSOAミドルウェア適用のためのパターンにおける技術的な内容について、さらに詳細な情報をお送りする。

［講演レポート］　SOA開発環境による段階的システム構築とSOAガバナンス ModelingForum 2007（主催：特定非営利活動法人 UMLモデリング推進協議会、9月13日・14日）で富士通の鈴木弘樹氏が講演を行った。講演タイトルは「SOA開発環境による段階的システム構築とSOAガバナンス」。同講演のハイライトを紹介する。

SOA化のメリットは「インターフェースの統一による再構築促進」「逐次処理による業務のスピードアップ」「経営の見える化促進」などがありますが、それを分かっていながらもなかなかSOA化が進まないのが現状です。その理由としては、ほとんどの基幹業務はすでにIT化されており、その処理に何ら問題がないためでしょう。しかし、問題が起こってからあわてて対処するより、段階的に改善策を進めていった方が効率的なのは、誰もが知ることです。 　例えば2つのシステムを連携する際、連携プログラムを個別に組むのではなく、サービスバスを導入すれば、2つのシステムのインターフェースを同一に整えなくてはなりません。これを足がかりに、別のシステムと連携したい時には、新たな連携先のインターフェースを整備します。こうして順次インターフェースを整えることで、サービスバスを中心にシステム全体を柔軟に連携できるようになります。これにより、システム全体の姿が浮き彫りになり、統制が取れた開発・運用が実現できます。 　これは開発者に限ったことではなく、ビジネスアナリストやサービスの管理者、引いては経営層に対しても有益です。再利用が促進されることで重複開発や運用コスト増が抑制され、システムの「あるべき姿」を描きやすくなることで、企業力も増加する。これがSOAで実現するITガバナンスです。