Archive

wAsync aims to make realtime apps possible in Android’s mobile device and Java/JVM clients communicating with framework like Node.js and Atmosphere, blurring the differences between the different transport mechanisms. Transports supported are WebSockets, Server Side Events, Long-Polling and Http Streaming. You can download all samples from wAsync’s main page.

This code will be invoked before the message is sent to Node.js and will covert the POJO to JSON. Next we define a decoder that will handle Node.js’s JSON response. We only decode messages, we aren’t interested by other events wAsync propagates:

That’s all. If you want to chat between Android and a browser, you can install this HTML file, which will use atmosphere.js, the Atmosphere Framework’s client side to communicate with Node.js. You can use the Javascript WebSocket API directly as well, but with atmosphere.js, you get transports fallback support for free.

Now let’s write the same client, but this time using the Atmosphere Framework instead of Node.js. wAsync supports natively the Atmosphere protocol with fallback transports like long-polling, so we can tell wAsync to use long-polling in case the server doesn’t support websockets. For the server, instead of Node.js, we use the NettoSphere server.

All of that work was done under several companies umbrella: Sun Microsystems, Ning, Sonatype and more recently Reverb. In all cases, I was allowed to work on those frameworks because they were used internally. For example, I’ve spent the last 18 months working at Reverb, significantly improving the Atmosphere Framework and even deploying it on Wall Street Journal, one of the biggest/live deployment I’ve ever made so far supporting WebSockets and Internet Explorer 6/7/8/9 at the same time. Phew!!!

So, with the current Atmosphere success, I’ve had a hard decision to take: work at Reverb and let the Atmosphere’s community grow and “leave by itself”, or resign from Reverb and try to build a company to support Atmosphere. Last January was difficult for me as I was constantly under fire by having to work on Atmosphere and at the same time help scaling the Reverb’s platform. Not a nice situation!

So, I’ve decided to tale a leave on absent from Reverb and try to build my own company around the Atmosphere Framework, called Async-IO.org. The website is live and the traffic is already passing 500 unique hit per day, so this is positive…but, It’s a major challenge for the following reasons:

I cannot stay unemployed for several months. Hence I allocate myself 5 months to succeed with my crazy decision. I know it’s a very small amount of time, but that’s all I can allocate.

I’m based in Canada (in Québec), not in California or in a city like London or Berlin where I can have funds from Venture Capitals Companies. Montréal is unfortunately stuck in the early 200o where IBM and Microsoft rules the city, so no luck on that side as well!

I want to try to do everything all by myself, from designing the website (thanks Github) and learn from existing open source projects that succeeded. I’m event sketching the official logo this week!

I don’t want to spend large amount of money on infrastructure. Instead, I would like to reward people that have been working with me in Atmosphere as soon as I can. But I need a solid foundation before I can do that.

I don’t have a large corporation financing my work. Since Atmosphere compete with framework like Socket.IO/Node.js, Vert.x and Play 2 (they are all powered by a big company), it’s a real challenge!

Atmosphere work with all browsers, mobile browsers and Java WebServers, and from version released sometimes 5 years ago. The testing matrix here is really complex and right now I strongly need to rely on the community to help, and in return I’ve adopted a short release cycle to make every body happy. That way too much time consuming so I need to improve that situation.

Continue being active with the community like I have been for the last 4 years!

Now, after reading this you can call me crazy and I would fully understand! Interested to help? Pretty simple:

Rate this:

Today, after almost 4 years of in and out works(*), I’m really happy to announce the immediate availability of the Atmosphere Framework version 1.0, the only Asynchronous JavaScript/Java Portable framework running on the JVM!

The Atmosphere Framework ships with multiple components, and can be used with JRuby, Scala, Groovy and Java:

Atmosphere Javascript: The client side of Atmosphere, supporting by all browsers. Supports Websockets and HTML 5 Server Sides Events when available, transparently fallback to Http Streaming/Long Polling or JSONP when not supported. Available for JQuery and Ext JS. Supports sharing/multiplexing a single connection amongst browser’s windows/tabs.

