I am currently working on a project that needs to work with WebSockets.
The clients will be the browsers only, so not interested in any message broker feature of these two.
Although I don't think that it would be much a difference, but would be interested if I can get a few comments on STOMP vs WAMP as a subprotocol using Spring-WebSockets.
And I might get a few hints that may help choose one over the other.
Cheers,
EDITED (27-02-2014):
As, programming directly with webSockets is low-level, so its suggested in many places (one the spring documentation) to use some sub-protocol.
Also, the use of a sub-protocol over websocket, is a type of native webSocket security; like you can do a sub-protocol validation.
There are many other sub-protocol that can be used instead of STOMP or WAMP like XMPP, AMQP.
I couldn't find much information related to these and webSockets, most of it is related to message brokers only.
The one reason (obvious) that I should use STOMP over any other sub-protocol, is that I am using spring-webSockets so for STOMP I don't need add any additional library at the server side, for others I would need to.
At the clients there are many JS libraries that I can use like socket.io for STOMP and similar JS for WAMP and others.
Since, my main concern is at the server side: So, STOMP it is.
I will update this post if I find out something new while implementing my solution.
Related
I've learned a respectable amount about networking protocols in Grad School and in professional experience and sent HTTP requests programmatically using AJAX and such.
The project on which I work professionally uses JMS to communicate and I'm curious about how it works.
When using REST (for instance) one makes an HTTP request with parameters in either the URI or the message header in order to invoke a service and further describe its needs.
A mentor of mine at work and I were discussing how JMS works and I'm struggling to understand at an application level how messages are actually sent. As far as I understand JMS in general (I realize there are many implementations of JMS) it is a specification for how to format data being sent.
Is the message itself still sent via HTTP(S)? Could it be SMTP?
Without going excruciatingly deep I would like to understand how one would, at a code level, send a JMS message from one service to another?
Am I even thinking about this correctly?
Can it be done any number of different ways?
Is there a convention that's used in the industry?
If someone could shed some light on JMS for me I would appreciate it.
Thanks!
JMS is not a protocol, it's an API specification. It's not something like TCP or HTTP protocol. Simply put the JMS specification defines signature of messaging APIs. How the APIs are internally implemented and what protocols they use to communicate with the messaging provider is vendor specific.
The vendor specific JMS implementations know how to communicate with their own messaging provider, but not with any other vendors messaging providers. For example IBM's MQ JMS implementation uses it's own protocol to communicate with IBM MQ Queue Manager, similarly Oracle JMS, Active MQ implementations with their own messaging provider.
Hope this helped.
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.
What is a good solution for communication via message broker that supports both (C)Python and Java/JMS applications? My particular requirements are:
open source solution
Available on Linux-based systems
No rendezvous between sender and receiver required (i.e. uses a message broker)
Multiple producers and consumers supported for a single event queue (only one consumer receives each message)
Unit of work support with two-phase commit (XA support nice to have)
Support for persistent messages (i.e. that survive a restart of the broker)
Supports JMS for Java clients
No component is "fringe", meaning at risk of falling out of maintenance due to lack of community support/interest
If there is a Python client that manages to "speak JMS" that would be awesome, but an answer including a task to write my own Python JMS layer is acceptable
I have had a surprisingly hard time finding a solution for this. Apache's ActiveMQ has no Python support out of the box. ZeroMQ requires a rendezvous. RabbitMQ does not appear to support JMS. The best candidate I have found is a combination of ActiveMQ and the pyactivemq library. But the first and last release of pyactivemq was in 2008, so it would appear that that fails my "no fringe" requirement.
The ideal answer will be the names of one or more well-supported and well-documented open source packages, that you have personally used to communicate between a Java/JMS and Python application, and that do not require a lot of integration work to get started. An answer that includes an "easy" (up to a few days of work) implementation of additional glue code to meet all the requirements above, would be acceptable. A commercial solution, in the absence of a good open source candidate, would be acceptable also.
Also, Jython is out. (If only I could...) The same Python applications will need to use modules only available in CPython.
JMS is a specification not implementation . RabbitMQ is a really option .
I have also happily used HornetQ http://www.jboss.org/hornetq from Jboss as with every thing it is more aligned with every thing Java EE but RabbitMQ would be choice espcially if you are using Spring as well
I have had a surprisingly hard time finding a solution for this.
Apache's ActiveMQ has no Python support out of the box.
ActiveMQ brokers fully support using the Stomp protocol out of the box. Stomp is a text based protocol for messaging that has clients for many platforms and languages.
ActiveMQ's documentation should contain information on how to set up a connector for stomp. In its simplest form, enabling a connector would look something like:
<transportConnectors>
<transportConnector name="stomp" uri="stomp://localhost:61613"/>
</transportConnectors>
Once enabled on the broker side, you can then use any python library that supports stomp. You can then use Stomp on the python side and JMS on the java side for communication with the broker and sending/receiving from specific destinations.
You might want to take a look at OpenAMQ and another look at RabbitMQ.
The underlying messaging technology used by RabbitMQ and OpenAMQ is AMQP. You should be able to easily find Python and Java clients that work against both of these brokers (and ostensibly any other spec-compliant broker).
If JMS is a must-have, then you might be able to find a JMS client out there implemented on top of AMQP (OpenAMQ provided such a client at one time, but I am unsure of its current status).
We had been using GlassFish Message Queue (formerly Sun Java MQ) - it is inherited from OpenMQ
It satisfies most of your requirements, if not all.
We had been using fail over-clustered brokers in Red Hat Linux (RHEL) - it is reliable for heavy usage. Though some 'quirks' lurk here and there.
Basically I need a bidirectional client-server communication (Java) where the client calls methods on the server, but also needs to get "callbacks" if certain events in the server occur.
The methods theirselves have quite complex input and output parameters and lateron it would be nice to include authentication to the system.
Which approach would fit my requirements?
I already build a prototype with RMI, but I read that there exists a number of problems especially for "callbacks" when the c/s are in different networks.
Additionally I would like to avoid JAX related technology, becuase of my complex data structures in the parameters.
Have you thought about using JMS. Within this architecture, server and client will register to a queue or topic and are able to send messages to each other. This enables sych and async application behaviour.
Please have a deeper look into JMS here:
http://java.sun.com/developer/technicalArticles/Ecommerce/jms/index.html
And a really nice implementation is ActiveMQ:
http://activemq.apache.org/
I've had lots of luck with using CometD for callbacks for webapps.
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.