Flash Communication Server Article

The problem with this setup is that you end up keeping the remoting logic on the Flash client. If your application needs to use the Flash Communication Server, there are many reasons why you should place the remoting logic on the server instead:

• The Flash Communication Server would like to do server-side authentication of the client that is trying to connect. This is a perfect opportunity for the Flash Communication Server to request authentication from the application server—which could use a database of users and their permissions to accomplish this.
• You don’t have to worry about clients connecting to the application server directly. You have a controlled environment. The Flash Communication Server manages all the remoting with the application server and also manages the communication with the Flash clients.
• If the remoting logic exists on the server, it makes it easy to populate data into a shared object. The Flash Communication Server requests data from the application server via Flash Communication Server Remoting. The application server retrieves the data stored in the local database based on the query string provided to it. The application server sends the data to the Flash Communication Server, which the Flash Communication Server in turn uses to populate the shared object.
• The above example also minimizes the load on the application/database server. Imagine a constant database query of all music artists whose name starts with “B.” This can be retrieved from a database and stored in a local shared object on the Flash Communication Server. Because the shared object can be updated once a day, you minimize the load on the application server. Of course this begs the question, what about the load on the Flash Communication Server. The answer depends on which resource is more valuable at the time. It’s certainly imaginable that querying for data once by the Flash Communication Server and then delivering the data to each client is less resource-intensive than each client querying for the data separately (see Figure 5).

• It's desirable to move all remoting logic into a one centralized place on the server. This can reduce the complexity of the application and provide more security. For instance, the Flash Communication Server and the application server could both be behind a firewall, making their communication more secure than it would be between a Flash client and the application server.
• You can move persistence to the database more easily and have the shared objects serve as proxy objects for that database.
• Notification to a client is simplified when the Flash Communication Server reestablishes a connection to the same client. The client might just require the same data (for example, stock quote portfolio, address book, contacts all stored in a database). The data can reside in a server-side persistent shared object; as soon as the client subscribes to the shared object the data is delivered. There's no need for the client to start doing Flash Remoting at this time because the query was already performed in an earlier session by this (or maybe another) client and so it's cached in a server-side shared object.
• You can optimize notifications. If both the Flash Communication Server and the application server are behind the same firewall and on the same machine, the latency, bandwidth and overall performance of the communication between the two are excellent—or at least better than if the Flash client tried to remote directly to the application server. For example, if the application is looking for a price alert, it makes more sense for the Flash Communication Server to do the price polling via Flash Communication Server Remoting with the application server. If the price target is reached, the Flash Communication Server can notify the Flash client via RTMP. This system is optimal compared to the setup where every client tries to poll the application server for the same data via Flash Remoting.
• You want the client logic to be as simple as possible or you want the client application to be as small as possible. In those cases, it is better to offload the remoting logic onto the Flash Communication Server.

So when do you use Macromedia Flash Remoting?
Does it ever make more sense to use Flash Remoting over Flash Communication Server Remoting? Of course! It depends on your system and the needs of the Flash client. Below are some situations where you may want to use Flash Remoting over Flash Communication Server Remoting:

• There is no Flash Communication Server anywhere in the equation. Obviously here you want Flash Remoting to communicate with the application server.
• You want to deliver data over a secure protocol. For extremely sensitive material where you want data to flow over a secure protocol, and you need to deliver the data to a Flash client, you can use HTTPS requests with Flash Remoting. In this case you could also envision a scenario where both Flash Communication Server and Flash Remoting are incorporated into the design.
• Your application uses Flash Communication Server but also has a section that does not require real-time communication. For instance, your stock portfolio application might have a chat component communicating via the Flash Communication Server. In that case, the stock portfolio section could be done with Flash Remoting without affecting the Flash Communication Server logic.
• You don’t want to overload the Flash Communication Server. If this is an issue for your application, use the Flash Communication Server only to perform real-time communication. In many cases, the choice whether or not to use Flash Communication Server Remoting is obvious; sometimes it isn't. An obvious case is when Flash clients can update data and you want other Flash clients to be informed immediately of those changes—and data is to be stored in a database controlled by an application server. Use Flash Communication Server Remoting here. The Flash Communication Server should receive the update request from the client, pass on the update via Flash Remoting, and inform all other connected clients about the change, preferably automatically by a shared object update. This is greatly preferable to having all interested clients periodically polling the applications server. In other, not-so-obvious cases your choice might be based more on a question of style or ease of development.

Resources
Here are some useful links that explain Macromedia Flash Remoting in more detail:

Macromedia Flash Remoting Overview

Common Questions About Flash Remoting

Macromedia Flash Remoting: Open the Gate for Rich Dynamic Content

Macromedia Flash Application Development Center

About the Author
Slavik Lozben is a principal engineer on the Flash Communication Server team. He was involved in the design and implementation of many of the features in the product. Slavik joined Macromedia in January of 1995. He originally worked on the Director product line. When Macromedia bought what is now known as Flash, he saw a tremendous opportunity and joined Robert Tatsumi and Jon Gay, the creators of Flash. He has been on the Flash team ever since.