This month the topic is Web services. Previous articles looked at the RIA, component-based development, XML, and the role of ColdFusion as a data source. In this issue we examine the role of Web services in RIA development.

What is a Web service? Two years ago I really didn't have a clue. Sure, I had heard some of the buzzwords such as SOAP and WSDL, but back then I couldn't have told you what they meant. Then Macromedia asked me to speak at their developer's conference: MAX. Knowing of my passion for Flash and data integration they offered me a great topic: Flash and Web services. It was a wonderful opportunity and a great eye-opener for me. Just what is a Web service? Let's break it down. Web. Service.

The Web refers to an immense information space and network that enables unprecedented access to resources. A Web resource is some type of electronic construct, such as a file, network, processor, application, or service. Every Web resource is identified by its URI and accessed via Web protocols.

A service is a resource that exposes its functionality through a programmatic (rather than a graphical) interface. The method of calling the service, and the possible results of that call, are exposed via documentation (the schema). Developers only need to concern themselves with this programmatic interface.

A Web service, therefore, is a resource that is identified by a URI and accessed by applications using standard Web protocols in accordance with the schema that describes its programmatic interface.

Applications can be assembled from these services.

The service provides an interface that can be called by another program. This interface acts as an adaptor between the Web and the actual application logic that implements the service. The programmatic interface provides a layer of abstraction that makes the connections flexible and adaptable. This application-to-application programming interface can be invoked from any type of application client or service

What Role Do These Web Services Play in RIA Development?
Web services provide a standardized method of passing commands and complex data between the client and the server.

Macromedia recognized the power of this technology and expressed a serious commitment to it with the MX product line.

Jeremy Allaire succinctly stated Macromedia's position: "The convergence of rich clients, Web services and the need for a more scalable Web application development and deployment model have driven Macromedia to deliver components and Web services as part of Macromedia MX. ...empowering a wide range of developers to access the power of object-based component development, rich client/server models and Web services without the pain of complex frameworks. The Macromedia MX product family combines ColdFusion Components with the rich client capabilities of the Macromedia Flash Player, the development capabilities of Macromedia Dreamweaver MX, and the openness and interoperability of SOAP and XML Web services."

This series of articles has explored that vision. We have seen how Flash's data and UI components provide for rapid visual development. In the last issue we saw how ColdFusion provides an extremely simple method of creating a rich data source. User-Defined Functions (UDFs) in a ColdFusion Component (CFC) can make data sources for both Web services and Flash Remoting technologies.

The standardization that a Web service brings to distributed computing is based on its use of standard Web protocols. The most notable are HTTP and XML. Domain Name Service (DNS) technologies also have a role.

So, how do we use all this in Flash?

The first thing we need is the Web service's WSDL file. WSDL stands for Web Service Description Language. It is one of the flavors of XML that Web services use.

Please be very clear on one thing; the WSDL file is not the Web service. The WSDL file is a description of the Web service. Think of the WSDL file as the metadata for the service. It describes what the service does, how it communicates, and the actual Web address of the service.

The WSDL file describes the service's programmatic interface. It is a contract. It promises us that if we do this, we will get back that.

The good news is that we should never have to either read or write a WSDL file our selves. The WSDL file should be automatically generated by the technology in which we created the service. When we need to use a Web service, the technology we are using should be able to read the WSDL and help us consume the service.

Flash, Dreamweaver, and ColdFusion all provide that level of support.

In ColdFusion the WSDL is generated when we append ?wsdl to the end of our ColdFusion Component's address. If our component's address is www.mydomain.com/mycomponent, the address for the WSDL is www.mydomain.com/mycomponent?wsdl.

From this WSDL a proxy object can be created. The proxy object is an object we instantiate on our server, or for our purposes, in the Flash client, that has all of the methods and properties of the service described by the WSDL. We can then use all of the functionality of the remote service right on our local proxy. Commands and data are passed between our proxy and the actual service using another flavor of XML; SOAP.

SOAP (the Simple Object Access Protocol) is the XML schema that provides a standardized way of exchanging data and commands between a Web service and a Web service consumer. SOAP is independent of the platform, object model, and programming language used.

This standardization provides for great flexibility. Any client on any platform can communicate with any service on any platform. Such exchanges are said to be "loosely coupled."

This broad flexibility means that the exchange may be slightly lacking in efficiency. If we were dealing with a specific service and a specific client we could format the exchange in the most efficient manner without regard for other clients and services. This is what Flash Remoting does.

Flash Remoting requires a Flash Remoting­enabled server and the Flash client. The exchange between the service and the client is accomplished by exchanging binary data in the Action Message Format (AMF). This binary is leaner and more efficient than the textbased marKup of the SOAP XML. Flash Remoting represents the most efficient way of exchanging commands and data with a service. Flash Remoting will be the subject of the next article in this series.

Let's look back briefly at last month's article on ColdFusion as a data source. We saw that by simply setting the access attribute of a user-defined function to remote we could create a ColdFusion data source that functioned both as a Web service and a Flash Remoting data source.

