System.Messagingはニュートラルか?

昨日の話題について、oka326さんがさらなる考察をまとめられているので、それについて少々。

まず、System.Messagingはメッセージキューを操作するAPIである、という意味では、最初からCOM+を前提としたSystem.EnterpriseServicesに比べたら、まだ実装中立になる余地はあります。ただ、System.Messagingには、明らかにWindows/MSMQの実装を前提としたAPIが散在していたりします。たとえばActiveXMessageFormatterとか、CryptographicProviderType(.MicrosoftExchange)とか、一部の列挙型がなぜか不思議な数値バインディングを持っていたりとか。メッセージキューサービスの機能そのものも、どれだけ標準的なAPIが（標準的なAPIとして）実装されているのか、自明ではありません。

これは、LDAPに基づいて設計されている.NET 1.xのSystem.DirectoryServicesとは対照的なものです（.NET 2.0は、ActiveDirectory専用のAPIが大幅に追加されていて、しかもネームスペースを分けるという当然の配慮も怠られているのですが）。あるいは、クライアント別のConnection/Command/DataAdapterなどとは別に、共通APIとしてSystem.Data.Commonが用意されているADO.NETとも違うものです（もちろんSystem.Data.Commonは別に何かしらの標準があるわけではないですが、少なくとも共通APIをSystem.Data.SqlClientから切り離そうとはしているわけです）。

つまり、（IMHOですが）System.Messagingは、メッセージキューの共通APIではない、あるいは、共通APIとしては未熟なのです。これは、例えて言うなら、System.MessagingはJMSではあり得ず、むしろベンダー固有のAPIに近い存在です。

System.Messaging APIがある程度抽象化されているのは、MSMQの将来のバージョンとの互換性を考慮しているためでもあるでしょう。System.Data.SqlClientも、現在のバージョンのSQL Server (7とか2000とか）の機能の一部しか提供していないと思います。

IndigoはSystem.Messagingに比べたらもちろんハードルは高いのですが、System.Messagingよりmonoで実用に耐えるAPIであれば、実装する価値は十分にあるでしょう。もちろん、実物を見てみないと、何とも言えないのですけど。（4年くらい前には、System.Windows.FormsもクールなAPIだと思われていました）。