ohneda/chapter1.md

## chapter1.md

      
    Raw
  

              chapter1.md
            
          
    第一章 オブジェクトからWebサービスへ


Webサービスとはなにか

サービスをどのように使えば、論理的な機能を複数のアプリケーションで共有できるのか。構成の異なるコンピュータプラットフォームを強調して動くソフトウェアにできるのか
Web サービスは、異なるシステムを統合する方法を提供し、再利用可能なビジネス機能を、HTTP 経由で公開するもの


ローカルオブジェクトから分散オブジェクトへ

オブジェクトとは、振る舞い（例：ビジネスロジック）とデータをカプセル化するために、現代の多くのプログラミング言語で使われているパラダイム

オブジェクトのホワイトボックス再利用

オブジェクトを使う開発者が、オブジェクトの実装に自由にアクセスできること
クライアントがオブジェクトを直接操作する
こうしたクラスを、異なるプログラミング言語やプラットフォームから利用するのは簡単なことではなかった。


オブジェクトのコンポーネント化

異なるプログラミング間で、ソフトウェアを再利用する試み


オブジェクトのブラックボックス再利用

コンポーネントの利用者が内部の参照や修正をすることはできないこと
例: ActiveX コントロールなど

アプリケーションにはオブジェクトのメソッド・プロパティ・イベントを記述したバイナリのインターフェースが提供された
コンポーネントを使うクライアントは、コンポーネントと同じプラットフォームで実行する必要があった
オブジェクトは最終的にリモートにデプロイされ、クライアントと異なるアドレス空間、異なるマシンに存在する


分散オブジェクト

CORBA, DCOM, RMIなど
コンポーネントと同様に、ブラックボックス再利用
リモートプロキシを含むバイナリライブラリが生成され、通信に必要なロジックが含まれている
クライアントと分散オブジェクトが同じ技術を使っている限りはうまくいく
ただし、以下のような欠点あり

開発者にとって実装が複雑
オブジェクトのシリアライズ/デシリアライズのプロセスがベンダー間で標準化されていない
TCP ポートでの通信が標準化されていない
クライアントと分散オブジェクトで同じ状態を維持するため、スケーラビリティの妨げになる問題が多く発生する


なぜ Web サービスを使うのか

モバイル・デスクトップ・Webアプリケーションなど、さまざまなクライアント間で、比較的容易に共通ロジックの再利用や共有ができる
HTTP と標準的なデータ交換フォーマット(XML や JSON など)を使っている
元から備わっている相互利用可能性や簡易性のおかげで、サービスを組み合わせるだけで複雑なビジネスプロセスが実現可能になっている
クライアントとクライアントのリクエストを満たす手段を分離する間接レイヤを設けている

サービスの公開インターフェースに破壊的変更が生じない限り、クライアントとサービスが独立して進化できるようになっている


Web サービスの検討事項と代替案

Web サービスは呼び出しが「高価」である

プロセス内の呼び出すよりも、桁違いに時間がかかる


さらに問題なのが、Web サービスの呼び出しに分散型の通信が必要であること

クライアントとサービスの開発者は、部分的障害に対応する準備をしなくてはならない
部分的障害とは、クライアント・サービス・ネットワークのいずれかに障害が発生し、その他の部分は正常に機能しているというもの


こうした固有のリスクを考慮すると、開発者やアーキテクトは代替案を考えるべき

クライアントのプロセスでインポート・呼び出し・実行のできる「サービスライブラリ」を用意するなど

ただし、これらの選択肢は非常に複雑
クライアントをサービスの技術に結びつけてしまうことにつながる


Web サービスは、プロセスやマシンを超えた呼び出しでも「意味が通じる」ように備えておく
マシンを超えた呼び出しがどんなに正しいものだとしても、開発者は Web サービスの代替案を常に考えておくのが賢明

MOM( MSMQ,WebSphere MQ,ActiveMQ )
UDPなどのコレクションレスプロトコル

データロスやデータの重複、データの順不同などが発生する可能性あり


データストリームを送受信する

データのバッファが不要なので、メモリ使用量が少ない
届いた時点ですぐにデータが使用可能
巨大な文書やメッセージの転送にはよいが、動画や音声などのリアルタイム配信には適さない

その場合は、RTSP, RTP, RTCPなどが適切


サービスと疎結合の約束

結合とは、「何らかのエンティティが、他のエンティティに依存する程度」を表す
依存度が高いものは「高結合/密結合」
依存度が低いものは「低結合/疎結合」
クライアントとサービスを完全に分離することはできないため、以下のように考慮しなければいけない結合の種類がある

機能の結合

クライアントは、サービスの機能に依存している
サービスの機能に不具合があれば、クライアントは確実に影響を受ける


データ構造の結合

クライアントは、サービスが送受信するデータ構造・そこで使われているデータ型・メッセージの文字コードなどを理解しなければいけない


時間の結合

リクエストの受信後すぐに処理しなければいけない場合は、時間の結合度が高いと言える
リクエストの処理を遅延することができれば、時間の結合度は低くなる

Web サービスでは、リクエスト/ACKを使って実現可能


クライアントがレスポンスを待つ場合も、時間の結合度が高い

非同期レスポンスハンドラを使用することで、軽減可能


URIの結合

クライアントは、サービスのURIと密結合している場合が多い

Linked Service, Service Connector, Service Registry, Virtual ServiceなどがURIや場所との結合を弱める


SOAP について

SOAの定義は幅広い

異なるシステムを統合し、ビジネス機能を再利用する手段を提供する技術的なアーキテクチャスタイル
ビジネスサービスの全ライフサイクルにおける作成と利用のすべての側面において、ガイドとなる設計スタイル
所有者の異なる分散型の機能を構成・利用するためのパラダイム


まとめると、SOAは「ビジネス機能」をサービスにして、論理的なドメインを構成し、ライフタイムを管理する設計パラダイムや方法論であるということ

オブジェクト指向分析よりも要求を明確に伝えることができる
ただし、その実装には多くの方法が存在する