Flash-powered web applications (whether constructed with Flex or OpenLaszlo) are a nice complement to server-side logic implemented in Java EE. It is not uncommon to have the Flash application hosted on a different machine than the Java EE application server is hosted on and so the crossdomain.xml file is required.
This situation is even more common when a Flash-based application wants to access a different provider's APIs and services (think Yahoo!, Google, etc.). When you are accessing someone else's services from your own Flash-based application, you do not need to worry about the crossdomain.xml file (it is their concern and there is nothing you can do about it anyway if they don't provide it). However, if you want to provide services for others' Flash-based applications to use, then crossdomain.xml creation and placement is required.
When using GlassFish (the Java EE reference implementation), the "top level" directory for placement of the crossdomain.xml file is the "docroot" subdirectory under your GlassFish domain's directory. For example, if you use the default domain of domain1, you'd place the
<<GLASSFISH_INSTALL_DIR>>is the directory into which you installed GlassFish (such as
C:\glassfish). This is described in the java.net GlassFish forum and in the Flex 2 General Discussion forum.
Additional details on using GlassFish with OpenLaszlo can be found on the OpenLaszlo on GlassFish blog and in Harpreet Singh's weblog. For additional details on running Flex-based Flash applications on GlassFish, see Senthil Chidambaram's blog entry. More details regarding the use and contents of the Flash crossdomain.xml file are available in the Flex documentation and in OpenLaszlo documentation.
UPDATE (08/14/2008): Flash Player security has been tightened since Flash Player 9 Update 3 (188.8.131.52). I recommend reading about changes, including changes to the
crossdomain.xmlfile, in the Adobe document Policy File Changes in Flash Player 9. Changes that may impact you include a requirement that the
Content-Typevalues in server response headers be set to any text type (such as
application/xhtml+xml. Other changes include stricter socket policies and the use of the final URL (rather than the original URL) as the basis for determining the appropriate policy file in the case of a redirection within the same domain.
UPDATE (11/27/2007): I have added some useful links to resources related to the Flash
Cross Domain XML
A Site Dedicated to crossdomain.xml at Aral Balkan
Cross Domain Policy Files
The Dangers of a Cross-Domain Ajax with Flash
Cross-Domain Ajax Insecurity
Cross-Domain Policy File Usage Recommendations for Flash Player
Don't Forget Your Cross-Domain Policy Files