Accessibility

Table of Contents

  1. Introduction
  2. Types of Web Services That Work with Flash MX Professional 2004
  3. Limitations of Handling Web Services in Flash MX Professional 2004
  4. Differences Between the WebServiceConnector, WebService API, and Flash Remoting
  5. Web Service Proxies as an Alternative to Flash Remoting
  6. Building a Generic Web Service Proxy in PHP

Getting a Handle on Web Services in Macromedia Flash MX Professional 2004

Web Service Proxies as an Alternative to Flash Remoting

When working with web services developed in-house and hosted on internal servers, you have full control over the policy file. The cross-domain policy only becomes an issue when consuming public web services hosted on remote servers that have not granted you access through a policy file.

In this case, you can use Macromedia Flash Remoting to act as a web service proxy and bypass the cross-domain policy file. Another approach is to create your own web service proxy. A web service proxy is simply an object on your server that will handle the interaction with the web service. Your Flash file calls this object just as it calls any other server-side script.

In general, it's better to use Flash Remoting than to create your own web service proxy. You can use Macromedia Flash Remoting or the open-source AMFPHP version. But there are a few reasons you might want to create your own web service proxy: Flash Remoting is simply not feasible, or your existing application platform is in a language that Flash Remoting does not support and you want to stay consistent with one server technology, or you simply prefer to manage your own code. In each case, you can create a web service proxy in the server-side language of your choice.

You can find some solutions for ColdFusion, PHP, ASP, and Java server-side proxies in the Server-Side Proxy section of the Macromedia TechNote, Loading Data Across Domains. These proxies simply let the server-side script do the reading of the remote file. Then, Flash calls the server side script instead of the remote file.

Unfortunately, this trick does not work with the WebService API. If a developer uses the WebService API, the only remote URL he or she comes in contact with directly is the WSDL description URL. However, the WSDL merely describes the web service. To actually interact with the web service, the WSDL specifies and calls out to other remote URLs. It is those URLs that violate the cross-domain policy; they are the reason the simple proxy from the TechNote doesn't work with the WebService API.

Page 5 of 6
Previous Page
Next Page