/seda-proto

Simple application proto with HTML client, WebSockets communication, and Java server side application. Server handles incoming messages in serialized fashion and broadcasts results.

Primary LanguageJavaMIT LicenseMIT

Purpose

Simple client-server application prototype. Build with asynchronous messaging, serialized message processing and staged event-driven architecture (SEDA) principles. It combines few technologies I have researched recently, like html5, websockets, Disruptor, and so on. Purpose is to help me remember later what I have learned.

Typical data flow

Html Client sends message (JSON)        All Clients receive message
  |                                         ^
  v                                         |
Data transfer (WebSocket)               Data transfer
  |                                         ^
  v                                         |
Server Api layer (Jetty)                Server Api layer
  |                                         ^
  v                                         |
Queue in (Disruptor) -> Data storage -> Queue out

Running instructions

Program

  1. Go to root folder
  • type "mvn clean install exec:exec"
  • open web browser at localhost:8080
  • click "Connect"
  • write some values to push fields and click "Send"

Source code analysis

  1. mvn clean site
  • open target/site/index.html in browser
  • Check Project Reports from bottom left link div.

Metadata

Some requirements

  • Client-server architechture, multiple clients and one server, with some simple functionality, like storing key-value pairs.
  • Server must handle requests with FIFO principle, request order must not change.
  • Clients must get information of changed state on server at the same time.
  • Provide believable try for good performance.

Technology selections

Public API

WebSockets as protocol between client and server. It makes asyncronous message delivery possible and works with modern browsers, which is nice.

  • Alt: HTTP polling with long timeout? Probably not as efficient. Kind of kludge.
  • Alt: ZeroMQ? Interesting, but hard to make work in web browsers.
  • Alt: RabbitMQ? Hard to make work in web browsers, needs dedicated server app.
  • Alt: SPDY? Not enough knowledge to say anything.

JSON as message format between client and server. Works well enough, especially with web browsers.

  • Alt: XML? Could work. Bigger msg size than JSON and unwelcome complexity with namespaces etc.
  • Alt: Google Protobuf? Interesting, but hard to make work in web browsers.
  • Alt: Apache Thrift? Might work, but wants to mess with protocol layer too, documentation lacking.
  • Alt: Apache avro? Does anybody use this?

Client Application

HTML5 and Javascript with some selected libraries. Easy and fast to build PoC.

  • Alt: Java Swing or JavaFX Client? Binary blobs are so old school. OTOH, would make other protocols and message formats possible.

JQuery for some random Javascript tasks.

  • Alt: AngularJS, ... no need in simple project.
  • Alt: Google Dart? Interesting, but not relevant.

Twitter Bootstrap 2 for UI elements

  • Alt: Bootstrap 3? Might upgrade to it later

Server Side Application

Standalone Java Application with selected libraries

Maven for building the software

  • Alt: Ant, Ivy,.. I have no interest in learning to use these
  • Alt: Gradle, ... maybe some other day

Guice for wiring different components together.

  • Alt: Wire components by hand? Small simple application, could be done, but using DI is more fun.
  • Alt: Spring? No need for 90% of its features. DI part not as solid as Guice.
  • Alt: CDI? Not really a good solution outside application servers.

Embedded Jetty 9 for WebSocket implementation. Seems to be still somewhat work in progress, with major rewrites even inside version 9.

  • Alt: Java EE 7 compatible application server and its WebSocket support via JSR 356? Don't want to go that way.
  • Alt: Spring Boot. Might work, but I wan't select components myself.

Disruptor 3 for implementing SEDA (queues, stages). Background info in article The LMAX Architecture - Martin Fowler

  • Alt: Multiple ArrayBlockingQueue objects or other Java List objects with self-managed threads. Disruptor has better feeling.

json-simple for handling json. Seems to work. JSON Java side has multiple different solutions, hard to know which would be right.

Javolution for storing queue data in preallocated ByteBuffers to minimize GC. Idea is from this ticketing demo

  • Alt: Store data outside heap blog

Logback and SLF4j for logging purposes. Seems to be the right way ATM.

  • Alt: Log4j 2.x, new interesting stuff, but too little too late? But! "Asynchronous Loggers based on the LMAX Disruptor library". :)