Atmosphere Runtime: The server side of Atmosphere, supporting all major WebServers. Supports WebSockets and HTML 5 Server Sides Events when available, fallback to WebServer’s Native Comet Implementation or the ugly Servlet 3 Async API at last. Also works transparently on top of the Netty and Grizzly Framework (no Servlet Container required). It also transparently brings WebSockets support to any exiting Servlet, without any changes required!

Atmosphere Jersey: A native extension to the Jersey Framework (REST). Transparently brings WebSockets and HTML5 Server Side Events to your REST architecture, using the JAX RS API. Also support the strange JAX RS 2 Async API.

Atmosphere works with every Java EE Application Serverand can automatically negotiates the best transport between the client and server. Atmosphere’s support portable WebSockets with Jetty, GlassFish, Grizzly 2, Tomcat and Netty. Write once, deploy anywhere!

In short, Atmosphere works everywhere and with every framework. Websockets, Server Sides Events or any HTTP techniques are supported transparently. Write one javascript, one server file and Atmosphere will make it work every where, without any changes! As simple as (Client)

You can see the Wordnik’s Atmosphere implementation lives, servicing approximatively between 40 to 50 millions of requests per day on WSJ.com (depending on enabled pages), or with any website using our Related Content PlugIn.

Atmosphere gets more than 25 000 downloads per month and widely used in production. Follow us on Github or Twitter. The more we are the better it will be!

(*) I would like to gigantically thanks Tony Tam and Erin McKean (and the team @Wordnik) for allowing me to work a significant amount of my time on Atmosphere every day, since last year!!.

Rate this:

The Socket.IO framework is defined as “Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms.”. If you are familiar with the Atmosphere Framework, this sound like a perfect match: The Atmosphere Framework aims to make realtime apps possible in every JVM based-Server, every browser and mobile device blurring the differences between the different transport mechanisms.

The major difference is with Socket.IO you are “stuck with node.js”, where with Atmosphere you can pick up the JVM based server of your choice, and get the guarantee that your application will works AS-IT-IS with any of those servers. Socket.IO + node.js forever? Not anymore! This blog introduces Socket.IO for the JVM, or how to write Socket.IO application running on the JVM, using the Atmosphere Framework!

If you are coming from the Socket.IO community, you may want to take a look at this page to grab more information about Atmosphere. For this blog, I will use the usual chat example I always use to demonstrate how simple Atmosphere is. And more important, all existing Atmosphere Application will works with Socket.IO WITHOUT ANY CHANGE! That means you can easily throw away your atmosphere.js code and instead use the Socket.IO library instead, without having to change anything on the server side.

Now, let’s write a really simple chat, let’s use an AtmosphereHandler, which is defined as:

Let’s make it clear, I could have used a JSON parser but for the sake of this blog I just want to make it really really simple. The idea here is all requests mapping the ‘chat’ pattern will be delegated to this AtmosphereHandler. Every time a broadcast operation happens (when the Socket.IO POST data), that data will be delivered to the AtmosphereHandler#onStateChange, which will write the data back to the Socket.IO client. If there is N connected client, the onStateChange will be asynchronously called N times, with the end result of sending N response back to Socket.IO. Note here that there is no special code for handling transport, e.g everything is all handled by Atmosphere. That means the above AtmosphereHandler TRANSPARENTLY supports WebSockets, HTML5 Server Side Events (SSE), HTTP long-polling, HTTP Streaming or the JSONP technique. The best transport will be picked by Atmosphere based on what the client and server supports. Of course if you like to write bare metal Socket.IO application, take a look at this class, which demonstrate the low level protocol support in Atmosphere.

Now we have the choice of WebServer, but for this blog I will use NettoSphere(Atmosphere running on top of the Netty Framework). You install SocketIOChatAtmosphereHandler by simply doing:

The key part is the socket.on(‘chat message’, message) which will be invoked every time a new chat message is published. That’s IT! Pretty simple, it is? Now, depending on the browser you are using, Websockets or Long-polling will be used, TRANSPARENTLY! You can browse the complete code here.

Rate this:

