Mobile multiplayer games blog: JavaFX + WebStart + Web Services +

In this post I will give an overview of the architecture that I’ve used to supply a connected thick (JavaFX) client application to a customer.

Here is the scenario: our company has an important customer who wishes to access and view some real-time data related to their business.

After some thought we’ve decided that the ideal platform for the client app is JavaFX (eye candy), the client deployment method is WebStart and we’ll provide the data to the client via a SOAP Web Service. Easier said than done it turns out 🙂

There are a few issues with this set-up.

The JavaFX client app can be written without major problems (see my previous posts about my beef with JavaFX tools) but I’ve found it best to create separate Java module to handle the WS communication. This is also useful since Maven doesn’t seem to be able to build mixed source trees. Therefor the client app is composed of two separate JARs:
– Java library to handle WS client code generation and some utilities that are easier written in Java
– JavaFX GUI client that depends on the Java library

Simple enough Web Service deployed on GlassFish v2.1 JavaEE 5. Nothing special to note here.

This was one of the trickiest parts. Since we have a number of servers (dev, test, stage, production, etc.) and we want a client which is downloaded from a specific server to connect to the WebService running on that same server. This we achieved by using a servlet to dynamically generate the JNLP file for the WebStart deployment. The servlet plugs the correct values into the JNLP for two things:
– where the client jars are located (i.e. codebase)
– a run-time property for the client specifying the WS location
The client (once launched) uses the WS location property to connect to the correct web service.
The servlet gets this information from system properties which can be easily set using the GlassFish web admin console. This means that we compile the code once and deploy it to any GlassFish server and all works well as long as we don’t forget to add the two properties to the server.

JavaFX as Rich Internet Application Platform

JavaFX as Rich Internet Application Platform

JavaOne wrapped up on Friday. We hosted individuals from across the globe, and from every industry: consumer electronics and gaming, to enterprise IT, space exploration, factory automation, the automotive industry, academia – like the network itself, Java delivers something for nearly everyone, everywhere.

This year’s biggest announcements centered around Java’s role in the future of rich internet applications (or RIA’s). What’s a rich internet application? It depends on your perspective – from mine, it’s any network connected application that persists in front of a user, typically outside a browser, that can operate when disconnected from the network.

On the one hand, I’d claim Java’s always been a RIA platform – before the world really wanted one. Early Java applets delivered interactivity, but at the expense of development complexity and, in the early days, performance – when a browser, and more recently Javascript, would suffice.

But browser based applications are hitting complexity and performance limits, and content owners are striving for higher levels of engagement (via high definition video, or advanced interactivity). Developers are demanding something new – the browser’s a wonderfully accessible programming model, but it’s a weak deployment model for rich/disconnected applications.

An unspoken driver of RIA is also business model evolution – many companies behind rich applications are seeking independence from browsers and search engines, whose default settings and corporate parents present a competitive threat. There’s a growing appetite for locally installed applications that build rich, direct and permanent engagement with consumers. No one wants to pay a toll to meet their own customers.

With that in mind, as we looked to reinvent the Java platform, we heard a consistent set of requirements. And not just from coders, but from sports francishes seeking to directly engage their fans, media companies wanting to bypass browser defaults, to artists and businesses and device manufacturers – everyone’s looking to uniquely engage consumers via the network. These audiences have nearly identitical requirements for a RIA platform – they want technology that:

  • Reaches every internet consumer – on desktops, mobile, and new devices, too.
  • Delivers high performance – and the ability to engage creative professsionals in the design process.
  • Leverages existing skills and enterprise infrastructure.
  • Is totally free, and open source.
  • Provides content owners with control and ownership of their own data.

At JavaOne last week, we addressed every one of those issues – here’s how:

First, RIA developers want to reach every consumer on earth, and on every device.

Why? Because the market is in front of consumers – no matter what screen they may be using. Desktop, mobile phone, personal navigation, digital book – you name it. The market’s in front of all the screens in your life, not just a PC.

That said, on PC’s alone, Java’s popularity has grown in the last few years, as measured by runtime downloads – we routinely download 40 to 50 million new Java runtimes a month, and update more than a billion every year. The adoption of the Java platform exceeds the adoption of Microsoft’s Windows itself – Sun’s Java runtime environment (JRE) is preloaded on nearly every Windows machine (from HP, Dell, Lenovo, etc.), but also runs on Apple’s Macintosh, Ubuntu, Fedora, SuSe, Solaris and OpenSolaris desktops. In addition, a JRE is present on billions – yes, billions – of wireless and mobile devices, from automobile dashboards and navigation devices, to Amazon’s Kindle (did you know Amazon’s Kindle is a Java platform?).

