2001年2月12日、サーチエンジンの米Google 社は、 ニュースグループの資産などを持つ米Deja.com を 買収したことを発表した。
Google は、検索結果といっしょにキャッシュへのリンクが表示され、 リンク切れによってページが見えないことがないのが特徴の検索サイト。 それだけでなく、検索を専門にしているだけあって、 Yahoo や Infoseek といったポータルサイトに比べて、 かなり良質の検索結果を出すのだが、 さらに磨きをかけて良くなりそうだ。
これまでのポータルサイトでは、掲示板 （HTML 版のニュースグループ）の内容が検索で引っかかることが あったが、ニュースグループの内容が引っかかることは無かった。 専門性を持つ分野において良質の検索結果を得るには、 活発な掲示板（メーリングリスト）を検索するのがよい。 たとえば、プログラマ向けの掲示板サイトで検索すると、 知りたい情報にあっさり引っかかる。 今回の Google が行った買収により、このような あっさり感が誰でも利用できるようになるかもしれない。
現在、Deja.com で、メーリングリストの Google 検索が β版としてできる。試しに日本語で入力したところ、 全く引っかからなかった。 やはり、しばらくは英語のみであろう。
ところで、貴方（プログラマ）は、良質の検索が使える 掲示板サイトを使っているだろうか？ 以前、このページに書いたのだが、開発分野が広くなるにつれ、 プログラマには、知識の多さよりも、解決方法を検索する 能力が必要となる。 良い掲示板サイトを知っているか知らないかで、 開発の実力が大きく変わるとも言えるだろう。 私の場合、Visual C++ に関して利用している掲示板サイトは、 ActyNet の VC++ML である。マニュアルやヘルプに答えを求めて 苦労している方は、ぜひ使ってほしい。
2001年2月6日、米Microsodt社がラスベガスで開催した 「Microsoft Windows Embedded Developers Conference」 の基調講演で社長兼CEOのSteve Ballmer氏は、 「今後5年間ないし10年間で、組み込みシステム市場が 最重要分野の一角となる。」と語り、 ハードウェアベンダとの協力体制を敷くことにより、 シェアを30％程度にまで押し上げることが可能であるとした。
この会議の中で「Windows Embedded Strategic Silicon Alliance (WESSA)」と呼ぶハードウェアベンダの団体の結成を 発表した。この団体に加盟しているベンダに、 次期 Windosw NT Embedded（Windows XP Embedded）や 次期 Windows CE（コードネーム Talisker）の ソースコードを公開し、 ベンダ固有のマイクロプロセサの性能をフルに出せるように するためと、組み込み機器の市場投入を加速 （開発期間の短縮）をするための協力体制を敷く。
WESSA のメンバーになっている日本の企業は、 米で人気があり、HP Jornada に組み込まれている SH シリーズ（MPU）を持つ日立製作所、 日本の主な PocketPC や HandheldPC に組み込まれている Vr シリーズ（MPU）を持つ NEC （米NEC Electronics は今回のカンファレンスに合わせて 新製品 Vr4131 を発表）、 TX System RISC を持つ東芝がある。 海外の企業となると、英ARMや米Intelなどを含め、13社もいる。
CE は、Intel の寡占状態ではなく、世界各国の様々なベンダが ひしめきあっているのだが、すべてを Microsoft のみが サポートしていくのは難しいため、今回のソースの公開と なったともも考えられる。しかし、OS をベンダが改良した場合、 これが Microsoft のものと言えるのか曖昧になってくるため、 アーキテクチャのライセンス提供という形になるであろう。 現に、CE のソースは、オープンソースではないので、 独自の機能を加えることはできない。 これは、i モードの Java に独自の API を加えてもよいという、 NTT Docomo の戦略と異なる。
ソフトウェア開発会社にとって、ソースは財産であるため、 簡単に盗まれることがないように非公開にすることが多い。 現に、オープンソースにしたソフト（特にGNU関係）は、 ソフト自体が商売にならないケースが多い。 しかし、協力関係になった相手にはソースを公開しないと、 その部分がブラックボックスとなり、バグを駆除するときなど 開発の弊害になることが多い。 Microsoft は、その矛盾を踏まえた ビジネスモデルを模索しているようにも思える。
2001年2月1日、EJB（Enterprise Java Beans） コンポーネントに関するコンソーシアムは、 EJB アプリサーバで動作可能なコンポーネントの ガイドライン「ポータブルコンポーネント規約第１版」 を公開した。
EJB は、RMI（Remote Method Invocation： Java プログラム間、マシン間メソッド呼び出し）に 信頼性を上げる仕組みと、トランザクション処理などを 加えたものである。簡単に言えば、 データベースのサーバで動く Java プログラムを 再利用可能なコンポーネントにする技術である。 機能としては、分散オブジェクト技術である DCOM(Microsft)や CORBA （Object Management Group）と同じであるが、 Java に特化しているため扱いやすい。
このように EJB は、Java オブジェクトに ポータビリティ（相互運用性）を持たせる技術であるが、 Java オブジェクト（Enterprise Beans）自身が、 ポータビリティを無くしてしまう機能を持つことができるため、 これを制限する必要がある。 これをまとめたのが、今回発表されたガイドラインである。
ガイドラインの内容は、「プロセス境界に依存した 操作の禁止」、「セキュリティ情報へのアクセスの禁止」 のように、EJB の持っている機能をそのまま逆らったものが多く、 EJB を理解していれば、それほど難しいものではない。
全体的に「〜をしてはいけない」のような 禁止項目が並べられているが、単に禁止しているだけでなく、 回避方法まで紹介されているとことがよくできている。 しかし、専門用語やクラス名がたくさん出ているので、 EJB をよく理解している者しか理解できない可能性が高い。
ガイドラインができたばかりなので仕方ないが、 将来的には、コンパイラやソース解析ツールの警告で、 自動的に禁止項目と一致する操作があることを 見つけ出すことができるようにするか、 禁止項目の回避方法を、 EJB サーバの VM（Virtual Machine）が エミュレーションすれば、 より確実に分散環境ができあがるだろう。
しかし、EJB サーバ（ミドルウェア） がいくつか発表されるわりには、 Enterprise Beans（コンポーネント）自体の供給が 需要に追いつかないという現状がある。 これは、データベース・アプリケーションのデータ （ユーザ定義型）に汎用性を持たせことが難しい、 すなわち、汎用的なコンポーネントにできるものが少ないことが、 普及しない１つの原因ではないかと私は考えている。 そうなると、メソッドのオーバーライドなどを用いて 多少のカスタマイズをしなければ再利用ができない。 しかし、カスタマイズするには、 オーバーライドする前のメソッドのソースが オープンでなければ、どのようにカスタマイズすればいいか 理解するのに時間がかかってしまい、 開発効率の向上にはつながらない。 フリーのオープンソースの文化が育ちにくい エンタープライズの分野では、 コンポーネントが活発に流通することは、 期待できないのではないかと私は考えている。
今回のガイドラインは、 EJB をミドルウェアとして使うときの 参考になるのだろう。