J2EE v/s NodeJS for real time applications

Hi,

Just want to trigger your thought process on the above topic.

NodeJS & JavaScript is emerging as strong contender and alternative to J2EE for and real time as well as enterprise applications to some extent in view of the following

  1. JAVA , J2EE is 20 year old technology and bulky and needs massive JVM, J2EE server, build systems , IDEs etc. NodeJS is small (15 MB) light weight easy to get started with especially for smaller and real time application.
  2. JAVA’s threading and synchronization issues are avoided with NodeJS’s single threading approach.
  3. Though JavaScript gives rise to other issues like its asynchronous execution, call back hell and depth of nesting etc, but new extensions such as async are available now to bring synchronicity when ever required. Each language has its own strengths and weeknesses.
  4. With ES6 extensions JavaScript is becoming a strong yet simple language. You can achieve a lot with a few lines of JavaScript code (some of the NPM’s are 10 , 20 lines of code). Where as there is a famous joke about JAVA , that if you want an API for banana in JAVA , you get gorilla holding the banana and the entire jungle behind the gorilla.
  5. Being Interpreted language, its easy to run and debug the JavaScript code. Just refresh the browser to run the code in browser, or on server nodemon will automatically restart on a code change. JAVA will involve re build and rerun to debug/ correct a small error.
  6. NodeJS has few 100 thousand NPMs , you can pick and choose the ones that you want for your application. Some very useful libraries such as Socket.IO, file system, web RTC, websockets etc.are available.Most libraries have both synchronous and asynchronous versions. NodeJS is even coming out with scientific library for use in scientific applications. Its not an immature community!
  7. JavaScrpt’s is defacto standard for client side scripting for dynamic pages since its beginning, in fact it was designed for it initially as DOM manipulation language in the browsers. With advent of Canvas/ SVG/ WebGL standards and client frameworks like Angular/React/Vue it has become even more powerful for client side programming.
  8. NodeJS gives a seamless single programming environment on client as well as server side for developing full stack applications.
  9. What’s the support for JAVA in future? It has changed hands from SUN to ORACLE to who next? IBM? We don’t know. Where as NodeJS is built on Google’s JS V8 run time and NPMs are open source.

In summary, in my opinion, NodeJS and JS are emerging as a serious contender and alternative to J2EE for certain type of applications such as real time and small footprint applications requiring low system resources and fast response. J2EE is and overkill for such applications. The advantages of NodeJS over J2EE far outweigh the disadvantages for such real time and light weight applications in my opinion. Of course there will be resistance from legacy users of J2EE who will try to laugh if off and brush aside and snub the NodeJS community, due to fear of unknown and in order to defend JAVA, but in my opinion both technology will coexist but newer ones will prefer NodeJS as far as possible as its advantages far out weigh its disadvantages. Your reaction is welcome.

best regards

2 Likes

Good article. Many JAVA programmers are in panic these days. In India, computer science graduates are openly advised to stay away from JAVA. Main focus in job market is Javascript, C#, Kotlin and Python. Looks like Oracle has decided to kill JAVA. Do you think JAVA is dead?.

What’s your take on this?.

We must thank this gorilla for creating millions of jobs and providing a decent livelihood for millions since 20 years. If everything becomes simple and easy, it will create massive unemployment problem. We can't loose our bread by killing the gorilla.

In fact new technology is providing more employment opportunities these days. Old technology is providing jobs for maintenance of legacy systems. Look around the job market today what's in demand ! No one is killing the gorilla things evolve by them selves.

This seems to be an old video.

JAVA is a classical language and ideal for teaching the concepts of oop , interfaces , threading and synchronization etc to students of CS. PASCAL used to be the language of academics in the early days when oop was not evolved. The best part is JAVA & JVM is freely available for practice. C# built on concept of JAVA but not freely available and requires .NET.

Of course PYTHON , JS etc are also freely available but they are not ideal OO languages for teaching the concepts. However they are practical and pragmatic languages and being interpreted languages are they easy to use.

Since Kotlin is 100% interoperable with Java, i think IA must transpile Ignition server and switch over to Kotlin asap. When it comes to front end development, i think JAVA is dead. Python and React/Angular/VUE etc will takeover.

I suggest, IA must launch “Ignition Kotlin” beta versions without any further delay to win and retain the customer confidence.

But Its still built on underlying JVM, so whats the big advantage of just trans piling Ignition to the new language. Its still old wine in new bottle. We hardly achieve any thing new!

The need for a Java alternative has arisen because Oracle has announced that commercial use of Java will end by January 2019. After that, one may have to pay Oracle to use Java or they may kill Java once and for all. I think, JVM will still be freely available. Not sure. So, what's the best alternative?.

