OPCよ汝は何処へ3

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もこの文書に書かれた指針の中でその位置や役割を再構築していく必要があるでしょう。そしてそれは、具体的なインターフェイス仕様の変更という形で現れてこなければならないはずです。

OPCよ汝は何処へ2

候補1 SOAP

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

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

OPCよ汝は何処へ1

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

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

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

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

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

TechEdが終わったよ。

　TechEdも終わったよ。今年のTechEdは２日間だけということもあってちょっと消化不良的な感じがする。とはいうものの、そこはTechEdということで、今回私がセッションを聞いた範囲でまとめておきましょう。

Yukon

来年このYukon登場以降しばらくの間は、マイクロソフトにおけるアプリケーションプラットフォームはこのYukonになるだろう。YukonだけでWeb Serviceサーバを構築することが可能になる。Webサービス、あるいはドメインのサブシステムの単位では論理的な構成はともかく、物理的な構成はより集約型の構成になっていくだろう。

SOA

　SOA,サービス指向アーキテクチャ。エンタープライズアプリケーションの構築は、オブジェクト指向に基づいた分散オブジェクトをベースにしたソフトウェアシステムから、サービス指向アーキテクチャによるWebサービスとそのオーケストレーションを中心としたソフトウェアシステム構築に移行していく。
　SOAに関しては、自分の中でもう少し整理がついたらまた書いてみます。

EDCが終わった。

昨日でEDCも終わり。Project2003 serverはエンタープライズレベルのプロジェクトマネージメント用のプラットフォームとしては十分なものになっていると思う。国内で普及できるかどうかは、実際のプロジェクトマネージャや経営層にどこまでプロジェクトマネージメントに対するリテラシーが存在するかだろう。しかし、うまく使えば、確実に社内リソースの有効活用が可能になる。

今週はTechEd

明日からEDC/TechEdに行ってきます。

書評： C#デザインパターン

前半の言語自身の解説が必要かどうか疑問。というか、個々の文章の端々から著者がC#自身が嫌いなのが伝わってきます。
後半はGOFのパターンの説明になるのですが、各パターンを説明する例題がGUIアプリなので、余計なコードが多くて、パターンの説明用例題としては不適切な感じがする。また、書籍内に例題すべてのコードがあるわけではなく、必ず付属CD-ROM内のコードを参照する必要があり、CD-ROMのコードを参照しようとする段階で思考がとぎれてしまい集中できないので、その点もマイナス。
正直、C#自身については別の書籍で勉強して、デザインパターンについてはGOF本か、結城氏の本を参考に書籍内のコードを自分でC#に修正していくやり方で学習した方が良いと思う。
あえておすすめはしない。

C#デザインパターン
James W. Coopeｒ著 トップスタジオ訳
日経BP発行
ISBN4-8222-8169-8

風邪ひきました。

皆さんもご自愛のほどを・・・

書評：ウェブログ入門

ここに来るきっかけになった本です。とりあえず日本語で読めて、一通り解った気になれるよい本です。(これがすごく大事。)
丁寧に説明が書かれているので、自分でWEBページを作った経験があるような人なら、この本だけでここまではたどり着けるはず。
今のところ最高のblog入門書だと思う。

ウェブログ入門
田口和裕　堀越英美　ばるばら　sawadaspecial 著
翔泳社　発行
ISBN4-7981-0404-3

初めまして。石坂です。

ここでは日本語では情報の少ないOPCに関する話題とか、マイクロソフトテクノロジーだとかについての話題だとか、それらに対する僕の考えを書いてゆきます。そしてたぶん愚痴もたくさん。（ｗ