Code Library

Building Communications Solutions with UCMA Although the Lync SDK is used to integrate communications functionality into applications that
run on the client, UCMA is typically used to build communications applications that run on the
server; for example, hosted in Internet Information Services (IIS), exposed through Windows
Communication Foundation (WCF), or running in a Windows Service. A UCMA application is
usually a long - running process such as an automatic call distributor used to handle and distribute incoming calls in a call center. Users interact with the UCMA application via an endpoint that can either be a contact in Lync, such as sip:HelpDesk@fabrikam.com , or simply a phone number. The user can start a Lync call, instant message with the UCMA application contact or dial the phone number associated with the application.

Consider the following scenario where Contoso, a fictitious company, uses a UCMA - based
application to run its call center operations.

When customers call Contoso’s customer service phone number, the UCMA application picks up the calls and guides callers through a workflow, such as one built with the UCMA Workflow SDK, to gather information from them such as the reason for their call, their account number, and so on. After the workflow gathers the necessary information from the callers, it places them on hold and searches for an agent with the right skills to assist them. Customers remain on hold until an agent becomes available; the UCMA application tracks all the agents ’ Lync presence so it knows when an agent becomes available again to handle a call.

When an agent picks up calls, he or she already knows a lot about the callers based on the information they provided. An Agent Dashboard application hosted in the Lync conversation window can display information about the caller such as order history or any open customer service tickets that require attention. The agent can use this information to provide better service to the customer.

An application such as the customer service Agent Dashboard is built using the Lync SDK, including the Lync controls and the Lync API. The UCMA application interacts with the Agent Dashboard using the Context Channel, a new feature in UCMA 3.0 that provides a channel across which a UCMA application and Lync SDK application can send information to each other. For example, if the agent realizes that he needs to consult another agent to help with the call, he can issue an “ escalate ” command from the Agent Dashboard application. The command is sent across the context channel to the UCMA application, which knows how to process it and look for another available agent with the necessary skills to assist with the call.

Part of a supervisor ’ s duties in Contoso ’ s customer service department is to monitor the performance of agents and coach them on how to provide better service to customers. The supervisor can launch a Supervisor Dashboard application that shows a list of all active calls. The supervisor selects a call to silently join, allowing him to monitor the call without the knowledge of either the customer or agent. The new audio routes functionality in UCMA 3.0 enables developers to build routes across which audio can travel in a conference, effectively controlling who can hear what. When the supervisor is monitoring a call, audio flows to her from the conference but doesn’t flow back in, allowing her to listen in to a call without being heard. If the supervisor needs to provide coaching to the customer service agent, an audio route is established from the supervisor to the agent, allowing her to “ whisper ” to the agent without the customer hearing any of the conversation.

UCMA 3.0 includes several other enhancements that are covered in more detail later in the book, including an easier development experience for working with presence and conferences, and a
feature known as auto - provisioning, which greatly simplifies the process of managing the plumbing and configuration information required to run a UCMA application.

Source of Information : Wiley - Professional Unified Communications Development with Microsoft Lync Server

Adding Context to Conversations The context of a conversation refers to the subject or topic of the conversation; the Lync API provides some mechanisms for embedding context directly into a conversation, allowing the participants to immediately know what a new conversation is about.

A great example of adding context to a conversation is the “ Reply by IM ” feature in Microsoft Outlook that allows you to respond to an email message using Lync. The message recipient sees the subject of the original email message in the incoming conversation notifi cation window (also known as the toast) and as the title of the conversation window. When the person receives the instant message, she knows right away what you are contacting her about.

The Lync API introduces the concepts of Launch Link context and Lync Extensibility Window context that you can use to enhance the communications capabilities of your applications by embedding context into the conversations started by the application.