Writing Portable WebSockets’ applications using the Java Language can be challenging. Since there is no API standardization yet, several “native” API exists (Play!, Vert.x, Kaazing), you can easily get locked with their API, changes, single vendor etc. The same “problem” happens with well known WebServer: Jetty, Tomcat or GlassFish all have native API making your application not portable. Worse, the same problem happens on the client side: Grizzly, Netty, JWebSocket all have their own API. Not better on the browser side as well: Firefox went with its own API instead of the recommended one (MozWebSocket, fixed in Firefox 12).

So, already giving up? The solution is simple: use the AHC library(client) and the Atmosphere Framework (browser and server). The AHC library adds a thin layer on top of existing WebSockets’ client libraries, using the Netty Framework as default. The Atmosphere Framework allow portable WebSockets across Java based WebServers.

Part I — Writing the Server Component

The Atmosphere Framework works on top of existing native WebSocket implementation and currently supports Jetty, Tomcat, GlassFish and the Netty Framework (the NettoSphere). The Atmosphere Framework allows writing pure WebSockets applications as well as applications supporting the HTML 5 Server Side Events, Long-Polling or HTTP Streaming. Today this blog will only focus on writing WebSockets-only applications. So, no fallback on another transport in case WebSockets aren’t supported, but it is important to note that Atmosphere transparently support that transport’s fallback.

The portable API and easiest way to write pure WebSockets with Atmosphere is called WebSocketHandler, and can be defined as:

All this code is doing is to broadcast the received messages to all connected client using the MetaBroadcaster utility classes. Since, by default, all connected WebSockets are registered at ‘/*’, no extra code is required. Of course we could have wrote something more complicated (like writing our own WebSocket Protocol), but that’s not the goal of this blog.

Part II — Writing the Browser Component

For the Browser component, let’s use the Atmosphere JQuery Plugin, which supports all browsers and could fallback to another transport in case WebSocket aren’t supported. In the easiest form, all we need to do to receive WebSockets messages is:

Of course a real application will not use the alert call. An interesting callback here is the onTransportFailure, which is called in case the browser or the server isn’t supporting WebSockets. For sending WebSocket’s message:

subSocket.push("Hello World");

Part III — Writing a Java Client

Now let’s write a portable Java client using the AHC library. As simple as

By default the AHC library use the Netty Framework for WebSockets support, but other framework (like the Grizzly Framework) can easily be replaced.

For a more complex, portable WebSockets application, take a look at the Atmosphere Chat sample, which transparently support WebSocket, Server Sides Events, Long-Polling and Streaming. If you are planning to use WebSockets and Java, I strongly recommend you look at Atmosphere instead of using private native API and get stuck on a server/framework forever. For more information, ping me on Twitter or follow the Atmosphere Framework!

Rate this:

The current Safari version (~5.1.5 … on OS X and iOS) implements an old version of the WebSockets specifications. This old version can cause major issues with Java WebServer in production. Here is some recommendations to workaround Safari. Important note: my observation are based on large deployments using the Atmosphere Framework.

My recommendation is if you need to put a WebSocket application in production, use Jetty 7.6.3 or 8.1.3. GlassFish is also a good server but much more heavyweight to use if you are planning to write pure WebSocket applications. NettoSphere is fairly new and until Atmosphere 1.0.0 is released, I’m not yet recommending it (yet!). Note that the Netty Framework’s WebSocket implementation can be considered a STABLE as well, but to run Atmosphere on top of it you need NettoSphere.

Now if you can’t any of the stable WebServer, you can still use WebSockets. All you need to do is to write a Servlet’s Filter that will detect the WebSocket version and force Safari to downgrade to another “transport” or communication channel. Server Sides Events, long-polling, http streaming, polling or JSONP can then be used to reconnect. You just need to implement the reconnect inside your websocket#onClose function. With Atmosphere JQuery PlugIn, the reconnect is done transparently, e./g no special code needed. The Atmosphere Filter looks like:

So if you aren’t using the Atmosphere Framework, make sure you have some sort of Filter than will block Safari from creating problem.

If you are planning to use WebSocket and Java, I strongly recommend you look at Atmosphere instead of using private native API and get stuck on a server forever. For more information, ping me on Twitter!