Macintosh Developer Online (MDOnline)

2001年8月9日発行号 - 旧版WOのサポート

関東地方はずっと涼しかったのですけど、今日の午後からけっこう暑くなってきていて、急に汗ばんでしまっています。夏が戻ってきたかのようです。世の中は夏休みモードになっているか、あるいはなりそうかという段階のようで、スピード感が落ちてきたような感触がありますね。で、MDOnlineもいちおう夏休みモードにそろそろ突入します。聞くところによると、MacWIREさんは来週はあっさりお休みということだそうですので（まだ言ってはいけなかったかな？）、来週はMDOnlineは発行頻度を落とします。ただ、実はいろいろ仕事があって実際には休めなかったりするのですけど（苦笑）。今週の土曜日までは通常とおり発行して、来週は2回程度の発行にしようかと思います。よろしくお願いします。
WebObjectsの記事はなんか体力使いますね（笑）。なんていうか、流れに乗った説明ってすごく難しいのはオブジェクト指向の特徴なんですけど、どこまで説明できているか心配なところでもあります。今日は体力を使い果たしたので、前文はこのへんで。そうそう、WebObjectsのトライアルCDはまだありますから、どうぞ御応募ください。
（新居雅行 msyk@mdonline.jp）

TIL》旧バージョンのWebObejctsの販売と技術サポートを年内に終了する予定

旧バージョンのWebObjectsについてのサポート終了に関する通知がTech Info Libraryに掲載された。WebObjectsはVer.5.0と4.5.1が最新版としてこれらのサポートは継続される。Ver.4.5についてはすでに販売は中止されているが、技術サポートは2001年11月1日をもって終了となる。なお、Ver.4.5.1へのアップデートも9月28日で終了する。Ver.4.5.1の技術サポートとアップデートは今後も継続される。また、Ver.4.0.1の販売と技術サポートは、2001年12月31日で終了する。

関連リンク：WebObjects 4.5, 4.0.1: サポート終了のお知らせ
カテゴリ：Tech Info Library-J, WebObjects

WebObjects 5とOpenBaseを使ってみる／5.データベースの内容をリスト表示する(1)

OpenBase上に作った住所録のデータベースを、WebObjectsのWebアプリケーションにより、ブラウザから参照したり、入力できるようにするということを、今回からしばらく行う。目標とするのは、2つのページを作ることだ。1つはデータベースの内容を一覧するためのリスト表示ページ、もう1つは入力を行うためのフォームを含むページである。もちろん、実用的にはいろいろ細かな機能は設定しないといけないが、WebObjectsとデータベースの連動を見るために、非常にシンプルな機能に制限して作っていくことにしよう。
まず、前回までのところで、EOModelerを使って、住所録データベースのモデルは作成されている。このモデルは、もちろん、WebObjectsのアプリケーションが使って、実際のデータベースアクセスを行うのであるが、前回も説明したように、モデル化によって、データベースの中身はオブジェクトとして扱えるのである。ただ、これは全体的な話だ。具体的にツールでどうなるのだという話になると、若干のイメージの違いが出るかも知れない。
たとえば、Visual BasicやJDBCのプログラムでも、ある意味ではフェッチしたテーブルの内容はオブジェクトである。手続き言語的に書くのであまりオブジェクトという雰囲気はないのだが（笑）、取り出したデータはオブジェクト的に扱える。これらの枠組でのアプリケーション作成となると、とにかくパターンはあるとしても、そうした接続、SQL実行、データの取り出し…といった一連のプロセスを逐一プログラムで書くというのがよく知られているパターンかもしれない。
しかしながら、WebObjectsでは見方を変えてほしい。データベースの中身が取りあえず、まとまってどーんと取り出せるのである。プログラムを書く場合はボトムアップ的にアクセスするとしたら、WebObjectsの場合は、ある種の設定をすると、それがすなわちデータベースから取り出した一連のデータであったり、あるいはデータベースにアクセスする足掛かりになったりするのである。そうした設定は簡単に行えるのが特徴なのである。意味的には、データベースから取り出したもの〜すなわちそれはオブジェクトなのだが、それが1つの変数なのである。変数というとプログラム的だが、WebObjectsでは「変数」に相当する設定を1つ加える。これがデータベースから取り出したデータそのものなのである。後は、それをページに配置するだけといテイストなのだ。もちろん、背後にはEOFのはたらきが隠されているとういことになるが、そうしたことはエキスパートになってから知ってもいいくらいで、開発ツール上での簡単な操作1つで、Webページ内でデータベースが利用できるということがとりあえず重要だろう。ただ、あまり簡単ばかりを強調しては誤解されるのだが、その操作そのものは、知っていないとまず分からないだろう。ウィザードとか、ツールボタンがあるわけではないからだ。やみくもにメニューを片っ端からやっていったところでうまくはいかない。まず、基本的なやり方の部分はしっかりと理解してもらいた。