Launch Link context allows conversation recipients to launch applications directly from the Lync conversation window. For example, you select a customer account when working with a CRM application; after selecting the account, you can see the account manager ’ s presence and are able to start an instant message or audio conversation with her directly from the application. The
conversation that the account manager receives contains a link that she can use to launch the CRM application directly from the conversation window. The contextual data payload supplied with the conversation also includes information about the particular account that you are contacting her about. The user can launch the CRM application and automatically load the customer account record in question.

Lync Extensibility Window context allows you to host Silverlight or Web applications in the Lync conversation window. When a person receives a conversation that includes Lync Extensibility Window context, the Lync conversation window expands to host the specified Silverlight or Web application. The application hosted in the Lync conversation window enhances the conversation by providing additional services to it not available in the out - of - the - box Lync experience.

Launch Link and Lync Extensibility Window context are often combined to provide an end - to - end contextual conversation experience to the user. For example, a developer working in Visual Studio can highlight a section of code — using a Visual Studio add - in — and learn which team member authored that section of code. The Lync controls are used to show the team member ’ s presence and, if she is available, start a conversation with her. When she receives the conversation, you can use Lync Extensibility Window context to display the section of code in question in a Silverlight application hosted in the Lync conversation window. If the developer needs to modify the code, you can use Launch Link context to include a launch link in the Lync conversation that allows her to start Visual Studio and automatically open the project containing the code.

You can build two main types of applications to run in the Lync conversation window. The first is a companion application, such as a translation application that provides two - way translation of an
instant message conversation. This type of application interacts with the conversation but doesn ’ t depend on it for startup parameters; the user can start this application as needed from the Lync conversation window. The other type of application depends on the conversation it is hosted in to provide the necessary startup parameters; for example, when a customer service agent in a call
center receives a call, a Silverlight application automatically loads in the Lync conversation window and uses the caller ’ s phone number to look up the customer record and display information, such as the recent order history to the agent.

The contextual conversation functionality provided by Launch Link context and Lync Extensibility Window context allows you to inject contextual data into conversations, providing for a richer and more efficient conversation experience that ensures that participants always have access to the contextual application data that they need.

Source of Information : Wiley - Professional Unified Communications Development with Microsoft Lync Server

Working with Lync UI Suppression When the Lync client is confi gured to run in UI Suppression mode, its interface is completely hidden from the user. Applications that use Lync UI Suppression are responsible for recreating those user interface elements from scratch. The Lync API with Lync running in UI Suppression mode is the recommended development pattern for applications you would have previously built with the UCC API.

Lync UI Suppression requires that the Lync client is installed on the user ’ s machine; this eliminates the complexity of managing the connectivity of the application back to the Lync server infrastructure. In UI Suppression, you use the Lync API to replicate some of the functionality available in the Lync client, such as signing users into Lync, retrieving their contact list, and starting and responding to conversations in different modalities.

When working with UI Suppression, you interact with conversations at the modality level —activating individual modalities manually, creating conversations, adding participants, and disconnecting the modalities when the conversation is completed. For example, you can build a Silverlight instant messaging client that provides a completely customized user interface for instant message conversations. In this case, you would be responsible for recreating application functionality and user interface elements such as a contact list and conversation window. You would work directly with the instant message modality, creating a conversation, connecting the modality, sending instant message text to participants, notifying participants when someone is typing, and delivering the instant message text to the participants in the conversation.

Using the Lync API with Lync running in UI Suppression mode, you can build compelling Lync - replacement solutions such as a custom instant messaging client, or a dedicated audio/video conferencing solution.

Source of Information : Wiley - Professional Unified Communications Development with Microsoft Lync Server

Integrating Lync Functionality into Your Applications Using the Lync Controls Think of the Lync client as being built out of LEGO blocks, each providing a specifi c piece of functionality such as showing the presence of contacts, organizing contacts into groups, and interacting with contacts by starting instant message or phone conversations. The Lync controls separate the functionality in Lync clients into individual controls that developers can drag and drop into their Windows Presentation Foundation (WPF) or Silverlight applications.

