OPC TRANSITIONS TO UNIFIED ARCHITECTURE FOR GLOBAL INTEROPERABILITYというプレスリリースがOPCファウンデーションから発表されました。内容極めて掻い摘んでしまうと、題名から期待される物とはほど遠くOPCを現状のCOM/DCOMベースのアーキテクチャをXML Web Serviceへ移行させるよって言うことなんですが、個人的には「あー。」って感じですね。

ぼちぼちと書いていますが、OPC DAはXML Web Serviceなんぞで扱うほど大きな粒度を持ったコンポーネントじゃねぇっつーの。もっと細かいんだからバイナリーインターフェイスじゃねーとねー。

この先OPCも長くないかも。デファクトなしの暗黒時代に逆戻りかなー。まぁせこせことDCOMでつなげばいいですけど。

Visual Studio .NET 2003 最新ドキュメントへのアップデートという物がでました。

MSDN用の物で、120MB。巨大。しかしドキュメントのパッチがでるとは。

内容的には評判の悪かった、フレームワークの各クラスのコードサンプルが強化されている模様。

ダイエーホークスがホームの利を出したか、勝利。結局最終戦までもつれることに。しかし伊良部はだめだなー。しかしファンじゃないチームが出場している日本シリーズは冷静に見ることができてこれはこれでおもしろいですね

というわけで購入。

私の場合は電池1個より2個の方が落ち着いていい感じです。

スクロールホイールは引っかかり感は確かになくなりましたが、少し重たい感じですね。

後、おけつが光らないのがちょっと悲しい。

会社用も色違いで購入決定。

今日Amazonから届いて、斜め読み。

CLRや、クラスライブラリの説明が詳しく、丁寧で、好感が持てます。特にCLR上でのコンテキストの扱いについて日本語で書かれた数少ない書籍だと思う。ただ、CLR自体の解説はDon Boxの.NET Essentialほどではないので、心配しなくても大丈夫です。(笑い)これは、足りないと言うことではなくて、実際にソフトウェア開発を行う上では必要十分な内容ということです。

少なくとも、今から.netでソフトウェア開発を行い始める人の為の本ではありませんが、一通り、入門書や、SDKのチュートリアルを終えた人にはよい本だと思います。入門書ではとばしがちな、CLRについての体系的な技術情報、リモーティング、クラスライブラリの詳細、デバッグ方法についての知識を得ることができます。これで物足りないようであれば、.net essentialでも、ECMAのCLI仕様書でも好きな物を読み進めてくださいませ。

あと、Managed C++についての(日本語の)情報に飢えている一部の方に朗報です。今すぐこの本を手にしましょう。たぶんこの本を逃すとしばらく出てこないと思います・・・。

実践C++/C# .NETプログラミング

Richard Grimes著 宇野俊夫訳

翔泳社

ISBN4-7981-0348-9

NHK BSの解説は長嶋全日本監督。長嶋氏の監督論全開でおもしろい。やはり動物的勘だけで監督をする人ではないようだ。

現在8回表、阪神4対ダイエー4の同点。

Microsoft .NET Developers Conference 2003

日本版PDCが開催されることが決まったようですね。

現状ではいけそうにない。悲しい。

OPCはインターフェイス仕様です。インターフェイス仕様だけではアプリケーション、ソフトウェアシステムは成立しません。実際に動作するソフトウェアシステムを作成する必要があり、それを作成する為には何らかのインターフェイス仕様を元にソフトウェアシステムを構築する為の指針、もしくはフレームワークが必要になります。たとえば、EJBというインターフェイス仕様を使用して、ソフトウェアシステムを構築するための指針として、サン・マイクロシステムズは、「Java 2 Platform, Enterprise Edition アプリケーション設計ガイド」いわゆるブループリントを提示しています。

しかしながら、OPCファウンデーションはこのような明確な形で、OPCによって作られるソフトウェアシステムの外観という物を提示していません。しかしながら、それが何もないわけではなく、実際にはマイクロソフトから提供されています。それがWindows DNAです。OPCは独立したインターフェイス使用であるとともに、Windows DNAの製造業向けの指針であるWindows DNA For Manufacturingを支える基本的な要素の一つです。つまり、OPC DAをはじめとする、OPCの各インターフェイスは、Windows DNAを通してみると、その位置や存在意義が見えてくると思います。その将来も。

これは、OPC　XMLも例外では無いと私は考えています。OPC XMLは.NETの中でとらえるよりも、Windows DNAをWeb Serviceに対応させた、Windows DNA 2000の中で考えていく方がとらえていく方が自然でしょう。

OPCはWindows DNAにおいては、UDAの範囲外のデータアクセスレイヤーとして存在しているにすぎません。

そして現在の.netの世界でどうでしょう。マイクロソフトは.netでのソフトウェアシステム構築の指針として、「Application Architecture for .NET: Designing Applications and Services」という、Javaのブループリントに相当する文書を発行しています。OPCもこの文書に書かれた指針の中でその位置や役割を再構築していく必要があるでしょう。そしてそれは、具体的なインターフェイス仕様の変更という形で現れてこなければならないはずです。

候補1 SOAP

OPCファウンデーションもOPC XMLという形ですでに規格化を始めていますし、SOAP Ver1.1の範囲にとどめれば、一定の相互接続性も確保できます。

しかしながら、私はこのSOAPがDCOMに変わるOPCで使用するコンポーネントアーキテクチャの決定打とは思えません。現状のSOAPはHTTPで通信されることがほぼ前提で、この方式は数十m秒から数秒の定周期でタスク間の通信が発生するOPCの世界には遅すぎて適していません。現状のSOAPはOPCよりももっと大きな粒度のオブジェクトのインターフェイスとして使用されるべきです。

ということで、OPCの将来について、これから少しずつでも書いていこうかと。

とりあえず現状のOPCを整理してみます。

現状のOPCはDCOMのカスタムインターフェイスとして、アプリケーション間のインターフェイスを規定したものです。このようなインターフェイスを規定するメリットとしては、異なるアプリケーション間でもこのインターフェイス規約（あるいは契約）を守ることで、相互接続性(インターオペィラビリティ)を確保することができます。デメリットとしては、ここではDCOMという特定のコンポーネントアーキテクチャに縛られてしまうため、他のプラットフォームや、コンポーネント技術たとえばJavaへの展開や、それらを使用したソフトウェアシステムとの相互接続性というのは失われます。また、コンポーネントアーキテクチャは永遠ではなく、賞味期限付きのものであるのでいつかは廃れてしまい、市場の中での影響力を失ってしまいます。つまり、特定のコンポーネントアーキテクチャに依存してしまうことによって、インターフェイス規約自身がそれと市場の中での寿命を同じにしてしまうのです。

そして今、DCOMの市場内、あるいはMSの中での位置づけが、相対的に下がりつつあり、従ってOPCの位置づけも下がりつつあると考えます。少なくともWindows上でのコンポーネントアーキテクチャが、DCOMから.net Frameworkに移行しつつるので現状のOPCではない何かが必要になっていると思います。

その何かが何であるのかを考えていこうと思います。