2.2 web アプリケーション開発に必要なハードとソフト 大規模サイトの場合、こっこっとした手作業だけでは更新速度を保つことができま せん。情報更新用のしくみ、アップデートを簡単にするしくみが必要です。たとえば、 サイト管理者専用に情報の追加や更新をするためのフォームを用意しておく、データ べースを併用して Web ページを自動生成するシステムを作るなどの工夫が可能です。 デザインを更新しやすくするためのスタイルシート ( P. 222 ) 導入も有効でしよう。 ・回線速度 自分の努力だけではどうにもならないのが回線速度です。しかし、少なくとも、 Web サーバからバックポーン * までの間の回線速度および回線容量を確保するだけ でも、状況は改善されます。特に、容量には注意しましよう。アクセス量が多い場 、容量の少ない回線はすぐにパンクしてしまいます。 高速道路も混雑していればダメ 速度だけではなく容量も重要 図 2-4 ・回線速度を改善するには 間に合わないよ ~ 引っ越しは当社へ ! 拡張性をふまえた設計 が取りにくくなります。どこまで必要かを判断することが肝要です。 テムが構築できます。ただし、あまり考えすぎるとシステムが " 重く " なり、身動き す。拡張性を持たせることで、システムの変更や追加に耐えやすい、長持ちするシス Web アプリケーションに限らす、コンピュータのシステムで重要なのが拡張性で 図 2-5 ・拡張性と軽さのトレードオフ なんでも 入れられるよー 【バックポーン】ネットワークの幹線 ( P. 85 ) 。 ワークとつながる部分の回線など。 そこまで 必要 ? 根本的な設計が まちがってるかもっ たとえばアクセスポイントを持つプロバイダ自身がほかのネット

2.2 Web アプリケーション開発に必要なハードとソフト 電子化の際に重要なのは、データを確実に一元化することです。データがばらばら になっていたのでは、電子化ができないだけではなく、業務へも支障をきたします。 たとえば、データがパソコンの中と紙の書類とに分かれていると、データの検証や検 索といった作業が煩雑になります。特に検索はコンピュータの得意分野なので、検索 機能が活かせないのは惜しい話です。 このためには、データを確実に電子化するためのしくみを考えることが肝要です。 図 2-8 ・データ統一・電子化のためのルールを作る ルール① 発送したら コンピュータにも 入力すること なんで ? 手間の増大・入力忘れ ( データの不整合 ) 0 〇 ルール② コンピュータに 入力しないと発送できません 入力すると 発送処理に 回るんだ稻 ? 必ず入力するしくみをつくる データの定型化そして電子化ができれば、自動化まではあと一歩です。定型化され た電子データならばプログラム処理は用意です。既存システムも活用できるでしょ う。また、コンピュータは定型データを扱うのが得意です。蓄積したデータをもとに ダイレクトメールを発送したり、全体の販売傾向を探ったりとさまざまな形で活かす ことができるでしよう。 図 2-9 ・そしてデータの定型化・デジタル化 今のところは手作業。 でもデータはパソコンに 入っているよ 0 定型化された デジタルデータは 必ず自動化できる ! すべてコンピュータで 処理しています ! . 丿 こんなことが できるかも ・在庫管理と連動 ・発送手続きと連動 ・在庫の情報を web ページにフィードバック ・電話受付時も同じ情報が使える ・発注処理と連動 ・データ分析 ー元化 例 : 蓄積したデータをもとにダイレクトメールを発送 全体での販売傾向→ Web サイトやカタログ作りに反映 個人ことの販売傾向→傾向に合わせたダイレクトメールを自動生成 0 0