Which is to say, the Java platform reaches more people than any other software technology the world has ever seen.

Second, RIA developers want performance, functionality AND simplicity.

Why? Because content owners and application developers want to engage consumers – and want to engage artists and creative professionals in the workflow.

Java’s history with simplicity isn’t perfect – which is why our teams have rewritten the applet model, and focused so intently on making the new consumer Java runtime environment (download a beta version here) exceptionally fast to load within a web page, exceptionally performant for complex interactivity, and trivially accessible to consumers. We’ve also simplified Java with a scripting language, JavaFX script, that enables creative professionals to engage with coders to create immersive experiences, while embracing the creative tool chain (from interaction design to pixel manipulation) used by the worlds designers and digital artists.

And I’m really pleased we’ve solved the desktop installation problem, by making JavaFX applets separable from a web page with a simple drag and drop (click the image above to watch this demonstrated). Developers can now bypass the browser to trivially install apps on desktops – once the applet’s dropped on the desktop, content owners have a direct relationship with their consumers.

You might have also seen that we’re adding full high quality audio and video codecs to Java on every platform on which it runs – resolving another gap for RIA developers, support for time-based media (click here for a demo of high performance video).

Third, enterprises want to reuse their existing Java skills and assets in moving to RIA.

Nearly every enterprise employs programmers with Java skills – it’s still the number one internet language taught across the world, and found pervasively in global business infrastructure. As businesses move to engage their customers via RIA platforms, reusing existing skills, and connecting RIA’s to existing systems, gives the Java community a unique ability to build from what exists – rather than attempt to replace it.

This familiarity also allows businesses and developer teams to focus on engaging with consumers – rather than irritating IT with new infrastructure requirements (JavaFX developers simply link to existing enterprise infrastructure, vs. requiring new systems for RIA apps).

Fourth, RIA developers want free and open platforms.

Why free? Because developers don’t want to encumber their applications with royalty bearing dependencies, or use technologies that predefine where consumers might appear. You don’t build developer communities around closed source, you build user communities – and this is an instance where developer selection and adoption will define the broadest RIA marketplace. JavaFX will, like all of Sun’s software platforms, be made freely available as open source, and it’ll be released via the GPL (v2) license.

And lest you think free and open software is the province of those with goatees and tattoos… we’re seeing a rising tide of developing nations mandating free and open software in government and academic procurement. Why? To protect choice, and build indigenous opportunity – there’s no reason to build dependencies upon proprietary software if you can avoid it.

Lastly, lets face it, the real value in Web 2.0 is the data – not the app. And that data is YOURS.

If you’ve been watching the social media space as carefully as we have, you understand the value of instrumentation and intentionality in building a business on the web. Knowing what users are doing with your product, whether it’s a fantasy cricket league or a consumer banking application, enables more innovative business models, the delivery of higher value services, placement of more valuable ads – data allows for better decisions, and better value creation (and bluntly put, higher CPA).

But most rich internet applications are built, then deployed – into a fog. Developers who leave the confines of the browser either lose access to information about what their users are doing, or have to rely upon a technology provider that’s inserting itself into their data stream. And some of those technology providers compete with content developers.

With a project code named Project Insight, we’ll be instrumenting the Java platform to enable developers to harvest the data stream generated by their RIA content. JavaFX developers can focus on their business models – rather than enhancing someone else’s.


With all that said, what’s the success of JavaFX worth to Sun?

By definition, it’s worth more to Sun than the adoption of someone else’s platform (known as “positive option value”) – and the proprietary infrastructure used to serve it (don’t forget, RIA’s have rich internet back-ends (RIBs?). And in the RIA world, all the options are going to be priced at free, anyways – this isn’t a contest to be won on price.

From where I sit, the platform likely to win will be the one that sets developers free – to pursue markets, opportunities and customer experiences as they define them, not as vendors define them. Now, setting developers free – that’s where we can excel. It’s in the DNA of everything we do.

For developers, learn more at And be sure to check out NetBeans – like Java itself, it’s starting to rock the free world…

See also