MicrosoftはサーバサイドWCFに関しては、今なお沈黙を続けている。サーバサイドWCFは命脈の尽きたテクノロジである、という印象を一旦は与えたが、その後すぐ、発表の否定まではしなかったものの、少し待ってほしいと述べている。
クライアントサイドWCFについては当初から使用可能であったにも関わらず、Microsoftは何年もの間、サーバサイドWCFの.NET Coreへの移植を拒んでいる。ライブラリ全体がこのようになっている理由について、チームの規模以外には、何の説明もされていない。ソースコードはReference Sourceで入手可能であり、大部分のバインディングはクロスプラットフォーム作業に適しているにも関わらず、この状況なのだ。
Windows専用のセキュリティオプションとバインディングがいくつか存在する(名前付きパイプ、MSMQなど)点には、考慮の余地があるかも知れない。しかし、他のライブラリに関しては、Windows Compatibility Packですでに対応されている。
このような不満な状況は、Scott Hunter氏が書いた記事が発端となっている。
.NET Core 3.0以降については、.NET Framework機能の移植は行いません。Web Formsの開発者が、.NET Coreを使用して新たにアプリケーションを開発する場合には、最も近いプログラミングモデルを提供するBlazorをお勧めします。リモートまたはWCFサーバの開発者が.NET Coreで新しいアプリケーションを開発する場合には、ASP.NET Core Web APIまたはgRPCを推奨します。この２つはクロスプラットフォームであり、プログラミング言語間の互換性を持ったコントラクトベースのRPCを提供しています。Windowsワークフロー開発者には、Workflowがオープンソースとして.NET Coreに移植されています。
この記事は、RESTはWCFの代替ではない、と言ってきた多くの.NET開発者を困惑させた。同じ議論がgRPCにも当てはまる。WCFユーザの目から見たgRPCは、WCFの提供する他の部分を無視した、単なるバインディングに過ぎないのだ。簡単に言ってしまえば、どちらもWCFの最大の存在意義である、抽象的なコミュニケーションフレームワークの役割は果たさない。(言うまでもなく、レガシやコントラクト上の理由から、WS-*/SOAPをサポートする必要があるのだ。)
Githubコメンタのdgxhubbardは、次のように書いている。
Scottは、"gRPCを使ってください！"と言っています。これがどのような意味なのかを正しく理解するために、この決定を下した人たち自身が、WCFサーバサービスを実際にgRPCでコードしてみて欲しいと思います。.Net Core3以降を導入するというのは、穴だらけの道路に進むようなものです。WCFを模倣するためにサービスを書き直さなければならないようならは、.Net Core 3以降の採用は、当分の間見合わせることになるでしょう。
Chris Benard氏も同じ意見だ。
こちらでも同じです。gRPCがドロップイン・リプレースに近いというのは、私には理解できません。WCFの大きな売り物のひとうは、サービスコントラクトモデルとインターフェイスを満載したDLLを、サーバとクライアントで共有できる機能でした。私の見る限り、gRPCは、プロキシ生成に依存しているようなのです。サービスの中には、後で再生を可能にする目的で、オブジェクトをシリアライズして保存しているものもありますが、gRPCでどうやって実現するのか分かりません。
NetDataContractSerializerを手作業で使用して、gRPCパイプか何かにバイトを送り込むような方法は取りたくありません(そもそもNetDataContractSerializerはCoreにあるのでしょうか？多分ないと思いますが、DataContractSerializerはあります)。完全なフレームワークとしては、サポートされていないものが他にもあります。
コントラクトは、私にとっては大きな問題ではありません。サーバ/クライアント間でDLLを共有するモデルだからです。
単一のServieHost上に複数のエンドポイントを持てるか、という問題もあります。ひとつのエンドポイントにTransportSecurityを、別のエンドポイントにMessageSecurityを設定することができます。エンドポイントでセキュリティを実現する方法のアップデートに、これを使用しているのですが、これもgRPCでサポートではサポートされていません。
言うまでもありませんが、アウトバウンドポートをひとつずつ開かなければならない企業ユーザもいますから、gRPCを使って、単純に同じポートでクラスタに移行するという訳にはいきません。
これはすべて、.Net Coreが当分の間、サーバ側では使用できない状況であることを意味しています。幸いにも私はこれまで、WS-Securityやクライアント側のものを使っていないので、その点には固執しませんし、考えてもいません。ただし、netstandard2.0で共有されているサーバ側DLLを改めて対象にして、Core WCFクライアントとFramework WCFサーバ間でどのように機能するかを確認する必要はあります。
結論: これは悪夢です。フレームワークを失うことになります。
後記：ローカルなプロセス間リモート処理で使用する、名前付きパイプもサポートされないようです(笑)。WCFでは、当たり前と思っていたのですが ...ああ。
矛盾したメッセージ
MicrosoftのMatt Connew氏はいくつかのコメントで、WCFユーザ今後の道があることを示唆している。
Scottの発言は、WCFリポジトリについて語ったものではありません。現在のWCFは.NETから分離されており、フレームワークの一部というよりも、外部ライブラリに近い存在です。現時点でサーバサイドWCFについて言えることは何もありませんが、より多くのWCF機能を移植するためのドアは閉じられていませんから、より多くのシナリオをサポートしたいと考えています。
Matt氏も先頃、同じような発言をした。
//Buildの後に寄せられた多くの意見は拝聴しております。もう少しお待ちください。大企業の歯車は大きくて重く、回転するために多大な労力を要する場合があるのです。Scott HunterはBuildで、開発作業が進行中であると発表しました。それが事実です。
しかしながら先日、MicrosoftのStephen Bonikowsky氏は、これに反する発言をした。
WCFのサーバサイドに関しては、このリポジトリの一部として含める予定はありません。サーバ側には多くの関心が集まっていますが、#2695で進行中の議論、特に@mconnewの先日のコメントが参考になると思います。
この発言は、LINQ-to-SQLがEntity Frameworkに置き換えられた時と同じように、サーバサイドWCFが別のリポジトリになるという意味に解釈できる。私たちが知らないだけで、Microsoftには、計画を公開する準備ができていないのだ。