I am brand new to the Java EE world. As an exercise to try and familiarize myself with Java EE, I'm trying to create a tiered web-app, but I'm getting a little stuck on what the best way is to spin up a service in the background that does work.
Parameters of the service:
It must open and hold a socket connection and receive information from the connected server.
There is a 1-to-1 correlation between a user and a new socket connection.
So the idea is the user presses a button on the web-page, and somewhere on the server a socket connection is opened. For the remainder of the users session (or until the user presses some sort of disconnect button) the socket remains open and pushes received information to some sort of centralized store that servlets can query and return to the user via AJAX.
Is there a Java EE type way to handle this situation? Naturally what I would think to do is to just write a Java application that listens on a port that the servlets can connect to and spawns new threads that open these sockets, but that seems very ad-hoc to me.
(PS: I am also new to Stack Overflow, so forgive me if it takes me some time to figure the site out!)
There are three main containers in the Java EE stack: the Web container, the EJB container, and the JCA container. JCA is meant to provide inbound and outbound connectivity with third-party systems, such as database, JMS broker, or others.
The "right" way to create an connection to a Telnet server from an EJB or web app would be to use a JCA connector for that.
[client] <-|-> [web] <--> [ejb] <--> [jca] <-|-> [telnet server]
The pipe | denotes remote boundaries. A assume EJB are locals, but they are optional anyway; you can use JCA connector from the web layer also.
I suggest you investigate if there are existing implementation. A quick google gave me this result: JCA connector for Telnet client.
Another approach (but not compliant with the spec), is to start the thread that listens to the socket from a ServletContextListener. The thread will run in the web layer and you can manage connectivity with the Telnet server as you wish.
I suggest you have also a look at this other SO question: Java EE application that listens to a socket.
In both cases, you will probably need to figure out how to temporary store the information received by the Telnet server (the centralized store that you mention) that will later be displayed in the web interface. This is again problematic with Java EE, because the spec forbid the usage of global state. For instance, you should not use static field in theory. But in practice that works if you have only one instance of your app running.
That's only a rough sketch, but I hope it helps.
Related
I'm new-ish to networking, and I'm swimming (drowning) in semantics.
I have a VM which runs a Java application. Ideally, it would be fed inputs from the host through a RabbitMQ queue. The Java application would then place the results on another RabbitMQ queue on a different port where it will be used by the host application. After researching it for a bit, it seems like RabbitMQ only exists in the localhost space with listeners on different ports, am I correct in this?
Do I need 2 RabbitMQ servers running in tandem, then, (one on the VM and other on Host) each listening to the same port? Or do I just need one RabbitMQ server running while both applications are pointed to the same IP Address/Port?
Also, I have also read that you cannot connect as 'guest/guest' unless it is on localhost, which I understand, but how is RabbitMQ supposed to be configured/reachable to anything besides localhost?
I've been researching for several hours, but the documentation does not point to a direct answer/how-to guide. Perhaps it is my lack of network experience. If anyone could elaborate on these questions or point me to some articles/helpful guides, I would be much obliged.
P.S. -- I don't even know what code to display to give context. Let me know and I'll edit the code into the post.
RabbitMQ listens to TCP port 5672 on all network interfaces out-of-the-box. This includes the "loopback" interface (to allow fast connections to self) and interfaces visible to other remote hosts (including VMs).
For your use case, you probably need a single RabbitMQ instance for both directions. The application on the host will publish messages to one queue and the Java application in the VM will consume messages from that queue and push the result to a second queue. This second queue can be consumed by the application on the host.
For the user, you need to create a new user with the appropriate rights. This is documented in the access control article. To create the user, you can do it from the management web UI (after you enabled the management plugin) or using the rabbitmqctl command line tool.
The last part is networking between the host and the VM. It really depends on the technology you use. It may work out-of-the-box or you may have to configure how VMs are connected to the network. Refer to the documentation of your hypervisor.
I am planing to develop JavaScript client application that will connect to Java server using websocket. Server should handle many connected clients.
After some reading I found out websocket single thread. This is not good if I want to run databases query that can block everything for a while.
What I am thinking about is to opening separated websocket for each JavaScript client. One socket is listening for new connection and when connection is established creates some unique id. After that opens new websocket and send id to client using listener socket. When client received id close first socket and connect to new one.
What do you think, is it good solution? Maybe I am missing something?
Spring 4 gives you the chance to use a thread pool. The documentation is here:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html
You could use Akka to manage all the concurrency and thread management for you. Or you could use the Play Framework that already builds on Akka and that supports WebSocket quite nicely. With Play you can choose between Java and Scala on the server side.
You should use NodeJS on the server to handle the socket i/o. You can connect to it via your javascript client apps, and then make calls to your Java based API. NodeJS is non blocking (async) and you should be able to leverage your existing Javascripting skills to quickly build a Node app. You could even use a full MEAN stack to build the client/server app. http://meanjs.org/ or http://mean.io/#!/ are two popular places to start.
I want to build a chat application and am confused about deciding whether to use sockets or RMI to build the application. I have heard that RMI is difficult to configure and deploy over the Internet, since that is my intention I was wondering what would be more appropriate to go with, sockets or RMI. Also is it easier to solve issues because of NAT in sockets or RMI ?
What if I want to add voice support at some later point, does it help deciding which way to go ?
1. For applications like Chat Messenger, my bet will be on Sockets.
2. RMI will be an over kill here.
3. Moreover NAT issue is not about Socket or RMI, its about Static IPs.
4. If you want to deploy a Chat Server over the net, then first you must have a Static IP, you need to have to ask your ISP to provide you with one of them at extra cost, or there are sites over internet, that makes your dynamic ips as static.
5. But if your server is locally located in a LAN environment, then i think you won't have a problem in doing it.
Both are reasonable choices that could be used to build a chat server/client. A socket can be set up to take incoming connections and start a new thread for each "chatter" alternatively RMI can be used to create a distributed object on which the client can call methods.
RMI is basically a layer over sockets often used in distributed computing where some transparency is needed and remote methods need to be called. It also allows for stateless connections to the server.
If you choose to implement the server in RMI just be warned that thread safety may be an issue.
For a local server it is probably easier to use pure sockets.
For more details on RMI:
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html
I would like to have the clients query each other through the server without delay ( = no polling interval ).
Example: Server S, clients A and B
Client A wants to request Client B.
Client A will make a request to the server S, no problem there.
Then Server S needs to be able to request Client B but how to do that without polling?
All the node.js/APE (for PHP) technos are designed for the web, however I don't use a web server for that. Does Java has something close to a push technology/framework that is not web?
I would really prefer a solution that doesn't require each client to use their own reserved port (I don't want to end up with 1 WebService per client for example)
Note: all the clients are on the same machine.
A couple of options...
Plain socket communication. java.net.Socket, java.net.ServerSocket. Maximum flexibility but requires knowledge of low level TCP/IP API/concepts.
The good old RMI. Java based RPC layer on top of TCP/IP. Works good when client and server are both in Java and generally in same subnet. May give problems when client and/or server are natted.
Spring Remoting, it's actually pretty decent.
Bi-Directional Web Services. i.e. clients host their own WSes which the Server calls when it needs to do a callback.
JMS as someone already mentioned.
Distributed Data Structures, Check out http://www.hazelcast.com/
Lots of options to chose from, no need for webserver.
If you really don't want to use a web server then I would check out JMS. That being said, all the cool kids are using web servers these days since the protocols are so ubiquitous.
Your use case requires a messaging protocol. We don't really know the scope of your problem but you already said you want a server to exchange requests between clients, so I would go with an existing solution rather than a roll your own approach.
JMS has been mentioned and is certainly a viable Java based solution, another would be XMPP which is a real time communication protocol commonly used for instant messaging.
It is an open standard that has both server and client support in every major language and platform. This would allow you to have standalone apps, web based ones and apps for mobile devices all being able to communicate with each other. The only potential gotcha for your use case is that it is text based. Since you haven't said what requests you want to pass back and forth, I don't know if this will fit your bill or not.
You can use Smack for client side development in Java and any OS server you want.
I created a game and I want to put it on online. I want to buy a website (I'll probably use goddaddy to buy a domain name and use them as the web host) to use as the server to handle game play. Because I would need a separate server for each game, I would need each game's server to exists on different ports. So this leads to my question, is is possible to access these ports on my future web server? (I wrote the program in Java, so I would assume that I would access the ports from the server side by choosing a port for a ServerSocket, and from the client side by using the IP address from the website and the chosen port for a Socket)
(note: also, I am aware that it may be easier to simply use one port and run the servers on different threads instead, but I am just curious to have my question answered)
thanks a lot,
Ian
Technically it is possible to use different ports, but I don't think that a webhoster like goddaddy will let you run a java process that binds to a special port.
If you mean that you are going to create your own TCP server you obviously can create as many instances of your server and configure them to listen to different ports. But it is year 2011 now. This solution was OK in early 90s.
I'd suggest you to use Restful API that works over HTTP. In this case you can forward calls to server side of each application using URL, e.g.
http://www.lan.com/foo/login?user=u123&password=123456 - log in into application foo
http://www.lan.com/bar/login?user=u123&password=123456 - log in into application bar
In this case you need only one server (the web server) that is listening to socket (port 80).
Your server side implementation could be done using various web techonlogis (php, java, asp.net etc) on your choice.
Yes, that should work. The security manager permits connections to a different port on the same IP address that the applet was loaded from.
You can run a Java server on whatever port you want. Each server will accept incoming requests on one port.
The correct way is simply run on one port and each connection will instantiate a new servlet instance (which happens to run in its own thread) that can then service that request. You usually don't need to run separate ports or worry about concurrency, especially if all the stuff that's shared between connections (e.g. multiple players in one game) is handled through database read/writes.
Your host (GoDaddy) will have to allow you use of those ports, but if they are providing proper hosting (not virtual hosting) and given you your own IP there's no reason why you shouldn't be able to.
Your solution may work theoritically, and I like AlexR's solution. But providers like godaddy doesnt let you run a java server, on ANY port. You will need to find out somebody who does. What I found is the cost goes up from $5/mo to about $20/mo, but you get a much better (read faster) machine. Good wishes, - MS.