
This past quarter, I was taking a class in which I got to play with web services. I developed a web service in Java and used the latest application server, Glassfish, to deploy it. To consume the service, I was going to write a C# desktop application, and a Flash Lite mobile app. I thought it would be very exciting, and a lot of fun.
I was wrong.
The C# app was nothing remarkable. In fact, I was very impressed at how easy Microsoft has made web services. Just point Visual Studio at the auto generated (more on this later) WSDL file, and you can make the calls easily.
The flash application was…. more of a problem. So, in an attempt to explain why it was a problem, let me make a nice broad claim…
Flash will not work with Glassfish.
Random Yokel: But Dave! Isn’t the point of web services interoperability?
Dave: Why yes! Which is why I don’t know who to be more mad at…. Adobe or Sun!
So, Lets discuss what is wrong!
Using Glassfish, you automatically generate a WSDL based off of your Java code. The WSDL itself is valid XML, and a valid WSDL. However, when I pointed my little flash mobile test application at the WSDL, it failed. The error that Flash Lite 3.0 gave me was:
There are no valid services/ports in the WSDL file!
Weird. Especially because there definitely is a single, valid service and port in the WSDL… but that’s ok. I tried to turn it into a standard Flash application (rather than a Flash Lite 3.0). I removed the little bit of ‘mobile only’ code, and ran it again as a Flash 9 app (but the code was still ActionScript 2.0). It loads… so I try to execute my helloWorld() method (just returns the String “Hello World!”), and it fails:
Element tns:helloWorldResponse not resolvable
Strange. However, at least it appeared to get farther this time. Now, this error message gave me a little bit of a headache for a while… and then I found out the Flash does not support xsd:import. So, because the WSDL file that Glassfish will automatically generate (I suppose I should have guessed it would cause me problems), includes an import to an external schema defining your data types, Flash will choke. Ok. Let’s get around that. So, I took the WSDL that was generated by Glassfish and merged in the schema file. Simple enough, no problems. Run the code, pointing to the new WSDL which I hosted on my server (so: http://localhost/newWSDL.xml, rather then Glassfish app server: http://localhost:8080/Path/File?wsdl)… New error:
Unable to connect to endpoint: <PortURL>
Damn it. Nothing appears to be wrong with my code, C# and PHP can easily connect to my service. I was able to find this document, which basically says that Axis (another Sun app server) is sending poorly formed SOAP packets, and the solution is purchasing Flash Remoting. Right. I believe that. If the packets were poorly formed, I should be getting errors in other languages. Besides, my helloWorld() method is only returning a String! Personally, I want to think that it is some Flash sand-boxing issue, but I truly can not figure it out. Why this is so difficult? My final conclusion on this project was that Flash can not connect to a Glassfish app server (at least, out of the box). If someone has figured out how to make the two play nice, I would love to hear it.
This is bad news for Sun and Adobe. The point of web services is interoperability between systems. If you can’t deploy a simple application using Glassfish (which is the new Sun App Server…) that can be consumed by a simple Flash app… what is the point? Sure. I could go the Microsoft route, but what if I don’t want to? What if I can’t?