もう1つWebObjectsの重要な概念を説明しておこう。Webアプリケーションだから、当然ながら、クライアントが見るのはWebページである。Webページと言えば、HTMLファイルといいたいところだが、WebObjectsではいわゆるHTMLファイルは作成しないに等しい。HTMLファイルはスタティックなものであるから、当然WebObjectsの用途とは相反するが、Webページというものの作り方の考え方が違うのである。Webページは、クライアントのリクエストがあると、一連の設定を使って、クライアントが見るためのWebページを生成する。これがまず1つのポイントだ。
生成するいうと難しそうだし、プログラムを作るのかと思うかも知れないが、WebObjectsでは基本的な定義はあらかじめ用意されているので、プログラムはかかなくても基本的にはWebページは生成可能だ。ただ、日本語を使うとなると、どうしても数行はかかないといけなくなる。ただ、決められたものだからそれは苦にはならないだろう。いずれにしても、プログラムはちょっとは書かないといけないけど、プログラムで根本的な定義を記述するわけではないのである。
WebObjectsがWebページを生成するための必要な設定は、実はいくつものファイルになっている。それらのファイルで、レイアウトと、データベースとのつながりなど、さまざまなものを定義する。いずれもテキストファイルなのである程度理解されれば、それを開いて見てもらいたいのだが、テキストを編集するわけではない。こうしたダイナミックに生成されるWebページの設定を行うためのツールとして、WebObjects Builderが用意されている。このツールを使って、諸設定を行うことで、ページの生成ができるようになるのである。
ページの定義は基本的にはHTMLではあるが、HTMLを編集するのではなく、それなりにページの形式で編集可能なツールとなっている。ただ、GoLiveやDreamweaverなどとくらべると編集機能的には弱いので、場合によってはこうしたツールとの併用を考える必要はあるだろう。また、こうしたツールとの併用をやりやすくする機能のサポートも欲しいところだが、それはさておき、データベースの内容を表示するとなると、データの中身によって結果的には表示結果は異なるので、あまりWYSIWYGである意味は薄いように思われる。むしろ、生成されるHTMLをある程度想定しながら、ページ設計ができるくらいでないと、なかなか実用的なWebページは作れないとも言えるかもしれない。WebObjects BuilderはHTMLを知らなくても利用はできるが、理想はHTMLを理解した上で使うのがいいと思われる。
HTMLにはデータベースアクセスのタグなどはない。だが、WebObjectsではデータベースへのアクセス結果を最終的にはWebページに展開することができる。そうしたことを可能にしているのが、「WebObjectsコンポーネント」である。WebObjects Builderでの作業をしているときに、HTMLの範疇からははずれるけど、WebObjectsコンポーネントという特別なコンポーネントをページに配置することができる。当然、WebObjectsコンポーネントはWebブラウザは解釈できないものだが、WebObjectsは、サーバ側でこれらのコンポーネントの設定をもとにして、データベースから取り出した値やそれを含むタグなどに置き換え、HTMLとしてWebブラウザに送り込むのである。こうした特殊なWebObjectsコンポーネントを埋め込み、データベースとの連係の設定を行うといのが、WebObjects Builderの重要な機能なのである。

以上、WebObjectsの重要な概念をなんとか説明してみたが、百聞は一見にしかずということで、とにかくWebObjectsを動かしてみよう。その後に、改めて読みなおしていただけると、より理解していただけるかもしれない。

まず、Project Builderを起動して、FileメニューからNew Projectを選択し、新しいプロジェクトを作成する。ウィザードが出てくるが、プロジェクトの種類はWebObjects Applicationを選択する。保存するディレクトリは適当な場所でかまわない。プロジェクト名も適当につけておく。ただ、プロジェクト名は最終的なアプリケーション利用のURLに出てくるので、URLとして問題ない名前にするのがいいだろう。

