The challenge of enterprise-level collaboration is to make data sharing effective and keep costs down. Applications built with C++ or Java must be delivered to the end-users' desktops along with some piece of the collaboration software. That can be a headache for IT departments because it is another set of files to deploy, upgrade, and test.

For me, collaboration has a broad meaning: two or more applications running on distinct computers sharing data. There is usually some sort of middleware connecting them: software that moves the data from one location to another.

After spending nearly 10 years in the financial services arena, I can tell you that enterprise applications are highly collaborative affairs. Traders need to know current stock prices, orders for buying and selling equities flow across the Internet, and conversations between counter parties take place in real time around the world 24x7.

IT departments in the financial services industry have been reluctant to place their bread-and-butter applications onto the Web because the means to push information onto the end-user's desktop has not been practical. Java applets, which can use Java Messaging Services, have appeared from time to time. However, their large downloads and browser-compatibility issues have dissuaded IT from heavy investment.

Now the combination of Macromedia Flex and Macromedia Flash Communication Server (FCS) make it possible for a new generation of Web applications to take on the collaborative mantle and challenge traditional desktop applications. IT departments finally have the combination that they have long sought of rapid development, simple deployment, small download, and integrated collaboration. After all, most PCs already have the Flash Player and that's all you need. There is no additional software required. IT departments can deploy their collaborative applications to their Web and application servers, and the users' browsers do the rest.

This article shows you how to build a simple collaborative application in Flex that uses FCS's shared remote objects.

FCS
Most IT departments have heard of FCS. They see it as a way to stream video and audio with ease from a central server to end-user's desktops. Nonetheless, many fail to see that beneath the glitz of those high-bandwidth applications lies a useful nugget: shared remote objects. Easy to develop, FCS-based applications can share data across the enterprise or around the globe in real-time. Sending blotters of stock trades, or simply chatting between counter parties, is nearly effortless for FCS.

Note that Java has its version called Java Messaging Service (JMS) that has a number of implementations. CORBA (Common Object Request Broker Architecture) often underpins many middleware systems.

FCS is a piece of software (usually run on its own machine) tasked with moving information from one Flash Player to another Flash Player. Macromedia typically markets FCS as a way to stream video and audio to and from the Flash Player. Proprietary software within FCS makes it possible not only to broadcast video to many users simultaneously, but to receive video as well.

One example application is an online conference with an interactive whiteboard. Each participant has a camera and the program provides a virtual whiteboard. The current speaker's image is transmitted to all members of the conference. As the speaker draws on the whiteboard, everyone sees the diagram taking shape.

In my opinion, the most powerful aspect of FCS isn't its ability to share data. The real power is the fact that it can be programmed or scripted so its behavior supplements the application.

I have written Java- and C++-based applications that use software to share data with remotely connected users. The middleware (i.e., JMS or CORBA) is normally a black box. That is, you can install and configure it, but you cannot make it perform any functions that its creators did not intend.

This is not true for FCS. As with Flash and Flex, FCS uses ActionScript as its language. Each FCS actually runs multiple applications (see Figure 1). A single FCS can run a video conference application as well as a stock price ticker.

For example, if an FCS application is acting as a chat room, the FCS application can save the messages to a database (using Flash Remoting and a J2EE server). The FCS application can also authorize each user that attempts to connect to the application by allowing or rejecting the connection.

Flex
Because FCS connects Flash Player to Flash Player, you must write the user interface portion in Flash. However, IT departments have been reluctant to use Flash because of its reputation as a Web designer and artist tool. Macromedia Flex is a new and easier way to write Flash applications. Flex is ideal for enterprise development because it uses tools with which you are already familiar: Dreamweaver, text editors, and your favorite J2EE application server (with .NET on the horizon). Flex application files are compiled into Flash SWF files and downloaded into your browser's Flash Player plug-in.

