活動報告


●第91回セミナー(Windows DNAコンソーシアム主催)実施報告

日 時:1999年5月12日(水)13.30〜18.10
場 所:マイクロソフト新宿オフイス17Fセミナールーム
参加人員: 77名
テーマ:「COM+」
 第1部 『COM+を理解するためのCOM/DCOM再入門』
     マイクロソフト株式会社 ソリューションデベロッパー事業部
     ソリューションテクノロジー部 担当課長 野村 一行 様
 第2部 『MTSからCOM+への展望』
     (1)「MTSの基本概念とアーキテクチャ」
     同 上  野村 一行 様
     (2)「MTSプログラミングモデルとCOM+への導入」
     マイクロソフト株式会社 ソリューションデベロッパー事業部
     ソリューションテクノロジー部 西谷 亮 様
     まとめ マイクロソフト株式会社 ソリューションデベロッパー事業部
     ソリューションテクノロジー部 次長 萩原 正義 様

 今回のセミナーは、久しぶりの分散コンピューティングの標準技術であるCOMをテーマにして行われました。内容的にも高度で講義にも熱がこもり、また最後には、萩原正義様による「まとめ」もあり、予定を1時間半も超えて行われました。

セミナー会場

 第1部では野村講師から、分散コンピューティングの標準技術であるCOM/DCOMのアーキテクチャ、機能及びプログラミングモデルをもう一度振り返り、COM+の概念の理解へと導くというお話がありました。


 はじめに今回のセッションの意義として、「わざわざ入門でなくて再入門と名づけているのは今後Windows 2000になってCOM+という新しいテクノロジーが出てくるが、基本的には現状のCOM/DCOM、MTSの延長にあるのでもう一度その辺のテクノロジー、概念、アーキテクチャをおさらいして、COM+の全ての概念が新しいのではないということをお伝えするのと、改めてCOM+の開発をする時にとっかかりのアーキテクチャ、概念を頭に入れながら開発していただくことを目的にしている。セッションスライドのハンズアウトはかなり厚いが、ご出席の方に理解していただくだけではなくて、是非これを持ち帰って会社の中でも他の方に回していただきたい」とのおことわりがありました。
 また、出席の皆さんに挙手によりお伺いしたところ、MTS(Microsoft Transaction Server)については1/3強の方が初めてであり、COMに関しては多くの方が既にご存知だということです。

 まず、「COMの特徴」として、1つ目はCOMと一言に言うけれども2つの面(スペックと実装)がある。一つはスペックであり皆さんが作るコンポーネントをCOM対応にする仕様の部分が厳しく規定されている。それによって全然顔も知らない人達が作ったコンポーネントを何の矛盾もなく連携させるということが可能になっている。また、ユーザー定義コンポーネントを動かすための実装部分が当然必要である。それはマイクロソフト側から提供されているもので、よく皆さんがいうところのCOMがこの部分である。当然COMの上でコンポーネントを動かす仕様の部分があるけれど、勿論仕様だけではプログラムは動かないのでマイクロソフトが定義しているCOMのランタイムの部分が当然存在することになる。2つ目の特徴として、COMは、クライアントとコンポーネント間を連携させるためのバイナリーの標準である。これはC++のオブジェクト指向言語と違ってソースコードが無くてもバイナリーレベルでのコンポーネントがオブジェクト指向の考え方によって連携ができるということになる。一つはコンポーネントの場所を特定したり、作成方法を標準化しているということであったり、オブジェクト同志が通信するための標準化を決めてあったり、またバイナリー標準ということで特定のプログラミング言語に依存しないという形の特徴を備えているが、そのための言語バインド(言語非存なプログラミングモデル)の標準というものを持っているし、また一旦コンポーネントを作ったら二度とバージョンアップしないというわけではないのでアップグレードするための標準といったものも提供している。3つ目の特徴は、COMは実装とインターフェイスを分離したプログラミングモデルを採用しており、オブジェクト指向のカプセル化の概念をバイナリーのレベルで実現している。

 次に「オブジェクト技術はなぜ必要か?」では、必ずしもオブジェクト指向が必要でないということも当然有り得るわけである。例えばソケットプログラミングはオブジェクトの方が早く動くということはないので、それに見合った対価というものがないと当然オブジェクト指向を採用する意義がない。オブジェクト技術がなぜ必要かを一言で言うと、“少ない投資で多くの結果をなす”ということになる。
 @マイクロソフトはDNS(Digital Nervous System)というコンセプトを提供しているが、企業情報システムは企業にとって一種の神経系であることは間違いない状況である。つまり企業の成長やビジネス環境の変化に企業情報システムが適合できないと企業の組織そのものがおかしくなってしまう。
 A 企業情報システムにはより効率的で外部の環境の変化にも適合できるシステムが必要である。それには、何よりも容易な再利用性であり、既存の資産は捨てられないからそれを生かしつつ新技術を取り入れることができる。オブジェクト技術はこのようなテクノロジーを非常に上手くやっている。また、カプセル化による実装の隠蔽ということでは、そのコンポーネントを使うユーザーや管理者の方々に頻繁に機能が上がったからといって再学習を要求していたら何時まで経ってもシステムの運営ができないから、そういった実装の詳細を隠しながら、実はコンポーネントは徐々にアップグレードしていくというアプローチを取ることによって柔軟なシステムが早く構築できることになる。

 「分散オブジェクト技術の要件」では、オブジェクト技術を適用するのに、C++やJavaといったオブジェクト指向言語でプログラムを書くことの他にどのようなものが必要かというと、当然ローカルな環境で分散オブジェクト技術を当てはめようとしても無理なわけであって、3つの分散オブジェクト技術(リソースの共有、ホスト間のメソッド呼び出し、オブジェクトの管理)が必要であると、それぞれの説明がありました。
 分散オブジェクト技術の要件をWindowsのアーキテクチャの中でシステムレベルで提供しようというモデルがWindows DNAという3階層アーキテクチャによる分散モデルということになる。これは、全てのレイヤーに渡ってコンポーネントオブジェクトモデルの考え方が適用できるので、統合とイノベーションが非常に容易である。どこかのレイヤーだけの機能を変えることによってシステム全体のアップグレードが図れるのが一般的な3階層アーキテクチャの特長であるが、Windows DNAもその特長を持っている。また、今日使われているツール(Microsoft Visual StudioやDelphiなどさまざまな言語ツール)がCOMに対応することによってWindows DNA対応プログラムが簡単に作れるといった特長がある。また、COMを扱っているので言語非依存形のアーキテクチャとなっている。
 続いて、Windows DNA自体のアーキテクチャはCOM+を出したところで終りというわけではなく、将来的に今こういうことを考えているというお話がありました。プレゼンテーションロジックのところが、Forms+という名前のアーキテクチャになり、今のHTMLベースのプログラミングモデルとWin32 APIプログラミングモデルとは全く別になっている。これは、歴史的な経緯も違うし、XMLという新しいテクノロジーもどんどん入っているということで、統合が取りきれていないという状況であるが、Forms+の段階になってきてインターネットプログラミングとWin32 APIプログラミングを統合しようとする試みがなされている。それからStorage+が今ユニバーサルデータアクセスと呼ばれる統一的なデータアクセスのレイヤのところにあたるがここもかなり大きく変わる予定であり、プログラミングモデルとしてはOLEDBをそのまま踏襲する予定になっているが、スキーマの統合を図っているのが一番大きい特長であると思われる。マイクロソフトの製品の中でもExchangeとかActive Directoryなどのように全然別のスキーマ体系を持っている製品もあり、またサーバー製品においてもその意味が同じでありながら、まるきりスキーマ体系が違うということで情報の意味の交換ができないという状況を考えてStorage+ではスキーマの定義の交換の仕組みを見直すことを考えている。タイムラインとしては、Windows 2000では当然間に合わないので次のバージョンということになるが、このようにWindows DNAそのものも進化しているし、また今後も進化していく。我々のアプローチとしてはあくまでもCOMという概念の上にWindows DNAも成り立っているので、COMを今しっかり理解していただくことによってWindows DNAの将来がどのように変わっても柔軟に対応できるのではないかと思う。

 本題では、@インターフェイスと実装の分離、A作成とアクティベーション、Bオブジェクトとの通信、C複数クライアントからの再入、Dライフタイム管理、と大変熱の入った説明が86枚のスライドにより、休憩をはさんで行われました。
 参考文献として、Essential COM(Don Box著、アスキー出版局)、インサイドCOMアーキテクチャ(萩原正義著、DDJ日本語版1998/1,3,5,9,12月号、1999/3月号)、COMによる分散アプリケーション開発技法(Ted Pattison著、日経BP出版センター)、 Designing Component-based Applications(Marry Kirtland著、 Microsoft Press )、Inside DCOM(Guy Eddon/Henry Eddon著、アスキー出版局)が示されました。

 第2部では、野村、西谷両講師から3階層アーキテクチャによる分散アプリケーション開発の基幹技術である、MTSのアーキテクチャ及びプログラミングモデルについてサンプルコードを交えた解説がありました。また、COM+が提供するさまざまな新機能についてデモを交えながらの紹介がありました。

 第2部 (1)では、引き続き野村講師から、何故COMとDCOMの他にMTS(Transaction サーバーという一種の製品であるが逆にテクノロジーであると読み替えてもかまわないと思う)が何故必要かというとWindows DNA環境下、つまり3階層のクライアントアーキテクチャの分散環境でのサーバーの要件というのはいくつか現状のCOMとDCOMだけではプログラマ側の負担がかなり大きい部分があるのでMTSのサポートが必要となってくる、ということで、@MTSの基本概念、AMTSアーキテクチャについてお話がありました。
 これらは、「なぜMTSか?」、「MTSとは何か?」、「ORBとしてのMTS」、「MTS内のオブジェクト作成」、「コンテキストラッパー」、「コンテキストオブジェクト」、「TPモニターとしてのMTS」、「コンポーネントベースのトランザクション」、「宣言的トランザクション属性」、「トランザクションの制御」、「DCOMサーバーとしてのMTS」、「コンカレンシ概念としてのアクティビティ」、「サブオブジェクトのアクティビティ参加」、「Just-In-Time(JIT)アクティベーション」、「JITアクティベーションによるオブジェクトの解放」、「MTSセキュリティモデル」、「宣言的セキュリティ」、「プログラム的セキュリティ」、「MTS環境でのステート管理」、「ステート管理の場所」、まとめとして「C++ vs COM vs MTS」(C++はオブジェクト指向テクノロジーにとってクラスの概念を導入したものであり、COMはクラスをインターフェイスと実装に分けて考えたものであり、またMTSは実装部分をふるまいとステートという形でプログラミングモデルを分けて考えたものである)と多岐にわたってお話いただきました。

 第2部 (2)では、西谷講師から、@MTSプログラミングモデル(プログラミングモデル、利用方法、コンポーネント管理オブジェクト)、ACOM+への導入(COM+とは、COM+における新しいサポート事項、COM+を利用したプログラミング)についてお話がありました。


 @ では、MTSにて提供されるオブジェクト群7つの内、IObjectContext、IsharedPropertyGroupManager、IObjectControl、ISecurityPropertyについて説明があり、デモとしてMTSを利用したトランザクションアプリケーションの例が示されました。コンポーネント管理オブジェクトは、MTSにおいて利用されるアプリケーション、コンポーネントおよびセキュリティをスクリプトエンジンから管理することができ、コンポーネントの自動管理の例として、MTSコンポーネントのインストールなどのデモがありました。
 A では、「COM+が何故必要とされるのか」では、相反したアプリケーション(より柔軟な管理モデル、開発の簡素化と開発経費削減、耐障害性能の強化、既存資産の利用、セキュリティ、など)に対する要求にこたえるためである。「COM+でサポートされる機能」にはさまざまな要求にこたえるために、COM+ 管理モデル、COM+ Event、COM+ Queued Component、Dynamic Load Balancing、IMDB(In-memory database)、Securityがあり、これらについての説明がありました。「COM+とは何か」というと、既存のCOMテクノロジーに対し、MTSの持っていたトランザクションサポートやセキュリティモデルなどを包括的に統合したもの“COM + MTS = COM+”であり、また、“COM + services = COM+”ということもできる。デモとして、IMDB、COM+ Component Adminについての例が示されました。

 更なる情報がCOM Web Siteの http://www.microsoft.com/japan/comhttp://www.microsoft.com/com、またMSDN Onlineの http://msdn.microsoft.com/http://www.microsoft.com/japan/developer/  にあるので参照して欲しい、とのことです。

 最後に「今回のセミナーのまとめ」が萩原正義様からありました。


 このセミナーにはいろいろなスキルを持たれた方が出席されているので、例えばVBの開発者にとって細かすぎる内容であったところもあると思うが、開発言語に依存しないところでの説明をしたい。
 まず前半のCOMの説明でいろいろ出てきた技術の一つにオブジェクト指向というソフトウエアの中では優れた概念があったが、それとCOMとどのような違いがあるのかというと、細かいAPIの説明、マーシャリング、アパートメントとか、マイクロソフトが提供している独自技術があるがもう少し一般的な説明をしたい。
 まず、Windows、UNIX、その他のメインフレームのOS上でオブジェクトを使ったソフトウエアの開発が非常に有効になってきているが、OS或いはそこで動くファイルシステムというのは基本的にはオブジェクトということを全く知らないわけである。つまりWindowsでもUNIXでもプログラムを動かす単位はプロセスであり、スレッドであり、データを納める所はファイルである。特にこのようなOSはオブジェクトを専用に動かすために作られているわけではなく、マルチメディアを表示するものもあればペリフェラルのコントロールをするものもある。従ってそこでオブジェクトを動かすためには何らかの工夫がいることになる。例えばセキュリティを考えると、OSが持っているセキュリティ機能というのはファイルに対するセキュリティ、OSが管理するリソースに対するセキュリティというのはあるが、オブジェクトに対するセキュリティというのは持っていない。従ってCOMはオブジェクトを単位としたセキュリティを提供しなければいけない、その他にもイベントもそうであるし、トランザクションもそうである。OSは基本的にトランザクションを並列処理で動かすためにはプロセスの同期はやるが、オブジェクトの単位としてはやらない。従ってオブジェクトシステムのCOMの機能というのはOSの同期システムにマッピングしてオブジェクト単位の同期を保証するような仕組みを用意しなければならない。これがCOMがやっているいろいろな機能の所以である。要はCOMのようなオブジェクトを作って開発しなければいけないといった利点があるからこそOSの持っていないものをCOMが肩代わりしてやっているということである。
 将来的にはどうなるかといえば、マイクロソフトはCOM、MTS、COM+というロードマップを持って発展していこうとしている。それがどういう形で我々は提供しなければいけないかというと(その一端は最後のデモでちょっとお見せしたが)、一つは基幹業務の中でこのようなシステムを使っていけるということである。従来ある既存のメインフレームとCOMの技術にどのような違いがあるかというと、トランザクション処理という機能に関していえばほとんど同程度のものを持っているが、開発の仕方は全く違う。基本的にメインフレームの技術は大規模システムに向いており、信頼性が高い。ハードウエア的に見ればパーソナルコンピュータが提供するより数段高い信頼性を持っている、そういったところに違いはそれぞれある。ソフトウエアの観念からいって根本的に違いのあるのは、メインフレームではリソース管理に対して非常に厳密であることである。つまりある業務アプリケーションを動かす上でどれだけのデータが必要なのか、どれだけのメモリ容量が必要なのかを厳密にコントロールできるが、COM+が提供する技術ではそのようなものを持っていない。つまりそれぞれのトランザクションサービスで実現される業務の中でどれだけメモリが使えるのかということを厳密にコントロールする手段を持っていない。そういう意味ではメインフレームを専門にやっている開発者から見ると、リソース管理に関して非常に甘いというような指摘を受ける点がある。しかし、そういった点は徐々に解決していく方向にある。つまり今ないものは将来そのまま出てくる可能性があるということで皆さんの記憶の中に留めて欲しいと思う。その一部として今回少し説明がなかったが、オブジェクトプーリングの中でオブジェクトを予めどれだけ作っていくかという指定がExplorerの中でできる(メインフレームの中で一つコントロールのための属性を用意しているということであるが)といったものが将来増えていくことになる。
 もう一つCOM+で理解しなければいけないのは、先ほど西谷のセッションで「COMとサービスがCOM+になった」という簡単な説明があったが厳密に言うとそうではない。つまりCOM+になっても従来あるCOMの技術は並列して使われる。例えば、COM+の中で機能として恩恵を受けるのはインプロセッサだけである。基本的にはExecutableやサービスが動くような従来あるCOMはそのまま動き続けるわけである。それから前半の説明にあったマーシャリングの技術、モニター、IDispatch、IConnectionPoint、ActiveXコントロールといったものはCOM+ではなく、従来あるCOMのまま生き続けることになる。従ってActiveXコントロールの開発をしている人達は今まで通りその開発を進められることは勿論できるが、COM+から直接的に利益を得ることはない。COM+になってもそこからもっと優れたものを得られるかというとそういうわけではない。COM+はあくまでも大規模システム用の基幹業務に向くためのサービスを提供するものである。
 COM+の将来はどうなるかと言うと、今回話したのはCOM+1.0であって、Windows 2000の最初のリリースの時にOSと共に出荷されるものである。COM+にはもう一つCOM+2.0というものがあり、ランタイムといわれる機能である。これになるとActiveXコントロールの開発者でも利益を得ることができる。出荷はWindows 2000が出た後になるが、時期は未定である。
 COM+2.0がどのようなものになるかというと、今回最初の説明の中で疑問になったのは例えばVBのプログラマから見て、NEWという演算子を使ってオブジェクトを生成した時に、それがそのままCOMのオブジェクトとして動くのが一番いいのであるが、先ほどNEWでデモをやっていたがあれが全てではなくて、CreateObjectというAPIを使ってオブジェクトを生成する仕組みもある。つまりCOMの中でいろいろな開発言語(JavaでもDelphiでもCOBOLでもいい)を使って、その中で簡単に通常のプログラムと同じようにCOMが開発できるようになることが最終的に目指す方向である。何故それが今すぐできていないかというと、いろいろ理由がある。例えばネットワーク上にオブジェクトを作るときにネットワークアドレスを指定しなければいけない、それからそこでセキュリティのチェックがあればそのためのユーザー名を指定しなければいけない、それからトランザクションスコープで動くのであれば現在の動くであろうトランザクションの設定もしなければいけない、そういったものを全て隠してNEW一つでできるかというとそれは今の技術ではまだ無理である。もう少し正確にいうとCOMというのはタイプシステムと呼ばれるものであり、つまりCOMの中では先ほどMIDLのデータタイプの説明があったが、IDLインターフェイス定義の中で指定できるデータタイプは決まっており、Variant型が一つ入っているのであるが、タイプが決まっている言語非依存のタイプシステムであって、C++が持っているIntegerという意味と、COMが持っているIntegerとは厳密に違うものである。String型も同じで違うものを使っているわけである。NEWとやったときにVBのオブジェクトに対してのNEWと、別のCOMというタイプシステムを持っているオブジェクト生成とは違う。開発者にとっては見かけ上同じコーディングをしているのであるが、全く違うものをやっているわけである。つまり言語システムと分散技術を含んだオブジェクトシステムとが完全に融合するにはまだ時間がかかるということである。それをやるのがCOM+2.0である。もしこれができれば非常に開発は楽になる。残念ながら現在のCOM+1.0では開発が簡単になるわけではない。従来通りC++ではATLやMFCを使わなければいけないし、VBではそれよりは楽であるが、かな り制限がある開発を強いられる。また、COMが持っているいろいろなタイプライブラリを参照したりする開発をするわけで、必ずしも今と比べて開発が非常に簡単になるわけではない。それはCOM+2.0に期待していただきたい。
 最後に、COMを理解する上で一つにはオブジェクト技術を理解することが必要である。もう一つは分散技術であるが、特にセキュリティやトランザクション、またこれからいろいろな技術が出てくるがなかなか全容を理解するのは難しい。開発者といってもその立場がいろいろとあり、例えばユーザーインターフェイスしか設計しない開発者であればそこまで知る必要はないと思う。

 セミナー受講の感想をアンケートからご紹介いたします。アンケートは理解度、有用度についてお聞きしていますが、今回の理解度(平均)、有用度(平均)は、「第1部:理解度 3.08、有用度 3.92」、「第2部:理解度 3.12、有用度 3.56」、「セミナー全体:理解度 3.07、有用度 3.71」(評価値1.0〜5.0)となっており、初心の方には少々難解なようでした。

 第1部では、「COMの概念がとてもよく理解できた」、「既にATLによりCOMコンポーネントの実装を行っているので、有用度は低いが良くまとまった内容であると思う」、「今までプログラミングを通して理解していたものの全体を見ることができて良かった」、「復習という形としては、誤認している部分が見つかり有用だった」、「COM、DCOMに初めて接するものである。内容は非常に駆け足で進んでいるように感じたが、基本部分から総括的に説明を行ってくれ有難かった」、「PowerPoint資料でモニター画面内容に動きを付けた個所は非常に分かりやすかった」、「まだまだ概念的に理解できていないことがあることが良く分かり、有用であったと思う」、「C++ベースの話なので理解できなかった。ただし、分かる人が聞けば有効な話だと思う」、「詳細レベルをかなり概略的に説明されたので、理解し難い面があった」、「自分側の知識不足を感じた。もう少し基本を覚えてから資料を見直したい」、「私は実際にCOMを意識した開発に関わったことがないので、講義についていくのは大変でしたが、COMの基本を幅広く、ポイントを押さえて説明してくださったと思う」、「前半は事前知識もあり、ある程度の理解はできたが、スレッドモデルに関してはイメージが掴めず、あまり理解できなかった」、「概念図を示し、その説明に集中した方がいいのでは?」、「COMを理解させるためにボリュームが大きくなるのは分かるが、時間配分を考えて欲しい」、「アパートメントの説明がやや分かり難かった。例を取り上げての解説が欲しい」、「プログラミング全般をこれから学んでいくところなので非常に難しかった」、「基礎知識が足りなかったので理解しきれなかった」、「もう少し時間を取って詳しく聞きたかった」、「少しのデモがあれば良いと思う」、「内容が多いため、やはり短時間では理解が追いつかなかった。有用度としては基礎は大事であるが、VBやJavaによる開発がメインとなれば低くなる」、「漠然としか理解していなかったCOMでしたが、これを機会に本格的に学びたいと思う。ただ、COMの初心者には少々難解な内容でした」、です。

 第2部では、「COM+に関する情報が有益であった」、「非常に分かりやすい説明だった。MTSをフルに使用してみようと思った」、「プログラミングによる説明はとても良く、よく理解できた」、「実際のデモを通じてとても良く理解できた」、「デモが分かりやすく良かった」、「いろいろとデモがあったので具体的にイメージすることができた」、「COM+に関する説明は有用になった」、「VBによる具体的な説明があったが、実際の業務でも似たようなことが求められていたので、参考にしたい」、「イメージが何となく自分の中に見えたような気がするが、自分には不明な用語が多かった」、「仕組みと出来る事に分けて、もう少し時間をとって説明して欲しい」、「VC++によるデモがないのが残念だった」、「VC++でATLを利用したコーディング例が欲しい」、「デモが分かり難かった。COM+についてもう少し詳しい内容を希望する」、「知らない用語が多数あったため、内容がほとんど理解できなかった」、「もう少しゆっくり話して欲しかった。デモマシンの構成を説明して欲しかった」、「プログラミング全般をこれから学んでいくところなので非常に難しかった」、「言葉による説明が良く分からない。論理を追って聞いていても、話が長いので疲れてしまう」です。

 セミナー全体としては、「技術セミナーとして有益であったが、時間が短いためか概念的過ぎたように思う」、「正直なところ自分には解らない部分も多かったが、イメージ的が少し見えたところもあるため、用語を調べながら資料を見れば得るところが多いと感じた」、「時間が不足気味で残念だった。最後の講師のまとめが一番良かった」、「最後のまとめの話は大変参考になった」、「もう少しCOM+の割合を増やして欲しかった。最後の話は良かった」、「今後、今日の知識を有用にできるように開発に取り入れていきたいと思う」、「有用な一時を過ごすことができ、スキルアップにつながったと思う」、「内容に対して時間が足りない」、「DNAでの将来的にCOM+の役割についてもう少し詳しい説明があったほうが良いと思う。」、「COMからCOM+への展望をもう少し突っ込んだ内容にしていただけると非常に有用なものになると思う」、「質問の時間を途中で取って、全体の時間も2〜3倍にしてじっくりお話を聞きたかった」です。

 今後のセミナーへのご意見、希望としましては、「新しい技術を取得しようとするものにとって全体像をセミナーで教えてもらって参考書で勉強する方法は有効と思える。今回の野村講師のように講演資料を作るのに役立った本などを教えてもらえると、講演資料とともに今後の勉強がやりやすい」、「プログラミングテクニックについてデモの時間が多いほうがよい。半日ではなくて1日のセミナーにしてはどうか」、「技術の幅が広がり、全てをカバーすることは困難であるので、セミナー受講のため知識の前提条件を詳しく提示していただきたい」です。
 多くのご意見をいただきありがとうございました。


Contents         Windows Consortium ホームページ