Server side events with desktop client .i.e no browser (java) - java

We are in the need of "push notification" mechanism, to desktop clients written in java, and mobile clients such as android, ios and windowsphone8. I came across "server side events" which fits very well, as we only need unidirectional communication from the server to the clients, so websockets are overkill for this scenario. We are currently using polling as fallback but we want to avoid this as much as possible.
As I understand it the server needs to be some kind of "publish subscribe" module but I'm not sure if "spring framework" provides any helping hand here or if there are other frameworks helping out with the pipelining. I have read about redis being a good candidate for publish subscribe module. However what framework / component to use to connected a java desktop client to this publish subscribe module is what I want help with.
There are a bunch of technologies / framework out there html 5 websockets, socket.io and so on but these only work for web, i.e browser clients.. I'm looking at java.net.ServerSockets (not used it before) but slightly unsure if that is the best approach. We will have a seperate "service module" running on the same desktop as the java desktop client, This service will handle a push notifications.

Sounds like you could use Java Messaging Service (JMS)
Spring's support for JMS
http://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/jms.html
J2EE JMS
http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/overview.html#1027335
Also, check out these similar questions --
how to notify java desktop clients about changes from server?
Push notifications to various devices through a common code

Related

it is possible to send messages from a Java class to Skype for Business distribution group without using client software

it is possible to send messages from a Java class to Skype for Business distribution group without using client software If it is so, then how it is possible.
I am continuously browsing but didn't get any solution yet.
We build such a integration and used the XMPP Gateway (but needs to be configured by the system administrator) which is part from a Skype for Business environment. So what we build here, we setup a XMPP Server, our application is working with the XMPP Server and an XMPP Federation between Skype for Business and the XMPP Server. Might be an overkill for your needs but as you didn´t share much more infos about what you wish to build this might be an possible options ;-).

Spring webapp: sending notifications to java and android clients

I recently started developing my first web application with Spring and I'm stuck with a question I could not really find an answer to. What I have is a simple Spring MVC application running in tomcat which provides data in form of JSON, XML or binary via REST. This service is consumed by two clients I developed, a simple Java desktop application and an Android app. So far the clients only got information about new data by polling.
What I want now, is a way for the server to send notifications/messages to the clients when new data is available. For the Android client it would be good if the notifications could received anytime, not only when the app is currently open of course. I found lots of information for JavaScript client code but very little really useful, up-to date input about what the options for java and android clients are.
It would be really great if someone could give me some idea what would be the best way to achieve what I want (ideally something which integrates well with Spring on the server side), what protocols/libraries/frameworks to use, maybe even point me to some example or tutorial, how to implement this on server and client side.
Thanks in advance for any input.
For android or mobile devices, Google Cloud Messaging is the preferred way of sending messages to applications running on devices.
Example : spring gcm server side project and a sample tutorial.
For desktop apps, either poll regularly the server or run something in background like crontab or active-mq to check the messages and start the desktop app.
WebSockets are the best solution. check the implementation in java in the server side

communication between jruby app and java app that are on different servers

Anyone has expirience on having Jruby project running on Jboss (using torquebox or whatever) with an ability to communicate with another "japps" not on the same jboss where jruby app is, i.e. some java project on another jboss?
I know there is an torque-messanging but dunno if it's possible to communicate with external(out of jruby-app's jboss) app?
Best practices are welcomed.
Thanks in advance.
P.S. placing that other app on the jboss where jruby app is not acceptible solution.
I can recommend you to use Thrift and build communication via them.
Thrift have generator for both your needed languages (Java and JRuby) and provide good and fast communication.
UPDATED:
Thrift is RPC (remote procedure call) framework developed at Facebook. In detail you can read about it in Wiki.
In few word to save you time, what it is and how to use it:
You describe you data structures and service interface in .thrift file(files). And generate from this file all needed source files(with all need serialization) for one or few languages(what you need). Than you can simple create server and client in few lines
Using it inside client will be looks like you just use simple class.
With Thrift you can use what protocol and transport used.
In most cases uses Binary or Compact protocol via Blocked or Not-blocked transport. So network communication will be light and fast + with fast serialization.
SOAP(based on XML on HTTP) packages, its in few times bigger, and inappropriate for sending binary data, but not only this. Also XML-serialization is very slow. So with SOAP you receive big overhead. Also with soap you need to write (or use third-party) lib for calling server(tiny network layer), thrift already made it for you.
SMTP and basically JMS is inappropriate for realtime and question-answer communication.
I mean if you need just to put some message in queue and someone sometime give this message and process it — you can (and should) use JMS or any other MQ services(Thrift can do this to, but MQ architecture is better for this issue).
But if you need realtime query-answer calls, you should use RPC, as protocol it can be HTTP(REST, SOAP), binary(Thrift, ProtoBuf, JDBC, etc) or any other.
Thrift (and ProtoBuf) provide framework for generate client and server, so it incapsulate you from low level issues.
P.S:
I made some example in past https://github.com/imysak/using-thrift (communication via Thrift Java server + Java Client or node.js client), maybe it will be useful for someone . But you can found more simple and better examples.
Torquebox supports JMS. The gem you specified torquebox-messaging allows for publishing and processing of HornetQ messages on the local JBoss AS server/cluster that the JRuby app is running in. I don't think it currently supports connecting to remote servers.
Using this functionality in your JRuby app you could then configure your Java app on another server to communicate with HornetQ running in the JBoss AS that the JRuby app is running on.
Alternatively you could always implement your own communication protocol or use another Java library - you have access to anything Java you want to run from JRuby.
You can use Web Services or JMS for that

