How Rich Internet and Smartphone Apps are Driving a Return to Client-Server Architecture

Solace recently announced a new network card that can boost the capacity of each Solace’s appliance to 80Gbps of bandwidth. As more companies embrace real-time computing and “big data” fueled by information flowing between mobile devices, sensors and social networks, this kind of capacity will enable some seriously cool innovation. But I believe there’s even more to it than that – I think this kind of massive capacity will influence the very nature of enterprise applications.

Think about the fact that smartphones didn’t exist just ten years ago. Think about the server-side ramifications of all that recent change, and where we are today. Having a hardware-based HTTP termination point, WebSocket wireline support, higher connection density and using messaging as a communication paradigm even over HTTP is allowing front end applications to become much more scalable, faster, and most importantly easier and more intuitive.

Lets examine this from an application developer’s perspective to see if we can extrapolate what’s next.

Remembering Darwin – the front-end evolution with the changing ecosystem

The evolution of application front ends and back ends (i.e. client side and server side) has been a game of leapfrog, with one’s evolution enabling and driver the other. This is not surprising as the division of responsibility in a typical IT organization has had different people developing front end and back end systems. It’s also interesting to note that the footprint and sophistication of clients has cycled between thick and thin several times.

• Terminal Age:  Early computers (servers) had thin clients. During the days of the Mainframe, the front end was a green screen terminal with virtually no processing power itself.
• Desktop Age:  Windows-based operating systems (Mac and PC) enabled graphical user interfaces which along with the mouse revolutionized the user experience. Behind the scenes relational databases came along that could store and provide data in a simpler and more powerful manner than file systems. With a more powerful PC, the client evolved into a much more functionally rich, thick client. This was the era of Oracle/Power builder or VB/MSSQL or SAP.
• Web Age: The Internet drove the need to provide information and interfaces to unknown users in a secure manner without making them install thick clients. HTTP and HTML became popular because as pure text protocols they could be transparent from a security standpoint, and web browsers that understood HTTP and could turn HTML tags into graphical displays removed the need to download and install anything on the client side. The thin nature of this new kind of client, which some derisively called the “dumb browser” led to the development of sophisticated application server technologies such as J2EE, Asp .Net, and LAMP. When these backend technologies became powerful enough to compensate for the browser’s shortcomings, companies began using browsers as the basis of internal applications. Some upgraded their backend systems, but others used integration techniques like EAI, SOA and ESB to let people interact with server-side and mainframe applications via their browsers – several generations of technology linked with middleware.
• Mobile Age:  The browser didn’t remain dumb for long. Fueled by Moore’s law, Desktops evolved into laptops more powerful than servers from a few years ago, memory leaped from megabytes to gigabytes and processing went from megahertz to gigahertz. That power enabled Applets and plugin technologies like ActiveX and Flash, and then AJAX enabled a new level of application richness without any client-side software. Now HTML5 is making Rich Internet applications richer every day. Since they download the GUI components upon initialization, subsequent interactions are much more responsive and don’t require full page refreshes. Unlike web apps, RIAs don’t rely on servers to generate an HTML page to serve up. They can receive raw data and repaint select sections of the screen. We’ve cycled back to a smarter, thicker client – one so sophisticated that you can now buy laptops powered by them!

So what does back-end bandwidth have to do with front-end applications?

The 6x10Gbps Ethernet card from Solace is the next generation termination point for the modern web and mobile client. It terminates HTTP in Hardware, supports WebSocket wireline for HTML5, supports binary payloads and brings messaging in hardware as a paradigm to web and smartphone applications.

It supports classic request reply, and the very interesting push messaging a.k.a pub sub, where the app can get updated content by listening to relevant “topics”, which the server side can publish. A modern stock ticker or flight information display system, or sports scorecard or betting odds display, or an object updating on a map – all these are “push” messaging by nature – which we have implemented as “pull or poll”. But with Web messaging, they can now be implemented the way they should be – publish /subsribe, and only data and not html flowing from server to client (browser and app alike).

And for most interactions, the good old request reply is also supported, via messaging in hardware. I.e. you can click a button to buy or sell stocks, or place a bet or buy a ticket or pay a bill – isn’t that just a message going from you client (browser or app) to the serverside (Solace hardware), which then goes to the business logic systems?

No OS, no external hardware, no interrupts, 99.999 reliability and 1 appliance easily taking 20 web servers out, simplifying the app server greatly, by making it to what it should do – application business logic, and not what it ended up doing – transport handling. Let’s move the transport into hardware. We run switches or Wifi hardware even in homes – so that we don’t see BSODs or Out of Memory Errors in them. Transport can be and should further be moved to hardware.

Messaging – Simplifying the Web and Mobile Platforms

Modern web apps are leveraging this new architecture rapidly. And M2M integration is naturally following as well. A hardware endpoint for all channels – front ends or sensors –  changes the game completely. Much larger volumes or data can be now handled. Big Data in Motion is as critical as Big Data Analytics – and appliances make that possible. Most importantly, much richer and more responsive and functional apps are being created – by dropping the baggage of handling HTTP and HTML in app servers, moving this to hardware.

In Part II of this article, I’ll go through how a web app can be migrated to leverage this hardware HTTP server architecture in detail, explaining the diagram shown here.