Licensing – Should Node.js and MongoDB Be Bundled Together?

This is not really a war that you can win with the approach you have lined out. As others have pointed out, simply disabling the network, or clicking "no" when the firewall asks you whether or not to allow your application to phone home, will bypass the phone-home. Aside from that, users absolutely hate this type of thing, and you may be required to explicitly have the user tick a checkbox saying that they understand what the system is about to phone home (according to the law in some countries).

So, what can you do? My advice would be:

• Try to reward your paying customers with value-adds (frequent updates, online tutorials, etc), rather than effectively punishing them.
• Don't worry too much about pirates. In many cases, they are unlikely to have purchased your software in the first place, the least they can do is spread awareness of your application.
• If you really can't handle the fact that your software is going to be pirated, make it an online app (if the nature of the software is such that this is possible). There was an interesting article by a developer who made this move, and found that his web version sold far better, was far easier to identify what features users actually used (since it's not really calling home if you're already on the server), and there was far less reluctance for people to whip out their credit cards (sorry - can't find the link).

To understand this approach is to be familiar with the goals and advantages that each of these very different frameworks take.

Node.js is a server side solution for efficient middle tier development of a web application. Some advantages of this are that client and server code can be written in the same language allowing the domain model to exist, without translation, between client and server.

JSF is a component based web framework that allows for MVC development, and allows for a server side event model that can occur on user interaction with the client.

If you had to integrate them then ask yourself why you would need to? JSF will allow you to define your client view and server side controller simultaneously so why would you have need for a second controller in Node.js? If you decided to go with the Node.js approach then while your server side needs are met, your view still needs to be addressed which coincidentally allows you more control over the presentation of your web application than JSF typically allows.

Assuming you need to do this, the best way is to have Node.js provide business logic and data access to your separate JSF application through the use of REST based web services. I would implement a wrapper around the Node.js web services and make these wrapper calls within my JSF Managed Beans.

The only reason I see for this approach is

• If there exists a compelling business reason, like if data can only be accessed through a third party REST based web service that happens to be implemented in Node.js, or if you need to integrate with a component that a separate development group is responsible for.

• If you wish to learn both technologies and do not have enough time to learn them each separately.