The Lync controls include a control to show the presence of a contact; for example, the presence of an account manager in a CRM system. Controls are also available to easily start an instant message or audio conversation with that contact at the click of a button. with no additional code required. A set of other controls provides functionality for managing contact lists; for example, to integrate the user ’ s Lync contact list into an application. You can also use custom contact lists to create and display an ad - hoc list of contacts, such as the account team for a client in a CRM application. Additional controls are available to search for contacts and display the results. Controls are also available to set the current user ’ s presence, personal note, and location.

Due to their obvious dependence on user interface elements of the Lync client, the Lync controls are not available in UI Suppression mode.

Integrating Lync functionality into applications using the Lync controls allows users to launch communications directly from the application that they are working in without needing to switch to the Lync client. The Lync controls are available in WPF and Silverlight and are extremely easy to use; you only need to drag and drop the appropriate controls into the application, and they work without the need for any additional code.

Source of Information : Wiley - Professional Unified Communications Development with Microsoft Lync Server

BUILDING COMMUNICATIONS APPLICATIONS WITH THE LYNC SDK The Lync 2010 SDK includes the Lync controls, a set of Silverlight and Windows Presentation Foundation (WPF) controls that you can use to integrate functionality found in the Lync client directly into your applications.

The SDK also includes the Lync application programming interface (API), a brand - new, managed API for building custom communications solutions. The Lync API is intended to replace the IMessenger and UCC APIs available with Office Communications Server 2007 R2. The IMessenger API was easy to get started with, but was fairly limited in functionality; it was also a little cumbersome to troubleshoot because it used COM interoperability to interact with the running instance of Communicator on the user ’ s machine.

The UCC API was very difficult to get started with in comparison, but it provided the most power and functionality if you wanted to build a Communicator replacement. Unlike the UCC API, the Lync API requires the Lync client to be running — it reuses the connection that the client has established with the Lync infrastructure. You can configure the Lync client to run in UI Suppression mode — where its user interface is invisible to the user — enabling you to build custom communications clients previously only possible when using the UCC API.

Source of Information : Wiley - Professional Unified Communications Development with Microsoft Lync Server

LYNC PRODUCT OVERVIEW So, what is Lync? Microsoft Lync Server 2010 is the successor to Offi ce Communicators Server, and Live Communications Server before that. Although most people might be familiar with Lync as an enterprise instant messaging solution, it ’ s a lot more than that when you take advantage of all the features it has to offer.

Lync adds value to the Microsoft applications that you use every day: Office and SharePoint. It provides a unified communication and collaboration experience across Office and SharePoint, providing the same way to start an instant message, audio call, or desktop sharing session with a contact regardless of the application you are working in. The new Lync client (the replacement for Microsoft Communicator) enables you to connect with people within your organization by allowing you to perform a skills search to find coworkers with a particular skill. The Lync skills search queries users ’ My Sites for skills that they have indicated expertise in.

Lync provides a built - in conferencing solution that you can use to schedule and host online meetings with contacts both inside and outside your organization. Online meetings are easy to create by scheduling them in Outlook, or by selecting a list of contacts in Lync and starting an ad - hoc meeting. For users outside your organization who don ’ t have the Lync client installed, the Lync Web App — the successor to LiveMeeting — enables them to join your online meeting and participate in your application sharing session. Attendees can dial in to a conference call, or have the Lync Web App call them back on a number they provide. A new conference lobby experience allows presenters and the meeting organizers to exercise more control over the online meeting by notifying them when people outside the organization join the meeting and providing them with the option to admit these visitors (or not) into the meeting.

The following is a brief overview of the new features available to administrators. The Microsoft Lync Server 2010 Control Panel is a new Silverlight - based tool for administering a Lync deployment; it includes functionality to :

» Manage users
» Manage the various servers in the Lync topology
» Confi gure instant messaging and presence
» Create and maintain voice dialing plans
» Confi gure conferencing
» Monitor the quality of service in the deployment
» Adjust bandwidth utilization