要となります。 図 5-20 ・データの規模を考えて選択することが大切 そもそもボクには 車は不要かも ? 自転車でいいよ。 も一 .4 5.3 データベースサーバ データベースの規模の目安の 1 つが登録件数です。数千件程度なら小規模用、数万 ~ 数十万件なら中規模、数百万件を考えるならば大規模システムとみなすことができ るでしよう。 小規模なシステムを前提としたデータベースソフトで、数十万 ~ 数百万件のデータ を扱うのは、たとえ登録が可能であっても現実的ではありません。 大規模データベースの場合、データベースサーバを動かすハードウェアの選定も重 めちやめちゃ速いよ ! でもチューンナップに 専門知識が必要だよ ! でも専門家が いるよ ! 小回りがきくよ。 すぐに運転もできる。 でも長距離はしんどいかな ? 大量に運べるよ。 荷物をちょっとしか 運ばないなら無駄かも ? このほかの判断ポイントがアクセス数です。 Web サイトで扱っている内容によっ て、アクセス数は大きく異なります。 このとき、同時に多数のアクセスを " さばく " 必要があるかどうかを考慮しましょ つ。たとえば、商品リストを管理するデータベースシステムでも、洋服のように、カ まり重要ではありません。一方、書籍や CD のような商品の場合は、迅速で柔軟なキ タログを並べてそこから選ぶタイプの商品ならば、ユーザによるオンライン検索はあ 万 ~ 数百万円まで、さまざまな価格の製品があります。 コストの 1 つが導入コスト、つまりソフト自身の価格です。フリーのものから、数 ・コスト ーワード検索が必要です。

第 8 章 セキュリティ Web アプリケーション開発上のポイント 暗号化でデータを守り、ファイアウォールでサーバを守っても、 Web アプリケーシ ョン自体がセキュリティホール ( セキュリティ上の弱点 ) となってしまっては意味が ありません。暗号を強力なものにするのも大切かもしれませんが、それ以前の問題と して、システムの穴となるプログラムを作らないようにするための注意が必要です。 システムを攻撃しようという人は、必ず、システムの最も弱い箇所を攻撃します * 。 たとえば、ファイアウォールそのものを攻撃するよりも、ファイアウォール越しにア クセスできるサービスを攻撃するほうが簡単です。 図 8-13 ・穴を残さないことが大切 いらっしゃいませ このくらいやっとけば 崩せないだろう BOMB 立入禁止 こっちは 難しいかな 楽勝だぜ ・・・いくら壁を頑丈にしても、 ・何でも通してしまう窓口があったら意味がない ・セキュリティを考慮した開発 セキュリティ機能は、後からもある程度は追加できますが、最初から考慮しておく ほうがより堅牢なシステムが構築できます。暗号化が必要なプログラムならば、最初 から、どこで暗号化するかを考えた設計が大切です * 。 図 8-14 ・開発の初期からセキュリティを考慮する あー、ここ 暗号化したほうが いいかも ? じゃあ こっちもだ ここでチェックするように しておきましよう ここでチェックして おかないと おいおい。 こっちも通れるぞ じゃあ必ず この処理を通るように プログラムしよう この処理を通らないと いけないような しくみにしておこうね 【攻撃】「最も弱い場所 = 攻撃しやすい場所」とは限りません。特に、攻撃用のツールを簡単に入手できるようにな った現在、そのツールを使って片っ端から攻撃をかけてみるというスタイルが広く普及しています。 【設計】メンテナンスしやすさ、見通しのよさも重要です。特に、入力まわりや変数の扱いには細心の注意を払い ましよう。

第 8 章 セキュリティ ーセキゴリティの概要 顧客コミュニケーションや販売などの目的で Web サイトを運営したり、 Web を利 用した業務システムの導入を考えていく上で、セキュリティ管理はたいへん重要です。 ます第一に、データを守らねばなりません。これには、個人情報や企業情報の漏洩 を防ぐだけではなく、通信内容の改ざんを防ぐことも含まれます。 次に重要なのが、サーバなどを含めたサイト全体のセキュリティです。不正な侵入 によるコンテンツの書き換えや情報の窃取のほか、サーバをサービス不能な状態にす る攻撃への対策が必要です。 暗号化技術 インターネット上のデータは、通常、そのままの状態で回線上を流れます。住所や クレジットカード番号などの個人情報を扱う場合、データの暗号化を行なうことで、 安心して取り引きができるようになります。 Web プラウザ←→ Web サーバ間のデータを暗号化するには、 SS L (). 197 ) という 暗号化技術を使うのが一般的です。企業間の取り引きでは、 lPsec や VPN (Virtual Private Network : P. 203 ) も利用されます。 VPN は、インターネットの中にプライ べートなネットワークを仮想的に構築するための技術で、暗号化通信によって実現し ます。 これらのセキュリティ技術の核となっているのが、 " 公開鍵方式 " と呼ばれる暗号 化方式です。 図 8-1 ・インターネットと暗号化技術 インターネットには 0 誰でも自由に参加できる インターネットでは ・共通鍵と公開鍵 データがそのまま流れる データが盗まれたり、 改ざんされる可能性が 暗号化が必要 暗号化の際に用いられるキーワードは " 鍵 " と呼ばれます。データに対し鍵を使っ

