MSDN Magazine - January 2009 - (Page 78)

Business Service integration The call center solution, just like any LOB application, needs to be integrated with data that may be stored in a relational database. I will use Web services as a vehicle for this integration. Caching For a better user experience, I will cache the information locally in memory as well as on the disk. The cached information may include the XML files that indicate the rep’s prompter scripts and other reference data that may not change often. Security Application security is a fundamental requirement of this kind of application. The security includes authentication, authorization, privacy of data in flight and at rest, and user profilebased data trimming. integration with the Cloud Services Integration with a cloud-based foundation service, such as storage service, requires special server-side infrastructures. This is so that the use of cloud services can be closely monitored and throttled for accountability and service levels. I will cover integration with business services, application security, cross-domain policies for Web services, and application partitioning in Part 2 of this article. Push Notifications with Socket Server Screen pop is one of the fundamental requirements of a call center application for transferring call context from the telephony infrastructure to an agent’s screen. The transferred call context may include any information spoken (for IVR systems) or keyed in by the phone-in customer. The notification can be sent to the Silverlight application within the browser in one of two ways: through client polling or server push. Polling is fairly easy to implement, but it may not be the optimal choice for call center scenarios where state synchronization between the telephony events and the client application has to be precise. It is for that reason that I will use push notifications using Silverlight sockets. One of the important capabilities of Silverlight is communication with TCP sockets. For security reasons, Silverlight only allows the connections to the server ports in the range of 4502 to 4532. This is one of the many security policies implemented in the sandbox. Another important sandbox policy is that Silverlight can’t be Call Center Client (localhost:1041) 1. Socket.ConnectAsync() 7. Connected Socket 1. Socket.ConnectAsync() 7. Connected Socket Call Simulator (localhost:1042) Silverlight Runtime a listener and, hence, cannot accept inbound socket connections. For these reasons, I am going to create a socket server listening on port 4530 and maintain a pool of connections with each connection representing an active call center rep. The Silverlight socket runtime also enforces cross-domain optin policies on the server for all of the socket connections. When Silverlight application code attempts to open a connection to an IP endpoint on an allowed port number, opaque to the user code, the runtime will make a connection to an IP endpoint on the same IP address with the port number 943. This port number is hardwired to the Silverlight implementation and can’t be configured by applications or changed by the application developer. Figure 1 shows where the policy server fits into the architecture. When Socket.ConnectAsync is called, the message flow sequence is as shown in Figure 3. By design, messages 2, 3, and 4 are totally opaque to the user code. I need to implement a policy server on the same IP address as the call manager server. I could implement both the servers in a single OS process; however, for simplicity’s sake I will implement them in two separate console programs. These console programs can easily be converted to Windows services and made clusteraware for failover to provide reliability and availability. Asynchronous I/O Loops The .NET Framework 3.5 introduced new async programming API to sockets; these are the methods that end with Async(). The methods I will be using on the server are Socket.AcceptAsync, Socket.SendAsync, and Socket.ReceiveAsync. Async methods are optimized for high throughput server applications through the use of I/O Completion Ports and effective receive and send buffer management through the reusable SocketAsyncEventArgs class. Because of the fact that Silverlight is not allowed to create TCP listeners, its Socket class only supports ConnectAsync, SendAsync, and ReceiveAsync. Silverlight only supports an asynchronous programming model, and that’s not just for socket API but for any network interaction. Since I will be using an async programming model on the server as well as on the client, let’s get comfortable with the design patterns. One recurring design pattern is the I/O loop, which is ap- 2. R equ e ol st P icy pon se Policy Server (port 943) 3. Policies XML 4. P olic es yR clientaccesspolicy.xml 5. C 6. C onn onn ect Soc ke t ect ed Call Manager Server (port 4530) Figure 3 Silverlight Runtime Requests Cross-Domain Policy Automatically for Socket Connections 78 msdn magazine Silverlight Enterprise Apps

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.