We Keep Coding

Play Framework 2.5 with Server Side Events

I'm trying to make a simple tic-tac-toe online multiplayer game in Play Framework in Java (but I can read Scala too) and I need to notify one client when the other client has made a move - has inserted a new database entry. The frontend uses HTML and JS.
Do I use WebSockets or Server Sent Events for this and how?
Thanks a lot guys, the Play framework documentation for both is still not updated and it's a well known issue https://github.com/playframework/playframework/issues/5057 as well.
EDIT: The main question here is really how to do it?

Personally for a game I would establish a Web Socket connection over a SSE.
Fast data transfers
A two way stream of message, where SSE would require the client to send ajax requests and listen to SSE where WS all sits in one place.
Allows you to establish when one of the 2 clients looses connections, thus pausing or notifying the other player.
Resource you can use to Implement this:
https://www.playframework.com/documentation/2.5.x/ScalaWebSockets
Edit: Latest version https://www.playframework.com/documentation/2.6.x/ScalaWebSockets

Developing a Multiplayer Browser-Based Card Game With HTML/JS/AJAX/Java

I currently have a multiplayer card game developed and working in Java and it is working in the console. The game is similar in format to Bridge and Spades, minus the bidding process. It is a four-player game, and players take turns playing a card.
I am currently working to convert this to a browser-based webapp, and am adding Spring MVC, and using HTML, JavaScript, and AJAX for the UI and communication with the backend. I have a good idea of the approach I want to take on getting this to work single-player against the AI, allowing the user to play their card and using an AJAX call to get the next three plays from the server.
However, I'm wondering what kind of approach I would need to take for this to be multiplayer. I have seen some references to "Socket-programming," which I am unfamiliar with, but those seem to revolve around Java applets, instead of a browser-based app.
Basically, I am looking for a way to ensure that when a user starts a game and someone else joins, how do I ensure that they are connected to the same game, and are able to see each others' plays? I am asking this now before I have the UI fully developed for single-player, because I want to avoid a complete redesign to support multiplayer functionality.

Since you are creating a multiplayer game, you will need to have at least one server for your client(s) to connect to. Since you want to make this browser based, you will most likely need your own server (rather than having one of the clients be a server). When a user joins a game, it is logged on the server where that user is. When a player performs an action, the server processes the action, then sends a notification to each of the other clients connected to that room. At that point the clients UI updates.
In the past, you could not do this with pure HTML / JavaScript as you cannot open a socket. Which means, the server could not notify the clients. However in HTML5 you should be able to use WebSockets to achieve what you are doing with a server in the middle. The WebSocket API
However, if you don't want to use HTML5 WebSockets, there is another technique that imitates Sockets in JavaScript. That is, the server can talk to the clients. This technique is called long polling. The client sends a request to the server asking for an update, if there is no update available, the server holds the request until an update is available and sends it back to the client at which point they make another update request. Simple Long Polling Example
Another option, if you are very familiar with Java you may wish to check out Google Web Toolkit. GWT is a subset of Java that is compiled into HTML and JavaScript for the front end and if needed creates a Server Side java executable that you can use with TomCat or another web service. In this option, you have a few libraries that allow you to write socket-style code that will be compiled into Long Polling JavaScript.
Best of luck!

Wrangling up XMPP

Wikipedia defines XMPP as:
...an open-standard communications protocol for message-oriented middleware based on XML.
xmpp.org defines XMPP as:
The Extensible Messaging and Presence Protocol (XMPP) is an open XML technology for real-time communication, which powers a wide range of applications.
Although I'm sure both these definitions are very accurate, they don't tell me a thing about what I - a Java developer - can actually do with XMPP!
For instance, I've heard XMPP can be used with message-oriented middleare (MOM). How so? Can XMPP somehow integrate with my Apache Camel routes, my ESB or some SOA implementation to deliver a better/faster/more robust business tier? If so, how?!?!
A good, King's-English explanation of XMPP, along with some practical examples (preferable MOM-centric) would be greatly appreciated. Thanks in advance!

