 |
≫ |
|
|
|
|
|
IT（Information Technology）からB.T.（Business Technology）へ。この移行を遂行し、テクノロジーをビジネスの成果に直結させるには、SOA（Service Oriented Architecture）の採用が重要な鍵を握ります。それではSOAとは何か。またその導入を成功させるには、どのような点に注意を払うべきなのでしょうか。 |
|
|
解説者プロフィール |
|
|
|
|
日本ヒューレット・パッカード株式会社
コンサルティング・インテグレーション統括本部
シニア・コンサルタント
西村 毅 |
|
 |
|
|
|
|
|
聞き手 |
最近SOAという言葉をよく聞くようになりました。ITベンダーもSOAをキーワードに、製品やサービスを訴求するケースが増えているように感じます。なぜいまSOAが重要なキーワードになっているのですか？ |
|
|
西村 |
SOAのような考え方は、決して新しいものではありません。システムを疎な連携により構成したり、既存資産や製品の活用によって新規に開発するプログラム量を合理的に抑制する方法論は従来から実践されてきましたし、2000年頃にはWebサービスも提唱されています。2004年以降のSOAの興隆はこういった考え方がSOAの名の下に総合的に体系化され、Webサービスや関連製品の充実によって一気に実現性が高まり、導入が加速化された結果といえるでしょう。 |
|
|
|
|
聞き手 |
そもそもSOAとはどのような考え方なのですか？ |
|
|
西村 |
簡単にいってしまえば、システムを“レゴブロックの組み合わせ”のように構築していこうというアプローチです。業務システムというものは、いくつもの業務機能から構成されています。従来のシステム構築では、これらをひとまとめにしてひとつのアプリケーションとして実装し、それをアプリケーションサーバ等のコンピュータ上で動かしていました。しかし業務機能をアプリケーションから独立させて、これらを自由に組み合わせることができれば、アプリケーション開発はもっと効率化されるはずです。また開発期間も短縮されるので、変化対応の柔軟性も高まっていく。これがSOAの基本的な考え方です。 |
|
|
|
|
聞き手 |
自由に組み合わせられる業務機能のことを、サービスと呼ぶんですね。 |
|
|
西村 |
そうです。ひとまとまりの業務要素で構成されたソフトウェアコンポーネントをサービスと呼びます。
これらひとつひとつが、ひとつのレゴブロックに相当するわけです。これらのサービスを、レゴブロックの凹凸と同じように標準化されたインターフェースで組み合わせて、アプリケーションを形作っていくわけです。 |
|
|
|
|
聞き手 |
従来型のシステムとの比較を、もう少し詳しく教えてください。 |
|
|
西村 |
それでは下の図を見てください。左側が従来型のシステム、右側がSOAの考え方に基づいたシステムです。 |
|
|
|
|
従来型システムは、アプリケーション毎にシステムが構築されており、アプリケーションに必要な業務機能やITリソースも、それぞれのアプリケーションの枠の中に囲い込まれていました。このようなシステムの状態を“サイロ型”と呼ぶこともあります。牧場で干し草をためておく“サイロ”の形に似ているからです。アプリケーション毎に業務機能やITリソースを囲い込んでしまうと、他のアプリケーションに融通するといった柔軟性が失われます。その結果、開発に時間とコストがかかるようになり、ITリソースのムダも生じてしまうのです。 |
|
|
|
|
聞き手 |
これに対して下の部分を共通化したのがSOAなんですね。 |
|
|
西村 |
SOAの基本は先程のレゴブロックですが、下の部分の共通化である共通基盤も重要です。まず業務アプリケーションから、業務機能やITリソースを切り離します。切り離した部分は“共通基盤”としてまとめておき、これを複数の業務アプリケーションで利用できるようにします。こうすれば、新しい業務アプリケーションが必要になった場合でも、共通基盤に含まれる部分を開発する必要がなくなります。またITリソースも業務アプリケーション間で共有できるので、ムダな部分を少なくできます。
両者をもっと細かく比較すると、下の表のようになります。 |
|
|
|
|
|
|
|
| 最終結果としての設計 |
変化のための設計 |
| 密結合 |
疎結合、アジリティ、適合容易性 |
| 縦割りで連携しない構造 |
サービス間の連携 |
| ソースコード指向 |
プロセス指向 |
ウォータフォール型の開発
（その結果、長期化する開発期間） |
再利用を前提とした
インタラクティブでスパイラルな開発 |
| 個別業務とコスト中心の発想 |
ビジネス中心の発想 |
| ミドルウェアが実現の鍵 |
アーキテクチャが実現の鍵 |
| 技術の統一を志向 |
多様な技術の相互運用性を志向 |
|
|
|
|
|
印刷用画面へ
