Wednesday, September 17, 2008

Flex and .Net

I'm currently investing time in learning how to connect a Flex RIA to a .Net server. Having worked for many years on web applications in the finance and banking sector I am well acquainted with the trials associated with rendering forms and implementing user experience consistently on a variety of modern and vintage web browsers. The ability to design and code for a single runtime environment has strong appeal. The stumbling blocks for me have been a loathing for Flash-based advertising and poorly constructed Flash-based websites. Actually my loyalty to Firefox is due in part to the ability to selectively enable Flash via the FlashBlock extension. And did I mention that I also dislike Adobe Reader? How can Adobe turn something so simple into an unwieldy bohemiath.


However the biggest stumbling block is the lack of detail surrounding Flash/AIR session handling and caching. This is something that is well understood in browsers; an online banking site will typically store a session cookie in your browser cache and you can feel confident that cookie will be erased when the session is ended. I believe this isn't necessarily the case for Flash although I can't just now place my hands on the particular URL where this issue was being discussed. At the time it was enough to shelve my interest and it's an issue I need to revisit.


So there are a number of ways to connect from an AIR application to a server application. An obvious one is via Web services. This has the enormous benefit on the server side that having written and published your Web service it is now available for any client-side or peer-to-peer technology that knows how to speak your particular flavour of Web service (SOAP/REST). A disadvantage of even a well-designed SOAP Web service can be the amount of XML data being shipped to the client. This is going to impact the responsiveness of an application even over a broadband connection. For AIR the alternative is to use Flash Remoting, the benefits of which according to this Mark Piller tutorial "include significant performance improvements, reduced development costs, and a more natural client/server integration". At this stage I'm just going to accept those claims, I don't have any good reason to dispute them.


Using Mark's tutorial turned out to be a reasonable place to start. There is a commercial Flash Remoting product but Mark's company gives away the previously commercial WebOrb Flash Remoting application. The tutorial had one unfortunate omission that had me scratching my head, I was consistently getting an error message “Destination 'GenericDestination' either does not exist or the destination has no channels defined (and the application does not define any default channels.)”. I don't know if this occurred because I'm using Flex Builder 3 rather than version 2 as in Mark's tutorial. I found the resolution on one of the forum pages. I needed to provide the additional Flex Builder compiler argument -services "services-config.xml" and copy the services-config.xml, remoting-config.xml, and data-management.xml from C:\inetpub\wwwroot\weborb30\WEB-INF\flex into the src directory of my Flex Builder project.


The need I have at the moment is to feel confident I can replicate this quickly in order to pitch for some work. That work entails integrating a Flash/Flex application with .Net server-side and some form of repository, all in a package I can distribute to a hosting environment. Trying to tie those strings together is where the tutorial unravels. GenericDestination is not something I want to use for a production environment, it allows access to every deployed assembly in the .Net application. The tutorial even indicates that it shouldn't be used in a production environment. On the Web what is easy is often used by default, particularly by inexperienced developers. To identify the alternative configuration I need to dig deeper, I'm sure many wouldn't bother. This is a peeve, if you're going to go to the trouble of writing a tutorial, show me how to do the job correctly. In this case the easy way has serious security implications that may be ignored by developers who just want to get something out there.


So now I want to start filling in the gaps. The above-mentioned GenericDestination needs to be replaced with something appropriate. I need to understand what is required to deploy my application into a hosted environment. I need to integrate my application with some form of repository and I'm leaning towards NHibernate largely because I had some recent exposure to its Java forebear Hibernate and I'm curious.

No comments: