Computer Telephony Integration Softphone Architectural Question

I'm working on a project where I'm developing a pseudo Unified Communications middle tier solution (Presence & Call Control) utilizing Genesys as a ba开发者_Python百科ckend 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

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.

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