Our top story this week presents Rich Internet Apps (RIAs) as not just a direction but the direction for enterprise apps. What's your take on why this is such an important trend?
If you look back at the history of the Web, the browser brought about a tremendous revolution, but it was primarily a user-interface revolution. We believe we're at another inflection point that will bring about yet another dramatic improvement in usability.
The first revolution was really very document oriented. We have hypertext, home pages, bookmarks and forward and backward buttons. The core metaphor is one of documents, but that starts to run out of gas when it comes down to delivering rich media and applications. Applications are different than documents in that they're user interfaces for conducting multi-step operations and helping users interact with business processes and take action. It's not about reading and browsing. It's about doing things.
The Flash/rich-media connection is clear enough, but what's the connection to applications?
Flash was designed to bring motion graphics and then video and other types of rich media into an otherwise document-oriented Web, but we soon realized we had a similar opportunity to augment the Web browser for applications. That led us down the path of taking this ubiquitous cross-platform runtime -- the Flash player being on 98 percent of all PC's, running on Mac, Windows and Linux -- and coming up with a programming framework that follows the same methodologies, that uses the same tools and that follows all of the conventions that enterprise application developers are familiar with. That's our Flex technology, and you can think of it as a way to deliver service-oriented clients on top of your service-oriented architecture (SOA). Services come up through the back end and middleware, but it usually ends there. Flex extends those services to end-users and makes all that data that you've exposed via SOA meaningful to end users.
There are lots of ways to build RIA user experiences, but you have to use the right tool for the job. There's no one tool that's right for every solution. Ajax is really great for bringing incremental improvements to existing Web applications. If you have a big Web app and you want to eliminate page refreshes here and there and bring some improvements to the user experience, it's a great fit because it follows the same [development] model. It's relatively easy for Web application developers to understand and adopt Ajax for simple things, and that takes you pretty far.
Ajax gets a lot more complicated and more challenging to use when you're building full-on, large-scale rich Internet applications that are very data intensive and very graphical. A lot of Ajax frameworks are fairly lightweight and not terribly complete. Some of the commercial-grade frameworks are more complete, but they're often incompatible and can't be mixed and matched. When you pick one, you are really making a long-term commitment as to how your software is going to be built, so it could be a fairly risky decision.
Another problem with Ajax is that productivity tends to suffer because of the cross-browser compatibility issues that pop up when you're dealing with very large-scale applications. It takes time to track down and fix all the bugs. Flex is most powerful in these large-scale, complex development scenarios and it solves all the issues I just mentioned.
What about Microsoft Presentation Foundation?
That's an incredibly powerful tool set. It's really cool stuff and good technology, but it's still a little early. It's not yet widely proven in a lot of rollouts, so there may be lurking issues that we don't know about.
Earlier you mentioned the connection between RIA and service-oriented architecture. Why is that important?
It's critical because a lot of people think, "All data in the enterprise is going to be exposed via Web services and XML; that's great because any rich Internet application can talk to XML and SOA." On the surface that's true, but there's a much deeper architectural discussion going on about new ways to think about data and new ways to think about SOA in the context of rich Internet applications.
A lot of the work on SOA has been focused on system-to-system orchestration and integration, but the other dimension is SOA to the client -- services that are composed, exposed to client computers and rendered in a user interface so people can interact with them. That's an area where we've put a lot of R&D. We have a whole server-side offering in our Flex product line called Flex Data Services that lets you hook into your existing SOA, whether or not you've exposed everything as SOA and XML. We can connect directly into Java objects and JMS queues -- not just remote-procedure-call-style data, which is what SOAP gives you, but also real-time message and transactional data.
If you look at what people do with messaging and transactions, it's mostly focused on getting data from your middleware to be persisted effectively into the database or whatever systems of record you might have. The same transactional properties that you demand between middleware and the back end needs to be carried forward to the client side. So if I'm using RIAs to trade stocks or to shop and I lose my connection, you need to be darned sure that when that connection is restored that the changes that happened while the connection wasn't there can be replicated and synchronized with the client.
You've touched on the point that RIA, like desktop apps, should work in disconnected modes. How is Adobe addressing that problem?
One of the big limitations of browser-based clients is that your applications only work when you're online. The applications can't run in the background, so they're not like desktop applications. Customers have come to us and said, "I want my application to bust out of the browser and live on the desktop while retaining the deployment properties of the Web," meaning you click on a URL and it just comes down and installs. Developers also want the user to be able to download data to the client, unhook the computer, get on an airplane, work on the application remotely and then sync that data back up with the server.
The way we're delivering on that is with our Apollo client, which is the code name for our next client. It's a hybrid runtime that combines the capabilities of Flash with an embedded HTML engine… We're blending those together as a runtime so that you can build an application that installs from the Web, that blends a Flex-based RIA with maybe some Ajax widgets, and can then render PDF documents as well.
The big, big difference with native desktop software is the installation experience. With native apps, you would download this big thing, run setup.exe and 15 minutes later, you reboot your computer and then you've got a new application. With these applications, you click on a link and then you get a notification, "Do you want to install this on your desktop?" Once you answer "yes," 30 seconds later it opens and it's there.
Many software vendors are now building RIAs, but how far along are corporate developers in embracing the trend?
Last year was a pivotal year. RIAs went from something that very few of the very early adopter innovators were doing successfully to something that a lot of people were talking about and aware of, but still, not that many people were actually doing it successfully.
If you look at the job boards out there and titles such as "rich Internet applications" or "Ajax" or "Adobe Flex," you'll just see hundreds if not thousands of jobs. Organizations are actively looking for developers who have these skills. Speaking for our own community, Flex developers right now are in very high demand, and they're commanding significantly higher salaries and have more job choice than developers with more generic skills. You didn't see that at the beginning of 2006.