[Arch]実現可能性をどうみるか
何か硬いタイトルですが、何気に以下のような図を見てください。
図の良し悪しは置いといて、ようはサーバーという役割とクライアントという役割が物理的なコンピュータとして分離しているよということを表しています。このような構造になった時に、ソフトウェアを開発する立場として何を考えるでしょうか。
- 何を実現しようとしているのか。
- どういう機能の役割分担なのか。
- ネットーワークはどうなっているか(プロトコル、回線、etc)。
- 言語は何か？
要求を考える時に重視するべきことは、「何を狙いとしているのか」という点でしょう。そしてソフトウェアで実現すべき機能は何かということになるでしょう。
サーバーとクライアントが物理的なコンピュータとして分離されていますから、通信手段や言語も気になるかも知れません。でも物理的なネットワークの回線で繋がるということから、コンピュータ同士が通信を行う取り決めを行えばどのようなコンピュータとも通信そのものは可能なはずです。つまり、以下のようなことを決めれば通信は可能だと考えることができます。
- 通信プロトコルを合わせる。
- メッセージの種類と役割、データの項目を合わせる。
これ以外にも考えるべきことはあるでしょうが、通信プロトコル(たとえばHTTPを使うか、TCP/IPなのか)と交換するメッセージを決めれば、通信可能であることを予測することができます。サーバーとクライアントのソフトウェアやOSを気にする必要はありません。何故なら、純粋に接続可能かどうかを見極めることが大切だからです。
次に考えることはコストと実現可能期間かもしれません。コストを考える上で、同じOSで同じプログラミング言語で作成されていることは重要かもしれません。何故なら、標準で通信手段が提供されていたりするからです。異なるOSや異なるプログラミング言語の間で通信を行う必要があるかも知れません。通信手段を簡単に実現するライブラリがそれぞれに存在すれば、コストを削減することができます。もちろん独自に通信手段を確保することもあり得ます。ようはコストや信頼性、パフォーマンスと言った指標とのトレードオフで今回の実現手段を選択すればよいのです。この選択した実現手段を関係者に対して、適切に説明できて、実現手段を提示できれば良いだけです。
ここで重要なのはプログラミング言語でもOSでもありません。通信が可能かどうかであり、それが必要十分な手段(コストや納期など)で実現できるかどうかです。
ついでに言えば、このような物理的な構成になった時の弱点も考えられることが大切です。具体的に言えば、通信方式が同期式なのか非同期なのかです。そして大量のデータを送受信する必要があるかどうかなども通信方式を決定するときの、重要な事項になります。一般的にHTTPサーバーへ大量のデータを送信するとタイムアウト時間のチューニングが必須になります。タイムアウト時間を延ばせば、サーバーで管理するセッションオブジェクトなどの破棄タイミングをどうするかなどの懸案事項も生まれてきます。この問題を根本的に解消するには、大量データの送受信では非同期処理を採用するとか、別の手段を用いるなどが必要になるわけです。
これらの懸案事項というのは、実現可能性を考えるときに必要な機能を洗い出せていれば事前に検討材料にすることが可能になります。これらの実現可能性を漏れなく考えて実現方式を検討していくのがアーキテクチャ設計ではないかと私は考えます。
ここまで考えて行く上でプログラミング言語は、それほど重要なことでは無いという事実も重要な点です。もちろん逆でプログラミング言語から構造を考えていくという手段もあるでしょう。この手段の欠点は、プログラミング言語が提供する以上の構造を作れない点です。つまり限界は、プログラミング言語が持つということです。
PS.誰でもよーく考えれば思い浮かぶ事だと思っています。でも忙しすぎて、慣れた手段で実現していくことで、新しい方法や手段を考えなくなることが怖いと私は思っています。自戒の意味で。
