1
我需要实现在.NET的桥梁应用程序，它，在一个较高水平，主持一个WCF服务或让消费者主持一个？
-
在背面会谈的OCR系统
- 向他们发送图像和找回数据从图像可读格式
- 在前面，应用程序会使用桥接服务（WCF或其他方式）提交图像并期望可读数据作为响应。
整个操作将是异步模式。
将被消耗桥的服务的应用程序可以是.NET或Java主要基于。 （有可能是在未来现有的大型机应用程序太的可能性）
我的问题是关于解决发回可读的数据返回给消费应用程序。由于WCF回调不能与Java互操作，因此我无法使用wsDualHttpBinding。因此，2层的替代品，我目前看到的是：
- 一）有托管在其消费 应用程序可查询的桥梁另一个Web服务。
- 二）让每个消费者应用程序主机基于通过自己的技术桥梁提供的 标准化WSDL web服务。 然后，桥接器将在其数据准备就绪时使用应用程序的web服务。
我有两个选项的问题是：
- 有了），轮询始终是资源密集型的，但消费者 应用程序只需要消耗此WebService（生成自己 代理类） 。
- 用b，对于每一个需要注册 与网桥应用，他们需要创建自己的Web服务。这个 似乎没有像SOA架构推荐的那样如此松散耦合。
我的问题是，哪一个更适合保持系统的可扩展性和可扩展性？ 有没有其他的方法来实现这一点？
你真的应该提到，你是拉皮条自己的项目... – ErnieL
我拉皮条吧:)它是免费的，所以没有钱从中获益 – rpgmaker