アーキテクトへの道 シリーズ 第三話

Webサービスとは…SOAって?

メディアから取材を受けたり、官公庁主導などの各種団体に参加して活動する中で、最近必ず話題に登るのが Web サービス、サービス指向アーキテクチャです。みなさんいろいろな視点で解釈されていて、それぞれは決して間違いではないのですが、ご自分の興味の範囲に焦点が絞られてしまう傾向があります。そこで今回のテーマとしてこれらを取り上げてみたいと思います。つまり…「Web サービス」って何だ ? SOA との関係は…?

■Webサービスとは ?

Web サービスとは ?

つまり立場によって興味を持つ範囲が違うため、解釈の仕方もまちまちです。しかしこれらがすべて整った時点ではじめてWebサービスというものが世の中で有効活用されるわけです。どの観点も見逃すわけにはいきません。ただすべてに共通していえることが一つあります、これです。
「ソフトウェアの利用・提供スタイルが個別アプリケーションからサービスへと進化する」
やや難しい表現をしてしまいますが、ソフトウェアの抽象度が上がるということです。抽象度が上がるということはつまり物理的な配置への考慮、細かなインタフェースの意識や制限された利用環境から解放されるのです。ソフトウェアに自由を与えるのです。

図解:ソフトウェアをサービスとして提供する

このような環境を提供するために 2000 年に登場したのが Microsoft .NET です。「ソフトウェアをサービスとして提供し、あらゆる時間・場所・デバイスから利用できる」まさにこの図のとおりです。統一的なユーザー認証や、課金モデルなど克服すべき課題はいくつか残されていますが、こういった世の中へと進歩していくことは確実です。

■サービス指向アーキテクチャ…なぜ今 SOA なのか ?

ここから先は開発者にとって重要な意味を持つサービス指向アーキテクチャについてお話いたします。
「サービス指向アーキテクチャ(SOA)」の定義は何かと聞かれて即答できますでしょうか?なかなか難しいものです。なぜなら Web サービスと同様にこれも観点の違いにより様々な表現方法があるからです。以下のような回答が一般的です。

  • コンポーネント指向の粒度の大きなもの
  • Web サービスを利用したシステム
  • 疎結合型システム
  • ビジネスと IT のギャップを埋めるもの

それぞれが SOA の側面を示しています。この中で一番重要なのが 4 番目の「ビジネスと IT のギャップを埋めるもの」という定義です。1番目の解釈は危険です。なぜなら SOA はこれまでの方法論の延長線上と捉えるよりは、発想の逆転と考えるべきだからです。つまりビジネス要件をサービスとして表し、そのサービスをコンポーネントなりオブジェクトで構築していくというトップダウンアプローチが不可欠な要素なのです。サービスを粒度の大きなコンポーネントと考えると、相変わらずビジネス概念とは無関係のサービスが出来上がってしまいます。それは避けなければなりません。前回下図をご紹介しましたが、開発者、エンドユーザーの観点を上書きするとこのようになります。つまり SOA とはエンドユーザーの観点を取り入れるためのアーキテクチャなのです。SOA を正しく適用するためにはビジネスモデルから整合性を保ってサービス→コンポーネントという順番で構築していく必要があります。それが SOA のキーポイントです。

開発者、エンドユーザーの観点を上書きするとこの図のようになります

開発者の方にはいまいちピンとこないというのはよくわかります、かつて自分もそうでした。しかしここ数年 SOA について考えているうちにこの結論にたどり着きました。ですから何をサービスにすればよいのかという部分が非常に重要になってきます。その概念を以下の図でご覧ください。

SOA 概念

サービス指向では業務プロセスに着目します。その企業がどのような業務プロセスで構成されているのかを洗い出し、それぞれのプロセスをモデルとして表現します。その結果プロセスが呼び出している各機能、エンティティというものが識別されます。ここでいうプロセス(複数機能呼び出しを行うワークフロー)と各機能(ユーザー認証などの自立した単位)とエンティティ(企業を構成する資産、人・試算・帳簿など)をそれぞれサービスとして切り出し、構築していきます。そして業務プロセスの非機能要件(パフォーマンス・信頼性・コストなど)に基づいてインフラストラクチャを選定するというのが正しいアプローチです。さらに前回お話したとおり変化する部分と変化しない部分を切り分けることが重要です。業務プロセスは変化します、なぜなら取引先の変更、アウトソーシング、事業の拡大・撤退など様々な変化要因が存在するからです。ですがプロセスから呼び出される機能やエンティティはそんなに変化しません。それらをサービスという自律した単位で区別しておけばプロセスが変更しても、他のサービスへの呼び出し方法だけを変更すれば対応できるわけです。ここまではユーザーのビジネス要件をいかにうまくサービスとして提供していくかといった観点でお話しました。ここからはサービスの構築という側面について SOA のキーポイントをご紹介します。

■開発者にとっての SOA

前回お話したアーキテクチャ原則のうち高凝集度かつ低結合度(疎結合)というものがありましたが、SOA はこの原則を実現するものです。つまり各サービスは利用者からみてまとまった機能セットを提供するものであり(関連する機能が凝集されている)、かつ他のサービスとメッセージのやりとりだけで連携する(疎結合)ことで統合されたシステムを構成します。下図にサービスの概念図を示します。

SOA サービス概念図

サービスの設計を進める上で特に重要なのは自律性を確保するという観点です。つまり外部とはコントラクト(契約)とメッセージだけでインタフェースがとられていることが肝心です、外部サービスとの個別コンポーネント間の呼び出しや外部サービスの管理するデータベースへの直接的な呼び出しがあってはならないわけです。そして運用管理に関しても他のサービスには影響を与えず自分のサービス内に閉じた範囲ですべて実施できるように設計する必要があります。SOA が提供するメリットは、サービスを構築する開発者がそれを達成するために留意してこそはじめて活かされるわけです。これは SOA に限らず OO やコンポーネントにも言えることです。OO や SOA の目的を理解して、それを達成するために設計時点で熟慮が求められることをご理解ください。第一話でご紹介したアプリケーションの論理的な階層は、サービスをどのようなコンポーネントで構成するべきかを示しています。これに関する詳しい情報は .NET アーキテクチャセンターにある .NET のアプリケーション アーキテクチャ : アプリケーションとサービスの設計をご一読ください。

■SOA と Web サービスの違い

ちまたでは、SOAとはWebサービスを利用しているシステムであるという意見が見られますが、それだけは不十分です、その相違点を以下にまとめました。

Web サービスで可能なこと テクノロジーへの中立性 プラットフォームには依存しない
標準化 標準プロトコルを提供
広範囲な利用性 自動的なディスカバリと利用が可能
SOA で可能なこと 再利用性 コードや EXE のコピーではなくサービスを再利用
実装非依存 サービスは物理実装には依存しない
インターフェースを公開可能 標準フォーマットでのインターフェース公開が可能
利用者とプロバイダーとの契約を明確化 利用者とプロバイダー間で標準に基づく契約を締結
利便性の向上 利用者から見て適度な機能セットが提供されている

■まとめ

今回は Web サービスの意味するところと、サービス指向アーキテクチャについてご紹介しました。このようにソフトウェアの提供、利用形態が進化していくわけですが、ソフトウェアの構築に関しても進化していくことになります。次回はその代表的な取り組みである「モデル駆動」についてご紹介させていただきます。


コミュニティの追加

追加
表示: