You will need to know this at some point if you are interacting with SOAP in Flex, I guarantee it.
ISSUE #1:
Types registered in SchemaTypeRegistry may overlap across different services.
Description:
You have a UserService and a RoleService. Methods for both services return an ArrayOfString. This type is generated by Flex when you import the service into the project. You call methods for each service simultaneously that both return an ArrayOfString. However, you get a type coercion problem. Why?
Explanation:
When Flex imports a web service, it generates a Base{ServiceName} class. In this class, it registers types (like ArrayOfString) with a singleton called SchemaTypeRegistry when the service is instantiated. The problem is, it doesn’t qualify which ArrayOfString it’s talking about.
Therefore, when you instantiate UserService and call a method that returns ArrayOfString, the BaseUserService will map ArrayOfString to net…userservice.ArrayOfString. This works just great when you aren’t making asynchronous calls.
The problem arises when you make asynchronous calls to both UserService AND RoleService. The last service to register ArrayOfString with its corresponding ActionScript class wins. Then, when the result for the other service returns, it will try to explicitly cast a net…userservice.ArrayOfString to a net…roleservice.ArrayOfString and you will net a null result. It won’t error, because it uses the “as” keyword vs, an explicit cast (i.e. result as ArrayOfString, vs ArrayOfString(result)), which makes debugging even more mysterious.
Workarounds:
In my opinion, this is truly a bug in the framework vs a limitation. If you can make asynchronous calls, you should be able to asynchronously deserialize the results, plain and simple. However, we’ve only really found two plausible workarounds.
“Doctor, it hurts when I sit this way.”
“Then don’t sit that way.”
One workaround is to simply queue the calls. Wait until the first call returns, then instantiate the next web service and make the second call.
If you are into changing your back end to patronize the front end, you will need to make the return type unique.
Bon apetit.
ISSUE #2:
MyMethod can’t return an object of with the type name MyMethodResult.
Description:
If you have a ListUsers class, and you return an object of type ListUsersResult, your code will compile but your application will break.
Explanation:
Again, the problem lies in the Base{Service} generated class. The result wrapper will not generate properly if you name your result object in this manner.
Workarounds:
Again, don’t sit that way. You simply cannot append “Result” to the end of your result object if it is named the same as the method itself.
ISSUE #3:
Headers array gets overwritten.
Description:
You try to make a method call, but it sends an empty headers array, even after you’ve set the headers.
Explanation:
When Flex generates the method functions abstraction classes for your service, instead of “passing along the headers” as the ASDoc would indicate, it simply creates an empty array. Can you guess where this is found. Correct! The Base{Service} class. The first line after the method signature will be “var headerArray:Array = new Array();”.
Workarounds:
We have to remember to do a global search and replace for “var headerArray:Array = new Array();” replaced with “var headerArray:Array = this.headers;” each time we regenerate the web service abstraction classes when we need to preserve headers for method calls.
ISSUE #4:
You can’t have a service with a method named .logout()
Description:
If you name your method “logout” (i.e. for an authentication class), your generated class won’t compile.
Explanation:
The inheritance chain for the web service abstraction classes is: MyService HAS BaseCubeReportService EXTENDS AbstractWebService EXTENDS AbstractService HAS AsyncRequest. AbstractService has a public function logout():void that calls the logout() method of it’s asyncRequest object. When Flex Builder attempts to generate the logout abstraction method in your service class, it will error as though you were trying to override this function.
Workarounds:
Again, avoid usage of “logout”.
I sincerely hope this saves you the hours of debugging that we invested to gain this knowledge.
…And it seems to be the magic number for now. I’ve been using this version for a while and it seems stable and complete enough to actually use f’real. If you don’t know what it is, 
