Lessons from Porting a MS-Office-Scale App to Flex 3/Flash 9

Earlier this year, I led a consulting team which ported a large Windows client app (similar to a member of the Microsoft Office family; think something like Visio but with different functionality) to run in the Flash 9 runtime, using Flex 2 and Flex 3 Beta, in under 6 months.

I was invited to present a (very!) quick talk on some of our "lessons learned," as part of O'Reilly Ignite at Adobe MAX in October. Alas, schedule issues made it impossible to present at MAX. So here, in Ignite style (15 seconds per slide), are the key lessons from the project:

1. The learning curve for Flex/ActionScript 3 is very shallow for experienced software engineers, so a strong team can jump right in and be productive even without any Flex/Flash experience. Only two of our five developers had done any Flex or ActionScript work before at all. That said, Flex is still a “leaky abstraction” – some aspects (e.g., deferring an operation to a subsequent frame) of Flash Player still bubble up – so it’s useful to have at least one engineer who is familiar with coding for Flash.
   
2. There is no need to think about a Flex app as a Flash movie on steroids – simply think of it as a VM-based app (like a C# or Java app) from day one. Bringing standard OO pattern experience is very helpful. UML/Code generation tools for AS3 may be helpful too depending on your dev process.
   
3. Premature optimization is still the root of all evil. Most optimizations are a non-issue with the performance levels of Flash 9, and we found that a small number of relevant optimizations could be easily done toward the end of the project without significant pain in refactoring. Network operations, which were outside of our scope, were the only cause of performance issues. Nor did we compromise in terms of space: We had tens of thousands of lines of code, hundreds of features, and most of our display via custom code (the app is partly a diagramming app) … and it compiled to a .swf in the 670 KB range.
   
4. ECMAScript 4, JavaScript 2, ActionScript 3: whatever you want to call it, throwing static typing into the mix (without requiring it everywhere) rocks! Our unscientific feeling is that we enjoyed a 2-4x productivity improvement over a similar language (e.g., JavaScript) because of static analysis capabilities and compile-time error checking.
   
5. E4X on a large scale is a beautiful and terrible thing.
   
• The beautiful part is: It did not lead us to make a mess of our application with snippets of XML processing scattered everywhere (something we worried about at first), and the performance is amazing. We were doing a ton of XML for integration to existing systems so we worried at first. We measured it, and benchmarks of XML processing speed with E4X were far and away more than adequate.
  
• The terrible part is: the E4X API has some quirks and inconsistencies that are not documented, and in a number of cases we needed to cook up some ripe hacks to work around them. These issues can and should be cleaned up. E4X also misses a couple of (admittedly rarely used) aspects of the XML schema spec around attribute namespace scoping, that just happened to cause us some difficulty.
  
6. The Flex framework is in serious need of a native AS3 rich text, full [X]HTML editing widget. Workarounds currently include AJAX in the browser, or AS2-based components that can’t run immediately in an AS3 app's VM space.
   
7. For building some applications, the async-callback approach can create substantially more chaos than it eliminates. To address this, Flash/Flex needs threads, or at least continuations. In fact, this is the first time in my career I’ve really seen a problem (handling certain callbacks) where continuations would be an ideal solution and not just a clever one.
   
8. It is easy to mix open source Flash tools and commercial Adobe tools – my team did, and it worked well all the way around.

Since Flex/Flash are likely to stay key contenders for any RIA implementation project, I hope these learnings are helpful when embarking on that sort of work!

Microsoft Will See Your Web Services and Your Horizontal Database Scaling, and They'll Raise

Don Box has come out in defense of Microsoft's support of REST technologies a number of times. And this year we've started to see what else is behind the curtain, with project Astoria. Still being designed and built, but with bits available and integrated into VS2008 today, Astoria includes both local (your own machine/datacenter) and cloud services for data storage that support HiREST, relational modeling, and support for various data formats (JSON, POX, Web3S [the last a play on, and jab at, S3?], ATOM).

If you haven't seen these services, you need to check them out. In addition to being technically interesting (e.g., since queries can be expressed via REST-style URLs, your network appliances and front-end web servers can actually participate in execution or caching strategies!), these services are likely to be a big part of the web service landscape.

Whether you love Microsoft or not, it is fairly clear that the original ASP.NET SOAP implementation (and client generation) were years ahead of anyone else in terms of no-nonsense ease of use, compatibility, and extensibility.

These SOAP components were made available to developers in 2000 or earlier. They brought things like "Type [WebMethod], ok now you have an XML-RPC SOAP service. You're done, go home, have a beer," while Java was still trying to figure out how which alphabet to jam into the end of their JAX* wildcards, and inventing APIs where you just start off with a nice ServiceFactoryBuilderConfiguratorFinderInstantiatorFactory and go from there.

Why rehash this history? Because in its final form, the Microsoft solution is going to be influential. They may be late to the party here, but don't discount them.

Enterprises need service description layers for REST. Someone is going to give it to them in a way that they can use it. And an Amazon-S3-scale relational data service in the cloud (no, Freebase and the like don't count) could be really interesting to everyone who doesn't have enterprise, need-my-data-physically-in-house requirements. With ActiveResource a core part of Rails 2.0, I could see building read-heavy apps using caching and Astoria, and no local database at all! My clustering problems (and expense) have all just become someone else's problem!

There's something else to see here too: read the Astoria dev team blog and the comments. You're watching Microsoft designing and implementing a big API in real time with interaction from the community. Don't look for an open-source experience -- you can't check out the code and send patches. But there is a lively discussion going on between the development team and outsiders to try and come up with the best solution that fits the constraints.

No. It's Just About the Metadata.

If an ad-supported blog exists to stir the pot then I supposed the GigaOM network's future of software blog is succeeding. I thought the first post was tennis without a net. Actually I also thought the second post was tennis without a net. And now I think the latest, "Web Services war is over: Time to Rest" is just bogus hype. Not that REST isn’t gaining ascendancy, but it’s a case of the straw man fallacy.

The war was never between REST and WS-* specs: the WS-* specs have been despised, ignored, and abused since their introduction.

Nor is it between REST and SOAP (and the xml schema documents that go with SOAP, which are also despised) which WS-* was meant to supplement.

It’s a war of describing operation semantics versus hoping that they will be “implicitly self-describing” and that everyone can agree on what GET, PUT, DELETE, POST etc. mean.

 The latter, which is the purist REST position, works well for documents (e.g., HTML pages on the web), and alright for basic business objects (calendar appointment, car maintenance record) but gets a lot trickier for transactional services like “change John's seat on the second jetBlue segment today to 13A, or else the window seat closest to the front of the cabin, or else fail fast and give me a set of alternate available seats.” Can this be done with REST? Yes … kinda sorta … but the call will not be one of those trivial “implicitly self-describing operations on an entity” that REST works very well for.

The good news is that, in reality, both camps are converging on a compromise: REST with (optional) metadata: WADL, OpenSearch, WRDL, even the much-maligned (and for good reason) WSDL 2.0. The metadata supports tooling, automated strong bindings, better testing, automatic integration to enterprise object buses etc.

This is a philosophical step away from REST, but this is actually what we’re seeing coming down the pike for enterprise work, and the SOAP and WS-* people will be just fine with it.