This flexibility allows users in other frameworks (ASP.net, Java, PHP) to consume our ColdFusion data source as a Web service using WSDL and SOAP XML. The same data source can then be used by Flash clients as a Flash Remoting data source using the more efficient AMF binary. Macromedia has provided for efficiency within their products without excluding other technologies.

We have discussed the role of XML in Web services, but earlier I mentioned that Web services also use domain name service (DNS) technology. Part of the bigger picture of Web services is the idea of directories where we can browse for services to assemble applications from. These directories are called UDDIs (Universal Description, Discovery and Integration) and they are where Web services use DNS technologies.

While an optional part of the Web services framework, UDDIs present a very interesting development model. Developers will search these directories by functionality, or by industry, to find services to build applications from. Inventories, pricing, shipping information, and other business information will be able to be found in UDDIs.

UDDIs can be public or private. There are several public UDDIs, including those at IBM and Microsoft. One that has been very popular with the Macromedia community is XMethods (www.XMethods.com). The famous and popular Babel Fish service was once available there.

XMethods provides a listing of Web services as well as a list of clients using the services. In addition, through a partnership with Mindreef, Inc., XMethods provides a means of testing the service and seeing the underlying exchange of SOAP.

XMethods' home page lists the most recent additions to the directory. At the bottom of the home page there is a list of XMethods demo services. While you are on XMethods' site don't overlook the links for the full list of all the Web services listed at XMethods.

Our application will use a simple service from the XMethods demo services at the bottom of the home page. The Weather ­ Temperature service will give users the temperature when a ZIP code is submitted.

At the bottom of XMethods' home page, in the Demo Services section, find and follow the link for Weather ­ Temperature (see Figure 1). This will lead us to a page with information and links related to the service. Take a minute and look at the information on the page; the only thing we will need to use this simple service for is the address for the WSDL (see Figure 2). If we follow the link near the top of the page we can see what the WSDL for this service looks like. Note: This illo is very optional (see Figure 3). If we copy the address from the address bar we are ready to open Flash and build our Web service consumer.

Create a new Flash document. Add a new WebServiceConnector from the Components panel (see Figure 4). Like the other connectors, this component does not have a visual presence in the final SWF. It is often placed off stage, out of the way of visual elements. Give it an instance name of cxn.

Open the Component Inspector and go to the Parameters tab. Paste the WSDL into the WSDLURL field. Flash will go out, get the WSDL, analyze it, and use the WSDL information to assist us in creating our application. After a few seconds we can click the operation field underneath the WSDLURL field. This will show us all of the functions that we can run from the service. The Weather ­ Temperature service has one operation, getTemp. We'll leave the other settings at their defaults. The finished Parameters settings will look like Figure 5.

With the connection configured, we can build the user interface for the application. We'll add two text inputs from the UI Components to the stage, one above the other. We'll give the top one an instance name of zipcode and the bottom one temperature. In between them, we'll place a Button component. The Button does not need an instance name, as we will apply our actions directly to it. The finished set up will look like Figure 6.

With our components in place, we are ready to bind them together. We'll start by binding the user input (zipcode) to the service.

Select the WebServiceConnector on stage. In the Component Inspector panel move to the Bindings tab. Click the plus sign to add a new binding and select zipcode from the params (see Figure 7). Back in the Component Inspector, move down to the bound to field and choose TextInput, <zipcode> from the Bound To window. The finished binding will look like Figure 8.

Now, we'll bind the results to the interface. Keeping the WebServiceConnector selected and staying in the Bindings tab, click the plus sign to add the final binding. In the Add Binding window, select results (see Figure 9). Again, move down to the Bound To field. Open the Bound To window and select TextInput, <temperature>. The final binding will look like Figure 10.

All that remains is to program our button to trigger the call to the service. We will do this by adding a behavior directly to the button. Start by selecting the button on the stage. Open the Behavior panel and click the plus sign to start adding the behavior to our button. Choose Data > Trigger Data Source (see Figure 11).

From the Trigger Data Source window, be sure to select the WebServiceConnector; cxn. The applied behavior will look like Figure 12.

Test your movie. When the SWF opens you should be able to enter a valid ZIP code, click the button, and receive the temperature for that area.

One important thing to note: this application will work fine from the SWF player. It will not work if we put it on our server. Web services use XML in the exchanges of commands and data. When running from a Web server, Flash's XML class does not allow data to be loaded from other domains without a permissions file on that server. This will be examined with other security issues in a future article.

Summary
Remember that you can use last month's article to create your own Web service data source. Then your data source and Flash application can come from the same domain and there will be no security issues to prevent the loading of data.

Have some fun and play around with some of the other Web services at XMethods. Remember that some services may return objects to us that we cannot use. Any service that returns a string or number is a safe bet.

That's it for this month. Drop back next month as we examine and build an application based on Flash Remoting.