Ver1.1の範囲にとどめれば、一定の相互接続性も確保できます。私はこのSOAPがDCOMに変わるOPCで使用するコンポーネントアーキテクチャの決定打とは思えません。現状のSOAPはHTTPで通信されることがほぼ前提で、この方式は数十m秒から数秒の定周期でタスク間の通信が発生するOPCの世界には遅すぎて適していません。現状のSOAPはOPCよりももっと大きな粒度のオブジェクトのインターフェイスとして使用されるべきです。commentということで、OPCの将来について、これから少しずつでも書いていこうかと。現状のOPCを整理してみます。現状のOPCはDCOMのカスタムインターフェイスとして、アプリケーション間のインターフェイスを規定したものです。このようなインターフェイスを規定するメリットとしては、異なるアプリケーション間でもこのインターフェイス規約(あるいは契約)を守ることで、相互接続性(インターオペィラビリティ)を確保することができます。デメリットとしては、ここではDCOMという特定のコンポーネントアーキテクチャに縛られてしまうため、他のプラットフォームや、コンポーネント技術たとえばJavaへの展開や、それらを使用したソフトウェアシステムとの相互接続性というのは失われます。コンポーネントアーキテクチャは永遠ではなく、賞味期限付きのものであるのでいつかは廃れてしまい、市場の中での影響力を失ってしまいます。特定のコンポーネントアーキテクチャに依存してしまうことによって、インターフェイス規約自身がそれと市場の中での寿命を同じにしてしまうのです。今、DCOMの市場内、あるいはMSの中での位置づけが、相対的に下がりつつあり、従ってOPCの位置づけも下がりつつあると考えます。Frameworkに移行しつつるので現状のOPCではない何かが必要になっていると思います。その何かが何であるのかを考えていこうと思います。読み込み中...未分類TechEdが終わったよ。commentTechEdも終わったよ。今年のTechEdは2日間だけということもあってちょっと消化不良的な感じがする。いうものの、そこはTechEdということで、今回私がセッションを聞いた範囲でまとめておきましょう。Yukon来年このYukon登場以降しばらくの間は、マイクロソフトにおけるアプリケーションプラットフォームはこのYukonになるだろう。Serviceサーバを構築することが可能になる。Webサービス、あるいはドメインのサブシステムの単位では論理的な構成はともかく、物理的な構成はより集約型の構成になっていくだろう。SOASOA,サービス指向アーキテクチャ。エンタープライズアプリケーションの構築は、オブジェクト指向に基づいた分散オブジェクトをベースにしたソフトウェアシステムから、サービス指向アーキテクチャによるWebサービスとそのオーケストレーションを中心としたソフトウェアシステム構築に移行していく。SOAに関しては、自分の中でもう少し整理がついたらまた書いてみます。読み込み中...未分類EDCが終わった。comment昨日でEDCも終わり。serverはエンタープライズレベルのプロジェクトマネージメント用のプラットフォームとしては十分なものになっていると思う。国内で普及できるかどうかは、実際のプロジェクトマネージャや経営層にどこまでプロジェクトマネージメントに対するリテラシーが存在するかだろう。うまく使えば、確実に社内リソースの有効活用が可能になる。comment明日からEDC/TechEdに行ってきます。comment前半の言語自身の解説が必要かどうか疑問。いうか、個々の文章の端々から著者がC#自身が嫌いなのが伝わってきます。後半はGOFのパターンの説明になるのですが、各パターンを説明する例題がGUIアプリなので、余計なコードが多くて、パターンの説明用例題としては不適切な感じがする。書籍内に例題すべてのコードがあるわけではなく、必ず付属CD-ROM内のコードを参照する必要があり、CD-ROMのコードを参照しようとする段階で思考がとぎれてしまい集中できないので、その点もマイナス。C#自身については別の書籍で勉強して、デザインパターンについてはGOF本か、結城氏の本を参考に書籍内のコードを自分でC#に修正していくやり方で学習した方が良いと思う。