Flex applications are written in a form of XML called MXML (Macromedia's XML) that defines the content and placement of the user interface. There are lots of controls from which to choose: button, label, data grid, tree, slider, and so forth. There are also layout containers to help manage the placement of the controls. Of course, placing controls on a page would be useless without program code to control them. Flex uses Flash's ActionScript language to provide the necessary event handling and data management.

Example: Drag and Drop
I've chosen a fairly simple example to demonstrate how Flex applications can use FCS to collaborate with one another. This example shows off some of Flex's capabilities and it shows how easy it is to send data between applications. My example uses the same application for sending and receiving data. Figure 2 shows the application in use. The user peter has entered several orders directly into the DataGrid component. Below the grid is a list of the users currently online, represented by an image. These images not only tell you who is online, they are also drop zones - a place where you can drag one or more orders (rows in the data grid) to send them to another user. User peter's image is dimmed to indicate that his own drop zone is off limits.

In Figure 3, user peter is dragging two orders over the drop zone for user joseph. Notice how the drop zone highlights to indicate that it will accept the data. If user peter were to try to drop the orders over his own icon, the drop zone would not highlight. It would not make sense to send orders to yourself.

When user peter releases the mouse over the drop zone, Flex animates the graphics to show the data falling into the drop zone. If user peter moves out of the drop zone and releases the mouse, Flex animates the data to show it returning to its point of origin.

When the user releases the mouse over a highlighted drop zone, the Flex application extracts the orders from the data grid and sends them to FCS along with the name of the target user (i.e., user joseph). FCS then takes those orders and pushes them to user joseph's Flex application, which in turn, updates its data grid.

How FCS knows what to do and how the Flex application sends and receives the data is discussed in the section, Connecting Flex to FCS.

Figure 4 shows user joseph's grid after receiving the orders. At this point user joseph could modify one of the orders and send it back to user peter by dragging it over user peter's drop zone. The application is written such that it examines the data being received and replaces orders it already has (using the order code). It adds new rows to the grid for orders it does not have.

Note that the example illustrates just how easy it is to implement data sharing. Flex and FCS not only do the job of collaboration, they make it easy to do the job.

The sample application provides you with a glimpse of what is possible. If you choose to download the program code, make sure you run at least two separate instances of the application on different computers to get the full effect. Although the sample uses fairly simple data (and an array of order objects), you can send more complex structures. In fact nearly anything you can build with ActionScript you can share.

More Examples
For Example 2, I'll use the ubiquitous chat or instant message application. In this collaboration example, two or more people exchange messages. Figure 5 shows a multiroom chat application. All of the users signed on to the application are shown in the upper-left panel; below that are the available rooms. To the right, in the largest space, is the chat dialog with a tab for each room in which the user is participating. Below the dialog area is the input line for entering the text.

Example 3 is one of the most common applications seen in financial data systems: real-time price updates. This is often seen as a band of stock symbols; prices streaming around the screen; or as a table of symbols, prices, and other information.

Figure 6 shows a Flex DataGrid with currency exchange rates and volumes. The application works with FCS to bring real-time information directly to your desktop.

Connecting Flex to the FCS
Shared Objects
Flex (and Flash) applications use shared objects to communicate with FCS. An instance of a shared object lives within FCS, whereas proxies for it are present within the Flex application.

In Example 1 there is a list of active users. I describe the list by labeled images. When a user signs on to the application, an image automatically appears. Similarly, when a user signs off (closes their browser), their corresponding icon automatically disappears.

To achieve this, I created a shared object called users (see Figure 7) for the sole purpose of conveying who is currently using the application. Within the FCS application code, I add a new user to the list whenever an application connects. Because this is a shared object, FCS automatically synchronizes its list with those of all of the attached Flex applications. I coded the Flex applications to display a labeled icon.

1. Client 1 connects to FCS and attaches to the shared object, users. This causes a proxy for the shared object to be created in the Flash Player running the Client 1 application.
2. Later, Client 2 connects to FCS and attaches to the users' shared object. A proxy is created in the Flash Player running the Client 2 application.
3. The FCS application now synchronizes all applications attached to the users shared object. Both applications now know about each other.

Shared objects can do more than just share data. You can define functions on a shared object and have those functions called by FCS. In the first example, every user that signs on gets their own unique shared object. I wanted to define a function in the sample Flex application that would be called whenever there was data to be displayed in the grid. When one Flex application user drops their orders onto another Flex application user's image, FCS is given the orders, finds the shared object associated with the recipient, and invokes the function I defined.

Making the Connection
I created an ActionScript class to make it easy to use FCS from Flex applications called FlashComm. As this class is available to download, I will just point out some of the more interesting aspects. Following the suggested guidelines for Flex classes, my FlashComm class uses events to announce changes in its state.

• Closed, Failed, Rejected: The connection to FCS can be in one of these states. My FlashComm class dispatches a corresponding event rather than displaying an error message. This allows the overall application to do what is best at that point.
• Success: The connection to FCS has successfully connected. Now my FlashComm class can connect to the shared objects: users and one specific to my application instance (users peter, joseph, etc.).
• Change: FCS has sent some orders. My FlashComm class dispatches a change event to inform the application. This causes the orders to be added to the DataGrid.
• Users: FCS has resynchronized the users shared object because someone has signed on or signed off. My FlashComm class dispatches a users event that causes the application to add or remove user icons on the display.

Flex
Listing 1 shows the instantiation of my FlashComm class within the application's MXML file and some of the events it handles.

1. The change event is dispatched when data is being received from the FCS. The showNewData method either replaces existing records in the DataGrid (if the order codes match) or adds the order to the end of the grid.
2. The list of users is updated whenever it changes.
3. . A dialog box is presented to the user should the connection fail.

Listing 2 shows the Flex definition for the list of users. This is defined with a Repeater tag that generates the items defined within it for each record in its data provider. In this case, it would be the list of users.

The boldfaced lines are the event handlers for the drag-and-drop operation. The doDragDrop method is shown here:

function doDragDrop(event) {
	flashComm.sendOrders(dataGrid.selectedItems, event.target.label);
	restoreDragTarget(event);
}

Whenever the user releases the mouse, the selected items (orders) from the data grid are given to my FlashComm class to be sent to FCS along with the name (the icon's label) of the intended recipient. FCS then invokes the receiveOrders method defined on the recipient's unique shared object.

FCS Application
The last part of the example is the code that is run by FCS itself (see Listing 3). This is the application instance that makes the example work.

1. When the FCS application starts, it creates the orders shared object (if it already exists, the application attaches to it). Note that shared objects can be also be persistent. FCS will write their contents to a local file on the server and reload them whenever necessary.
2. When a client connects, a function is defined on the client connection that the client can invoke. This function takes the orders from the client and calls the receiveOrders method defined on the shared object. This is a powerful concept. What appears to be a single method invocation is actually many method invocations - one for each client connected to the same shared object.

If you have used other types of middleware (e.g., a CORBA-based system or a JMS system), imagine having the ability to place code in the heart of the data switch. In this example, FCS is distributing the data to everyone. However, it is possible to filter the data, sort it, save it, or augment it. You could, for example, see if the user about to receive the data is privileged to see all of the data and, if not, remove those bits not allowed. Or the FCS application could send the data to a J2EE server for storage.

To Collaborate Is Human
We have a need to work together; businesses thrive on this interaction. Traditional methods of sending data between applications, whether it be via serial line or Internet (using protocols from FTP to CORBA), have been complex to implement and deploy. I have tried to show the potential of combining FCS with Flex: powerful data collaboration coupled with sophisticated user interface controls delivered within a Web browser. FCS is surprisingly easy to use. The ability to tailor each FCS application with your own code opens the door to great possibilities. I used the drag-and-drop capabilities of Flex to illustrate how easy it is to adopt a new paradigm for a common goal.

I have developed similar Java-based applications using Swing for the user interface and an implementation of the Java Message Service as the middleware. Flex and FCS are, in my opinion, a tonic for the developer's soul.

Resources

The source files for this application are available in ZIP format from my Web site at www.keaura.com/flex.

More information about FCS can found on Macromedia's Web site at www.macromedia.com/software/flashcom.

Macromedia Breeze is another example of collaboration. Find out more at www.macromedia.com/software/breeze.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6
• Figure 7
• Source Code