■環境構築について
通常、4つの環境が関係してきます。
- 本番運用環境
- 本番試験(ステージング)環境 ... 本番とほぼ同じ状態に保たれている試験環境
- 開発環境 ... 開発現場の結合テスト環境
- 開発者ローカル環境(PC)
それぞれの環境でアプリケーションが同じように動作しなくてはなりません。複雑な本番環境には、同様に複雑な環境を作っておかないと本番でしか出ない問題が起きたりします。ただ、試験や開発には本番と同じようにコストは掛けられません。この時、決定的な要素は、
- ソフトウェアか、ハードウェアか?
と言う点です。サーバ型であってもソフトウェアであれば、本番と同等の構成を柔軟に構築できます。しかし、ハードウェアであると本番同等の環境を作ることは難しいでしょう。特に大規模システムでは本番システムとの差が大きくなりがちです。本番と試験環境で、ハードウェアを共用するのも望ましくありませんし、開発現場が分散している場合もあります。ライセンスさえ許せば、ソフトウェアの場合、開発PCに入れることさえも可能です。このような理由から環境構築に関しては、圧倒的にソフトウェアに軍配が上がるでしょう。
■問題発生時について
問題が発生した時には、問題を変換システムと切り離して考えられるかが重要です。切り離せるかどうかは2つのポイントがあります。
- URLが変わってしまうか
- 変換サーバなしでアプリケーションが動くか
URLが変わってしまうとテストできないケースがあります。変換サーバ型の場合、変換サーバを飛ばして直接アクセスすれば、当然URLが変わってしまいます。URLが関係する場合には変換サーバ型では問題の切り分けが難しい場合があります。その点、ラウンドアバウトはURLは変化しません。単にモジュールを切り離すだけなので問題の切り分けが極めて確実に可能です。
アプリケーションの動作自体が変換サーバに依存すれば、もう切り離してテストすることはできません。ここでもセッションが問題となります。特に擬似クッキーのような機能を使ってしまうと、アプリーケーションにドコモ端末からアクセスしても動作しません。ラウンドアバウトはセッションを使わない設計をしているので、アプリケーションのラウンドアバウト依存度は低く、無くてもアプリケーションは基本的に動作します。
これらの問題は、製品選定時には大きな項目にはならないかもしれませんが、長く尾を引く重要な項目です。ここでもApacheモジュールであるラウンドアバウトの優位点があると言えます。
0 コメント:
コメントを投稿