XMPP can be used for a wide range of messaging based applications. Basically, it provides core services which can be used to build XML based messaging applications. Its based on a decentralized client-server architecture and utilizes long-lived TCP connections for communicating...
core services include...
channel encryption, authentication, presence, contact lists, one-to-one messaging, multi-party messaging, notifications
service discovery, capabilities advertisement, structured data formats, workflow management, peer-to-peer media sessions
textbook use cases...
instant messaging (using presence, contact lists, one-to-one messaging)
group chat, gaming, systems control, geolocation, middleware/cloud computing, data syndication
bots (weather, database interface, system monitoring)
messaging modes/patterns...
point-to-point messaging is used to send to a specific receiver
multi-user messaging is used to message to a group of receivers
publish/subscribe support is used when there are large volume of events and systems are interested in differing subsets of events. Publishers put events into topics and subscribers indicate which topics they are interested in. This decouples the publisher/subscriber and allows for scalable real-time messaging. For more information, see this article: http://www.isode.com/whitepapers/xmpp-pubsub.html
deployment methods...
XMPP user - connects as a normal user and responds to requests addressed to the user
XMPP Server plugins - deployed as part of the server plugin architecture
XMPP Components - service external to an XMPP server that connects and behaves like a plugin
Java Integration
Smack API - A pure Java library, it can be embedded into your applications to create anything from a full XMPP client to simple XMPP integrations such as sending notification messages and presence-enabling devices.
Camel XMPP - A Camel component that allows integration with Smack API in Camel routes
To your specific question "can it be used in SOA/middleware?"....
yes, it can be used to wire together applications via XML messaging and XMPP APIs
whether its the best technology choice depends heavily upon requirements
one good use case, interactive system monitoring/management...here are some other examples
Also, XMPP integration with Camel is trivial. See this camel-xmpp unit test for a basic example of interfacing with a Google Talk server. Also, Camel's framework allows you to build an application and easily swap out different messaging technologies (JMS, STOMP, mina, etc).

I can start combining information from al kinds of sources found on the internet using Google (keywords: XMPP Java MoM examples), rewrite (or even copy) the definition of XMPP, but of course I will not do so. There is just too much. I also do not have examples available for you.
Below I will list the links I found most interesting, so you can start reading and get more knowledge on the subject.
1) http://www.xmpp.org/
This is probably the best starting point. Browse through the menu left to right and top to bottom. That is what I did. The site lists servers, clients and libraries, so you should be able to find the desired examples this way.
2) http://www.ibm.com/developerworks/webservices/library/x-xmppintro/index.html
Clear article, which also mentions MoM. No Java examples, but Ruby.
3) http://fyi.oreilly.com/2009/05/what-can-you-do-with-xmpp.html
Maybe you should just get the book? No examples in the article.
4) http://kirkwylie.blogspot.com/2008/07/real-mom-is-hard-lets-use-xmpp.html
Interesting article where the last line basically says: Why use XMPP if you can use AMQP or JMS?
I hope this helps you I finding what you need.

XMPP is an open and extensible standard for real time communications.
XMPP comes with a core that is defined in its rfc, which describes the basic protocol for doing instant messaging and exchanging presence information. However where XMPP really shines is in its extensibility: XMPP defines the building blocks (presence, message and iq stanzas) to create protocols of communication. These typically come as extensions. A list of currently available standard extensions can be found here. The most important of these are typically available for all the popular XMPP servers.
It is exactly this extensibility that makes XMPP appropriate as message-oriented middleware.
Let me take as an example Publish-Subscribe which is a typical pattern for middleware and becomes a necessity as soon as you depart from the scenario with a few entities where simple messaging is adequate. PubSub is used in situations where entities, or producers, produce information that is to be consumed by other entities, the consumers. Typically, the information is written to nodes, to which consumers are subscribed. Being subscribed they receive notifications when an item is added/updated/deleted. An incredible amount of use-cases can be elegantly covered by PubSub, from queuing long-running jobs and having workers handle them, to micro-blogging. XMPP has a very robust and widely available extension to handle PubSub in a standard way, described in XEP-0060 and providing out of the box a workflow for handling publishing, subscriptions, notifications and security. Having a look at the use-cases in the XEP will give you an idea for the simplicity of the whole thing.
Now, while most use-cases are covered by using (or abusing) existing standard extensions, eventually you might need the little extra custom protocol that is not covered elsewhere. Using your language of choice you can write an XMPP component defining your own protocol. You then connect the component to the XMPP server you are running and by using simple namespacing let the server know what kind of messages you can handle and let the server advertise your protocol capabilities to clients connecting to it. There is no end to how simple or complex you can make this. Lack of better example but maybe good enough for illustration, here is a component I wrote that leverages XMPP to do real-time collaborative editing in the Plone CMS (similar to Google docs). While the details can get complicated I think having a look at the "Protocol Specication" on that page will give you an idea.
Finally, concerning Java specific libraries as #boday mentions, there are libraries around that make it easy to start with as well as Apache Camel integration (although it only does simple messaging as far as I can see). Keep in mind though that the investment in understanding how XMPP works and being able to go beyond using existing libraries is really worth it and can lead to extremely powerful and yet simple integration.

