i need some idea/suggestion regarding the implementation of any simple/easy to use setup for such system:
I have two machines, where one will send commands (can be commands, configuration files, text, xml etc) (I have to decide in which way the commands should work) and the other will implement those command. However this is not a completely interactive terminal application, the sender just need to know if it was executed fine or not.
Also RPC is not an option, do i simply go by implementing client/server socket concept??
Is there any well known library to help realize such scenraio in Java? or may be some web server and http based communication??
Any suggestions for opensource libraries to realize such scenario?
If you use sockets or any other TCP messaging service, you will get guarantied message delivery, and then all you need is to write the response on the server end and send it back.
The Apache MINA project. MINA's API is lower level and a great deal complicated. Even the simplest client/server will require a lot more code to be written. MINA also is not integrated with a robust serialization framework and doesn't intrinsically support RMI.
The Priobit project is a minimal layer over NIO. It provides TCP networking, but without the higher level features. Priobit requires all network communication to occur on a single thread.
The Java Game Networking project is a higher level library. JGN does not have as simple of an API.
KryoNet is a Java library that provides a clean and simple API for efficient TCP and UDP client/server network communication using NIO.
Related
There are some literature on the differences between WebSockets and sockets on Stackoverflow. What I'm trying to understand, is why would I pick web sockets over normal sockets, if I'm writing a normal client/server application, where the server is not necessarily a web server and the clients connecting to the server is a native C++ or a Java client.
There's a huge advantage to WebSockets if you have to deal with browsers, what if I don't have to support browsers, should I still consider using WebSockets?
Edit:
More clarity to what I'm asking: Had WebSockets existed much earlier, would it be appropreate to replace https://en.wikipedia.org/wiki/Unix_domain_socket with WebSocket in the unix tools that use Unix domain socket for instance, or any other context where sockets are used in an IPC context. Another case would be if you were to write an IRC server, would you it be appropriate to use WebSocket instead of the ordinary TCP socket, is there any reason to stay away from WebSocket in this case?
If you're comparing WebSockets to TCP, WebSockets have a number of advantages:
Unicode support
Datagram-oriented interactions
HTTP CONNECT-based firewall traversal
However, this comparison is a bit of a false dichotomy. If you don't use WebSockets, you're not forced to start building directly on TCP. There are many other protocols out there (too many to count) with many great implementations.
Perhaps HTTP itself is well-suited to your application. Or maybe XMPP or Google Protocol Buffers or something else. It all depends on what your application needs to communicate.
Before you can select a protocol (or, rarely, design your own), you need to figure out what kind of communication your application needs to do. Then you can evaluate different protocols and decide which fit your problem well.
That said, the majority of development these days seems to focus around the web. Even if there's nothing inherently web-y about the application, many people choose HTTP as their protocol now. At this point, a ton of work has gone in to standardizing the use of HTTP as the solution for a wide range of problems, as well as building libraries to facilitate this use. Chances are, whatever you're building, HTTP will be a decent fit (again, I don't know what you're building, so this is just a guess).
I have to deploy some Java servers in a bunch of different networks. For each server, I need to monitor its status and send it tasks to be executed in that specific server. Something like distributed workers.
This servers would be used from different platforms and languages so I need to find a way to communicate with them and obtain the needed information. Which is the best way to do this? I've been reading about use JSONs to communicate with my servers but I'm trying to figure out if there is a better approach.
Another solution could be to have a web dashboard and control all through web petitions but I prefer the servers to be standalone. Any ideas on what I can do?
At the moment I would suggest REST interfaces for your Java server. Since REST with Json is easy to implement in other languages too and you can even use HTML and JavaScript to write a Monitor client. So from my point of view this is the most flexible solution.
An other solution would be to use XMPP to "talk" with the server and "ask" them about there state. I remeber this as a solution for machine to machine communication, but this was before the Json and REST boom so I would not suggest to go with this.
When your other platforms consists of Java and C# mostly SOAP could also be a solution, since there are good code generator for both languages which can create the WSDL from code and vice versa. But its kinda difficult to use SOAP in JavaScript (as far as I experienced) and maybe other languages have the same problem with SOAP.
If multiple platforms are involved, web services are probably your best bet. You can have you java servers expose web services (for status and task execution) and you can call them from anywhere/any system.
In my web-app, i need to push specific messages to my clients in real time. Web-sockets would be a good idea, but they don't work in IE, which should be supported as well.
Until recently we have been using StreamHub, but it's license has expired and the project itself seems to be dead. We also considered jWebSockets, but they seem a bit of overkill.
Again, all we need to do is to send messages from the server to specific clients as events happen on the server.
Could you recomend a lightweight, free and opensource solution for that?
Here's an opensource Java implementation of Socket.IO. It allows you to use Ajax mulitpart streaming to simulate WebSockets when your client doesn't support them. I've used it on projects in the past. It's horribly out of date with the most recent implementation of the WebSocket protocol, so if you plan on using WebSocket capable browsers in addition to IE, you'll have to update the source code to comply with the latest protocol. At one point I was researching a maintained replacement for Java Socket.IO and jWebSockets sounded like the way to go.
Take a look at the Atmosphere WebSocket/Comet library. I believe it can use long polling when WebSockets aren't supported.
I receive a WCF service to communicate, so, i need to create a client in java or python to get informations provided by this service that is a WCF TCP service. Is it possible?
I'm assuming that when you say the service "is a WCF TCP service", you mean that it employs the netTcpBinding (scheme net.tcp).
This binding relies on some proprietary Microsoft protocols in addition to public standards such as SOAP. These provide message framing, support for a variety of encoding schemes, and for the layering of security protocols over the message stream. This is similar to the netNamedPipe binding, and further details of these protocols are explained here on my blog.
The answer to your question is "yes, it is possible", but the bad news is that in order to do so you would have to implement all the proprietary Microsoft protocols in your chosen client platform. You will almost certainly want to avoid doing this, as it is a lot of work (though maybe someone has already written an open-source library for either Java or Python).
If you can't find a library, and are able to run any flavour of .NET on your client platform (or if it is feasible to interpose a separate Windows machine to act as a proxy, between your clients and the service) I would consider creating an adapter in .NET, to broker your access to the service. Such a thing could present a pure standards-based interface (e.g. WS-*) to the service, internally forwarding calls to the real service, to enable it to be consumed from other platforms.
EDIT: I wasn't previously aware of the Java interop library for Windows HPC which another answer has mentioned and linked to. This seems quite promising: open source and Microsoft-supported, which for this purpose is probably even better.
The net.tcp bindings are proprietary. Here is a site that mentions it in some other context.
The article points to a Java interop library posted on Github Interop Library Download Link
Hope this helps... I'm curious to know the answer as well, as I just happen to be getting involved in the Web Services side of the business.
I'm writing my first client/server android app, and need an advice regarding server architecture.
My app is not a browser based app, but a stand alone client.
On server side i use hibernate/JPA and would like to transfer objects to client side.
What should I use:
Implement MVC- meaning writing servlets that will handle http requests (via Apache for example).
Write my own stand alone primitive server, meaning using simple sockets connection(in java for example), and handle each client in a different thread.
if you can think on a better way, you're more than welcome to share..
HTTP is definitly your choice since many carrier will block other protocols, since application servers/containers will take care of handling the multiple connexions and since it will also be a base if you decide to have a browser-based version some day ...
REST + JSON based webservices are well suited for android, given its simplicity, lightness and readability, but SOAP is also available via kSOAP2.
In my opinion. writing your own socket server is only warranted if you are required to implement your own wire protocol.
Most likely it's not a case for you.
So stick with http since it's widely adopted and has excellent client support in Android.
As for specific server side technology, you need to enumerate your requirements and do some research.
Don't start with Apache if plan to use Java, though. Pick Tomcat or Jetty. For framework, my personal choice would be Spring MVC.
Well, I have some experience in this very sphere and we used apache + php "covered" with nginx. I believe it's better to use standard approach, such Apache + PHP or Tomcat + servlets, cause it's easy to scale if needed and support... Of course it interesting to write your own application, but you might have some troubles with when traffic grows or server is down etc.