WSDL in ActionScript

One of the advertised features of Adobe's Flex Builder is that it works with web services. Indeed, in any project you can import a WSDL and Flex Builder will generate lots of code for you. The resulting generated code states that the code generator is based on Apache Axis2, and it looks like it. This is mostly a good thing.

This is ok for a single developer or even a small team. Once you get to larger scale development, you usually want to keep code generated artifacts separate for the source code that generated them. Often you never want to check-in generated code. Why? Because then you have two sources of truth: the artifact (WSDL in this case) and the generated code. You don't want to have to keep these things in sync manually, you want your build process to do it. So you don't check in the generated code, and your build system generates it instead.

So ideally the code generation in Flex Builder could be invoked outside of Flex Builder. This may be the case, but so far I have no luck in this. It is certainly not a documented part of the SDK.

I looked for an alternative and found wsdl2as. This looked promising, but did not work out. First, it expects you to send in XML literals when sending SOAP messages. Sure it generates the boilerplate around the core message, but if I wanted to work directly in XML, I would not have bothered with a code generator. It has an option that seems designed to deal with this, but did not. Even worse, it does not handle anything except the simplest WSDLs. The first WSDL I tried with it defined complex types for the input parameter and return type of the web service. This caused wsdl2as to choke, as it expected any type information to be inlined. Sigh.

Googling MTOM

I use MyBlogLog to see the traffic stats to my blog. I noticed a lot of the referrers each day were from a Google search for MTOM. The search has one of my blog entries about an article I wrote on MTOM. I found it funny that my very short blog entry about the article shows up higher in Google than the actual article itself. The article has a lot more about MTOM and is linked to by my blog. Shouldn't that make it rank higher? The cynic in me thinks that my blog ranks higher because it is on the Google owned Blogger...

MTOM Article on TheServerSide

My second article for the TheServerSide is up. Like the first one I did for TSS, this one is on WSO2. The article is all about how easy WSO2 makes it to use MTOM for sending SOAP messages with binary data attached to them, as well as the advantages of using MTOM in the first place. Products like WSO2 are making it pretty painless to use SOAP and its "advanced" features like MTOM. This article explains some of that magic.

Artile on TheServerSide.com

My first article for TheServerSide.com is now available. It's about calling a SOAP-based web service from JavaScript. It uses WSO2, a powerful set of web service tools built on several of Apache's products like Axis2. WSO2 is similar to Geronimo. It takes a lot of best-of-breed technologies and ties them together in an integrated, and easy to use package. The article talks a lot about a JavaScript library called WSRequest. This is a very cool JS library for calling web services. It lets you expose your application through a web service, and then leverage the same web service for building a UI on top of that service. It's classic don't repeat yourself.

Flex Stocks Updated

I tweaked the Flex version of the Stocks app. I cleaned up the UI to make it just plain ol' white. I also integrated the HTML "host" page for the SWF file with the WAR and the source. So here it all is:

• Deployable WAR -- Drop it into to your web container and go to http://localhost:8080/Stocks
• WAR Source Code -- Unzip it and import into Eclipse
• Flex Source Code -- Unzip it and (hopefully) import into Flex Builder.

Enjoy!

I'm thinking of refactoring the original GWT app to use the exact same code as the code used here. More on that later.

Flex Stocks

As planned, I re-implemented the Stocks application from the first GWT tutorial using Adobe Flex. Here is a link to a short document I put together outlining the code and the interesting parts. It also has links for downloading the code I wrote.

It was really pretty easy to do this. Of course this was a pretty simple application. I might try to re-implement the advanced version of the Stocks application from part of the GWT tutorial. First, I'll do the easy one in Silverlight.

Silverlight and Flex in the Browser

The web browser is one of the great equalizers of the world. It's why Microsoft feared Netscape. If something runs in the browser, it doesn't matter where it came from. HTML, JavaScript, CSS are agnostic of the technology used to generate them. Don't get me wrong, browsers have their "quirks" and certain technologies make use of these quirks more readily than others, but these things aren't coupled. I can create an XHTML compliant application using ASP.NET and C# just as easily as I can create an app that uses lots of IE-only HTML and JavaScript using PHP.

There is an exception to this uniformity and that comes from browser extensions/plug-ins. These are capable of doing more proprietary communication with back-end servers. In a world where a new rich internet application framework is being introduced by some multi-billion dollar software company each month, one could easily imagine a tight coupling between such frameworks and the server technologies that feed them.

