Adobe ConnectNow is a free collaboration software that can be used for web conferencing. ConnectNow offers the users conference features like screen sharing, chat, notes, whiteboard, audio, and video to conduct meetings online. It's built on the Adobe Flash Collaboration Service (AFCS), which is a platform-as-a-service (PAAS) for building multi-user, real-time collaborative applications.
AFCS is comprised of three components: the client Flex SDK, Flash Media Server (FMS) server-side, and Java server-side. Flash Media Server (the "communication" server) is used to build collaborative applications between Flash clients or video delivery systems (with real streaming video instead of HTTP progressive download). Clients connect to the server using the RTMP protocol (or one of its variations) on a permanent socket connection.
Adobe integrated the ConnectNow application with Terracotta software to take the advantage of Terracotta's shared application memory store to address the scalability of the web application. In order to integrate the FMS application with the provisioning and authorization system and in order to actively manage the pool of FMS servers, AFCS uses a cluster of Java application servers, backed by Terracotta, that provide services like user login, permission management, content repository, and monitoring and cluster management for the FMS servers (to keep track of which meeting is running on which server and reassigning a meeting to a different server if the original server fails; since FMS connections are stateful and persistent they cannot use a regular load balancer).
InfoQ spoke with Raffaele Sena, Senior Computer Scientist in Adobe's Business Productivity Unit about Adobe ConnectNow and Terracotta integration and how it addressed their web site scalability requirements.
How does the Adobe ConnectNow application which is a web conferencing and collaboration application compare with traditional web applications?
The main difference between this collaborative web conferencing application versus traditional web applications is that most of the data we manage is transient. The application servers keep track of logged-in users, running meetings, users in a meeting, as well as meeting state; however, when a meeting ends and a user logs out, all of this information becomes useless. So, while a traditional web application, which is more database driven, will use a system like Terracotta as a distributed cache to improve efficiency, our system actually uses Terracotta as a "distributed shared memory" where most of the data shared between the machines is kept only in memory.
What are the typical scalability and performance requirements for an application in the web conferencing and collaboration domain space?
ConnectNow is deployed as a hosted system for which we anticipate tens of thousands of concurrent running meetings; however, we have designed the system so that we can partition the system in smaller clusters if needed. While performance is important, especially for user login and meeting startup (for which we do have to fetch information from a database), after that, most of the work done at the application server level is in the background (where the user is not interacting with this part of the system), such as monitoring running rooms, storing the room state when a meeting ends, etc. The most important requirements here are reliability and being able to recover from a server malfunction by "moving" the room management to a different server in the cluster.
Can you give us some examples on how the Terracotta solution helped with your system architecture?
One of the characteristics of our application is that a lot of data is localized. The application consists of two kind of servers: a "communication server" that manages the meeting communication (we use Adobe Flash Media Server for this, a highly optimized C/C++ server) and an "application server" that is a Java application running in a servlet container. For each meeting, there is a dedicated communication channel between the communication server and the media server, and for each meeting the application server keeps a copy of the meeting state, so only one machine in the cluster of application server is managing the data for a particular meeting. But again, if that machine fails, another will take over.
Without Terracotta, we would have to either store this data in a database or a file on a shared disk, which would have resulted in very slow performance, or keep it in a distributed cache knowing that each change made in the local copy would have to be propagated to each machine in the cluster, which would have resulted in a lot of unneeded network traffic and memory utilization. With Terracotta this became a non-problem: the data is stored in the distributed memory in a hashmap indexed by the room URL, but we know that since it's used only on one machine it resides only on that machine and the Terracotta server. If that machine fails, another will take over and the data will "magically" move over, with no specialized code in our application.
What was the application architecture of Adobe's ConnectNow system before the integration of Terracotta?
Before the integration with Terracotta, we used the database as the synchronization mechanism for the application, which was mainly an online presentation viewer. At that point we were dealing with a lot of static content for which we could avoid database queries, a small cluster, and we were able to leverage the database system when we needed to scale. When we added the web conferencing feature, we still had the original back-end that was designed for more static data, and we adapted it to serve a system that was really more transient. In 2007, we decided to rewrite the whole system to take advantage of the power of the new clients (Flash 9, Flex and ActionScript 3). On the application server side, we built a system tailored to the requirement of our web conferencing and collaboration applications.
So when we built AFCS as the backbone for the ConnectNow web conferencing application, we had in mind a system that managed mostly transient data. We wanted to avoid the database bottleneck where a database wasn't needed, and we just had to find the right tool to help us accomplish that. What we needed was something that would give us a "distributed shared memory" more than a "distributed cache" and it turned out that is exactly what Terracotta was able to provide us.
Can you explain the architecture details on how you were able to use Terracotta to eliminate the database from the picture?
Again, the main point here is that by the nature of our application, most of the data is transient. We do have a database that is a content repository from which we read the initial meeting state when a meeting starts, and we save the new state when it ends. But for all the duration of a meeting we run without a database.