Friday, May 30, 2014

Long Polling - Node.js, Netty, Worklight, MQTT...putting Long polling issue in perspective

Topic: Node.js, Netty, Worklight, MQTT...putting Long polling issue in perspective
 
Folks -- I have been engaged in various discussion around Long Polling issues, and I figure I share and seek you feedback on this issue. 

So this is by no means an exhaustive list --- but wanted to provide a  POV on  various options available to us in achieving the application design you seek, we ought to also focus ion the long term cost of maintenance of  our choices, especially in Mobile space as a lot on client side or the "eco system" is dynamic and enterprise needs to embark on a platform that can future proof them or provide a roadmap that allows for a flexible adoption of various application development frameworks.

1. Just Node.js option:
Value:
Node is a JavaScript web server runtime. Because it uses JavaScript, front-end developers can work in the same language as back-end developers. This concept is referred to as JavaScript Everywhere. In practice, this concept unifies development efforts by reducing the number of different concepts that developers must understand. Furthermore, the most used data exchange format, JSON, can be natively parsed by both ends. This is another way processing overhead can be reduced through simplification of serialization. In addition to the benefit of using a script language, Node's lightweight runtime enables rapid development and deployment.Node.js is a server-side development framework that makes use of event-driven non-blocking I/O.
Merits:
1. key factors are performance, timing, and focusing on a real problem that wasn't easily solved with other server-side dynamic languages.
2. using JavaScript, the language of the web.
3. Bridge the gap between the front-end and server-side architectures.
4. Supporting code reuse at every level - client, server and even database
5. Node.js is getting traction is that developers are used to the asynchronous programming style with JavaScript
6. The ever-growing pool of packages, most of which are conveniently hosted on github. Sometimes you can report an issue and find it fixed within hours! It's nice to have everything under one roof, with standardized issue reporting and easy forking.
7. Seems rather suitable for agile development and rapid product iteration.
Demerits:
a. Infancy - still need maturity from an "In-enterprise adoption" -
b. promise or node but not there yet - Node.js not just for package management but for scripting, interfaces, and most everything else as well.
c. Open Source - Supportability
d. Package management -- governance, management and security.
e. Risk - The ever-growing pool of packages, most of which are conveniently hosted on github -- this can be a interesting challenge to mange with risk from NPM/package, and managing not only security but  the intellectual property issues that surround it.

2. Use of WL as a Mobile Middleware using Node.js and a service.
Value:
I think since we are in enterprise space and will eventually have to address the enterprise integration challenges for mobile applications, I think it is vital we center this as a part of our discussion. Some Arguments I have used are as follows:
1.WL has a  agnostic message to our clients that you can do "native" , hybrid, or mobile web because the real value is in the platform, administration, up-keep, security, adapters, and integration layer we provide better than anyone else. - Integration
2.Mobile Middleware provides a layer of indirection, which allows for the back end services to be shifted without affecting the end point. - Flexibility
3.Ability to surgically enable and disable Application specific to a platform, administratively provide platform specific messages - Control.
4.Mobile Middleware also arms the enterprise to adapt and fit into to current Enterprise Security platform ( authentication, authorization and security policy enforcement etc) - Security
5.Mobile Middleware also provides an avenue to exploit existing services ( SOA Model) and since these services were design for Web Application, Mobile middleware allows for filtering and altering the content, prior to sending the response back to end use. - Flexibility, control and reuse and Optimization of existing enterprise services.
6.Mobile Specific Services - Unified push notification, SMS and devices specific notifications etc, provide an avenue to address these via platform.
There by use of node.js as a services layer will  minimize risk, around the application design, maintenance and overall delivery.
Merits:
1. IBM - We  have a "preview node adapter" for a while now.
2. With WL 6.2 and the new security feature that we introduce for REST services it should be easy to put Node.js directly in front of the mobile app, so your use case could be solved (from a WL perspective)
3.  Mobile middleware and Node.js are independent tiers -- this decoupling promotes reuse, and isolation and separation of concern.
4. Preserving the Management and governance -- IBM WL can serve as a  Management entity that integrated well with the enterprise systems - security/EIS etc, and node can provide a specific service.
4. extended value with use of - CEM , analytics suite and use of know design patterns  that can be easily applied.
Demerits:
1. Operational experience perspective -

2. Two tiers to manage -- giving up the convenience of Node.js and NPM package manager -- varied set of dev/build tools

3. Use of MQTT and Message sight (IBM product): - Thanks Bernard/Bryan
Value:
MQTT technology solves long polling.  MQTT is bi-directional rather than request/response.  So rather than having long poll, the either end - including the server can send data when ever they choose.
It's a pub/sub model.  So a client will publish to a topic - and which ever clients are subscribed to that topic will get the information.  It's designed to be light on battery life, bandwidth and keeps the round trips to a minimum - to give really fast interactions.  We have clients for lots of different devices and languages.  We have a JavaScript client.  You can find the source for these on Paho MQTT open source community (http://www.eclipse.org/paho/) - and find conveniently compiled and packaged clients in the IBM client pack (https://www.ibmdw.net/messaging/messagesight/).
Pub/sub allows for simple fan out of data from a single point to lots of subscribers.
Merits:
1. Use of MQTT - designed to provide low latency, assured messaging over constrained networks.
2. Provides 2 way communication channels
3. MQTTs "keep alive" - which is a  way for client to detect ( periodically and timely manner) when server ( IBM MS) connection is lost without long TCP like time-outs.
4. Purge of log running connection with no data.
5, Known advantages -- constrained networks, power usage,  connection efficiencies, device battery life, low cost of keep alives, etc.
 Demerits:
1.  Additional Design Considerations -- Applications connecting to URLs --- http opens a URL connection and exchanges certs, MQTT -- needs to establish a raw connection, perform cert exchange and then the other information -- so additional design considerations.

4. Netty vs Node.js:
a. Code Compactness:
- minimal server in node.js can be written only in few lines of code, whereas netty requires ~5 files with boilerplate code.
- Simple netty handler is about 20-30 lines of code, whereas in node.js the same functionality might be expressed with only a couple of lines.
b. Library vs Modular framework -
- Netty is an async communication library. Node.js is lot more than that: it's an async modular framework.
- Third-party Java libraries that might be used together with netty  
c. Intent - Two different design paradigms:
-  node.js was to build solid infrastructure for web servers.
-  Netty  was designed as a asynchronous network application framework
- Netty has been around for a while (2004) and has all kind of 'traditional' enterprise qualities - http support, can run in a servlet container, support for proto buff --- addressing traditional manageability, support and scalability concerns
- Node in relatively new and definitely has a larger developer mind share and ecosystem for innovation.
Note - all the merits discussed in Node.js discussion make Node a more attractive option when it comes to Mobile applications.

No comments:

Post a Comment