2010マツオソフトウェアブログソフトウェア開発に関連することを発信しています2010年7月24日土曜日COMコンポーネントをIISで実行するサーバサイドでCOMを実行したいことはままあることで、それでは、と普通にローカルで動作しているCOMをIISのプロセス上で動かすとCoCreateInstanceでインスタンスが生成できなかったりする。考えられる理由は下記の通り。・COMがシングルスレッド上でしか実行できない・IISのアプリケーションプールが正しくない一つ目は、いくつかのCOMはシングルスレッド上でしか実行できない。そのためマルチスレッド上でCoCreateInstanceを行ってもインスタンス生成ができない。回避方法はSTAのスレッドを開始して、そのスレッド上でCOMを呼び出せばよい。Methodただ、STAなので処理はすべて順番に行われる。そのためリクエストが多重になればなるほどパフォーマンス上のボトルネックになるので注意が必要だ。IISのアプリケーションプールのIDがNetWorkServiceのままだと動作しない場合がある。その場合は下図を参考にIDをLocalServiceに変更してもらいたい。COMを実行したいアプリケーションプールの詳細設定を選択する。プロセスモデルのIDをLocalServiceに変更する。IIS7WCFをSSLを介してSilverlightで使うSilverlight4.0でSSLを介してWCFを使用したときに大変困った箇所を紹介する。1からの導入方法の紹介ではないので、それが必要な人は他のブログを参照して欲しい。設定を行った環境は以下の通り。Control)を無効にしたほうが良い。直接的には関係が無いのかもしれないが、UACを無効にせずに環境設定をおこなったらいつまでたっても動作しなかったものが、UAC無効化後に再度設定すると正常に動作しはじめた。WCFの仮想ディレクトリを作るところで違いがあるようだ。7WCFの説明Silverlightで開発をする場合サーバとの通信手段ではWCFを使用するのがスタンダードだ。このWCFが本当に優しくない。素人には大変厳しい仕様になっている。WCFは通信部分をすべて隠蔽してくれるので、サービスの参照の追加を行うとプロキシクラスを生成してくれて、クライアント側から簡単にサーバにアクセスできる手段を提供してくれる。この隠蔽が大変曲者だ。プロキシクラスからサーバへリクエストを投げて何かしらの通信エラーが起こった場合、WCFはCommunicationExceptionを投げる。この例外、受け取るメッセージは常に一緒なのに要因は実に多岐に渡る。簡単に列挙するだけで下記の要因がある。・証明書の設定が正しくないひとつひとつの要因が大きいのに、すべてCommunicationExceptionで包まれているので初見ではまったく意味が分からない。ここでは参考になったブログポストを紹介しておくので同じ現象にはまっている人は参考にして欲しい。Domainエラーが発生する場合は、inetpub/wwwrootの直下にclientaccesspolicy.xmlかcrossdomain.xmlを配置する必要がある。その両ファイルの背景と構成の説明。長いので必要な箇所だけ拾い読みしてほしい。(SvcConfigEditor.exe)ServiceReferences.ClientConfigを編集するツール。記述に間違いがあるとエラーを出力するので、エレメントのチェックにも使える。7IISにSSLを設定する方法。真ん中から下以降を参考に。Domainエラーを出力する場合に参考にしてほしい。CommunicationExceptionでつまる原因は大体上記に当てはまると思うので、サーバに正常にアクセスできない場合は前述のブログポストを参考に対処してもらいたい。10のセッションビデオの中で「こういうのはPOCOで開発するんだよ」と解説してくれているのがあって(どのセッションかは失念)、そのときはたいして気にもしていなかったのだが、最近データアクセス層を作っているときに、おっ、ここはいっちょPOCOってみるか、と思いつき色々調べたらよく分からなかったので、今後のためにまとめておく。(※間違っているかも知れないので話半分で聞いてください)理解の元ネタは下記から収集。DTOとなっているのは、一見POCOとDTOは似ているので、POCOのことを正確に理解していない人は「POCOってのはDTOと一緒だよ」とのたまうらしく、そちらの世界に導かれると「じゃぁなんでPOCOが必要なの?」って質問に答えられなくなるので、ホントのところはどうなってんだよ?という魂の叫びの表れである。Objectの略称で、DTOの唯一の目的は状態(データとかも含むのかな?)を他の層(とか他のアプリなど)へ渡すことにあって、OOP(オブジェクト指向プログラミング)的な振る舞い(特にビジネスロジック的なもの)を持つべきではない。必要な情報を渡すためだけの箱であって、それ以上でも以下でもない。Object)から来ている(POJOのWikiはこちら)。frameworkをかませない(命令させない、規制させない)で行おう、という考え方。ここまでをまとめると、POCOはシンプルなOOPへのアプローチ方法の説明で、DTOはデータをどっかに渡すためのパターン、となるで、ここから自分の解釈になるのだけど、こんな風になるのかな、と図解してみた。ビジネスエンティティやドメインモデルと呼ばれるているオブジェクトがPOCOである。各層をつなぐ矢印があるけれど、その際に渡すオブジェクト(があるならば)はDTOでもPOCOでも良い。ドメインモデルと合致しないようなデータを渡すだけならば、それようにDTOを作って渡す方が良い。DTOはPOCOよりもシンプルな構造になる。Ignorance(PI:永続化に無知。変な日本語で申し訳ないけれど訳し方が分からない)でなければならない。Save()や、GetDataById()のような、永続性を持つロジック(データの読み込み、保存など)を実装してはならない。そのようなロジックはデータアクセス層に実装しよう。いうことでPOCOを使うと各層を明確に分離できるので、より良い構造になる。Design)を理解するのに良いと勧められていた本を紹介しておく。BooksにPreviewがあるのでそちらもどうぞ。Serverで行番号を取得するクエリを紹介する。2000で開発していた際に、同様の機能がないかとちまなこになって探していたのも今や昔。サンプルクエリが下記ブログにたくさん載っているので参照されたし。Japanウェブアプリ、デスクトップアプリ、モバイルアプリ、ゲームなどを開発しています。