Administrators can alternatively use PowerShell to execute management scripts in the topology. The Lync Server Management Shell provides an experience that Exchange and SharePoint administrators are already familiar with from managing their environments using PowerShell.

Now that you know a little bit about the functionality offered by Microsoft Lync Server 2010, it ’ s time to learn about the development tools that you use to build communications functionality into your applications.

Source of Information : Wiley - Professional Unified Communications Development with Microsoft Lync Server

Getting Used to Life Without a Big Design As Scrum teams begin to become adept at the technical practices, they will naturally begin to shift further away from anticipating users' needs and more toward adapting to them. This will result in a number of changes for the agile architect or designer to become accustomed to. The new realities caused by this shift include the following:

• Planning is harder. Estimating, planning, and committing to deliverables is already hard; it becomes more difficult in the absence of an up-front design. A lot of thinking goes into creating an up-front design. Some of that thinking is helpful in estimating how long things will take and in combining estimates into plans. The upside to forgoing the big up-front design, however, is that the work that needs to be estimated is often simpler so that individual features can be estimated more quickly and easily.

• It is harder to partition the work among teams or individuals. Having a big, up-front design in hand makes it easy to see which features should be developed simultaneously and which should be developed in sequence. This makes it easier to allocate work to teams or individuals.

• It is uncomfortable not to have design done. Even though we've always known that no up-front design can be 100% perfect, we took comfort in its existence. "Surely," we reasoned, "we've thought of all the big things so any changes will be minor."

• Rework will be inevitable. Without a big up-front design, the team will certainly hit a point where it needs to undo some part of the design. This two-steps-forward-one-step-back aspect of iterative development can be unsettling to professionals trained to identify all needs and make all design decisions up front. Fortunately, refactoring and the automated tests created during test-driven development can keep most rework efforts from becoming very large.

Doing a large, up-front design became popular because of the belief that doing so would save time and money. The cost of the up-front design plus the cost of adjustments was viewed as less expensive than the many small changes necessary with emergent design.

In the past, it was entirely possible that doing a large, up-front design would save time and money. After all, Barry Boehm demonstrated in Software Engineering Economics (1981) that defects are more expensive to fix the later in the development process they are discovered. But the technical practices employed by good Scrum teams can dramatically alter the equation. When a team uses good technical practices—test-driven development, a heavy reliance on automated unit tests, refactoring, and pair programming among them—it may find itself in the situation where it is cheaper to adapt to user needs by reworking the application more often than it is to anticipate those needs and rework only occasionally.

In traditional development there is a large cost on upfront analysis and design. This investment keeps down the number of later changes. But when a change is needed, it is relatively expensive to make because the change violates the primary assumption that change will be largely unnecessary. By contrast, the Scrum view shows many more changes, but the size of each bit of rework is smaller. This is the result of anticipating that change will be needed, but not knowing exactly where. Because of that, a Scrum team pursues technical excellence, always keeping the code well factored, with as simple a design as possible, and with a suite of automated tests for early detection of regression problems. So, while there are more occasions for rework, each is less of a setback.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

Pair Programming Pair programming is the practice of having two developers work together to write code. It originated from the idea that if occasional code inspections are good, constant code inspections are better. Many of the practices just described are made easier through the use of pair programming. Learning how to do test-driven development is made easier when working together. Feelings of collective ownership are created when code is produced in pairs. And having the discipline to leave the code cleaner than you found it comes easier when another developer is sitting beside you.

Clearly, there are some benefits to pair programming. That's why I invented it. OK, I didn't really invent it, but I like to think I did. I did happen across it out of true necessity, which is, after all, the mother of invention. In 1986 I was hired by Andersen Consulting in its Fos Angeles office. On my first day on the job I completed a skills survey. I marked myself as "proficient" with the C programming language, even though I was very much a beginner at the language. But, I reasoned, I'm studying it every night after work, and I will be proficient by the time they read this skills survey. Unfortunately for me, they read the survey the next day. And on the day after that I was on a plane from Fos Angeles to the New York office to a project that desperately needed C programmers.

