Recently, Branden and I were tasked to build a Flash UI on top of a web service.  Seems like pretty standard development...but, as you have to know by now, nothing is ever "standard" at Automata.  After some research, trial & error, and hand-wringing, we realized that the device we were attempting to connect to was using SOAP 1.2.  Well, unfortunately, Flex only supports up to SOAP 1.1, so we had a bit of a problem.

It didn't take us long to remember that SOAP was just XML, and that Flex's web service API was just a nice class that makes it easy to speak that language.  After deciding to nix the Flex solution (we were only using Flex for the WebService API), we moved to an all Flash solution.  We created a connector class to act as a web service API, and simply sent XML packets directly to the server using URLLoader.  One note about this solution is that it will only work if you have knowledge of the web service you are trying to use.  In our case, we had the entire schema at our disposal, so we knew the exact format of the service operations.

The connector class contains public methods to call the individual web service operations.  Additionally, we created individual request classes for each of the operations that extended a class called Abstract Request.  AbstractRequest provides a method send(uri:String, headers:Array) that uses URLLoader to send the request to the server.

The "uri" parameter of send() is the full path to the web service, with the "http://" attached.  The headers are the HTTP headers that you need to send to the web service for such things as authentication.  In our code, these are set in the Connector class, and passed to each request as it is needed.  The "_request" property holds the XML object that you will pass to the server.  This XML is formatted as an XML packet specific for this web service.  The value for this property is defined in the AbstractRequest sub-classes.

The _request property is an XML object that defines the format, and uses Flex-style binding to add the actual data from the constructor parameters.  This is a little-known XML trick you can do in AS3.  Branden found it in the Help section of the Flash CS3 IDE.  Pretty neat if you ask me.

Back to the AbstractRequest class, we simply set the data property of the URLRequest intstance to be the string representaton of the request XML, and call URLLoader.load(), passing in the URLRequest instance.  This sends the XML packet to the server.  The handler for Event.COMPLETE will receive the XML returned from the server.

Our connector class has methods like:

public function addGroup(groupId:String, groupName:String, flag:String):void {
	var request:AddGroupRequest = new AddGroupRequest(groupId, groupName, flag);
	request.addEventListener(ISYResultEvent.EVENT, onResult);
	request.addEventListener(ISYFaultEvent.EVENT, onFault);
	request.send(_uri, _headers);
}

This actually executes the web service call.

And just like that, you've build your own web service class.  While it's quite specific to the web service you are using, you could certainly expand it to consume a WSDL file so you can use it for any web service.

During a recent project of ours we found ourselves in the position where the developer creating the server-side code was a full 5 time zones away. This meant that we often had to do debugging over email. This was, as one would expect, excruciatingly slow. The issues that arose during integration almost always resolved around how we were mapping the servers .Net classes to our AS3 classes - one small change to the server class could break things on our end in a non-obvious way.

Luckily early in this process we discovered a piece of shareware called Charles, a web debugging proxy that's available for Mac, PC, and Linux. Once you fire Charles up it acts as a proxy for all of your web traffic. This lets you capture, view, and even throttle the data that's flowing between your machine and the web server. And best of all for us, it lets you view inside of AMF packets and see exactly what's coming over the wire. Once we got Charles up and working we able to tackle kind of issues that used to take us hours and resolve them in minutes.

We haven't done a done with Charles yet, but so far our only wish is that we knew about it sooner. Suffice it to say that we found the $50 registration fee to be well worth it!