Well, I have once again been privileged enough to attend the J-Fall 2014 on Wednesday, the 5th of November, in Nijkerk, the Netherlands.
I'll provide a short summary of the Breakout Sessions I followed, and the parts that really struck me as interesting. There's more information on the sessions available at [1].
My chosen schedule:
Keynotes
Bert Ertman, after 10 years at the NLJUG, has decided to step back and become a regular attendee of J-Fall. He is the most visible of the people behind J-Fall, as he has opened J-Fall, to the best of my knowledge, every year. Let us hope we shall see more of him and not less.
The Keynotes were not actually that interesting. The Keynote of Oracle was more related to awards for proven Java-ness, than what Oracle has planned for the future. The keynote of Oracle was provided by James Weaver, who was also giving a Session last year regarding JavaFX and guitar playing.
The Keynote of ING was surprisingly similar to last year, regarding the banks new way of working with software releases (Agile, Scrum, three releases every week, automated testing, DevOps, etc.)
The Keynote of Salves was interesting, in that it had a high geek-techy-factor, with drones flying, and brainwaves to control them, with pattern recognition in cameras. But the complexity of the setup, and the conference location and
The Dreaded Demo Effect got to 'em, which is a shame.
I found the best Keynote to be the one provided by Quintor, a consultancy business started in 2005, regarding a simulated Cluster with Hadoop they set up during one of their "Summer Camps" to brute-force a Shortest Path Algorithm. They needed some penguins to find an igloo between ice blocks and rocks. They created "Willem", a server that was running 20 or so virtual environments, chained in a Hadoop cluster with Apache HBase as work memory and Akka Reactive Streams.
The Sessions
Event-sourced architectures with Akka
A great number of projects are always based around the idea of
Shared Mutable State. This shared mutable state makes things very hard to scale, so it has traditionally been pushed to the database as far as possible. Stateless code always scales better, because it can be easily run parallel.
It seems to me that event-sourcing is basically based on the database transactionlog that has been in Databases for the past hundreds of years.
The idea is that we store the events that happened, instead of storing only the changes of data. In the latter case we lose a lot of history. In order to keep the side effects out of the way when replaying the event log, these are not re-done.
A simple example is, instead of storing Price and Orders, we store events like PriceChanged or OrderCancelled.
Of course, this presents problems as you have to rerun the event log in order to find out the current situation of the system. This is solved by creating snapshots.
Another problem is the fact that Searching for stuff becomes harder. So it makes sense to have basically two different modules, one module is responsible for changes (and stores events and the likes) and one module is responsible for querying and searching (and searches, for example, over Snapshots).
The abbreviation concerning this is called CQRS, Command Query Responsibility Segregation
2. Here the command model is the eventstore (the "journal") and the query model can have several data stores, each containing for example snapshots.
It is possible to have the module that stores events present hooks to the searchmodule to keep the segregated models synchronised.
Some software that is used for the event model and storage of events are:
- Cassandra
- Kafka
- DynamoDB
- MongoDB
- HBase
- HBase
- MapDB
- JDBC
We can use Java Serialization, the default, or specific implementations of Java Serialization for example Protobuf, Kryo, Avro.
Akka can be used for all this, it provides a new experimental persistence module called appropriately Akka Persistence, that uses event sourcing.
Code can be found on github at
https://github.com/sandermak/akka-eventsourcing. The url provided by Sander was
http://bit.ly/akka-es, convenient for if the source moves.
One of the advantages, are that events show the business processes a lot better than normal persisted objects do. With events it is much more clear
what is happening.
Conclusion is that event sourcing is very applicable to Domain Driven Design.
A word on versioning, a change in event-structure is going to cause a problem for the history (which uses the old event-structure). There are several solutions for this:
- don't change your event structure (which, likely isn't possible)
- use both old and new event-structure at the same time (which, introduces legacy code that needs to be maintained)
- change ALL your events, also the historical ones (which, from a purity standpoint is debatable)
- create a snapshot of the historical (old) events, and continue using new events henceforth (losing a bit of history)
I rated this as the best Session of the day!
Reactive programming with Java 8 and Java EE 7
Most of our programming is run sequentially, which, with the current advent of multiple cores, becomes inefficient (they say).
In Java 7 "Futures" were introduced to take care of doing things in parallel using ThreadPools.
A Future is a placeholder for a value that hasn't been set yet, but will (hopefully) be set in the future.
The Java API for Futures is very extensive with a lot of different classes containing a lot of different methods. In the future (my, was that a pun?) there might well come to the front a framework that abstracts away a lot of the nitty-gritty of this highly detailed API. Where the other sessions were light on the amount of code, this one more than made up for them.
Some codepoints:
- ForkJoinPool.commonPool() => suited to the number of cores the JVM is running on.
- Callable -> interface, provides a task to perform.
- ManagedExecutorService -> for externally configurated threadpools for example in an application server like Glassfish. It is a part of JEE 7.
- CompletableFuture -> takes care of Promise Pipelining. These may trigger actions.
The example provided was regarding Customer data, Contract data of that customer, and Communication data of that customer.
Modelling the flow (probably in a flow model) helps a lot, as you lose a lot of visibility on what the code is actually doing.
You tend to define/plan everything up front, with Futures, and then you start the ball rolling, so to speak, with the last call in the chain.
JAXRS 2.0 has the possibility to perform REST services Asynchronously. This can be done, using:
public void retrieve(@Suspended AsyncResponse response, ...
{
response.resume...
}
HTTP connections are released during requests, this will lead to much better scalability. (HTTP threads can be re-pooled)
His source is on github at
martijnblankestijn/reactive-rest-demo.
One diagram that basically says it all, where green is retrieval of customer information, and red and purple are contract data and communication data respectively of said customer:
Modularity and Domain Driven Design : a killer combination?
The idea of this session was to be serious about the standard software design pattern
Separation of Concerns, where you have Loose Coupling and High Cohesion.
The reason why, is that the Cost of A Change should be predictable, and should not result in slowly escalating costs, regarding lost/unattainable deadlines or high maintenance.
The way to do this is with Functional Modularisation, because a functional change should only impact that functional module.
There should be few hard connections between domains, for example no Foreign Keys or the like.
There should be no query between modules, which is a problem when you wish to do some serious Search Queries. A query between modules and across several modules, causes these modules to be tightly coupled.
So, in other words, cross module searches should be postponed as long as possible.
When this isn't possible, you could use CQRS, Command Query Responsibility Segregation.
Elasticsearch can be used to do the searching.
All the modules can be queried individually by the SearchModule, and the SearchModule uses elasticsearch.
Hand-on-Labs: Hands-on with Java 8
This was fairly interesting. They decided on providing a lab on several features in Java 8: the Lambdas (of course), and the new DateTime API.
I've managed to nick their Lab and plan on practicing more of the assignments at home (there wasn't enough time for me at the conference, there were quite many of them).
Microservices: the how and why?
Unfortunately, this was a bit of a miss. I am stuck with no clear idea of what Microservices are exactly, but it seems to follow quite closely in the footsteps of the Session on Modularity.
Here are some book titles mentioned:
- Domain Driven Design4 - Erik Evens
- Release It!5 - Michael T. Nygard
- Antifragile6 - Nassim Nicholas Taleb
Characteristics of Micro services:
- small (1000 lines of code)
- do one thing, and do it well (Unix philosophy)
- independent
- language agnostic communication
- highly decoupled
Conway's Law
3: organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
Basically what this means is that, for example, if you have three teams, one for the UI, one for the Middleware, and one for the database, you end up with a software product that uses a UI, a Middleware and a Database. If the entire team works on ONE microservice, you get the absolute best product. It also means you cannot have a standard team. It is SOA (Service Oriented Architecture) done right.
Missed Sessions
I was planning on visiting
Hot migration of JSF to cool SPA with smart hacks, but somehow that fell through.
Unfortunately, at the end of all that it was 17:00 hours, and I was Conference-tired, so I decided to skip
Using Docker to Develop, Test and Run Maven projects.
Conclusion
J-Fall always provides an excellent glimpse in what the Software Community (at that current time) feels is most important in sharing with their colleagues.
The main conclusion that I can take away from this J-Fall is that somehow a number of the Sessions was regarding a Separation of Concerns in one way or another (either by an event log, or modules, or micro services, or you-name-it). I heard the term CQRS more than once. Perhaps its importance is felt more and more now that the entire world is getting wired and complexity and unlikely combinations of projects is growing at a rapid rate. (Internet-of-Things anyone?)
References
- [1] NLJUG - J-Fall 2014
- http://www.nljug.org/jfall/2014/
- [2] Martin Fowler - CQRS
- http://martinfowler.com/bliki/CQRS.html
- [3] Wikipedia - Conway's Law
- http://en.wikipedia.org/wiki/Conway%27s_law
- [4] Domain Driven Design
- Erik Evens
- [5] Release It!
- Michael T. Nygard
- [6] Antifragile
- Nassim Nicholas Taleb
- ElasticSearch
- http://www.elasticsearch.org/
