|
|
|
Sponsored Link •
|
Summary
The alpha release of Apollo generated both excitement and healthy skepticism about Adobe's new client-side runtime. I decided to take a first-hand look at Apollo and summarize some of my findings in this blog post.
|
Advertisement
|
When Adobe announced in March the first alpha release of its new desktop runtime, Apollo, initial reactions were mixed. Positive comments seemed to agree with TechCrunch's Michael Arrington:
It could be the technology to watch for 2007. And Adobe is certainly counting on it to drive future revenue... Apollo will be useful for running desktop versions of critical web applications like email and calendaring, where offline access and application speed is sometimes important.
Others, however, had reservations about yet another technology to cloud the rich-client development space. Alex Iskold on ReadWriteWeb echoed those sentiments:
It appears that, intentionally or not, Adobe is on a collision course with IE, Firefox and the rest of the Web browsers. Firefox has already said it is [sic] looking to add support for offline applications into its next version. If this happens, it will be bad news for Apollo... IE plans in the same space are not clear, but we can be certain that if offline mode for web applications takes off, then there will be support in IE.
One thing most Apollo commenters seemed to agree on: Rich-client developer tools are reaching a critical mass, leading not only to more interactive Web applications, to but also to new application architecture styles.
I will have more to say about how rich-clients are influencing application architecture styles, such as REST, in a future blog post. For now, I'd like to report on my first impressions of Apollo, concluding with some comments on supporting off-line Web applications.
A concise definition of Apollo invites at least two considerations. Adobe's Acrobat Reader and Macromedia's Flash player are among the most widely used pieces of software on user desktops, and it seems sensible for a post-merger Adobe/Macromedia combo to fuse the best features of Acrobat and Flash into a single runtime. On the surface, that's what Apollo provides. (Note that the current Apollo alpha doesn't yet support PDF, but the 1.0 release will.)
An equally important consideration, however, is that Apollo is built on top of WebKit, the open-source browser toolkit. That means, in effect, that Apollo gives you the ability to offer your own custom browser to users of your application. For Apollo applications, that browser functionality is provided via an HTML component available in Flex's XML UI API. Creating and displaying the simplest browser requires just a few lines of code:
<?xml version="1.0" encoding="utf-8"?> <mx:ApolloApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" width="600" height="500" creationComplete="htmlComponent.location = 'http://www.artima.com'"> <mx:HTML width="100%" height="100%" id="htmlComponent"/> </mx:ApolloApplication>
Assigning a new URL to the location property, as in the creationComplete event's handler, causes that URL to be loaded into the browser component.
If you save the above code into a file and run that file through the Flex compiler, you can then generate an AIR file, Apollo's distribution format, and share that file with your users. Users with a pre-installed Apollo runtime can click on the AIR file's URL, causing the application to download and install on the desktop just as if it was a native application, including desktop icons and start menu integration. The Apollo runtime is under 6MB, and it is anticipated that in the future it might piggyback on some popular Adobe technology, such as Acrobat. A simple Apollo application I created resulted in an AIR file of just above 300KB.
The browser component, for all practical purposes, has the same rendering engine as Safari, and can equally execute JavaScript code. Indeed, Apollo's documentation predicts two kinds of applications targeting Apollo: those written primarily in HTML, and those written chiefly with Flex.
While it would make little sense to deploy Apollo for a pure HTML-based Web site, a more interesting possibility is to write a bit of Flex code to extend the Web user interface with the ability to interact with the desktop. An obvious use-case is giving access to the filesystem, but more intriguing desktop integration is possible, too, such as capturing input form a user's Webcam or microphone.
Flex-based applications can run inside Apollo with almost no changes. Indeed, a Flex application can be turned into an Apollo application just by changing the outmost application container from mx.core.Application to mx.core.ApolloApplication. In that sense, Apollo is similar to "Flash reflectors" that let Flash applications install and run on the local desktop.
I haven't yet experimented with Apollo's capability to let Flex code call JavaScript in an HTML page, and, vice versa, to have JavaScript call into Flex code. That two-way communication seems to be at the crux of a new type of hybrid Web UI: delivered as a regular Ajax page, such an application can discover the browser environment, and extend its capabilities if, for instance, it ran inside Apollo.
Apart from integration with the native desktop, the main focus of the Apollo alpha release is providing full access to the filesystem. Filesystem access is defined as an extension to the Flex API, since Flex sans Apollo, running in a browser, doesn't have access to the filesystem apart from simple file upload and cookie-style file storage.
An interesting aspect of Apollo's filesystem API is that it carves out a persistent storage area on the local disk for each Apollo application. Such application storage areas are specified in a platform-independent manner. Otherwise, there is nothing surprising about the Apollo filesystem API: It provides the standard sort of APIs to navigate the filesystem, and create, read, and write files.
The security implications of a downloaded Apollo application are similar to privileges allocated to any other natively installed software. That, in turn, is no different from security of Java WebStart, the closest Java technology to Apollo. Prior to installing an Apollo application, the Apollo runtime informs the user about the software's publisher, including the AIR file's digital signature, if there's any. Once a user agrees to install the software, the application has the full access capabilities allocated to the user.
Apollo also provides APIs calls that let the application determine if external network connectivity is available. An event listener mechanism notifies the application of connectivity changes occurring on the native platform. More than just an error-checking mechanism, network connectivity detection is supposed to enable applications with distinct online and off-line modes.
For such applications, lack of connectivity is not an error, but an indication to switch to a mode of operation that does not require connectivity. Apollo does not itself seem to provide an API to help define an off-line application mode—there is no magic cache or some other mechanism that would let the user believe that he is online when, in fact, he is not. Instead, developers are expected to think through the kinds of operations that can performed off-line, and craft the application's user interaction such that off-line mode is still useful to the user.
In the simplest case, off-line mode means read-only access to data, especially for applications that need to present exclusively online content. A more sophisticated design would use the local filesystem to cache additional content a user may wish to navigate, similar to how, for instance, Google's Web Accelerator pre-fetches content into the browser's cache.
Still more intriguing design challenges are posed by applications that let the user create new content offline, synchronizing newly created or edited objects back to a server when connectivity is again available. Such applications will likely borrow techniques from highly distributed databases and distributed caches to ensure an acceptable level of data consistency.
One such technique is the use of globally-unique object IDs. In the database community, Joe Celko wrote some years ago about the advantages of using globally unique IDs as database primary keys. Others have since summarized the pros and cons of using about 128 bits to define a database primary key value.
GUIDs, combined with optimistic locking and data versioning, may prove useful when implementing off-line mode with the ability to create and modify data: The client itself can assign a unique key to a newly created object, and that object can later be migrated to a database on a central server with a high degree of confidence that the object's primary key represents a unique database value. Flex's mx.utils.UIDUtil class supports the creation of such object IDs on the client.
Designing applications with distinct offline and online modes seems less of a client-side development challenge as a question of extending traditional enterprise architectures to gracefully deal with such hybrid clients. Assuming that every client operates with such diverse modes would incur an unfair overhead for more traditional browser clients (pushing 128-bit IDs around would waste a lot of bandwidth for traditional clients, for instance).
My sense at this point is that REST-style architectures that maintain little state on the server seem better suited to Apollo-like rich clients: Rich clients depend on rich client-side state, and managing both client-side and a server-side state, to paraphrase Ken Arnold, seems like double hell.
While Apollo itself doesn't prescribe a design for occasionally connected applications, it does simplify client-side state management: Apollo's persistent storage capability combined with Flex's sophisticated data binding API invite application architectures where the client, far from being just a UI layer, is an active participant in managing the application's data.
To be sure, Apollo is not the only emerging technology to bestow the client a greater role: As several Apollo critics point out, Firefox and Microsoft will soon offer similar choices.
That brings me to a concluding question: What server-side application architectures do you think are most suited to occasionally-connected applications? What do you see as the biggest issues arising from clients that take responsibility for managing some of an application's data, some of the time?
Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.
 | Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market.
Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit