2.1 Installing Flash Remoting
| Flash Remoting is built into ColdFusion MX (and later) and JRun 4, making these two application servers attractive to begin working with Flash Remoting. ColdFusion Markup Language (CFML) has the added bonus of being relatively easy to learn. Flash Remoting is also available from Macromedia as an add-on for .NET and J2EE servers. Table 2-1 shows the languages that you can use to create server-side Flash Remoting services in each type of installation. Table 2-1. Flash Remoting official language support
Table 2-2 lists the open source projects underway that support Flash Remoting using various languages. Table 2-2. Open source Flash Remoting language support
The following sections detail the installation and configuration of Flash Remoting in the server environments that are supported. 2.1.1 ColdFusion MXColdFusion MX and later run on a J2EE (Java 2 Enterprise Edition) platform. Therefore, you can write simple programs using CFML and the resulting application is compiled into a Java servlet. Admittedly, the variants of ColdFusion can get confusing. There are three basic versions. Free 30-day trial versions of the two commercial versions are available. After 30 days, they revert to the Developer Edition, which restricts IP address access but is otherwise full-featured :
Table 2-3 summarizes the platforms that ColdFusion MX Server will run on. Table 2-3. ColdFusion MX Server supported platforms
ColdFusion MX's J2EE underpinnings allow ColdFusion applications to be extended in Java. ColdFusion MX can also be deployed on top of an existing J2EE installation if you purchase the Enterprise edition. Using the Enterprise edition, you can run ColdFusion MX on a Macintosh as well, on top of a JRun 4 or Tomcat installation. Macromedia supports Macintosh installations for development only and not in a production environment. Installation on a Macintosh is covered at:
The system requirements for running ColdFusion MX on J2EE Servers are listed in Table 2-4. For web server requirements, consult your J2EE server documentation. Table 2-4. J2EE Application Server supported platforms for ColdFusion MX
As per the Macromedia technote at http://www.macromedia.com/support/coldfusion/j2ee/#servers, although you can deploy the Enterprise edition on any J2EE-compliant application server, not all are fully tested and supported for production use. For development and evaluation purposes, Macromedia has also tested Flash Remoting on Sun J2EE SDK 1.3 (the reference implementation) and Tomcat 4.1.12 (and later). It is best to consult the Macromedia site for the current requirements. Macromedia's site explains the details of the different ColdFusion variants and pricing:
Flash Remoting is also automatically installed as part of the ColdFusion MX Server package installation (Flash Remoting does not work with ColdFusion 5 or earlier versions). You can download and install the ColdFusion MX trial version, which will revert to a free developer's version after 30 days. The trial version is also included in the Studio MX package.
ColdFusion MX can be installed in several different ways and on a multitude of platforms. ColdFusion MX Server can be installed atop your existing web server (IIS, Apache, or others) or using the built-in web server. The built-in web server is a limited functionality web server, recommended for testing only and not recommended for production environments. More information on the built-in web server can be found at:
ColdFusion MX can also be installed side-by-side with an existing ColdFusion 5 installation, in which case it is installed with its own built-in web server on port 8500 rather than the standard web port 80. This port is crucial to making connections using Flash Remoting if you are running the standalone ColdFusion web server. You must specify the path to the server when you make your connection to a gateway URL, so if the server is running on port 8500 instead of port 80, the gateway connection code looks like this: var myURL = "http://localhost:8500/flashservices/gateway"; var myServer = NetServices.createGatewayConnection(myURL); Running side-by-side installations of ColdFusion 5 and ColdFusion MX lets you test existing ColdFusion 5 applications in the ColdFusion MX environment. Because ColdFusion MX was rebuilt from the ground up as a J2EE application, there may be compatibility problems with ColdFusion 5 applications, particularly with regard to the database connections, which have changed dramatically. There is a Compatibility Analyzer built into the ColdFusion MX Server that can help you determine the compatibility issues your older applications might have. Installation of ColdFusion MX is straightforward and covered at length in the documentation that comes with the software and at http://livedocs.macromedia.com. Once installed, Flash Remoting is immediately available. You can test Flash Remoting on a standalone ColdFusion MX Server by browsing to the following URL:
If you have a standard installation of ColdFusion MX Server that ties into your existing Apache, IIS, or other web server on port 80, you can test Flash Remoting by browsing to this URL:
If you see a blank page, you know that the gateway is working. If you see an error message or anything else on the page, something is wrong. Double-check your URL and port settings. There is no easy way to pinpoint and correct an installation error if you come across one. Usually, the only option is to recheck the steps you followed and reinstall the server. For more troubleshooting tips go to:
In a successful installation, you will not see a physical /flashservices/gateway directory in your server root. This path is a virtual directory that is known to the ColdFusion MX Server. It does not correspond to any physical directory on your machine. After a successful installation of ColdFusion MX, you will have the flashgateway.ear file in the path_to_CFusionMX \runtime\servers\default\ folder.
If you are upgrading a prior installation of ColdFusion Server, you can migrate your old ODBC and OLEDB data sources to ColdFusion MX Server, which uses JDBC. This can save you time when creating connections to existing databases. Existing ODBC data sources are migrated to JDBC format, which can exist side-by-side with the old ODBC data sources. Later modifying an ODBC data source will not affect the ColdFusion MX JDBC connections that bear the same data source name. JDBC data source configuration settings for ColdFusion MX Server are located in the path_to_CFusionMX \runtime\servers\default\SERVER-INF\jrun-resources.xml file. Knowing how to create and connect to data sources is necessary for developing the server-side services of a Flash Remoting application. Data sources in ColdFusion MX are defined in the ColdFusion MX Administrator, the visual interface for administering ColdFusion applications. The ColdFusion MX documentation covers this topic thoroughly. Additionally, if you plan to develop your Flash Remoting services in Server-Side ActionScript rather than CFML, you will have full access to data sources defined in the ColdFusion MX Administrator. As of this writing, there have been three major updaters to ColdFusion MX and a version upgrade to 6.1. Make sure you have the latest version of ColdFusion MX from the Macromedia site. Using Flash Remoting with ColdFusion MX is discussed at length in Chapter 5. 2.1.2 JRun 4JRun 4 is Macromedia's enterprise-level J2EE application server, which supports JavaServer Pages (JSP). Although Flash Remoting is available as an add-on for other J2EE servers, the JRun 4 installation includes Flash Remoting out of the box, making it the easiest way to Flash-enable a J2EE site. When using JRun 4 for building Flash Remoting services, you will most likely be programming the server-side services in Java. In addition, JRun 4 allows Server-Side ActionScript to be used, which is unavailable in the Flash Remoting package for other J2EE servers. JRun 4 also contains considerable enhancements that make it a worthy upgrade from previous versions of JRun, even without the Flash Remoting functionality. It is fully J2EE-compliant, having passed Sun's rigorous certification process for J2EE servers. In addition, it has full support for Enterprise JavaBeans (EJB) 2.0, hot-deployment technology (which avoids restarting the server when making changes), and enhanced support for web services. Of the J2EE servers on the market, JRun is one of the easiest to get up and running, thanks to its visual installation wizard, and one of the easiest to administer because of the extensive administration interface. If you are just starting out and want to get your feet wet with the Java language in the J2EE arena, JRun 4 is a good choice.
JRun installs with its own built-in web server to port 8100 by default, rather than the standard web port 80, to avoid conflicts with any existing web servers. The administrative server interface is available at port 8000, using the URL http://localhost:8000 . You can manually connect a JRun server to an existing web server as well, so that your pages can be accessed through the typical port 80. This can be done through the administrative interface of JRun. The built-in web server of JRun is recommended for developmental purposes only, not heavy use. If you choose to develop your Flash Remoting applications using the default installation of the server on port 8100, you must specify the port in your connection to the Flash Remoting adapter: var myURL = "http://localhost:8100/flashservices/gateway"; var myServer = NetServices.createGatewayConnection(myURL); You can test the Flash Remoting functionality in a standard JRun 4 installation by pointing your browser to:
where yourservername is the domain name or IP address of your web server. If you have set up a JRun server on the standard web port 80, you can point your browser to:
Again, just as in the ColdFusion installation, if you see a blank page, the Flash Remoting technology is working properly. If you don't see a blank page, check your JRun installation by testing the administrative interface or the samples included with JRun. If the server is working, you may have a problem with your gateway URL or port setting. If the server is not working, you may need to reinstall JRun. See the following URL for tips on JRun installation issues:
Chapter 7 shows how to install Flash Remoting in your web application rather than creating a server-wide testing installation. 2.1.3 Other J2EE ServersFlash Remoting is available for purchase from Macromedia as a separate product, named Flash Remoting MX for J2EE, that will work in almost any J2EE-compatible server. There is a 30-day trial version available from http://www.macromedia.com/software/trial_download. The trial version reverts to a server-side development-only version after 30 days, with which you can continue to use the Flash Remoting servlet on your local machine for testing purposes. Some of the servers that you can use with Flash Remoting include:
The following operating systems support the Flash Remoting gateway adapter:
These configurations are tested and supported by Macromedia, but other operating systems can be used at your discretion. I've successfully run Flash Remoting on Windows 2000 Professional with both JRun 4 and Tomcat in a testing environment. See http://www.macromedia.com/software/flashremoting/productinfo/system_reqs for the most recent system requirements for Flash Remoting. To install Flash Remoting for J2EE in a server-wide test environment, follow these steps:
The installer gives you the choice of installing the .war or .ear archives with or without sample files and documentation. The installer creates a directory in which the archives are placed. After running the installer, follow these steps to deploy Flash Remoting on your server:
Test the functionality of the servlet by browsing to:
In a default Tomcat installation using port number 8080 instead of port 80, test the installation by browsing to:
You should see a blank page. If the page is not blank, you must retrace your steps and make sure your web application mappings are correct. The Flash Remoting servlet is already mapped to /gateway in the web.xml file: <servlet-mapping> <servlet-name>FlashGatewayServlet</servlet-name> <url-pattern>/gateway</url-pattern> </servlet-mapping> The flashgateway.jar file can be deployed in any of your web applications by specifying the servlet mapping in the web.xml file for each application. Each application on your server can use its own path to the gateway. Chapter 7 explains how to install Flash Remoting in your own application using Flash Remoting for J2EE Updater 1, which includes a .jar archive. In your ActionScript code, the gateway URL is used to create the connection as follows (for the default installation): var myURL = "http://localhost/flashgateway/gateway"; var myServer = NetServices.createGatewayConnection(myURL); If you are having trouble making the connection, make sure your URL follows this general format:
A flashgateway/samples directory is also installed in the default gateway directory. These samples should work out of the box, assuming you are using a default web server at port 80. If not, you can open the .fla files in the subdirectories under the samples directory and change the paths in the ActionScript source. 2.1.4 ASP.NETFlash Remoting is available for purchase from Macromedia as an add-on server component (DLL) for ASP.NET. There is also a 30-day trial version available from http://www.macromedia.com/software/trial_download. The trial version reverts to a server-side development-only version after 30 days, with which you can continue to use the DLL on your local machine for testing purposes. Installation of Flash Remoting for ASP.NET is straightforward but requires that you have the Windows .NET SDK installed. The .NET SDK is available as a free download from the MSDN Download Center at:
You can also install the Flash Remoting samples to your web directory as part of the installation, which gives you a few sample C# and VB applications that utilize Flash Remoting. The samples can be run from the webroot \flashremoting\samples\default.htm file. The default installation of Flash Remoting places the files necessary for the Flash Remoting service to work in the flashremoting directory under your web root. This is also the directory where the samples are installed. They should work out of the box if the installation was successful. To test the installation of Flash Remoting for ASP.NET, point your browser to the following URL:
Notice the differences between this connection and the ColdFusion and JRun connections:
Each .NET application on your server uses its own path to the gateway. The HelloWorld sample application from Chapter 1 used the flashremoting directory, but if your application uses a different directory name, or none at all, you need to change the connection. A typical installation using the gateway.aspx file in a subfolder at the root of your web application might look like this:
Or if you are developing locally, you can use the localhost URL:
The installation of the commercial Flash Remoting for ASP.NET product also places the frconfig.txt file in the bin directory of your web root. This file contains the serial number of Flash Remoting. Additional IP addresses can be placed in this file as well. Chapter 8 covers ASP.NET in detail, including other installation and configuration idiosyncrasies. 2.1.5 PHP with AMFPHPAMFPHP adds the possibility of using Flash Remoting on PHP application servers, which are not supported by the commercial Macromedia tools. Because AMFPHP is open source, it may be used free of charge but it is subject to change and is being actively developed. The latest AMFPHP package can be obtained from its official web site:
Installation of AMFPHP is quite simple. Once you've downloaded and extracted the AMFPHP package, copy its flashservices directory to your web server's document root. Using Apache, the default Windows directory may be C:\Program Files\Apache Group \Apache\htdocs . In Unix and Unix-flavored systems, it may be /usr/local/apache/htdocs . On Mac OS X systems, it may be /Library/ WebServer /Documents . Alternatively, you can put the flashservices directory in the include_path of your PHP environment. See the AMFPHP readme file for details. The default gateway.php file should be sufficient to begin development of services, which should be placed under your webroot /flashservices/services directory and should follow the structure of your base classpath. After installing the gateway, browse to the gateway path:
If you see a blank page, the gateway is working. For more information on using Flash Remoting with PHP, see Chapter 9. 2.1.6 Typical InstallationsThe alphabet soup of technologies necessary to work with Flash Remoting can be confusing. Tables Table 2-5, Table 2-6, and Table 2-7 show several installations and typical components of each. These are not the only choices available by any means, but they represent the most typical configurations. Table 2-5 shows typical low-cost options for basic development. Table 2-5. Typical low-cost Flash Remoting installation options for development
Table 2-6 lists typical medium-cost installation options for medium- to high-traffic sites. Table 2-6. Typical medium-cost Flash Remoting installation options
Table 2-7 lists typical high-end options for enterprise-level sites with high traffic. Table 2-7. Typical high-end Flash Remoting installation options
As you can see from Tables Table 2-5, Table 2-6, and Table 2-7, Flash Remoting can be deployed using a variety of different configurations. With the main ingredients of an application server (CFMX, J2EE, ASP.NET, or PHP), web server, database, and the Flash Remoting adapter in place, you can deploy the server-side services of Flash Remoting applications. Next, we'll talk about where these services go and how they are named. |
EAN: 2147483647
Pages: 239