Federated enterprise and cloud-based collaboration services

Federated Enterprise and Cloud-based Collaboration Services John Buford, Kshiteej Mahajan, Venkatesh Krishnaswamy IP Communications Dept. Avaya Labs Research Basking Ridge, NJ 07920, USA Abstract—Because of the variety of types of collaboration services used in enterprises today, there is difficulty in integrating related work threads from different collaboration environments. Each collaboration tool differs in storage model, APIs, content organization, content addressing, content formats, user authentication, and user interface. Nevertheless users prefer to be able to choose which collaboration tool they use for a given interaction, and over the course of long-term collaboration, will typically use a variety of tools, including email, instant messages, wikis, blogs, web conferences, and shared documents. The solution presented here is to provide a federated integration of these different collaboration tools to make content access and transfer straight forward between different systems. Additionally, we enable the user to achieve this federation by working directly in the client application of their choice; we illustrate this with plug-ins for MS Outlook, Internet Explorer and Skype. Our architecture integrates both desktop and servercentric tools. Additionally it is now possible to use hosted collaboration services in the cloud. This further complicates the ability to federate collaboration tools because of requirements to protect enterprise information and information flows. We present an architecture to address the federation of cloud-based collaboration services. Keywords-Collaboration tools; cloud-based enterprise communications; application federation computing; I. INTRODUCTION Many enterprise collaborations start informally, such as an idea communicated via a phone call, instant message or email. Then the idea is discussed further, perhaps through additional emails. Documents might then be created and shared between the collaborators. When the goals and issues are clearer, other collaborators might become involved, through email, collaborative document authoring, or web conferences. Throughout this process, today’s enterprise users work with multiple collaboration and communication tools from different vendors. First, collaborations may involve outside vendors and customers, who may have different tools. Additionally there is currently no single-vendor collaboration platform that adequately incorporates all types of modes (VoIP, IM, blogging, email, document sharing, wikis, web conferences, etc.). Enterprises consequently use a variety of tools. Content created in one tool is not accessible from another tool. Over time, the discussions, blogs, documents, emails, and messages grow into islands of content. An integrated view of all the dimensions of a collaboration is important to the collaboration process but has to be manually managed by the user. © 2011 IEEE Further, collaboration services are now available in the cloud. The security of enterprise information and information flows is an important consideration as collaboration services are used to create and store proprietary information. Federating across the desktop, enterprise server and cloud requires careful consideration of information flows and security boundaries. This research is a continuation of previous work [1] to develop an integrated real-time collaboration platform called ConnectedSpaces. The purpose of this research is to develop automated tools that a user can easily use to replicate the content of a collaboration session to different environments (blog, wiki, Sharepoint, email, etc.). We have hosted our mediation service on an application server and integrated it with clients including MS Outlook, Internet Explorer, and Skype. The new results presented here include: An architecture and API for integrating disparate collaboration services, tools, clients, and servers • An implementation that demonstrates the federated collaboration service capabilities • An analysis of possible architectures for federated cloudbased collaboration services with those in the enterprise network The next section summarizes related work. Section III presents the problem statement. Section IV describes the architecture and gives examples of the operation with examples from our implementation. Section V presents architectures for federating between enterprise and cloud-based services, and analyzes them. Section VI concludes the paper. • II. RELATED WORK Collaboration tools enable groups of enterprise users to work as a team, sharing information and communicating as needed, without being co-located. There are many types of tools today, provided by different vendors. For a survey of collaboration platforms, see [2]. We previously discussed types of enterprise collaboration tools in [1]. Collaboration platforms vary from wikis, blogs, and shared documents to web-based collaboration systems to 3D collaboration spaces offered by virtual worlds. The metaphor of a shared space or room has been discussed in [3][4]. The integration of communication services into colloboration tools has been described in [5][6][7]. The use of virtual worlds and virtual environments for collaboration has been introduced in [8][9][10]. Many such environments have combined document sharing, collaborative annotation, white boards, group voting 978-1-4577-1328-6/11/$26.00 2011 IEEE 1 mechanisms, group calendars, chat windows, and session recording. We divide the specifics of the problem statement into integration of collaboration tools and cloud-based service integration. B. Federation Issues A goal of application federation is able to access content created in one application from another. Another goal is to minimize the user effort to work across applications. Another goal is to use documented APIs and per-application security mechanisms. Figure 1 Example timeline of a collaboration In terms of integrated collaboration environments, recent versions of Microsoft sharepoint [11], IBM Lotus Notes [12], IBM Connections [13] and Google Apps [14] have included an integrated set of tools. Microsoft Sharepoint [11] supports collaboration on a set of files or documents. In addition, a sharepoint site can include a variety of team interaction areas including blog and a wiki. There is no integration of third party collaboration tools, although APIs on both client and server side are available for extending a sharepoint. IBM Lotus Notes [12] provides email, IM, calendar, personal journal, and contacts. IBM Connections [13] provides collaboration spaces called Communities, blogs, social bookmarking activities, wikis, and file sharing. In Connections, a shared space called an Activity is used to integrate related documents, emails, and IMs. In addition, through integration with Google Desktop Server, an Activity can reference documents on the local file system. Connections integrates with existing applications through plug-ins including Lotus Notes, MS Office, MS Outlook, and MS Sharepoint. Google Apps [14] is a set of web-based applications which include some collaboration capabitilies. These tools include Gmail, Google Groups, Calendar, Talk, Docs, and Sites. Depending on the platform, there are APIs for adding extensions which can be used for custom tool integration. We will discuss these in the sections descrbing our experiments. III. PROBLEM STATEMENT A. Overview The goal of this work is to provide a federated collaboration service so that 1) users can continue to use the collaboration tool of choice for a particular team session, independent of vendor, and 2) the results of related collaboration sessions occurring in different tools can be easily organized, accessed, stored, and searched in an integrated fashion. Collaboration activity is often organized by the purpose or expected results, such as product design, customer requirements, or market analysis. We observe that many related enterprise collaboration sessions use different tools such as phone calls, instant messages, emails, and shared documents depending on the kind of interaction or discussion that is needed. Over time the results of related collaboration sessions are stored in toolspecific repositories such as chat history, email folders, recorded web conferences, or file system documents. These are some of the challenges in developing federated collaboration tools. • • • • • Different APIs: Tools have unique APIs, so that integration of a new tool requires custom programming. Different user identities and sign-on mechanisms: Most tools require user authentication, by user identity and login is tool-specific. Different content models and content format: Content encodings include html, wiki markup, plain text, RTF, and XML. The structuring of content various as well. Different content addressing: Some tools provide a tool specific “id” for a specific item such as a chat session or email. In most cases this id can’t be referenced outside of the tool’s API, i.e., as a URL or URI. Limitations for seamless UIUX: 1) Limitations on the ability of the client user interface to support new application UI components, 2) Increased number of steps to access content outside the current tool. C. Cloud-based Service Integration When a collaboration service is operated in the enterprise network, then the information storage and information flows are protected from unintended access by third parties by the security mechanisms in place in both the enterprise network and the collaboration service. When the service is operated in the cloud, then there are known security issues [15] associated with cloud-based applications. These include the vulnerability of the hosted OS, limitations of the management infrastructure available to customers to monitor and secure the OS, and risk of other cloud service tenants to monitor flows and make connections between different hosts in the cloud. Attack scenarios for cloud services are discussed in [16]. In this paper we are specifically interested in the issues related to application federation. When federating two collaboration services, one hosted inside the enterprise and the other hosted in the cloud, there are a number of architectures for mediating access. These include mediating via the client, mediating via a server in the enterprise network, and mediating via a cloud-hosted service. The goal is to avoid requiring any changes in the network firewall and to protect the flows and information coming from the enterprise. IV. FEDERATED COLLABORATION TOOLS A. Operation The federated set of collaboration tools should permit: In-tool content to be pushed to a selected collaboration tool. For example, from MS Outlook we can select an email or email thread and push it to a wiki page or web conference session. • External content to be pulled from a selected collaboration tool to the current tool. • Correct re-formatting of the content to meet the closest to the original format available in the target tool. • Searching content in one or more external tool repositories. For example, while communicating via IM, the user wants to search for related topics in prior conversations in chat history, email, blogs, wikis, and local files. • Tagging of content according to user-defined keywords. These tags can be used to organize related content and for search. • Dereferencing a reference to external tool content, preferably by addressing content using a URI syntax. All operations are constrained by the access rights of the user in the given tool or service. • Table 1 shows the available operations in various collaboration tool APIs. In most cases these operations are provided by APIs provided by a native library, and may require either installation at the server or a software registration step at the client. In some cases these are REST APIs. Table 1 Available API operations for application federation for representative applications Type Examples push pull search email N Y Y N Lotus Notes N Y Y Y Chat / IM Skype N Y N N Phone call Avaya Comm. N Y N N wiki MediaWiki Y Y Y N document Sharepoint Y Y Y N blog Sociocast Y Y N N Web Conf. Avaya Web Conf. Y N N N Y Y N N Table 2 Adapter API Method createSpace cloneSpace getSpace appendToSpace editSpace getVersion When a federated client needs to access content in another collaboration app, it issues the requested operation (push, pull, search, tag) to the corresponding application or server. Authentication credentials can be pre-stored at the application server or dynamically requested from the user. Additional operations supported in the application server include keeping a persistent copy of the translated copy, logging, and format translation. Persistent copies can be useful in case the original application is later offline or the content might not be available at the application in the future (as in the case of chat history). tag Outlook Persony B. Architecture Figure 2 shows the basic architecture. Each application provides an API or REST interface to support the operations listed earlier (push, pull, search, de-reference, tag). An application server runs mediation services which in turn invoke custom APIs or REST interfaces on either the client application on the desktop or the server running in the enterprise. Each service on the app server provides a common API (Table 2) to simplify the client side integration. Using a mediation service rather than going directly from each client reduces the complexity of client integration. The mediation server can also act as content repository for services that might be offline or inaccessible in the future. Purpose Create a new space with members, owner, and name Create a space using an existing space as the basis Get the contents of a space Add content to space Edit the space Get an earlier version of a space Figure 2 Enterprise-only federated architecture Figure 3 Federation to externally hosted applications Some externally hosted applications such as RSS Feeds or web conferences can be also accessed via this architecture (Figure 3). An RSS feed is an external data source and is not receiving data from the enterprise. A web conference receives specific types of content (presentations, shared apps or shared desktops) and is designed specifically for use outside the enterprise network. Both operate over http, so no enterprise firewall changes are needed. C. Client Extensions Three client add-ins were implemented for testing the federated functionality, for Skype, MS Outlook and Internet Explorer. The MS Outlook add-in is shown in Figure 4. A task pane shows the selected email or email thread which is to be pushed to a selected collaboration tool. The lower half of the task pane allows the user to select the destination, and in the case of browse-able repositories like wikis and Sharepoints, to navigate to the specific destination folder of interest. Additionally, a ribbon extension provides icons for launching other collaboration tools. The main features of this design are to support easy push of email content to other collaboration tools, and to be able to quickly launch the other collaboration tool if needed. Figure 5 Internet Explorer add-in Figure 4 MS Outlook 2010 add-in Figure 5 shows the Internet Explorer add-in. The top pane of the browser is the current collaboration environment, using a web-based UI. Using the URL, the plug-in detects which type of content is being pushed. The lower pane is used to select and navigate to the destination collaboration tool. The destination need not be a web-based interface. Alternately a toolbar can be used for selecting the destination and the operation of interest. The mediation server currently implemented includes connectivity to Microsoft Exchange, Skype, various components of Microsoft Sharepoint, RSS, Avaya web conferencing, wikis using MediaWiki, and Sociocast-based blogs. Figure 8 shows an example of pushing an email to a wiki entry. In Skype, the client application extensions run in a separate window, which then uses the Skype API to access the functionality of the Skype client. As shown in Figure 6 and Figure 7, chat history can be browsed and then pushed to a specified email or wiki. Figure 6 Skype chat to email Figure 7 Skype chat to wiki Figure 10 Mediation server in the cloud for cloud-based service federation Figure 8 Email to Wiki V. FEDERATION OF CLOUD-BASED SERVICES A. Architectures We experimented with two cloud-based collaboration services, Microsoft Sharepoint Online [17] which is part of the Office365 family and IBM Lotus Domino Server. Office 365 runs on Microsoft’s cloud platform which is called Windows Azure. Access to Windows Azure hosts can be obtained directly; Office 365 is a pre-packaged software-as-service offering. Domino Server runs in Amazon Web Services EC2 (Elastic Compute Cloud) [18]. The customer controls the platform configuration, including disk capacity, geographic area of the host, and firewall settings. Administration of the host services is through either ssh connection or via a SSL web interface. Figure 9 and Figure 10 shows the two possible models which we compare. In Figure 9, the application service which mediates access to the various collaboration services is inside the enterprise boundary. Alternately, in Figure 10 the mediation is done by an application server that is also in the cloud. In both cases we are assuming that the client applications are on hosts that are either located in the enterprise network or are connected to it via a VPN. Figure 9 Mediation server inside enterprise for cloudbased service federation B. Analysis We discuss two cases in which an enterprise client connects to both a cloud-based service and an enterprise-based service. First, the collaboration content is to be moved from the enterprise-based service to the cloud-based service. If the mediation server is inside the enterprise, then it requires no changes from the proposed federated model to access the content to be moved. To then push the content to the cloudbased service requires only that the network connections needed by the API are available on the virtualized host. While this doesn’t weaken enterprise security, it may mean that the cloud based host has an addition point of attack due to the requirement to open one or more ports. Second, the collaboration content is to be moved from the cloud-based service to the enterprise. If the mediation server is inside the enterprise, then it again requires no changes from the proposed federated model to access the content in the cloudbased service other than network connectivity so that the needed APIs may be invoked on the service. The content can then be pushed to the destination service inside the enterprise network. In either case, if the mediation server is outside the enterprise, then it means that clients outside the enterprise can also use the federated collaboration service capability. But collaboration services running in the enterprise network may not be accessible unless specific ports are opened on the firewall. In most enterprise networks, this would be an unattractive requirement. This includes access to both serverbased services such as email or wikis, as well as desktop-based services such as IM clients or softphones which today tend to store the content locally on the desktop. In summary, cloud-based collaboration services can be federated with enterprise-based ones provided the mediation service is inside the enterprise and the cloud-based service is configured for API access via the network. Placement of the mediation server in the cloud will enable external clients to access the federated capability but will typically limit federation to services that are also running in the cloud. VI. CONCLUSION Because of the growth and variety of types of collaboration tools used in enterprises today, there is difficulty in integrating work threads across individual collaboration environments. Each collaboration tool differs in storage model, APIs, content organization, content addressing, content formats, user authentication, and user interface. Nevertheless users prefer to be able to choose which collaboration tool they use for a given interaction, and over the course of long-term collaboration, will typically use a variety of tools, including email, instant messages, wikis, blogs, web conferences, and shared documents. The solution presented here is to provide a federated integration of these different collaboration tools to make content access and transfer straight forward between different systems. Additionally, we enable the user to achieve this federation by working directly in the client application of their choice; we illustrated this with plug-ins for MS Outlook, Internet Explorer and Skype. Our architecture integrates both desktop and server-centric tools. Additionally it is now possible to use hosted collaboration services in the cloud. This further complicates the ability to federated collaboration tools because of requirements to protect enterprise information and information flows. We presented an architecture to address the federation of cloud-based collaboration services. REFERENCES [1] J. Buford, K. Dhara, V. Krishnaswamy, X. Wu, M. Kolberg. Work in Progress: A Communications-Enabled Collaboration Platform. IPTComm 2010. July 2011. [2] J. Rama, J. Bishop. Survey and Comparison of CSCW Groupware Applications. Proceedings of SAICSIT 2006 [3] M. Roseman , S. Greenberg, TeamRooms: network places for collaboration, Proceedings of the 1996 ACM conference on Computer supported cooperative work, p.325-333, November 16-20, 1996, [4] T. Rodden. Awareness and Coordination in Shared Workspaces. In Proceedings of the 1996 ACM Conference on ComputerSupported Cooperative Work (CSCW’96). pp. 87-96. [5] S. Bly, S. Harrison, and S. Irwin. Media Spaces: Bringing People Together in a Video, Audio, and Computing Environment. Communications of the ACM 36 (1), pp. 27-47. [6] X. Wu, V. Krishnaswamy, C. Mohit. Integrating Enterprise Communications into Google Wave. IEEE Consumer Communications and Networking Conference (CCNC 2010). Jan. 2010. [7] X. Wu and V. Krishnaswamy, Widgetizing communication services, ICC 2010, Capetown, South Africa [8] S. Benford, C. Greenhalgh, T. Rodden, J. Pycock. Collaborative virtual environments. Commun. ACM 44, 7 (Jul. 2001), 79-85. [9] S. Vijaykar, M. Kadavasal, K. Dhara, and V. Krishnaswamy. Virtual Worlds as a Tool for Enterprise Services. IEEE Consumer Communication and Networking Conference, Las Vegas, Jan 2009. [10] E.-L. Sallnas. Collaboration in multi-modal virtual worlds: comparing touch, text, voice and video, The social life of avatars: presence and interaction in shared virtual environments, Springer Verlag, 2002, ISBN: 1-85233-461-4, pp: 172-187. [11] Microsoft Corp. Microsoft Sharepoint 2010. http://sharepoint.microsoft.com/en-us/Pages/default.aspx [12] IBM Corp. Lotus Notes 8.5 http://www.ibm.com/developerworks/lotus/library/notes85-new/ [13] IBM Corp. IBM Connections. http://www01.ibm.com/software/lotus/products/connections/ [14] Google. Google Apps. http:// google.com/apps [15] S. Subashini, V. Kavitha A survey on security issues in service delivery models of cloud computing. J Network Comput Appl (2010). [16] M. Jensen, J. Schwenk, N. Gruschka, L. Iacono. On Technical Security Issues in Cloud Computing. 2009 IEEE International Conference on Cloud Computing. [17] Microsoft. Sharepoint Online. http://www.microsoft.com/enus/office365/online-software.aspx [18] Amazon. Amazon Elastic Compute Cloud (EC2) http://aws.amazon.com/ec2/