Best way to manage asynchronous / push communication with web clients on a Spring based Java server

I need to push events to web clients in a cross-browser manner (iPhone, iPad, Android, IE/FF/Chrome/etc.) from a Spring based Java server. I am using backbone.js on the client side.
To my best knowledge, I can either go with a Web socket only approach, or I can use something like socket.io.
What is the best practice for this issue, and which platform/frameworks should I use?
Thanks
Looks like you're interested in an AJAX Push engine. ICEPush (same group that makes ICEFaces) provides these capabilities, and works with a variety of server- and client-side frameworks. There is also APE.
You can have a look at Lightstreamer.
My company is currently using it to push real time financial data from a web server.
I suppose Grizzly or Netty may fit your needs. Don't have a real experience in that scope, unfortunately.
I'd recommend socket.io as you mentioned in your question, if you're doing browser based eventing from a remote host. Socket.io handles all the connection keep-alives and reconnections directly from javascript and has facilities for channeling messages to specific sessions (users). The real advantage comes from the two-way communication of WebSockets without all the boilerplate code of maintaining the connection.
You will need to do some digging for a java implementation thoughConsider running the server directly from V8.

Server-client Java distributed application

I have to design a distributed application composed by one server (developed in Java) and one or more remote GUI clients (Swing application with windows).
As stated before the clients are Swing GUI application that can connect to the server in order to receive and send data.
The communication is bidirectional (Server <=> Clients).
Data sent over the network is mainly composed by my domain logic objects.
Two brief examples: a client calls the server in order to receive data to populate a table inside a window; the server calls client in order to send data to refresh a specific widget (like a button).
The amount of data transmitted between server and clients and the frequency of the network calls are not particularly high.
Which technology do you suggest me for the server-clients communication?
I've in mind one technology suitable for me but I would like to know your opinions.
Thanks a lot.
The first technology that came to my mind was RMI - suitable if you're communicating between java client and java server. But you may get difficulties if you want do switch the client technology to - say - a webinterface.
I would go with RMI but implement the whole architecture using Spring framework. This way it is independent of technology used and can be switched to other ways of communication (such as HTTP or other ) with almost no coding.
UPDATE: And Spring will allow you to have none of RMI specific code.
I believe sockets should do the trick. They are flexible and not especially hard to code/maintain. Most entry level programmer should also be able to maintain them. They are also fast and adapt to any kind of environment.
Unless, your server is going to be off-site or you expect to have firewall issues. In that case, web services are the way to go since your basic communication happens through port 80.
I would second msparer's suggestion of RMI, except I would just use EJB3 (which uses RMI as the communication protocol). EJB3 are very easy and even if you don't use the other feaures EJB gives you (e.g., security) you can still leverage Container Managed Transactions (CMT). It really does make development easy.
As for the server->client communication, you would probably want to use JMS. Again, using EJB3 this is pretty e3asy to do with annotations. The clients will subscribe to the message service and receive update notifications from the server.
And yes, I am currently working on an application that does this very thing. Unfortunately we are using EJB2.1. Still, it is my opinion that this is where EJBs really shine. Using EJBs in a web app is frequently overkill, but in a distributed client/server app they work very well.
You can try using ICE http://www.zeroc.com for establishing server-client connection.

Categories

Resources