Webサーバでは、セッション情報がステート情報となります。そのため、セッション情報を共有する情報を格納（共有メモリ、DBなど）します。

またはセッションアフィニティ（スティッキーロードバランス）と呼ばれる、負荷分散処理装置が同じサーバに入れることも考えます。
この場合、処理中のサーバに障害が起こるとセッション情報が消え、他のサーバで最初から処理し直しとなります。

このように負荷分散した場合には共有データをどうするのかは考える上でのポイントになります。

そこで、スケールアウトという考え方が浸透し、Webサーバ、アプリケーションサーバを横に並べて負荷が高まるにつれて一台あたりのトランザクション量を一定にすることでトランザクション量を増加しても対応できるようになりました。

負荷分散の基本的な考え方は、
　アクセスの入り口を1カ所に
　アクセスの出口を複数箇所にする
です。
この負荷分散をさせる１：Nの装置として、ソフトウェアが利用される場合、ハードウェアが利用される場合があります。

１） アクセスの入り口を1カ所にする
　アクセスの入り口を1カ所にするために、VIP（Virtual IP）を用いて、複数のサーバに対する入り口を一つにします。
　URLで振り分けをする場合でもVIPによって入り口を一つにします。

２） 出口を複数箇所にする
　負荷分散装置によって、どのサーバを選択するかを決定します。（負荷分散装置のアルゴリズムとして、ラウンドロビンや係数によって振り分けなどを選択できます）

この2つによって、負荷を分散し性能を維持していきます。

今回は単純なパターンとして、クライアント（ブラウザ）、Webサーバ、アプリケーションサーバ、DBMSの構成を
紹介します。

ポイントはアプリケーションサーバの存在で、Webサーバと連携してアプリケーションを動作させます。
アプリケーションサーバには2種類あり、Webサーバとの連携方法の違いで分類しました。

1)　Webサーバ上で動作するアプリケーションサーバ
　　PHP、Perlなどの言語が動作するアプリケーションサーバはmod_xxといった、Apacheのモジュールとして実装されており、別プロセス・別スレッドで動作します。

2)　Webサーバと独立して動作するアプリケーションサーバ
　　Webサーバと独立して動作するアプリケーションサーバがもう一つの種類となります。例えば、JavaのアプリケーションサーバであるTomcatやJBoss ASなどはこの種類です。Webサーバとアプリケーションサーバはプロセス間通信で連携することが普通です。

上記の構成の違いによって、特徴が現れるので構成を考える場合の参考となります。

これは、他の構成でも同じで、「構造が特徴を表す」という『構造主義』の考え方が私の考え方の根幹にあるので他の部分でたくさんでてくると思います。

あるサーバのデータが更新されたのに、それにひも付いている他のサーバのデータがサーバ障害によって更新されないといったことがあり得ます。データ不整合を防ぐために一連の更新処理がAll-Nothingで実施されなければなりません。
そのために、トランザクション制御（管理）することが重要になります。そのために分散オブジェクトにトランザクション管理機能を追加された構成が考えられます。それがCORBAでいえばOTSであり、一般的なアプリケーションサーバで言えばTPモニタです。

前回書いた構成にOTSサーバ、TPモニタを追加した構成が今日のアーキテクチャになります。

Webはこの発展系ですが、Web以外でもアプリケーションサーバとしてのミドルウェアを使う場合もありました。
Webシステムでたとえると一つのサーバとしてのイメージが強くなりますが、スケールアウトする構成ではなく、機能を束ねる単位でサーバを
分けて、構成しています。

分散オブジェクトをカテゴリで束ねてサーバ化した（CORBAなど）構成がこのような形状となります。

1対1であればサーバの変更・リリースもクライアントの変更・リリースも同じ事ですが、
一般的にはクライアントの台数は多く、時には数万台に及ぶ場合もあります。

クライアントの変更（バグ修正・新機能追加など）を反映させるために、クライアントを
再インストールしなければなりません。それには膨大なコストがかかる場合もあるため、クライアントの配布の
仕組みはセットで考えます。

運用管理ソフトの機能の一つか、Java Web Start、ClickOnceなどの技術を用います。

アーキテクチャとして考えると、この方式にもバリエーションがあり、データ格納のみをDBMSで実施する方式とデータとデータ処理の一部をDBMSで実施する方式に分かれます。（これは3階層のWebシステムでも同等のバリエーションがあります）

このような場合は、データ（情報）を共有し、アプリケーションを複数人で利用する方法を考えます。
つまり、スタンドアローンアプリケーションを各自のマシンに入れて、データだけを共有する方法です。

データを共有する方法はいくつかありますが、今回紹介する方法は、スタンドアローンで利用する
ファイルをファイルサーバで共有する方法です。

CIFSのようなプロトコルを利用してファイルを共有するサーバを介して、複数のアプリケーションが
連携します。

この方式は、同時に更新するブロックがファイルという全体に及ぶため同時更新に弱くなります。
同時更新を維持するためには片方を読み取り（参照専用）とするか、ファイルにロックをかけて誰かが使っている間は使えないようにするかなどの仕組みを追加する必要があります。

シングルビューのアプリケーションでは、ビューとモデルは対でしたが、マルチビューでは
モデルに対して複数のビューが関連します。

モデルにビューをプラガブルで関連できるようにして、表示させたいビューをモデルに
登録しておくことでモデルが変化した時に複数のビューを更新することができます。

単純な話ですが、仕掛けを考えないとスムーズにいきません。
また、モデルに登録するビューのインタフェースを明確にして、依存関係をできうる限り排除するというのもポイントとなります。

アーキテクチャという言葉がいろいろな意味を持っているなと思いました。
ユーザ企業の情報システム関係者（もしかしたらエンドユーザとしても）が持つべき視点を
網羅的に描かれた面白い一冊。
図も多くて直観的に理解できるのは何よりもうまい本作りだと思う。