Of course the mother of these new frameworks is Flex, Adobe's application platform built on top of Flash. One of the common companions to Flex is Flex Data Services. This is actually an Enterprise Java application for accessing enterprise resources (like databases) and serving up data to Flex clients. One would guess that you could do the same thing on your own, and not just in Java. Your Flex client makes gets/posts to a URL and parses the response for a data model. You could even use SOAP for all this, if you were a masochist.

The design behind Silverlight seems very similar. The quick start tutorials from Microsoft show a Silverlight client connecting to a web service. Thus it should not be too hard to build a Silverlight application that talks to a Java or PHP server. On a side note, I had one interesting realization from reading through some of the Silverlight tutorials. They make a big deal distinguishing between client-side Silverlight code written in managed CLR (i.e. C# or VB.NET) as opposed to code written in a scripting language such as JavaScript or Iron Python. My understanding of the CLR was that everything was compiled into Intermediate Language (IL.) It sounds like if you use C# for your Silverlight project, then this is the case, but not if you use Python. This seems ... odd. One approach I thought they might try was to compile everything into JavaScript and let IE's runtime handle it ... but then I remembered that they are providing Silverlight for Firefox and Safari.

So my plan now is to take the Stocks application I wrote for the GWT tutorial (part is out next week, by the way) and create a Flex and Silverlight version of the same thing. I might cheat and re-use the servlet that GWT creates, or I might create a REST servlet. Too bad there are JSR 311 implementations yet.

Oh yeah, and then there's JavaFX. There is a fair amount of JavaFX documentation and examples. However, I'm not really sure if JFX will use a similar mechanism as Flex and Silverlight. It seems like it has to. The example I've seen usually create all the JFX on the server and then ship it to the client for rendering. That approach seems kind of primitive and something that would be difficult for an interactive application (like the the stock application.) Maybe by the time I'm done with the Flex and Silverlight versions of things, it will be more obvious how to do the same thing with JFX.

Web APIs: Flickr vs. GMaps

I was doing a little research on web APIs. Two of the better ones (or at least well known and used) out there are Flickr and Google's Map (GMap.) They present two very different ways to enable third party developers to leverage powerful web services. So I thought I'd do a little compare and contrast.

Flickr's API is a classic procedural library. There are calls for almost any action you could possibly do with all things Flickr : photos, account, tags, sets, etc. You can upload photos, access photo streams, search by tags ... pretty much anything you can do on Flickr's site. Each call is a different HTTP request. You can send the package of your request in a variety of formats: REST, XML-RPC, and SOAP. The REST and SOAP follow the usual patterns for these formats. The REST requests are "pure" HTTP requests. Flickr's XML-RPC is very true to the RPC mode. It uses simple XML to specify a procedure to call along with it's parameters.

You can also specify the format of the response you get back from Flickr. Since they support REST, XML-RPC, and SOAP for requests, it's not surprising they support all these for responses. They recently added JSON and PHP as response formats. I was pleased to see JSON. I can imagine that if I was going to use Flickr's API, I would probably choose to use REST+JSON. Make a pure HTTP request and get back a JavaScript object. Seems like the lean-mean approach to me. I was surprised to see PHP as a response type. In this case, they are referring to serialized PHP objects. The structure of these objects is identical to the JSON structures.

GMaps is different in many ways to Flickr. Instead of supporting procedural calls to Google, everything is object oriented JavaScript. You include a library from Google and then use their objects. Many of their objects provide methods for making calls similar to what you see in Flickr. For example, you can geo-code a location, calculate directions, etc. But you don't make the HTTP request and you don't parse a response. Google's JavaScript objects do these for you.

The differences in these web APIs reflect the differences in these web services. Flickr is more of a pure data service. You can modify data (photos) and query that data (search for photos, etc.) Flickr wants to be your photo database. As such, they give you a number of ways to access your data. What you do with the data is up to you. Show your pics on a website, provide tools for uploading, print the pics, make aprons, whatever...

GMaps wants to draw maps for you. They don't want to give you mapping data for you to do whatever for it. They want to draw. They'll take your data and draw maps with it. They always draw the map, so they give your users a familiar interface that also integrates into Google. All roads lead back to Google.

Thus the APIs to these services are very appropriate for the services. I don't know for sure, but I'd wager they also reflect the programming design behind the services. It seems pretty obvious that Flickr is written in PHP and that Google Maps is written in Java (maybe the last one is less obvious, but I do have a little inside information on that one.) So it's not really surprising that a PHP site would have a very flexible, procedural API, and that a Java site would have more closed, object-oriented API.