Develop Reference

Spring boot+tomcat performance: Server-sent events vs websocket vs old-school REST

Suppose, we have a Spring boot application built with Tomcat and web-client works in browser. And we need to indicate some info about processes, runned on server-side. Server side is Spring boot application built with Tomcat.
As we know, there is 3 ways to implement such functionality:
1. websocket;
2. server-sent-events;
3. REST-service (GetMapping) on server side and timer on browser-side which polling that service with GET-requests each second.
Let's suppose that we have a lot clients, and that exactly our code have equal time and memory consumption in all 3 versions. Question: which way is cheapest by CPU, by memory and, maybe, by available connections?

Java web application calling different other Java applications (workers)

I am looking for a better logical solution of a situation where one core Java EE (Web) application will call/execute many other Java applications/workers (which can be core Java or J2EE(web) application (don't know what will be the best)) at a certain time.
Those other Java applications/workers will basically connect (individually) with different Data sources (can be from remote DB or REST or SOAP, etc...) and populate/update local DB at a certain period of time.
I was doing research on Java Quartz Scheduler recently. Do u have any good suggestion to me for this Enterprise level architecture?
Btw, I am using Spring 4, Java 7
Thank you as always for all good and professional ideas.
Sample diagram can be as follows:

You can connect your java application with others easy with spring's httpInvoker or rmiInvoker.
More information here: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html

Not sure to understand good, but you can look at a messaging mechanism. Typically, the WebApp will send a message that will be received by all the Workers.
Have a look a JMS which it designed for this kind of use, and integrates well with both JEE (it is a part of the JEE spec) and Spring.

There are basically two parts to your question:
How do I schedule jobs on a Java EE server?
How do I invoke remote services from that scheduled job?
Job Scheduling
The trick with job scheduling in a Java EE environment is that you are typically running jobs in a cluster, or more than one server. Thus, only one of the nodes should be running that job at a time "on behalf of" the cluster, otherwise, you'll get multiple calls to those remote resources for the same thing.
There is a standard out there for this, JSR-237, which covers Timers and WorkManagers. Each Java EE vendor has its own implementation. WebLogic has one, WebSphere has one, and JBoss has one (the JBoss one isn't compliant with the JSR, but it does the same thing).
If you are running one of the servers that only runs the web tier of the Java EE spec (i.e, Tomcat or Geronimo), then Quartz is a good choice.
How to invoke remote services from timed jobs
Echoing #Alexandre Cartapanis' answer, probably what you'll want to do is create a JMS Topic in your Java EE server, and then when the job runs, post a message to the topic. The remote services (whatever Java EE servers) subscribe to this topic, and then you can run your queries.
The big advantage here is that if you ever need to add another service that needs to populate the local DB, all you have to do is have that server subscribe to the topic - no code changes needed. With JSch or remoting, you'll have to make a code change every time a new service comes online. You also have to make code changes if DNS addresses or IP addresses change, etc, where as the JMS way is just configuration on the server. There's a lot more that you can do with JMS, and the support is much better across the board.
Spring has adapters for Quartz and I think there's one out there for WorkManagers and Timers too.

You can make use of JSch - Java Secure Channel to trigger remote ssh calls which can start a JVM and run the Worker class.
Here are some examples.

What is the best way to make simultaneous httpurlconnection calls in a Java EE application

We have a requirement where we have to make four web service calls from our EJB. All these calls are independent of each other and should be made simultaneously.
Today we are using ExecutorService to make these calls. There is a timeout after which we shutdown the ExecutorService and check the responses.
I want to know if there is a better way to do the same?
P.S.
We use websphere 8.5.0 which is a Java EE 6 server. I found there is ManagedExecutorService in Java EE 7. Is there anything in Java EE 6?

Have you considered using an asynchronous method on a Stateless Session Bean (with the #Asynchronous annotation)? This method would make the call to the web service and the app server (via the EJB pool) would be responsible for managing concurrency.
See: https://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html

Java application server without HTTP

I have a client software that is written in C++/C# and a database. Now I don't want the client to access the database directly, so I thought about placing an application server in the middle. This one should get a short request from the client, ask the database for new data, do some filtering (that can't be done in sql) and then return the data to the client.
My search for this kind of software brought me to Glassfish or Tomcat but my problem in understanding is, that these always want to talk http with html/jsp. Because most of my data is encrypted anyways, I don't need such plain text protocols and would be totally happy with something that just takes a byte stream.
On the other hand would it be nice to have a server handle the thread pool for me (don't want to implement all that from scratch).
After more than a day of searching / testing I'm even more confused than at the beginning (ejb, beans, servlet, websocket, ... so many things to google before understanding just the simplest tutorials).
TL;DR: how do I get Tomcat/Glassfish to just open a socket and create a new thread for every request, without any HTML/CSS/JSP involved?

Jetty and Tomcat are so called servlet container and thus primarly targeted at HTTP exchanges. Glassfish is an application server that uses a servlet container as one of its modules. I would stop thinking in that direction - that's all more like web applications and web services - some levels too high what you are asking for.
I think you should more look into sth. like Netty which is merley a "high performance protocol" server. Take a look at the documentation here (even some sort of tutorial there which might fit your use case).

GlassFish is an "enterprise application server", targeting the Java EJB specification. That's surely overdone for your purpose. You can give Tomcat a try. It is a "servlet container", targeting Java Servlet specification. Servlets have one purpose: listening to an incoming URL (request), executing Java code and returning a response, usually over HTTP.
For sure, you may start your own (plain) ServerSocket, for example using a ServletContextListener (which will be started once your application starts). But you should go for a higher protocol to send the data, like Hessian and Burlap, which is implemented in both, Java and C++ and easy to set up.

Web service implementation Java EE

I have web service cloud system based on Java EE. I use jboss as application server, java version 1.7
My system is something like a bridge between client and merchant servers. Client sends data via soap protocol (amount USD, merchantID, paymenttype and so on.) and i make service implementation based on requested params and send back to client.
I have a question:
There are two ways to make core implementation,
1 is to run it in main thread, every web service runs in main thread
2 per service call should be in separate thread.
I don't want code examples or anything, just what is the correct way to determine my solution?

You can use the jboss request processing thread pool to control it. There does not seem to be a reason to attempt custom thread pool. Its a a complete different discussion if you are thinking about asynchronous communication.
I got the below from another SO post which is helpful
http://www.mastertheboss.com/jboss-server/jboss-performance/jboss-as-7-performance-tuning?start=3

In my case, I designed my system as multiple threads managed by main thread. This solution is very helpful and easy to maintain.