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.
Related
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.
I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.
I am planning to do a simple Remote Procedure Call (RPM) over the web and I am currently using WebSockets. I was wondering if Jini is better than WebSockets or if there is a newer API or framework for Java to do RPC.
WebSockets and Jini are the main ones of note, both have their pluses and minuses. I'd say WebSockets is great just for the sheer amount of examples and documentation lying about. Jini is a lot different than WebSockets - so if anything the overheard of learning how to use it may not be worth it; that is up to you to evaluate, I spose.
I wouldn't use WebSockets directly because older browsers and/or corporate firewalls may have issues with it. SocksJS
is a respected wrapper that will gracefully degrade to another transport mechanism if required while still allowing you to work with a WebSockets type of API.
The client side is generally written in JavaScript but they have a number of servers written including two in Java: Vert.x and Netty. It looks like the Vert.x implementation is a little more mature at this point in time.
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.