ァータベースシステム 第 5 章 Web 同様、データベースにも、クライアントからの要求に応えてデータを提供する データベースサーバ * が存在します。データベースの規模が大きくなる場合、データ べースサーバの利用が必須となります。 図 5-19 ・簡易データベースとデータベースサーバ ァータベスサバ 簡易データベース えっと、 あのデータは・ プログラムの中で 直接データベースを 操作する ァータベースサーバ はいどうそ あのデータ くださーい データそのもの の操作は サーバにおまかせ ・サーバは同じマシン ではなくてもよい ( 負荷分散が可能 ) 選定のポイント システムが複雑になるにつれ、知るべきこと・やるべきことが増えます。また、導 入はもちろん運用・メンテナンスにもコストがかかります。 データベースシステムが本当に必要かどうかも含めて、データベースシステムの構 築にはなにが必要かを判断することが大切です。 ・規模・機能 車は乗用車から大型トラックなど用途ごとに種類が分かれています。同じように データベースシステムも用途によって向き不向きがあります。データベースシステム の場合、機能のほかに、規模に合わせた選択が重要です。 【データベースサーバ】 web サーバと同じマシンで動かすことができます。大規模システムの場合は、負荷分散の ために別のマシンで使います。 136

おわりに 逸脱しないようにする HTML に限らず、プログラムはいろいろな " 工夫 " ができます。使えるものを最大 限利用することは大切ですが、本来の目的から逸脱した使い方をしていると、身動き がとれなくなります。 たとえば、 HTML に頼りすぎたサイトデザインは、新たな環境への対応がとりにく くなります。 Web プラウザには流行りすたりがあるし、主要プラウザといえどバージ ョンアップは必すあるので、特定プラウザの特定バージョンに依存した作りになって いると、多くのユーザを逃してしまうだけではなく、思わぬ反感を買うことさえあり ます。 スクリプトや CGI プログラムにしても、あまりトリッキーなことをせず、多少煩わ しくとも正当なやり方を守ることで、最終的にはラクができます。ただし、現状に合 わせる、あるいは当座をしのぐ柔軟さも、時には必要です。 重要なのは " データ " システムを構築する上で、何よりも重要なのはデータです。基礎となるデータさえ しつかりしていれば、ほかはどうにでもなるものです。通販サイトや情報など、デー タベースがキーとなるサイトを運営する場合、多少煩わしくとも、使い回ししやすく 堅牢なデータ設計を心がけましよう。特に RDB の場合、データ設計の指南書が多数 出ているので、ぜひ参考にしてください。 また、 " コンテンツ系 " と呼ばれる文書主体のサイトでも、場当たりなマークアップ ( タグ付け ) ではなく、加工しやすい状態にしておくことで、再利用がラクになりま す。サイトの移転やリニューアル、紙媒体へ移す、携帯端末用のサイトを作るなど、 サイト全体の加工が必要になるケースはいろいろあります。この場合、 XML にして おくのが理想的かもしれませんが、たとえば、 " 1 文を 1 行にしておく " や、日記ならば " 日と日の区切りにマークを入れておく " 程度でも、加工は驚くほどラクになります。 使い勝手を考える 自分とまったく同じ環境を持っている人はいません。同じパソコン・同じ OS を使 っていても、ディスプレイの特性・照明・視力は人それぞれです。そもそも使ってい る人間そのものが違います。微妙な色合い、独特な操作方法など、いくら自分にとっ 359

