Coursera Service-Oriented Architecture Week1 Service-Oriented Architecture

Service-Oriented Architecture

ソフトウェアは、外部のサービスを利用することができる。天気の情報がほしいときには、観測基地を建てるのではなく天気情報APIを使うなどである。

サービスとは、コンポーネントとは違い、外部(たいていは外部の会社のサーバーやインターネット上)に存在する。 サービスについて話すとき、サービスのリクエスタとプロバイダ、両方の役割について言及することになる。

Service-Oriented Architectureは、サービスを構築する・利用する・組み合わせるやり方についてのアーキテクチャである。

Service-Oriented Architectureでは、非機能要件がたいへん重要になってくる。なぜなら、外部のサービスについては開発者が制御できないからである。 レスポンスタイム、サポート、可用性などである。サービスの利用には利益もあるが、トレードオフとのバランスを考える必要がある。

Service Principle

使いやすいサービスの提供のためには、サービスとService-Oriented Architectureのためのベストプラクティスがある。

  • モジュールになっていること:サービスはモジュール性があり、疎結合である必要がある。これによって、サービスは可搬性があり再利用可能になる。
  • 組立可能であること:例えば、Javaで書かれたサービスをRubyで書かれたシステムから利用できるといったように、サービスは外部のシステムに組み込まれることを前提とし、外部とは決まったプロトコルでコミュニケーションできるようになっている必要がある。
  • 自己記述方式:サービスは自分自身をどう使ったらよいか説明することができる必要がある。(WSDL等を使う)

Web-System Architecture

Webシステムは、 - プレゼンテーション層(ブラウザ、Webサーバ) - アプリケーション層(アプリケーションサーバ) - データ層(データベース) の層に分かれることが多い。 静的Webページを表示する場合は、 - プレゼンテーション層(ブラウザ、Webサーバ) - データ層(HTML) の二つの層だけでも事足りることがある。

このように、レイヤードアーキテクチャーを使うことは、関心の分離やコードの再利用に役立つ。

Remote Procedure Call(RPC)

現代のシステムは、ネットワーク越しにコミュニケーションできるようになっていることが多い。 個々のシステム、例えばクライアントとサーバーは、それぞれの用途に特化した構成となっていて、お互いの詳細な実装については知らない。その二つがコミュニケーションするためには、ミドルウェアを間に挟む。ミドルウェアがコミュニケーション用のインターフェースを提供することにより、やりとりが可能になる。これはデザインパターンのMediatorパターンに似ている。

RPCは、あるマシンが別のマシン上のプログラムを実行することができるようにする仕組みである。 - 呼び出し元 - 呼び出される側 - インターフェイス定義言語 の3つの主要なコンポーネントから構成されている。

Object Brokers

Object Brokerは、分散システム上でのそれぞれのコンポーネントを接続し、オブジェクト指向のアプローチによって使用することができるようにするものである。