Non-centralized app design - Good idea?
-
I am building a TAPI client for the company I work for. One of the planned features is to be able to see the active calls of the other employees within a group (Call center environment). I do not want to use a centralized system where a server handles everything, and having a server that just aggregates and distributes the information to the clients seems silly. The plan I have in my head right now is for each client to issue a broadcast of their individual updates, and to listen for broadcasts from the other clients and reflect the updates of others on screen. There would also be a client that monitors queues and broadcasts the information of the calls. The advantage that I seen in doing this, is that there is no single computer that can fail and prevent the clients from functioning. The disadvantage is that if a client fails, the status information becomes stale for the lost computer and any calls that were handled by the client that are not owned by an extension (such as parked calls) would then be lost to the restarted client. Is my design completely flawed? How could I make it better?
-
I am building a TAPI client for the company I work for. One of the planned features is to be able to see the active calls of the other employees within a group (Call center environment). I do not want to use a centralized system where a server handles everything, and having a server that just aggregates and distributes the information to the clients seems silly. The plan I have in my head right now is for each client to issue a broadcast of their individual updates, and to listen for broadcasts from the other clients and reflect the updates of others on screen. There would also be a client that monitors queues and broadcasts the information of the calls. The advantage that I seen in doing this, is that there is no single computer that can fail and prevent the clients from functioning. The disadvantage is that if a client fails, the status information becomes stale for the lost computer and any calls that were handled by the client that are not owned by an extension (such as parked calls) would then be lost to the restarted client. Is my design completely flawed? How could I make it better?
Like you've noted, the state management issue is going to be a killer. Other "desirables" that are going to be difficult to implement with a distributed model are reporting on BI things (stats/metrics), and tiered support, call handover... I'd focus on the advantage (resiliance/reliability) and see if you can get that by a more traditional means, such as clustering or redundancy.
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games. -
I am building a TAPI client for the company I work for. One of the planned features is to be able to see the active calls of the other employees within a group (Call center environment). I do not want to use a centralized system where a server handles everything, and having a server that just aggregates and distributes the information to the clients seems silly. The plan I have in my head right now is for each client to issue a broadcast of their individual updates, and to listen for broadcasts from the other clients and reflect the updates of others on screen. There would also be a client that monitors queues and broadcasts the information of the calls. The advantage that I seen in doing this, is that there is no single computer that can fail and prevent the clients from functioning. The disadvantage is that if a client fails, the status information becomes stale for the lost computer and any calls that were handled by the client that are not owned by an extension (such as parked calls) would then be lost to the restarted client. Is my design completely flawed? How could I make it better?
I'm not sure what Mark specifically is suggesting but in general his comments seem to be an improvement over what you posted. One interpretation of what he said is that taking a simpler strategy, e.g., a single server, and using standard tools to account for resilience, redundancy etc. On the other hand your post tends to sound like a peer to peer system. Perhaps you should find and study some technical information about P2P designs and issues. You may find some of the information/issues match your situation and gain some insight on the architecture and it's associated benefits and drawbacks.
led mike