1
我需要實現在.NET的橋樑應用程序，它，在一個較高水平，主持一個WCF服務或讓消費者主持一個？
-
在背面會談的OCR系統
- 向他們發送圖像和找回數據從圖像可讀格式
- 在前面，應用程序會使用橋接服務（WCF或其他方式）提交圖像並期望可讀數據作爲響應。
整個操作將是異步模式。
將被消耗橋的服務的應用程序可以是.NET或Java主要基於。 （有可能是在未來現有的大型機應用程序太的可能性）
我的問題是關於解決發回可讀的數據返回給消費應用程序。由於WCF回調不能與Java互操作，因此我無法使用wsDualHttpBinding。因此，2層的替代品，我目前看到的是：
- 一）有託管在其消費 應用程序可查詢的橋樑另一個Web服務。
- 二）讓每個消費者應用程序主機基於通過自己的技術橋樑提供的 標準化WSDL web服務。 然後，橋接器將在其數據準備就緒時使用應用程序的web服務。
我有兩個選項的問題是：
- 有了），輪詢始終是資源密集型的，但消費者 應用程序只需要消耗此WebService（生成自己 代理類） 。
- 用b，對於每一個需要註冊 與網橋應用，他們需要創建自己的Web服務。這個 似乎沒有像SOA架構推薦的那樣如此鬆散耦合。
我的問題是，哪一個更適合保持系統的可擴展性和可擴展性？ 有沒有其他的方法來實現這一點？
你真的應該提到，你是拉皮條自己的項目... – ErnieL
我拉皮條吧:)它是免費的，所以沒有錢從中獲益 – rpgmaker