Weblog for the AMIS Technology corner
Web
Create simple Java application to post JSON message to CometD Bayeux Channel using Apache HttpClient and Maven style NetBeans project
Jan 20th
The objective discussed in this article is to post messages to a CometD Bayeux Channel with a standalone Java Class – without dependencies on CometD. For example to control from Java the Slideshow introduced in the synchronized Slideshow demo application created using CometD (see previous articles Push based synchronized Slideshow demo application implemented using CometD and jQuery running on Tomcat and Publishing to CometD Bayeux Channel from inside the Oracle Database – PL/SQL based push to CometD Web Client ).
This article describes the creation of a simple Java Class leveraging Apache HttpClient to post HTTP requests (JSON messages) to a CometD Bayeux Channel. The main point is to show working code with the lest dependencies, not an optimal program (it is far from optimal). The article demonstrates how NetBeans and Maven conspire here to make the task as simple as possible. The Maven support in NetBeans allows me to simply create a new Maven style project of (arche)type Java Application.
Publishing to CometD Bayeux Channel from inside the Oracle Database – PL/SQL based push to CometD Web Client
Jan 19th
In recent articles, I have introduced CometD as framework for Server to Client and Client to Client Push: Running CometD 2 examples – locally on Tomcat using Maven and NetBeans http://technology.amis.nl/blog/14709/running-cometd-2-examples-locally-on-tomcat-using-maven-and-netbeans, CometD 2 Java Client Sample – open project in NetBeans based on Maven pom file, modify sources and run Java Based Comet Client (http://technology.amis.nl/blog/14720/cometd-2-java-client-sample-open-project-in-netbeans-based-on-maven-pom-file-modify-sources-and-run-java-based-comet-client) and Push based synchronized Slideshow demo application implemented using CometD and jQuery running on Tomcat (http://technology.amis.nl/blog/14870/push-based-synchronized-slideshow-demo-application-implemented-using-cometd-and-jquery-running-on-tomcat).
CometD allows web clients (or stand alone Java clients) to subscribe to Bayeux channels maintained by the CometD Server (Servlet). These clients can publish messages to the channels and CometD will deliver the messages to all or to selected clients – in a push-fashion. This makes it possible to push messages from the Java server side of a web application to web clients and indirectly to do the same between web clients. One example I have described of applying this technology is the synchronized slideshow: a web page is opened in two or more browsers. When a slide is selected in one of the browsers, the slide is selected in all browsers (because they all subscribed to the channel that a slide selection event was published to).
This article adds another push channel to the overall picture: it describes how the Oracle Database can publish directly to the Bayeux Channels (by posting to the CometD servlet over HTTP) and thereby perform push to the subscribed web clients. Database to browser push – how does that sound?
Stand-alone Java Client for jWebSocket Server – communicating from Java Client to Web Clients and vice versa over WebSockets
Jan 15th
In a previous article, I have discussed the open source jWebSocket Server and a simple installation and configuration (http://technology.amis.nl/blog/14940/first-steps-with-jwebsocket-open-source-java-framework-for-websockets-installation-and-running-samples). Subsequently, I have shown the implementation of a web client for a synchronized Slideshow application, where WebSocket communication is used to perform Client 2 Client push (http://technology.amis.nl/blog/14949/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-jwebsocket-server-the-open-source-java-websocket-server). In a third article I have explained how jWebSocket server can be integrated with a Java application that can start the server and interact with it (http://technology.amis.nl/blog/14973/implementing-a-java-server-side-component-for-jwebsocket-server-for-websocket-interaction-with-web-clients). Finally in this article I demonstrate how a stand alone Java Client can connect to a ‘remote’ jWebSocket server and open WebSocket interactions with it.
The functionality realized in this article is a simple Java application that listens to slide selection events as pushed from the clients to the WebSocket and that also pushes slide change instructions over WebSockets to the clients. After starting the jWebSocket server and opening one or more clients, running the Java Application created in this article will guide all clients through a sequence of slides.
and a few seconds later:
Implementing a Java Server Side component for jWebSocket Server for WebSocket interaction with Web Clients
Jan 14th
In a previous post – http://technology.amis.nl/blog/14949/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-jwebsocket-server-the-open-source-java-websocket-server – I discussed the implementation of the synchronized slideshow application using Web (HTML/JavaScript) clients and jWebSocket as websocket server. In an earlier article, I described the same for the Kaazing WebSocket server – http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway – and both stories are (fortunately) fairly similar. In the Kaazing article I also described a Java based Server Side ‘client’ or ‘WebSocket interaction partner’. In the jWebSocket article, that part was missing and in this article I will rectify that.
This article will describe how a Java application can integrate with jWebSocket server – in fact: start the server from within the Java code -and subsequently register listeners that intercept WebSocket communication from other interaction partners such as Web clients. The Java application can also send messages to specific clients or broadcast to all clients. This article will merely scratch the service by describing how a simple Java application interacting in this way with jWebSocket server can be created in NetBeans 7.
Finding the information to achieve this was not very easy by the way. And finding out how a stand alone Java application can connect to a stand alone (separately running) jWebSocket server is still slightly beyond my reach.
Push-based synchronized slideshow web application – implemented using WebSockets and jWebSocket server – the open source Java WebSocket server
Jan 13th
In a recent article, I have introduced jWebSocket – an open source Java based server for WebSocket communication: http://technology.amis.nl/blog/14940/first-steps-with-jwebsocket-open-source-java-framework-for-websockets-installation-and-running-samples. In this article, I have described how to download and install the jWebSocket server and how to get going with running some of the distributed samples.
In another recent article, I looked at the implementation of a slideshow application where multiple web clients are mutually synchronized using WebSocket based communication using the Kaazing commercial Web Socket Gateway: http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway.
In this article, I will implement that same Slideshow application as with Kaazing, this time using the jWebSocket server as my underlying WebSocket infrastructure. It turns out that no server side configuration is required for this initial, somewhat naive implementation that does not use a specific channel but simply has all clients of the jWebSocket server participate in the communication. A more advanced set up would undoubtedly use some way to ensure that only interested parties connected to a specific web socket or channel would actually receive the slide selection events. As it stands, the implementation is quite straightforward – based on the file presenter.htm shipped with the jWebSocket Client Samples (directory demos\slideshow).
The result will look like this – just like it looked with both cometd and with Kaazing:
First steps with jWebSocket – open source Java framework for WebSockets – installation and running samples
Jan 12th
This month, In have been delving into Push architectures for the Web, looking into WebSockets among several other things. WebSockets, a fairly new standard (!) evolved along with HTML 5, specifies a communication protocol that provides an alternative to classic HTTP communication. WebSocket based interaction has lower overhead and – more importantly – is bi-directional which means that push from server to client is really supported (and not just emulated through poll, long poll or streaming responses as is currently the case in comet push style frameworks).
All modern browsers provide support for the WebSocket specification – meaning they can communicate based on the WebSocket protocol (ws:// and wss:// in addition to http:// and https://) and they implement the WebSocket client side (JavaScript) APIs. These API are well defined – http://dev.w3.org/html5/websockets/ – and seem to be truly standard across all browsers.
The WebSocket server side is at this moment not very well defined. Other than the fact that the communication over ws:// and wss:// should be handled by a server, not much has been decided about the server side of WebSockets. Currently, WebSockets is not supported in classic JEE servers although such support seems imminent with JEE 7 through the Servlet 3.1 specification (JSR 340, http://jcp.org/en/jsr/summary?id=340; also read http://antwerkz.com/websockets-and-java-ee/ on how WebSockets my be included in the Servlet API). Initial support for WebSockets has been shown in Jetty and GlassFish, with other JEE containers undoubtedly following suit in next 18 months or so. In the meanwhile, several stand alone WebSocket servers have been released, including Kaazing (a commercial offering which I mentioned in two earlier articles: http://technology.amis.nl/blog/14755/get-going-with-kaazing-websocket-gateway-html5-edition-installing-locally-and-running-demos and http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway) and jWebSocket (an open source offering – http://jwebsocket.org/), that I will introduce in this article.
These WebSocket servers are capable of handling WebSocket interaction with a variety of clients – well, the server should not have to care about the type of client but only about the communication. How the WebSocket server should relay WebSocket messages received from a client to a back end service is not well defined, at least not in a standardized way. Vice versa: how back end services can deliver their push messages and events – chat message, JMS message, mail reception, RSS entry, Tweet, database update, business event … – to the WebSocket server for onward routing to interested clients is not covered by an existing standard either. Even integration of WebSocket interaction into regular JEE Web Applications is very much in question. Kaazing spokesmen even suggested that perhaps WebSocket communication provides the foundation for a whole new type of application in which traditional JEE application servers are no longer needed (see: http://www.businesswire.com/news/home/20111019005426/en).
Well, before going to deep into these discussions, let’s take a look at how we can get the jWebSocket server going to at least run a few demo application on our local machine (or at least my local environment).
Push based synchronized Slideshow demo application implemented using CometD and jQuery running on Tomcat
Jan 9th
In a string of recent articles, I have discussed downloading, installing and running demos for a number of different tools, frameworks and libraries that support push-style (web) applications in one way or another. I have looked into ‘classic’ comet with Grizzly, Atmosphere and CometD as well as ADF Active Data Service and WebLogic Pub/Sub (Bayeux) Channels. I have also looked to WebSockets with jWebSocket, again Atmosphere and CometD and also with Kaazing. I am now working on a series of articles in which I use each of these frameworks and push infrastructures to implement the same simple push-style application – to see how that goes and to compare the various implementations. The functionality I will be implementing is simple:
- through the web client (HTML 5/javaScript), a user can select an image from a list of ’slides’
- the selection of the image is communicated to the server (background WebSocket based or alternatively regular AJAX)Comet (Bayeux)/Long Poll style)
- the server informs all connected clients about the selected image through a pushed message (background WebSocket based or alternatively Comet (Bayeux)/Long Poll style); these clients all synchronize that slide selection
- a Java (server side) component can also connect to the server and listen in to image selection events as well as publish image selection messages of its own
The first article discussed the implementation using WebSockets and Kaazing Gateway (http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway). In this article, I will present an implementation using the CometD framework.
Get going with Kaazing WebSocket Gateway – HTML5 Edition – installing locally and running demos
Jan 8th
My last few articles on this blog site have all dealt with push architecture and technology in some way. This is an area that I have been investigating into quite bit recently. Part of these investigations had to be of course Kaazing, a specialized commercial offering, specifcally around WebSockets and its application in new HTML 5 application architectures.
Kaazing suggests a new way of implementing multi-tier (web) applications.
Communication between client and back end services happens over WebSockets. The Kaazing Gateway handles all WebSockets communication, turning messages from various back end services based on technologies such RSS, XMPP, JMS into WebSocket events.
Kaazing supports a variety of clients – though HTML 5 (JavaScript) web clients (including those running on mobile devices) are probably the most prominent ones.
Push-based synchronized slideshow web application – implemented using WebSockets and Kaazing WebSocket Gateway
Jan 7th
In the last few articles, I have discussed downloading, installing and running demos for a number of different tools, frameworks and libraries that support push-style (web) applications in one way or another. I have looked into ‘classic’ comet with Grizzly, Atmosphere and CometD as well as ADF Active Data Service and WebLogic Pub/Sub (Bayeux) Channels. I have also looked to WebSockets with jWebSocket, again Atmosphere and CometD and also with Kaazing. I intend to now take a closer look at some of these frameworks, by taking a simple push-style application and implementing it using each of these frameworks. The functionality I will be implementing is simple:
-
through the web client (HTML 5/javaScript), a user can select an image from a list of ’slides’
-
the selection of the image is communicated to the server (background WebSocket based or alternatively regular AJAX)Comet (Bayeux)/Long Poll style)
-
the server informs all connected clients about the selected image through a pushed message (background WebSocket based or alternatively Comet (Bayeux)/Long Poll style); these clients all synchronize that slide selection
-
a Java (server side) component can also connect to the server and listen in to image selection events as well as publish image selection messages of its own
-
bonus: it may also broadcast ‘new image available’ events to allow the web clients to update the list of images presented to the user
In this article, I will present an implementation using the Kaazing WebSocket Gateway. The application parts that I created or configured are a static HTML page with some JavaScript elements, the Kaazing gateway-config.xml file and a single Java Class. Maybe 50 lines of code in total, to get a fully operaional push style WebSocket application. Not a bad start for this series. Note: I would like to thank Matthias Wessendorf from Kaazing for his help.
First experiences and getting started with GlassFish 3.1 and NetBeans 7.x – it’s a breeze
Dec 31st
Several years back, AMIS selected GlassFish as its preferred Open Source J(2)EE Application Server, over for example JBoss. Some of the criteria at the time were: speed of implementation of new functionality and integration of JEE (being the reference implementatoin), ease of administration, enterprise quality, small yet rapidly growing market share (the band wagon to hop onto). The fact that now GlassFish is under Oracle’s wings and heavily invested into has further underlined our selection.
During these past few years, I have not had a lot of hands-on experience working with GlassFish. Apart from attending sessions and HOLs (hands-on labs) at JavaOne, reading articles on internet and in general staying updated on the developments around GlassFish, unlike some of my colleagues at AMIS I did not touch the software myself.
Today that changed. I had some time on my hands, an interest in working with WebSocket support in GlassFish and a desire to finally work on the product for myself. This article is a report on my first steps. What I had to do in order to get my first web application running after getting hold of the software and installing the product. It is short and very straightforward, as it is dead-easy to get started. I really like that!
So based on my experiences, I can only recommend that you give it a spin yourself. It should not take you longer than 45 minutes to get GlassFish 3.1 set up, along with NetBeans 7.x, and start a sample web application as well as create and run your own web application.