After arriving in New York, I met another programmer who had also been transferred because he knew C. I knew I couldn't deceive him, so I came clean and confessed my exaggeration on the skills survey. "Ugh," he said, "I lied, too." Our solution was that we would work together—pair programming, although we didn't call it that. We figured that between us we were as good as one "proficient" C programmer. And, we reasoned, if we worked together on everything, they wouldn't know which of us to fire.

It worked like a dream. He and I worked together for much of the next eight years at three different companies, pairing as much as possible, especially on anything difficult. We wrote some amazing and incredibly complex products, always with low defect rates W e also felt that even though there were two heads for every pair of hands on the keyboard, we were highly productive when working this way.

Since those early, positive experiences with pair programming, I've been hooked. I knew it was a good way to write code. On the other hand, many of us in this industry (myself included) were first attracted to this work because we could sit in a cubicle with our Sony Walkman playing (yes, it was that long ago) and not have to talk with anyone all day. Even now, there are days when I enjoy nothing more than listening to some loud music on my headphones while code is flowing from my fingers as fast as I can type. Because I still relish those days, I have a hard time ever mandating to a team that they must do pair programming 100% of the time.

Fortunately, most teams have realized that the vast majority of the benefits of pairing can be achieved even when it is not done all day, every day. So, when coaching teams, I always push them to adopt pair programming on a part-time basis; use it for the riskiest parts of the application. I encourage teams to find the guidelines that help them pair enough, while stressing that enough is somewhere greater than 0%, but also acknowledging that I can understand the reasons they may have for wanting it to be less than 100%.

There are many advantages to pair programming, even for teams who do it less than 100% of the time. Although most studies show a slight increase in the total number of person-hours used when pairing, this is offset by a decrease in the total duration of the effort. That is, while pairing takes more person-hours, fewer hours pass on the clock (Dyba et. al 2007). Although projects are always under financial pressure, the overriding concern is not so much person-hours as time to market. Pair programming has also been shown to improve quality. In a survey of studies, Dyba and colleagues found that each study showed an improvement in quality with pair programming. Additionally, pair programming facilitates knowledge transfer and is an ideal way to bring new developers up to speed on the application. It is also an effective practice for working in uncharted territory or solving difficult problems in known parts of the system.

"It costs more; I don't want to pay two programmers to do the job of one . "

Pair programming will cost more in the short term. However, that additional initial cost may very likely be paid back with shorter schedules and with higher quality, leading to lower maintenance costs down the road. Rather than take industry studies as your proof either way, prove this to yourself. Pair on the most difficult modules and see if they have fewer defects and are easier to maintain later, perhaps in comparison to similar modules from other programs done without pair programming.

" We're in a hurry. We can't have two programmers on one task."

Actually, if you're in a hurry this is the time you need pair programming the most. I've already mentioned that pairing leads to shorter project durations (while increasing overall effort, or person-hours). Additionally, there is even some evidence (Williams, Shukla, and Anton 2004) that pairing is an effective way to counter Brooks' Law ("adding manpower to a late software project makes it later"). In other words, if you have an aggressive deadline or are tempted to add people to a late project, these are ideal times to incorporate pair programming.

" When working on a tough problem , I need some quiet time to think through the problem."

Talk with your pairing partner and agree to separate for an hour or whatever you need to think through the problem. When you resume pairing, start by sharing any insights either of you had.

Thing To Try Now
In your next sprint planning meeting, commit to doing some pairing. Make the commitment explicit by adding tasks to the sprint backlog: " Mike and Bob pair for t w o hours," " Mike and Mehta pair for an afternoon," and so on. This is a good way to at least get comfortable with pairing. It is too easy to put off pairing with a vague commitment to try it sometime in the near future. Having tasks in the sprint backlog, though, acts as a constant nagging reminder, and, as a result, is much more likely to result in action.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010

Code Library

Categories