◇プロジェクトのひな形としてWebObjects Applicationを選択する
　

◇プロジェクトを保存するディレクトリを指定するとプロジェクトが作成される
　
（続く）

カテゴリ：データベース, WebObjects

WebObjects 5とOpenBaseを使ってみる／5.データベースの内容をリスト表示する(2)

こうして作られたプロジェクトを見てみよう。Web Componentsというグループに、Mainというグループがある。そのなかに、Main.java、Main.wo、Main.apiと3つの項目がある。これらをまとめて、実は1つのWebページを生成するための必要な定義なのである。つまりこれらは「Mainという名前のページ」を作成するための必要な定義がグループとしてまとめられている。これら1かたまりが1ページだということがまず重要だが、さらに、「Main」という名前も重要である。WebObjectsでは、ページの移行でこの名前を文字列として指定する。だから、この名前を参照することがある。

◇最初からMainページが用意されている
　

ところでこのMainというページだが、実は他のある部分の定義により、起動すると最初に表示されるページとして設定されている。言い変えれば、Webクライアントからアクセスすると、最初に表示されるページなのである。ページの追加方法は別の回で改めて説明するので、まずはこの最初に表示されるページに、住所録のデータ一覧機能を組み込むことにしよう。
Mainページの中身に、Main.woというグループ（フォルダ）がある。もちろん、その中にもファイルがあるのだが、このフォルダだけ、なぜかアクア色をしている。これら一連の定義を編集するのがWebObjects Builderであるが、このMain.woつまりアクア色のグループアイコンをダブルクリックすることで、この場合だと、Mainページの編集を行うためにWebObjects Builderが起動するのである。つまり、分かりやすく色をつけてくれているのだ。早速ダブルクリックして、WebObjects Builderを起動し、Mainページの編集にとりかかってみよう。最初はMainページは何も中身がないし、下側のリストでは、ApplicationとSessionというのが見えているだけである。
さっそく、データベースの中身をページで使うという設定を行ってみよう。前回に作成した、EOModelerのモデル定義ファイルを開く。左側に、データベースのテーブルを示す項目のPersonaladdressがあるので、それを、WebObjects BuilderのMainのウインドウ内にドラッグ&ドロップする

◇EOModelerの項目をページに取り込む
　

すると、次のように、Add Resourceというダイアログボックスがメッセージとして表示されるので、ここではYesボタンをクリックする。（以下の図の一部は実際の手順とは異なったファイル名になっている点は御容赦いただきたい。）これは、モデル定義ファイルを、プロジェクトに追加しますが、いいでしょうか？　という意味のダイアログボックスだ。

◇モデル定義をプロジェクトに組み込むかどうかを訪ねるダイアログボックス
　

すると、次に、Add Display Groupというダイアログボックスが出てきてNameというテキストフィールドがある。Nameはとりあえずは最初から入っている名前でいいだろう。そして、Add & Configureボタンをクリックする。

◇Display Groupを追加するダイアログボックスが表示される
　

このDisplay Groupというのは、いわば、データベースの取り出した中身を管理するオブジェクトの種類だと考えれば良い。このDisplay Groupは、Webページでデータベースから取り出した値の一覧を作ったり、あるいはデータベースに追加するなど多彩な機能があり、よく使われるオブジェクトなのである。それを要はここで作ってしまうのだが、EOModelerからドラッグ&ドロップで作成できるというわけだ。
さて、Display Groupを作る時には、必ず設定ダイアログボックスで設定を行う必要がある。Add & Configureボタンをクリックすると次のようなダイアログボックスが表示される。

◇Display Groupの設定ダイアログボックス
　

Entityはモデルの中のエンティティで、今回の場合は他のものは設定できない。ここで、Fetches on loadを選択しておく。これを選択しないと、データベースへの取り出し作業（フェッチ）は、プログラムを記述して行う必要がある。効率を高める場合などはこれはオフにするところかもしれいないが、今回は簡単のためにオンにしておこう。そして、Sortingは取り出したレコードをどのフィールドを手がかりに並べ替えるか指定するものだ。指定しなくてもいいが、ここではnameフィールドを指定した。Entories per batchはとりあえず0にしておくことで、全部のレコードを取り出すようである。通常は、ここに整数を指定して、たとえば10レコードずつフェッチするような動作をさせることができる。