9.2 表 9-8 ・フォーム HTML (HyperText Markup Language) form input button select option optgroup textarea Object fieldset end フォーム fieldset によるフォームグループのタイトル 必須 フォームコントロールをグループ化する。タイトルを定義する厄 gend 要素が 埋め込みオブジェクト。アプレットや ActiveX などを埋め込む ( フォームコントロール ) 複数行入力可能な入力フォーム ( フォームコントロール ) 文字列とコントロールを関連づける ( フォームコントロール ) 選択肢 (option) をグループ化する ( フォームコントロール ) セレクトボックス (select) 内の選択肢 option で記述する。 ( フォームコントロール ) セレクトボックスを表示する。それぞれの選択肢は く / button > で囲まれた部分 ) がボタン上に表示される ( フォームコントロール ) ボタンを作る。 button 要素の内容 (<button>— フィールドが表示される ルの種類は type 属性で指定し、たとえば type = text ならばテキスト入力用の ( フォームコントロール ) テキスト入力やボタンなどを表示する。コントロー olumn 仕様を確認しよう HTML でこのような書き方はできるのだろうか ? ということを確かめるには、主要 ブラウザでの動作を見るだけではなく、 W3C が定めた仕様を確認することが大切です。 ブラウザは、とにかく表示できることが重要であり、文法などに多少問題があっても できるかきり処理しようとします。独自の解釈で表示内容を整形することもあるので 「こうするとうまくいく」と感じるような場合があっても、それに依存するべきではあり ません。 仕様と実装 ( 実際の動き ) が一致しているとは限らないというのも事実です。実装に沿 った柔軟なテータ作りも時には必要ですが、仕様から逸脱しすきないよう心がけること でデータを長持ちさせることができます。 資料 HTML 4.01 Specification : http://www.w3.0 「 g/TR/htm14/ CSS2 Specification : http://www.w3.org/TR/CSS2/ msdn online Web Workshop (Microsoft 社 ) http://msdn.microsoft.com/workshop/ TechnicaI Manuals and Notes (Netscape Communications 社 ) http://develope 「.netscape.com/docs/manuals/ 23 /

おわりに ふたたび「なにが必要か ? 」 web アプリケーションには、本書で取り上げてきたようにさまざまな技術が絡ん できます。それらの技術を利用すれば、多種多様なことが可能になります。そこでま ず、「なにが必要か ? 」「なにをやりたいか ? 」「どの程度のものが必要か ? 」といった点 を見極めることが最も重要となります。 汎用性はどこまで必要か ? 一般的に、汎用性の高いものよりもターゲットを絞ったもののほうが効率がよく、 扱いやすくなります。しかし、ターゲットが絞られたものは拡張性に乏しく、新たな ことをしようというときに思わぬ足かせともなりかねません。 汎用性は大切です。しかし、どこまで汎用的である必要があるのかは見極める必要 があります。たとえば、汎用性が低くても、汎用的な形に変換できる、あるいは汎用 性のあるものと連携できるのであれば、さしたる問題とはならないかもしれません。 安全性はどこまで必要か ? 安全であるに越したことはないのはもちろんですが、過剰な防御は処理速度や使い 勝手を犠牲にすることにもつながります。安全性が高いものは、機構が複雑なため、 構築が煩雑になり、導入・維持にコストがかかりがちだという面を忘れないようにし ましよう。 予算の関係でハードウェアの信頼性を上げられない場合は、バックアップを強化す るなど、対策はいろいろあります。クラック対策は確かに大切ですが、クラックされ 355

10.2 ・要素は必ず入れ子になるようにする XHTML (eXtensible HyperText Markup Language) 要素が必ず入れ子になっている必要があります。 HTML でも、要素は必す入れ子になっている必要がありましたが、 web プラウザ では入れ子になっていない状態でも " それなりに " 表示されていたので注意が必要で す。 ・要素の例 <p>XHTML ( まく Strong>XML です。く /P> く /strong> ← 間違い 入れ子になっていない く P>XHTML ( まく strong>XML ですく /strong>o く /P> ←正しい 終了タグを省略することはできません。 ・終了タグを省略しない します。 HTML と違い、 html 要素は省略できません * 。 の子要素となります。 XHTML では html 要素 (<html>—</html>) をルート要素と なお、 XML では、文書につき 1 つのルート要素があり、すべての要素はルート要素 HTML では、 li 要素のように終了タグが省略できる要素もありますが、 XHTML で はすべての終了タグが省略不可となっています。 ・終了タグの例 く > く 1 土 > 要素が必す入れ子になるようにする く 1 土 > 終了タグを省略しない く / ul > く > く 1 土 > 要素が必ず入れ子になるようにするく / li > く 1 土 > 終了タグを省略しないく / 1 土 > く / ul > 【 html 要素】 HTM L でも省略しないことが推奨されています。 ←間違い ( 行末のく / ⅱ > がない ) ←正しい 291