计算机电话集成软电话架构问题
我正在开发一个伪统一通信中间层解决方案（在线状态和呼叫控制）的项目，利用 Genesys 作为后端，该后端是 CTI 解决方案提供商 (www.genesyslab.com)。该解决方案的前端可以是一个基于 Web 的应用程序（尽管我的公司是 Microsoft 商店，但最好不要使用 ActiveX）
Genesys 使用基于套接字的通信，并且通信是异步的。例如，我向 Genesys 发送拨打电话的请求，Genesys 会响应一个事件，指示正在拨打并建立电话呼叫。
基于我在 n 层设计方面的有限经验，到目前为止，我设想的是一个 Windows 服务来处理与 Genesys 的套接字通信并维护环境中所有调用活动的状态。接下来，我看到一个 WCF 服务与 Windows 服务进行通信，以向基于 Web 的客户端提供有关调用状态的详细信息（使用基本或 ws 绑定）。这将使我不再使用 ActiveX，但需要轮询，因此很可能我会有多个具有负载平衡的 WCF 实例来共享负载。
我走在正确的轨道上吗？ WCF 可以与 Windows 服务通信并为客户端提供服务吗？任何其他架构方法建议将不胜感激！
此致， 贾森
I'm working on a project where I'm developing a pseudo Unified Communications middle tier solution (Presence & Call Control) utilizing Genesys as a backend which is a CTI solution provider(www.genesyslab.com). The front end of the solution could be a web based application (Prefer not to use ActiveX although my company is a Microsoft shop)
Genesys uses socket based communication and communication is asynchronous. For example I send a request to place a phone call to Genesys and Genesys responds with an event indicating that the phone call is being dialed, and established.
Based on my limited experience with n-tier design, what I'm envisioning so far is a windows service to handle the socket communication to Genesys and maintain state of all call activity in the environment. Next I see a WCF service communicating to the windows service to provide details about call state to web based clients (using basic or ws binding). This would allow me to get out of using ActiveX, but would require polling so most likely I would have multiple WCF instances with load balancing to share the load.
Am I on the right track? Can WCF communicate to a windows service as well as provide service to clients? Any other architectural approach suggestions would be greatly appreciated!
Best regards,
Jason
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您当然可以实现一个 WCF“网关”服务，将 CTI 协议实现公开为 WCF 友好的 SOAP Web 服务。如果 CTI 协议依赖于有状态连接，则将其实现为无状态 SOAP Web 服务可能会很困难。但是，根据您选择的客户端技术，这可能不是必需的。
ActiveX 控件与登录用户具有相同的权限。因此，它可以创建到 CTI 后端的 TCP/IP 或 UDP 套接字连接，从而完全不需要 WCF。
如果您使用 Silverlight（我强烈推荐它而不是 ActiveX），那么您将需要 Silverlight 应用程序具有更高的信任度，以便在任意端口上创建套接字连接。通常，Silverlight 应用程序只能在端口 4502-4534 上创建套接字连接 ，但具有更高信任度的 Silverlight 应用程序可以使用任何端口。
Silverlight 通常比 ActiveX 拥有更好的“声誉”，但实际上，ActiveX 和 Silverlight 都需要您的客户足够信任您才能安装某些内容。
You could certainly implement a WCF "gateway" service that exposes the CTI protocol implementation as a WCF-friendly SOAP web service. If the CTI protocol depends on stateful connections, this could be tricky to implement as a stateless SOAP web service. However, depending on your choice of client-side technology, this might not be necessary.
An ActiveX control has the same permissions as the logged on user. So it could create TCP/IP or UDP socket connections to the CTI back end, avoiding the need for WCF altogether.
If you use Silverlight (which I would highly recommend over ActiveX) then you would need the Silverlight application to have elevated trust in order to create socket connections on arbitrary ports. Ordinarily, a Silverlight application can only create socket connections on ports 4502-4534, but a Silverlight application with elevated trust can use any port.
Silverlight generally has a better "reputation" than ActiveX, but in reality, both ActiveX and Silverlight will require your clients to trust you enough to install something.
除了“中间层”WCF 服务之外，您还应该让 Windows 服务托管 WCF 服务。这将是 WCF 服务与 Windows 服务通信的最简单方法。此 WCF 服务只能通过中间层服务调用来与电话集成交互。
为了恢复能力，您实际上可以将端点设置为集群或路由服务端点，这将允许您相对无缝地引入 Windows 服务的故障转移。
此外，我通常会避免 WsHttpBinding，因为它会增加大量开销，以实现启用功能的好处，而不是通常不需要
In addition to the "middle tier" WCF services you should make the windows service host a WCF service too. This would be the simplest way for the WCF services to talk to the Windows Service. This WCF service would only be called via the middle tier services to interact with the telephony integration.
For resilience you could actually make the endpoint a cluster or a routing service endpoint this would allow you to introduce failover of the windows service relatively seemlessly
Also I'd avoid WsHttpBinding generally as it adds a lot of overhead for the benefit of enabling functionlity that isn't commonly required