Deployment of an Adobe AIR application in an enterprise environment

Question

Dear Team members,
first of all my apologies for posting this thread in more than one forum (see Installations Issues) but the argument is very important to us and I don't know where discuss it.
I would like to post a question to you regarding deployment doubts that we are trying to address.
My company is working on the new version of our primary application previously built as a J2EE application with some reporting functions with Flex, and we want to use AIR in order to leverage its possibilities:
Seamless integration with existing application functionalities (implemented as standard JEE web application pages) thanks to the integrated HTML capabilities
Improved integration of the user interface with the desktop
Native processes to provide additional functionalities
Our application is targeted to pharmaceutical industry, subject to FDA regulations, and it affects more than 5000 users for each customer, so we have some specific requirements affecting the deployment and distribution of the software:
Allow to run multiple versions of the software on the same client machine (to support test and acceptance activities in addition to the production environment)
Minimize the effort of the initial setup on each client
Manage the version upgrades without manual activities on each client
Keep the test/acceptance and production environments strictly aligned to improve effectiveness of formal validation (ideally, an application once validated should be transported in production without any source code modification, recompilation or repackaging)
The current browser-based strategy is perfectly fit to these requirements, and in the shift towards a desktop-based strategy we need to continue satisfying them as much as possible. We evaluated the standard distribution strategy of Adobe AIR applications, and noticed several attention points in this scenario.
The first issue we encountered is the back-end services endpoint discovery problem. Simply hardcoding a server URL in the packaged application could be a viable solution for public internet-accessible applications, but we need to support multiple customers in their intranet, and each one typically requires multiple environments for the application (acceptance, production, etc.). Maintaining dozens of different packages of the AIR application to support all these customer environments clearly is not the solution. Neither we want to force thousands of different users to enter and maintain the correct server location in their local preferences.
So, we thought to use a badge hosted in the back-end application to run the local AIR application: using the underlying API, we could activate the application specifying also the network location of the back-end services. We could also rely on the badge to install the application (and the AIR runtime if necessary)… however, application packaged as native installers cannot be installed, upgraded, or launched by the badge API (and we need to package ours as native to use native processes).
We also noticed that multiple versions of an AIR application cannot be installed side-by-side in a client machine, and that the installation and upgrade of the application can be performed only when the local user has administrative rights on the machine (using standard or native packages), forcing us to rely on external software distribution systems in some customer scenarios (introducing additional complexities in the release cycle).
At this point, in our opinion the standard deployment strategies of Adobe AIR applications are unfit for enterprise environments. In the enterprise world, many of the applications have migrated to a completely browser-based solution, while others enhanced their client layer to comply with the requirements, for example installing only a thin portion of the client code and allowing to connect to multiple server versions/environments with it (e.g. the SAP GUI universal client). Without smarter deployment and distribution tools, AIR applications currently are a step back compared to web applications in terms of manageability.
So, we are trying to develop a solution to address these problems, with some concepts similar to JStart: install on the client machine a launcher application capable of being activated from a web page, dynamically locate, download and run the actual client bytecode, transparently enforce client software updates, and supporting multiple applications (and multiple versions of the same application). However, we are facing many technical problems due to internal architecture of AIR and we already spent a considerable amount of effort trying to find a solution. We are now thinking to return on the choice of AIR, going back to Flex.
What is the position of Adobe on this argument? Is Adobe aware of these issues and are there any plans on this topic? Any advice?
Thank you in advance

Answer 1

For those following along, Oliver Goldman will be answering this post in future articles on his blog.
Many great comments and questions here. I’m working on some follow-up posts to address these; nothing I could cram into this comment field would really do your query justice. - Oliver Goldman
Pursuit of Simplicity
Chris