wiki.webvm.net/pp2007

Aplix's AJAX platform

Paddy Byers paddy@aplixcorp.com and Kai Hendry hendry@aplixcorp.com

Aplix is committed to providing an excellent Web user experience on mobile devices. There is a huge potential in the extension of Web technologies and services to mobile. Codename JSX is a new product initiative by Aplix to improve the mobile Web by leveraging the Jblend platform.

Company background

The Aplix Corporation is recognised for its JBlend platform, the market leading Java platform for mobile phones and other consumer electronic devices. JBlend implements the most advanced Java features, and had been shipped on over 359 million units as of June 2007.

Introducing (codename) JSX

The Java platform can complement the Web. Via a javascript library (JSX) Web developers can detect and use mobile device functionality that Jblend has access to, which the browser typically does not.

JSX provides a bridge between the web application environment and the Java runtime that is present on nearly every handset today. The real power of this comes from the fact that the Java library can access platform features, through a wide range of standardised Java platform APIs defined as profiles (commonly known as JSRs). There are profiles that allow a java library to access:

JSX expects in fact that a series of JavaScript APIs will be developed, and each of them only needs to be deployed to the device once, no matter how many different web sites make use of them. So JSX is designed so that it supports the deployment of JS APIs (which are a combination of a Java library, and a JS wrapper that instances the library), and the management and coexistence of those APIs.

Problems we want to address at this workshop

Referencing many JS modules this way can be problematic when there are complex apps that could give rise to multiple inclusion, conflicts in the global namespace, load-order dependencies between modules, and contention for certain events.

The community is beginning to address this problem by defining frameworks to allow modules to be developed independently and then combined within an application without conflict. JSX could include or integrate with such a framework, which additionally takes care of the installation of Javascript libraries, and persistent storage of permissions associated with those libraries.

How JSX works

JSX optimally hooks into the browser in the same way that a traditional browser plugin works. However if the plugin can not be deployed for one reason or another, a locally running Jblend Web service enabled by the user can provide a fallback.

JSX structure

Benefits

Leveraging Java Standards

The biggest single benefit is that these new APIs (say a location API, or a PIM API) do not need to be embedded in the phone and, more important, do not need to be defined by a single committee as is the case with JSRs in Java. Now, any interested party can define their own APIs to suit their own purposes, so long as the underlying functionality needed is available via a Java profile. APIs can be created and deployed by publishers, carriers or manufacturers as needed, and superseded by standard APIs once they become available.

For content developers

Most important, they get the ability to make web apps integrate with the mobile platform, but avoid the user-install and management problems associated with Java apps. Wherever a given Java profile is available, the corresponding features become available to web applications.

It means that the developer can avoid using browser-specific APIs, which fragment the application. Opera are deploying some Opera-specific APIs to provide access to the platform, but apps developed to these will not work in any other browser.

Finally, the JSX mechanism has no dependency on HTML or any other specific details of the markup language. Any environment that uses JavaScript or a similar language can use JSX. For example, SVG or SMIL players, or widget engines.

For browser vendors

The benefit to the browser manufacturer is that web applications can become fully fledged applications alongside native apps. This vastly increases the relevance of the browser environment for carriers and developers.

By deploying JSX, the browser manufacturer avoids the need to define proprietary APIs.

The browser manufacturer can also benefit from a simplified porting process. For each of the platform interfaces that exists (ie PIM, location, etc) there would normally need to be a porting and integration effort for each handset model that the browser is ported to. This can be costly and timeconsuming when there are countless many interfaces and so many device models. With JSX, this effort can be largely avoided because all of the hard work has already been done by Aplix.

For carriers

The benefits to the carrier derive from the greater value that can be delivered to the user via web applications. Anything that makes the network more valuable to the user, and promotes connectivity and communication, brings value to the carrier.

Carriers are rightly concerned about security, and opening the platform to web apps is clearly something that raises potential security hazards. It is essential to have an effect and robust security framework in place, so that only trusted web sites can gain access to sensitive platform information or services. JSX leverages the significant investment into security infrastructure in the Java VM, and will provide a security model (that is, permissions and trust model) that is familiar to carriers.

Carriers are also wary of the potential for fragmentation arising from the multiple Rich Internet Application (RIA) technologies that are coming about. JSX provides a means of unifying at least parts of the application and service architecture around a platform standard that is independent of Microsoft, Adobe and Nokia.

Finally, JSX with its JS module framework, should be able to kickstart a mobile web API ecosystem, which ultimately will reduce the costs of creating and deploying web-based mobile services, and benefit users and carriers alike.