以上の作業で、Mainページの下の欄に「personaladdressDisplayGroup」というものが加わった。これは、モデル定義にあるPersonalAddressテーブルをもとにしたDisplay Groupであり、具体的にはテーブルそのものとページとのつなぎの役目を行う。personaladdressDisplayGroupの項目をクリックすると、さらにいろいろな項目が出てくるが、その中にあるdisplayedObjectsをクリックすると、さらに右側に、テーブルのフィールド名が見えるのが分かるだろう。このあたりは、現実にはテーブルあるいはフィールドがオブジェクトとして利用できる状態になっているということも意味しているのではあるが、ともかく、Display Groupはデータベースとつながっているのは理解してもらえたと思う。

続いて、次のように操作をして、キーというものを定義する。これも結果的にはWebObjects内で利用できる変数を定義する。（WebObjectsではキーとはオブジェクトから値を取り出すキーワード的な意味合いのある重要な概念だが、とりあえずそういうものがあるとしておいてもらってしばらくはかまわないだろう。）Display Groupは、複数のレコードもともなうデータベースの中身的な変数であるが、ここで作るキーはその中にある1レコードを代表させるような変数として機能する。正確な表現ではないのだが、ここでは、一種のテーブルに対するカーソルのように機能するようなオブジェクトなのだ。後からDisplay Groupで取り出した一覧データをもとにして、一覧データを作る時、その1レコードずつのフィールドを指定するのに、ここで定義したキーを使う。
キーを定義するには、WebObjects Builderで、下側の分割された領域のうち、いちばん左の領域をcontrolキーを押しながらクリックし、表示されるメニューでAdd Key to Mainを選択する。すると、次のようなダイアログボックスが表示されるので、必要な設定を行う。

◇キーの設定を行うダイアログボックス
　

ここではキー名としては、Nameのテキストフィールドで「AddressKey」とキー入力した。そして、Typeの部分にあるドロップダウンリストで、データベースのテーブル名であるPersonaladdressを選択する。これはすでにオブジェクト化されたテーブルを利用するというか、テーブルの内容を代表させるようなキーとして機能させるのである。チェックボックスは、最初のAn instance variableをオンにしておくだけでいい。

こうして、AddressKeyというキーもMainページに加わった。このAddressキーも選択すると、右側の列にテーブルのフィールド名が見えている。

　

ここまででデータベースを利用する準備が整った。プロジェクトファイルのResourcesというグループを見てもらうと、モデル定義ファイルが加わっているのを見てもらえるだろう。これを見て、「なんだ単にプロジェクトに追加すればいいの」と思うかも知れないが、実はWebObjects Applicationのプロジェクトは若干複雑な構成になっている。ターゲットが3つあり、Javaのソースやあるいはモデル定義ファイルはそのうち、基本的にはApplication Serverというターゲットだけに加わるようにしないといけない。だから、もし、手作業で組み込んだ人はそういった設定に変えておく必要があるだろう。ただ、上記のように、プロジェクトを作成して、最初にプロジェクトとは別に作ってあるモデルファイルをドラッグ&ドロップすることで、適切な設定でプロジェクトに取り込まれるのである。この操作で流す方がおそらく手順的にはいちばんシンプルになるのじゃないかと思い、紹介をしたということである。次回は、実際にページにコンポーネントを配置しよう。

カテゴリ：

Windowsサーバを侵食するCode RedはMacのサーバやルータにも影響する

先月来、ウィルス騒ぎが大きくなっていることは、よく御存じだとは思う。そのうち、Code Redと呼ばれるワームは、Windows標準のWebサーバであるIIS（正確にはIISに含まれるインデックスサーバ）の機能不全部分をうまくついたワームとして報道されているため、Macintoshを使っている人は対岸の火事としか思っていないかもしれない。しかしながら、MacintoshサーバあるいはUNIXサーバを使っている場合には影響があるかもしれない。さらに、サーバを立てていないとしても常時接続を行っているのであれば、このワームの影響を受ける可能性があるので注意が必要だ。つまり、Windowsに関係なく、このワームは危険なのである。

◇「Code Red ワームに関する情報」新種の Code Red II に注意を
　http://www.ipa.go.jp/security/ciadr/vul/20010727codered.html

Code Redはあるサーバに感染をすると、さらに別のサーバに感染を起こすために、HTTPのリクエストを大量に別のサーバに送る。その大量のリクエストはIISに対して起こすというよりも、やみくもにリクエストを送るといった様相を示している。感染するのはIISだが、IISあるいはWindows以外のサーバに対してもアタックは試みるのである。公開しているWebサーバを持っている人は、Webのログを見てもらいたい。ちなみに、以下のものは、筆者が管理しているUNIXサーバのログにあったものだ。こんなGETリクエストがやってくる。

GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a

もちろん、default.idaファイルWebサーバにない場合にはウィルス感染は行われないが、まずはこうしたリクエストが大量にやってくることやあるいは処理上の問題で、ルータがハングアップしたりするといった症状は十分に考えられるし、実際、そうした被害は機種によっては出ているようだ。これについては対応となると、ルータの開発元にたよるしかない。たとえば、Yamahaの古いルータだとCode Redからのアクセスによってルータが落ちることがあるようだが、ファームウエアのアップデートで対応している。

◇RTシリーズのTCP/IPに関するFAQ
　http://www.rtpro.yamaha.co.jp/RT/FAQ/TCPIP/www-server-vulnerability.html

一方、Webサーバの方ではあるが、WebSTARやQuid Pro Quoなどで、URLリクエストが長いことから起因するエラーが発生し、サーバが落ちてしまうことがある。WebSTARのサポートを行っているアイ・ツゥからは「Code Red/Code Red IIに関して」として注意を促すメッセージが公開されている。また、WebSTARなどを含む、W*API対応のWebサーバでこうしたリクエストによる不具合が発生しないようにするプラグイン「Code Red Killer plug-in」がKen Maezono氏によって公開されている。Macintoshでサーバ運用をしている人は、こうした情報をチェックする必要があるだろう。なお、WebSTARなどではCode Redに感染するわけではない。攻撃を受けたサーバが落ちるといった問題に直面するのである。だから、WebSTARがこれが原因で落ちていても、「マシンからフォーマットして…」という必要はない。とりあえず前記の対策プラグインを入れるだけでほとんど問題は回避できるだろう。

◇Code Red/Code Red IIに関して
　http://www.i2j.com/news/01Aug.html#Aug02

◇Code Red Killer plug-in
　http://www.synapse.ne.jp/~kmaezono/CodeRed/

Apacheサーバについては、Code Redの攻撃があっても単にリクエストエラーになるだけで、障害は発生しないようだ（もっとも、ログが異様に増えるのは困ったものだが…）。
すでにCode Redの被害に会っている方は多いと思うが、このワームの威力はかなりのもので、今後も続く可能性は十分に考えられる。今は大丈夫でも、安心はしない方がいいと思われる。

カテゴリ：ネットワーク, サーバー製品, サーバ

Mac OS 9やMac OS Xでのスレッドのアーキテクチャを解説した文書が掲載

Technical Noteに、Mac OSでのスレッドのアーキテクチャを解説した文書が掲載されている。Mac OS 9およびMac OS Xのいずれもカバーしており、全体的な概略が理解できるだろう。Mac OS 9では、Thread Managerを使うものと、nanokernelベースのMP Taskの2種類がある。Mac OS 9でのプロセスについての動作が非常に詳しく掲載されており、通常の場合とMT Taskが稼動している場合での説明がある。Mac OS Xには5つのスレッドのAPIが用意されている。Machのスレッドがシステムの一番奥深いレベルで、その上位レイヤにPOSIXのスレッド（pthreads）、さらにその上位にCocoaのスレッド（NSThreads）がある。また、CarbonのMP TaskやThread Maanagerは、いずれもpthreadsの上位レイヤで稼動している。これらのどれを選択するべきかといったことや、スレッドの動作、APIを混合して使う場合の注意などが記載されている。CarbonでのI/Oレベルの割り込みに、Mac OS Xではスレッドが使われるなどの動作上の違いについても記載されている。
（スレッド：マルチタスクを実現するためのOSが提供する機能。たとえば、1つのアプリケーションの中で、複数の処理を並行的に稼動させる場合、プロセスを「スレッド」として生成して実行させる。複雑なマルチタスク処理でも、スレッド関連のAPIを利用すると、一般には非常に簡単に並行的に動作する複数のプロセスを稼動させることができる。その意味ではスレッドは、プログラミング上の手法だとも言えるだろう。）

関連リンク：TN2028: Threading Architectures
カテゴリ：Technote, Mac OS X, Mac OS 9