Let me just give you a good overview of what XMPP is ?
XMPP ( Extensible Messaging and Presence Protocol )
It is a Real time communication protocol.
The first IM service based on XMPP was Jabber.org
One XMPP binding is BOSH. Others include TCP and WebSocket.
BOSH is "Bidirectional-streams Over Synchronous HTTP", a technology for two-way communication over the Hypertext Transfer Protocol (HTTP).
BOSH emulates many of the transport primitives that are familiar from the Transmission Control Protocol (TCP). For applications that
require both "push" and "pull" communications, BOSH is significantly
more bandwidth-efficient and responsive than most other bidirectional
HTTP-based transport protocols and the techniques known as AJAX.
BOSH achieves this efficiency and low latency by long polling.
How does XMPP works?
XMPP achieves low latency by implementing Long polling.
What is Normal Polling and Long Polling ?
NORMAL POLLING:
Consider the old chat apps that used normal polling. Here the top of the graph indicates client side. Bottom indicates server side. Let the timeout be 5 min.
Client asks the server : " Is there any new message for me ?"
Server Responds : "No ! "
After 5 min
Client asks the server : " Is there any new message for me ?"
Server Responds : "No !"
After 1 min
Client Receives a message
After 4 min
Client asks the server : " Is there any new message for me ?"
Server Responds : "Yes! " + message.
LONG POLLING
The top part of the graph is client . Bottom part is server.
Client asks the server : " Is there any new message for me ?"
Server Answers : "No ! But you may soon receive a new message, so let me just hold your client state for 5 min in the server."
After 5 min
Server Responds : "No !"
Client asks the server : " Is there any new message for me ?"
Server Answers : "No ! But you may soon receive a new message, so let me just hold your client state for 5 min in the server."
After 1 min
Client Receives a message
Server Responds : "Yes! " + message.
You can see clearly, how instantaneously the communication happens.
You can read more about XMPP HERE
In case, if you are curious to set up your own XMPP server, read this.

XMPP is fundamentally a protocol for chat room clients to talk to a chat server. Camel does allow you to integrate with XMPP so that you can consume messages from or produce to such a mechanism http://camel.apache.org/xmpp.html
When you start talking business tier, ESB, SOA etc. and MOMs you're probably looking for a messaging mechanism that supports point to point and publish subscribe messaging. You're probably also thinking about things such as guaranteed messaging, high availability, and fine-grained security. You won't get these from a mechanism that reads and writes text messages into a chat server. A messaging platform such as ActiveMQ is likely to be a far better fit.
There are very few instances where I would contemplate using XMPP with integration mechanisms, maybe as a notification mechanism to a dev chat room, or as a duct-tape mechanism for controlling servers that monitor a chat server for instructions.

An event delivery library in Java?

I'm looking for a library that will allow me to deliver simple text events from the server to the clients via sockets. Something simple and lightweight. I can write it myself, but decided to check if such thing exists first. The idea is that there's an application that generates events (such as order rejected or an internal error occurred) and acts as a server. Those events must be delivered to all connected clients in real-time. And a client is just a tray-icon app that pop ups the said event's text. Some simple UDP client/server. Does anyone know if there's a library out there for Java?
Thanks!

There are many possible solutions, but if you want simple I suggest you try Hazelcast
It is as simple as using java.util.{Queue, Set, List, Map}. Just add the hazelcast.jar into your classpath and start coding.

This could be easily accomplished with XMPP pubsub. You can use Smack to connect to the server of your choice that supports pubsub (OpenFire, ejabberd, ...) so your application that creates the events is the publisher and the clients are all subscribers. It will require a 3rd party server to be used (many are open source), but it is just a single library for all client access. I have experience with OpenFire and it can be set up in about 15 minutes.
Many will not consider this light weight, but rolling your own pubsub solution is really not necessary.

You should check out JBoss Netty and/or Apache MINA, which are both frameworks for building network protocols. It's debatable whether you consider them simple, although you can certainly build lightweight implementations with them.

XMPP Client incompabilities

I'm currently working on a project that is building a java-based desktop application to interface with a website. We want to incorporate IM capabilities, so we decided to use XMPP.
The problem is our application has other features, and anyone using another client to connect to our XMPP server will cause problems with our website (e.g. our client will be able to send our messages with a certain message type that the user won't be able to use, but with another client they could send those message types).
Is there anyone to either allow only our client to access the XMPP server or prevent other clients from using certain features? I know this is against the idea of open standards, but we don't want to build a proprietary IM solution from scratch.

You are building a proprietary solution, it just might not be completely from scratch, and that's not necessarily a bad thing. But please don't call it a XMPP service unless you are going to support XMPP clients. You will get the same reaction as you get with a "web site" that requires your proprietary browser.
For features that can be negotiated, look at Feature Negotiation and you might be able to get away with saying your server doesn't have a specific feature to other clients, but secretly supporting it in your own. That won't actually block something from being attempted, so it's pretty poor solution.
You can get instant messaging capabilities without building a desktop application (with all of the platform support headaches that entails). Consider Orbited which can give you the instant messaging interactivity your looking for and would make it much easier to integrate on the server.
And just as a side point, there shouldn't be any messages that cause problems with your web site, any more than there could be a URL that causes it problems, or a query combination, etc.

Not sure of all your requirements, but it sounds like you could probably use the pubsub or pep features of XMPP. These are extensions to XMPP that allow you to create specialized payloads that can be accessed on a user to user level (Personal Eventing Protocol XEP-0163). If it is simply a general notification to everyone who is interested, then PubSub (XEP-0060) may be what you want.
These protocols allow for securing access to the pubsub nodes and will not get affected by the standard chat messages, as they are a different protocol.