I’ve used JavaScript professionally in a number of ways:

  • As Object-oriented model

I really like the language as a prototype-based object-oriented language. The prototyping makes the inheritance really nice. So it’s possible to have a base library that can be extended massively with project-specific modules, without touching the shared codebase and without duplicating code

If you can use ES6 or higher, JS is really easy to write.

  • For IO with NodeJS (microservices)

Early styles of async IO in NodeJS were a bit verbose IMO, having nested callbacks for file and error handling made code quite hard to read, with lots of indentation if you weren’t carefully naming every single function. But the current async/await style is very nice.

It makes it easy to write very performant IO-heavy software, without having to worry about multithreading issues. The code looks very linear, which is rare for asynchronous software.

The gazillion of small packages for NodeJS is a bit ridiculous though. If you can write a task in 10 lines, it’s unlikely it will ever need an update, so I’d rather not depend for that on a separate library, but incorporate it in my own codebase. But nobody is obligating you to use those libraries.

  • To make dynamic web pages

Honestly, although this was the first purpose of the language, I hate to make dynamic web pages. Altering the DOM directly is annoying, so you need a library like Angular or React. Then you can spend weeks getting better at it, bumping into issues where apparently you do need to manipulate the DOM, getting into fights with your library. Debugging these is very hard too, as after a while, you don’t know whether it’s the library or your own code modifying the DOM.

And worst of all, 3 years later, the library isn’t popular anymore, or has a new, widely incompatible version, and you still need to keep up with the development and also keep supporting older products.

  • Summary

That said, it’s hard to compare Java to JavaScript. JavaScript is obviously made for leaner, smaller programs. While Java is better for huge code bases AFAICS. F.e. in JS, when you have a performance problem, it can be because it just couldn’t be handled by the JIT, but needed to be interpreted. Changing a single statement in a function can make an entire function 10x to 100x slower.

If you want to make something small in Java on the other hand, you’re screwed. The setup code and ways to distribute/install the software are quite cumbersome for small projects.

But all in all, these points are moot as Ignition is written in Java, and translating software to a different language is a huge job which will always bring new problems to the surface.

2 Likes

Of course we are not trying to fix something that's not broke. However for smaller and simpler requirements like SCADA server on edge devices, embedded devices, controllers requiring OPC UA on them, it might make sense to use NodeJS based systems.

As regards JS based client frameworks, ultimately under the hood they all do DOM or virtual DOM manipulation only. Where as SCADA system including Ignition don't use DOM for UI, due to requirement of graphic display. At least I haven't come across a 100% DOM based SCADA system for UI. This might be due to web based approach to SCADA which was pioneered by IA came later than traditional client server based architectures where UI was on MS windows or unix's X-Widows. Web based systems are primarily designed for HTML and text interfaces for IT applications. They are now being extended with HTML5 and graphics etc.

Of course threaded code in JAVA is much easier to write and understand and debug compared to asynchronous JS code. In general life is easier in sequential approach than in event oriented programming.

Is it NOT possible to write a more powerful Ignition from the ground up in Python+JS (without JAVA)?. I think, Youtube is a very good proof of the power of Python. May be, people can use it as a dedicated SCADA for ML.

With Internet becoming better and better, I guess its time to think of a cloud based SCADA based on subscription model!

1 Like

honestly there are tons of these out there.

Some SCADA for high school projects are there but nothing serious enough for a business. Ignition is the only SCADA which i have found qualified as a cloud SCADA. I think it's also a lot cheaper to buy full Ignition, deploy it on cloud and provide subscription based service for clients especially for smart Infrastructure projects.

Nevertheless, subscription based cloud SCADA is very attractive for SMB clients who can't afford to run a 24x7 control room on site, pilot projects and telemetry projects.

Yes , and use MQTT or PubNub to connect plant floor controllers and devices to Ignition hosted on cloud on dedicated VMs

1 Like

no there re tons of them. Out of respect for Inductive, i will not link to any of the sites, but a couple of searches should net you many "IOT" cloud services that will allow you to work off of a subscription model.

I think, India has a good potential for this business model. I am sure, IA is open minded to discuss any viable business proposition. Needs some serious attention.

Why not. Especially for geographically distributed SCADA applications like Smart Cities, or distribution systems, transportation systems etc its possible to deploy it any where, not only in India.

1 Like

companies like L&T execute smart city projects in India and private utility companies like Reliance , Adani , Tata power are the possible customers, but most of the prospects are in government sector in India.

1 Like

Perhaps some of the SI's can try to port one of their existing projects to cloud on a pilot basis in parallel and see the performance.