【.NET】WCF〜Windows通信基盤技術【通信】
三文字テクノロジは流行らない法則。
なんかさ、最近のMicrosoftって宗教みたいじゃね?
信じる者は救われる〜〜〜〜みたいにw
4 :
874:2009/10/15(木) 01:48:05
スレ違い
"874"はみす
>>847 でも、ここってMicrosoft教WCF宗派が集うスレじゃね
正しくは.NET宗WCF派だ
>>7 ちなみにアプリ間の通信に関しては
他にどんな宗派があるの?
>>8 まず業界標準のOMG/CORBAがある。
また、CORBAと互換性(相互運用性)があるのか否かが最大の注目点。
もし無ければ、ブリッジ(or ゲートウェイ)が標準提供される必要がある。
このブリッジはプログラミングレスであることが重要。
さもなければ、MSの宗教(MS教.NET宗WCF派)であると見なす。
10 :
デフォルトの名無しさん:2009/10/16(金) 19:09:50
WCF vs CORBA
WCF vs xml-rpc
WCF vs SOAP
WCF vs socket
WCF vs RPC
WCFはサービス指向だからCORBAとはあまり合わんかも。
ちなみにWCFは通信プロトコルじゃないよ。
WCFのモデル上で各種通信プロトコルが実装される。
Webサービスとかその他諸々。
CORBA対応するとしてもそういうイメージ。
元々あらゆる通信プロトコルを
単一のプログラミングモデルで扱えるようにするのが目的だから。
>>11 >CORBA対応するとしてもそういうイメージ。
・CORBA対応は後発であるWCF側で対応する
・その対応により、既存システム側に変更は不要
・上記はMSが保証する
>>12 >元々あらゆる通信プロトコルを
>単一のプログラミングモデルで扱えるようにするのが目的だから。
・その「あらゆる」という言葉には、当然、CORBAも含まれている
・.NET系以外のシステムであっても、相互運用可能である
・上記はMSが保証する
これらは、すべてYESですか?もしそうであれば宗教扱いを止めます。
・コンポーネント指向プログラミング
− 再利用方法:分散環境でのコンポーネント、部品再利用
− 再利用環境:同じ開発環境および同じぷラットフォーム
− 代表する技術:ActiveX、COM/DCOM、JavaBeans、EJB、CORBA/COM
− インタフェイス定義:IDL
− 問題点:特定プラットフォームへ依存、ファイヤウォールの透過は困難
↓
・サービス指向アーキテクチャ
− 再利用方法:分散環境でのサービスの再利用
− 再利用環境:サービス指向アーキテクチャ環境
− 代表する技術:SOAP Webサービス、*WCP*
− インタフェイス定義:WSDL
− 問題点:業界共通の定義は、まだ存在しない
「これからはじめるWCFプログラミング」(秀和システム)より
15 :
デフォルトの名無しさん:2009/10/16(金) 23:20:57
ABC
A:アドレス
B::バインディング
C:コントラクト
>>11 CORBAとかその辺がやってたことを再実装して売り出すというやつですか。
>>14 >− 代表する技術:ActiveX、COM/DCOM、JavaBeans、EJB、CORBA/COM
> − インタフェイス定義:IDL
> − 問題点:特定プラットフォームへ依存、ファイヤウォールの透過は困難
問題点が特定プラットフォームへ依存ってあるけど、それはActiveX、COM/DCOMのこと?
Windowsシステム上でしか動かないし、他のシステムと相互運用性ないし。
自分から原因を作っておきながら、さも全体に問題があるように語るの?
もしも、それでWCFを拝んでいるようなら、やっぱ MS教.NET宗WCF派 だよwww
>− 代表する技術:SOAP Webサービス、*WCP*
えーと、"WCP" って、まさか Windows Communication Protocol じゃないよね。
今時、特定プラットフォームへ依存するプロトコルなんてありえないし。
だからWCFは単なるプログラミングモデルだってのに。
サービス指向の考え方がわりと根底にあるっていう特徴はあるにしても。
メインはWebサービスだし、MS教とか関係ないっつの。
WCFに関してはね。
>>13 通信プロトコルではないの意味が分かってないのか?
.NETでは通信のプログラムはこういうモデルで書こうというだけの話に、
宗教もくそもない、既存の標準のしくみを置き換えるものでも何でもない。
20 :
14:2009/10/17(土) 06:41:53
21 :
デフォルトの名無しさん:2009/10/17(土) 07:33:20
>宗教もくそもない
すべての宗教、思想、道徳をあたたかくつつみこんでくれるわけですね。
しかし、それはいっいどんなものなのでございましょう?
22 :
デフォルトの名無しさん:2009/10/17(土) 12:52:33
通信のインフラストラクチャ
>>18 >メインはWebサービスだし、
というよりも、WCFはWindowsプラットフォーム上でしか緊密な相互運用性が保証されず、
他のプラットフォームとの間は、Webサービス(SOAP)みたいな粗結合な仕掛けでしか
相互運用できないってのが事実だろが。まったく信者はこれだから....。
>19
>.NETでは通信のプログラムはこういうモデルで書こうというだけの話に、
で、そのモデルとやらは、Windows以外のプラットフォームを包含しているのか?と指摘しているんだよ。
漏れはMSを全否定する気はない。特に、MSの持つXML関連の技術は、高く評価している。
たとえばWPFは、MSらしいXML応用技術だ。そして、WPFはWindowsプラットフォーム(.NET)上で
閉じているから、その世界の中で信者達が信仰している分には、何をしようと無問題だ。
でもな、MS教がネットワーク、あるいは分散システムに進出するとなれば、話は大きく変わるんだよ。
それが何度も言っている「他プラットフォームとの相互運用性」という課題。
WSDLだってば
>>24 DCOMもCORBAも共にインターフェイス定義にはIDLを採用してた。
では、DCOMとCORBAとの相互運用は可能だったのか?
WSDLは相互運用性を実現する技術要素の一つでしかない。
WSDL採用だけでは相互運用性は保証されないんだよ。
まったく、これだから信者は始末に負えない。
教祖MS様の言う事は、全て正しいと思い込んでる。
もったいぶってないで「相互運用性が保証される」ための「十分条件」をいえよ
おれにあわせれば、それでいいんだよってことか
CORBAやってるやつはそれをすててWCF使えばいいってのも同様に十分条件となるってことだな
まあ、、、時間を無駄にした
>>28 >>23でWPFを例えにしたけど、WCFも同じ。
Windowsプラットフォームだけの閉じたシステムを構築するなら、WCFでも無問題。
ただし、CORBAでもなんでもいいが、他のプラットフォームが存在しているシステムにWCFベースの
Windowsサブシステムを追加しようとした場合、相互運用性が課題になる。
既存の(メインフレーム/UNIX/Linuxで動く)基幹システムを、すべてWindowsに置き換えろってか?
笑われるぞ。もしそれを正気で言ってるとしたら、それこそMS教の狂信者だぜ。宗教って怖いね。
>>28がWindowsだけで閉じた世界に生きているなら、時間の無駄だよ。
というか、相互運用性という言葉の意味を知らずにカキコしているのか?
だから、WSDLだってば
WCFは、「Windowsでのプログラミングモデル」であって、
他の環境でWCFのプログラミングモデルを使う必要などない
という大前提をなんで無視するの?
ってかなんでそんな大げさな仕組みと思いたがるの?
勝手に思い込んで信者とか?
もう気色悪いんだよ。
しんでもCORBAがい言ってんならそういうのはWebサービス信者に言えよ。
WCFは.NETでの通信プログラミングモデルにすぎないって
何回いわせるんだよ。
他のプラットフォームにしても現在、相互運用性を保障する技術がない。
だからこれからMSも他プラットフォームもWSDLを使っていこうってことなんだよ。
MSはCOM/DCOMをすてる。他のプラットフォームにいるやつもCORBAをすてる。
今からWSDLに集結しましょうっていう話だと思うよ。
CORBAを使いたがってるやつは、その行為自体も相互運用性を保障するものではないってわっかってんのかね?
>>29 誰も言ってないことを妄想語り。
これだから基地外は。
こいつはもちろんWebサービスが出てきたとき発狂しまくったんだろうな。
基幹のシステムをみんなWebサービスに置き換えるのか、とか言って。
Webサービスなどの相互運用を意識した標準に則ったサービスを
Windows上で構築したり呼び出したりするときは、
WindowsではWCFのプログラミングモデルを使って構築する。
Windows同士のネイティブな通信でもWCFを使う。
Windows以外のシステムではそちらで都合のいいプログラミングモデルを使って
やっぱりWebサービスやCORBAやその他要件に合わせた技術で構築する。
これの一体どこにMS信者とか狂信者とかそんな言葉が出てくるんだか。
WCFはプロトコルスタックとプログラミングモデルが独立してるのがミソ。
標準的な通信方式でもネイティブなローカルな方式でも
デファクトになってきた新しい方式でも
今後新しい方式が出てきても、
基本的にプログラミングモデルは変えなくて良い。
ただ対応するプロトコルスタックを提供するだけ。
まあそういう考え方はは昔からないわけではないが、
実質的にあまりうまくいかなかった。
何でだろうな。
Microsoftが考えたフレームワークに沿って作業しない奴が多いから。
40 :
デフォルトの名無しさん:2009/10/19(月) 09:56:05
このスレは良スレの予感
>>39 つ WindowsDNAでも使ってろ!HailStormでも使ってろ!
42 :
デフォルトの名無しさん:2009/10/19(月) 23:14:26
パフォーマンスやら性能とかってどうなんでしょう?
>>38 .NET で閉じてるうちは自由にトランスポート層を選択できるけど、
非.NET な世界と会話しようとした途端に
WebService を選択せざるをえなくなって、
それ以降は WebService と言う制限を受ける。
サービス実装が透過してるから
「速度が重要になったらあとでソケットにしよう」
なんてことが設定レベルで出来るはずだったのに
そのうまみがまったくない。
だったら外と通信する部分は最初からソケットで組めって話になる。
Webサービス(SOAP)前提ってことは、要するにセマンティクスとして
リクエスト&レスポンス(コール&リターン)しか使えないRPCと大差無しという事。
MS/DCOM、OMG/CORBA、それにOSF/DCEさえ満足に使えないプログラマが大半だったのに、
それが教祖MSの考案した新教典WCFだからという理由だけで、
>>37,38みたいな能天気な発言で盛り上がれるんだから、
ここのミサに集っている連中の宗教狂いレベルも分かる。
ましてや
>>39なんて狂信者の発言なのに、それを誰も咎めない。
やっぱりMS/WCFは宗教だろ。wwwww
45 :
44:2009/10/20(火) 04:40:58
自分のカキコを読み返してみると、
>>38はMS教典WCFの矛盾に気が付きかけているから、
引き合いに出すのは不適切だった。
>>44のカキコから削除する。失礼した、ゴメソ
>>38 逆に、
>>44へ追加するのは
>>32,34あたりか。
>>44 >Webサービス(SOAP)前提ってことは、要するにセマンティクスとして
>リクエスト&レスポンス(コール&リターン)しか使えないRPCと大差無しという事。
SOAPってリクエスト&レスポンス(コール&リターン)前提だったのか。
初めて知ったよw
>>43 詰まるところ何が言いたいの?
最初からみんなソケットで組めってか?
>>44 つまり何が言いたいのか分からない。
お前らみんな狂信者だって言ってるだけだな。
>>44 Windowsでの汎用的な通信プログラムが
それなりに楽な共通プログラミングモデルでできるってだけの話に
一体何を言ってるんだ?
44は無視していいけど、
とっとと具体的な話題に入らない方も悪いと思う。
で、議題募集。
前にでてるパフォーマンスとかいいんじゃない?
あとこんなの作ってみたとか、作り方教えてとか、ここがうまくいかないとか。
手を動かさないと始まらないよ。
> 前にでてるパフォーマンスとかいいんじゃない?
MSの宣伝ではRemoting以上の速度(つまり、パフォーマンスはかなり良い)って事になってるね。
実際、使ってみてパフォーマンスで困るような事はなかった。
ただ、ChannelFactory<T>を使う場合は動的コード生成を行うせいか、初動が遅かった。
(といっても、1秒程度だが、コマンドラインツール等で使用すると微妙に気になるかも)
svcutilで生成したコードはを使えば、動的コード生成なし使えるかもしれないが、
そこは試していないので不明。
ついでに、うちがWCFを採用した理由も書いておこう。
「silverlightに対応しているから」
この一点に尽きる。
現状では、
.Net3.5とsilverlightの両方に対応したコードで使える通信フレームワークというと
WCFしか選択肢がない。
>>52 何を開発しているのか書いてくれないと、だから何?って感じでつ
54 :
デフォルトの名無しさん:2009/10/23(金) 15:01:19
だれかなんか作った?
Windows2000がまだあるっていう理由でWCF使えてません。
.NET Framework4.0なんて夢のまた夢…。orz
そういう話じゃないだろ
>>57 いや、そういう話だろ。
2000じゃなかったらWFCで作れるプロダクツがこの世に存在するってことはまだあたりまえのことじゃないからな。
情報クレクレ君が多いな
60 :
デフォルトの名無しさん:2009/10/25(日) 19:53:14
Mr. Okure
61 :
55:2009/10/25(日) 23:04:35
>>61 でも、そういう環境って貴重だよ。
あたりまえにできそうなことができるってわかっただけでも貴重な情報。
こまかなトラップいっぱいあるからね。この世界。
63 :
61:2009/10/25(日) 23:54:11
>>62 乙ですね。
落とし穴…いっぱいありましたよ。
スレ違いになるからコレ以降はカキコしませんが。
ActiveDirectory環境下でWindowsサービス使ってログオンをHookする時とかに、うぎゃーとか。
Apacheで展開する時に、SSLとVirtualHostを同時に運用しないといけなくて、うぎゃーとか。
最初は鯖側をASP.NETで作成してたのですが、ソースをIISへ転送しないとダメで、
こりゃ実装としてマズーでうぎゃーとか。
Javaで再実装後、1台のJ2EEサーバーで同一アプリを同時展開するために、うぎゃーとか。
んで、本業じゃないんで漏れの睡眠時間がうぎゃーとか。www
プログラマーじゃないんです、ハンコ屋なんですとか言っても信じてもらえないし。
えぇ。友人のためにボランティアで作りました。
64 :
デフォルトの名無しさん:2009/10/28(水) 17:26:45
これ設計したやつ天才だな
65 :
デフォルトの名無しさん:2009/11/21(土) 08:54:04
hoshu
66 :
デフォルトの名無しさん:2009/11/30(月) 21:54:23
age
67 :
デフォルトの名無しさん:2009/12/09(水) 21:10:23
ルック
最近始めた。これ面白いね。
プロトコルや通信路によってコードを変えなくていいのが良い。
69 :
デフォルトの名無しさん:2009/12/15(火) 23:26:01
これって、JavaでいうRMIとかも含んでいますか?
JavaのRMIのシステムをWCFで再構築しなおすことってできますか?
>>69 RMIに相当する機能(オブジェクトのマーシャリング)は含まれていない。
WCFは、RMIよりもSOAP/DCOM/CORBAと類似性のある仕掛け。
RMIと違い、提供するサービスを明示的に記述する必要がある。
遊びで触るくらいなら動かせると思うけど、ある程度の規模の
RMI応用システムを想定しているのなら、かなり苦労することになるだろね。
少なくとも上に書いた三つの類似技術のどれか一つを、
概念的にでも理解できていないと、WCFは使いこなせないよ。
結論:苦労してWCFを勉強しても、三つの類似技術と同様、普及することなく
忘れ去られる技術だから、WCFを勉強しても無駄になるだけ(笑
WCFって普及するとかしないとかそういうもんじゃないだろう。
まったくだ。
WCFの勉強自体に苦労はない。WCFによるサービスをシステムを構築する上で
IISでどうホストするかが重要。セッションとか。
>>71,72
他人のレスに文句つけるくらいなら、質問者(
>>69)に適切なレスしてみればいい。
システムをxxxからWCFへ移行したいなんて要望は、この先ありふれた質問になるよ。
底辺プログラマには無理な注文かな(笑
何がしたくてここに来てるのかなぁ。
>>73何が言いたいのかよくわからん。
お前WCFが何か分かってないだろ。
分かってたらそういう反応にはならない。
また基地外が暴れてんのかよ
78 :
デフォルトの名無しさん:2009/12/24(木) 23:50:19
ほしゅ
>>76 残念。私は高さだ。
さしずめ君は÷2かな。
じゃあ僕は円周率ちゃん!
もし面白いつもりで書いてるなら、絶望的に笑いのセンスが無いと思う
半径の俺に隙はなかった
83 :
デフォルトの名無しさん:2010/02/19(金) 10:38:32
84 :
デフォルトの名無しさん:2010/05/05(水) 20:37:19
最近使い始めたけど、何これ超楽w
もう他じゃ無理w
HTTPより簡単?
比較対象が違う
実際の通信にHTTP使ってる場合も多いし
HTTPの上のレイヤ
テストも兼ねて、.NET4.0のWCFを試してみたんだけど、4.0のWCFが使い物にならない…。ナニコレ。
BindingでCustomBindingを指定して、GZip有効にすると3.5でOKなのに4.0だとエラー吐くとか、もうね。orz
# SP1待ちか?
とりあえず3.5止まりッス。うぇうぇうぇ。
WCFってlinuxのpostgresとかのDBとは通信できないの?
>>89 PostgreSQLのDBサーバ〜クライアントライブラリ間は、TCP/IP上の「独自プロトコル」で会話している。
これはMySQLやDB2のような他のRDBも同じ構造。そして、この独自プロトコルをWCFのサービス定義に
対応付ける(マッピングさせる)ことは技術的に非常に困難だから、(対Linuxプラットフォームに限らず)
・WCFで外部世界のDBと直接通信する「汎用的な方法」は存在しない。
次に、現実に要望があった場合、実際にはどうやって実現させるについて。一般的な言い方をすれば、
・PostgreSQL上で構築されているデータモデルにSOAPサービスを追加実装&公開し、
このSOAPサービスをWCF(Windows)側からアクセスさせる
ことによって実現できる。注意すべきは、個別のデータモデルごとにSOAPサービスを定義&実装する
必要があるということ(汎用的な方法は存在しない)。SOAPサービスの実装方法については、
Linuxであれば、たとえばRubyを使うのことを勧める。Rubyなら標準ライブラリにSOAPサーバ機能(SOAP4R)が
含まれているし、あるいはRuby on RailsのActiveResourceと呼ばれるSOAP向けフレームワークを利用できる。
などと、ここまで説明してきたけど、かなり面倒だよ。WCFは「Windows諸島という絶海の孤島」で
Win同士が会話することに特化して異常進化したものだから、外部世界との通信の実装には高いスキルが要求される。
だから、素直に(WCFではなく)C#向けPostgreSQL APIを使って開発するのが、単純/簡単/高速/トラブル無しで済む。
言い換えると、ガラパゴス諸島へ移住する気がないのなら、WCFの勉強は無駄・無駄・無駄www
WCF叩いてるように見えて、ちゃんと読むとマンセーしとるw
PostgreSQLのDBから取りだすものをGrassFishにNetBeansで作ってC#で読む、というのをやってる
まあ直接やった方が楽ではあるな
93 :
デフォルトの名無しさん:2010/10/28(木) 07:40:06
WCFなんて特に語ることないだろ。スレなんて立てるな。
WCFでP2Pファイル共有システムを構築したいのですが何かアドバイスください。
基本的にはユーザー側のアップロードが出来ない仕様でトップダウンという
形でファイルだけを受け取れる様にしたいです。
色々独自で調べたのですがいまいちピンと来ないです。
96 :
デフォルトの名無しさん:2011/11/20(日) 14:25:48.38
ピンと来ないですね。
97 :
デフォルトの名無しさん:2012/03/03(土) 00:00:27.35
.NET 3.5 を使用していますが、メモリリークが激しく、1ヶ月の連続使用にも耐えられません
98 :
デフォルトの名無しさん:2012/06/28(木) 16:57:07.18
32bitアプリと64bitアプリ間のIPC(名前付きパイプ)を、業務の必要で作ったんだけど、
なんか異空間を結ぶ霊界通信みたいで面白かった。
普通はお互いの存在すら知ることができないのに。
99 :
デフォルトの名無しさん:2012/09/21(金) 20:38:52.50
HTTPBindingで利用してて、初回の接続の遅さと
しばらく放置した後の接続の遅さがよくわからん。
一回コネクション確立できたら次からサクサク、コネクションがタイムアウトになると
再度コネクション作るのに時間かかる
こんなイメージなのか
?
質問です
WaitForSingleObjectの反対の関数ってないですかね
非シグナル状態になるまで待機させたいのです
よろしくおねがいします
引数変えればいいはず
商用利用するサービスを構築するために、
バックエンド側にある、WCFサービスを実装するコンピュータにはWindows Serverが必要なの?
それともデスクトップWindowsでOK?