It’s time again: The ConSol gang is coming back to Antwerp. And again,
we are presenting you our Devoxx impressions fresh from the movie
theaters. As last year, two of use (Georgi and Roland) went ahead
wereas the rest of us (Olaf, Kathrin, Christoph and Torsten) will join
us on Wednesday.
Monday and Tuesday are traditionally the days for the University talks
with in-depth coverage of certain topics.
# Modular Architecture Today by Kirk Knoernschild (roland)
Kirk started with in a detailed introduction, why modularity
matters. A module system provides a runtime environment for
modules. In Java, the unit of modularity is the JAR File.
When designing apps, two competing forces: Flexibility and
Complexity. The more flexible a system is, ther more complex it
become. Although modularity adds to this complexity it helps in
maintance over time, which traditionally gets harder and harder
otherwise.
Since Kirk is known for his excellent book Modularity Pattern
(highly recommended!), he briefly describes five different
categories of modularity pattern, describing some of
them. Unfortunately he walked very quick through this list.
He emphasises that it is not only important to think not only about
class design, but also about package and, even more module design,
since modularity increases architectural agility.
To summarize the first part before the break, Kirk does quite some
evangelizing in order to make modularisation an essential part of
every enterprise architecture. He is also emphasize the possibility,
that with a rigorous module system, a very high level of flexibility
can be reached. But frankly, is this extreme level of flexibility is
really required in reality ? How often do you exchange the persistence
layer of an existing application ? And if the answer is ‘never in my
career’, are you still willing to pay the price of this extreme
flexibility ?
From my experience when we tried to build an enterprise application
purely based on OSGi modules one year ago (resulting in 60+ bundles),
we ended up switching back to plain WAR deployment (but still keeping
modularity on the build level via Maven modules). Why ? There are two
reasons: First, many dependent libraries like mail.jar or
activation.jar don’t play well in the OSGi world, because of the way
how they look up other classes (we ended up to patch them all). Next,
release management was quite a disaster: How to deploy 60 bundles as a
single release ? Nowadays, Aries and friends could probably help, but
I don’t know. Unfortunately there was no discussion about this
installation hell. I think there is an answer outside for this
essential problem.
Also, what I really missed, was mentioning that there is intrinsic
module support by certain build systems. All examples where done with
ant and handmade target and setup of the classpath. But yes, you
might hate it, but there is something like Maven (or even
Gradle). Having maven for modelling modules declaratively is not only
‘syntactic sugar’ but it helps enormously in setting up IDEs properly
in order to avoid ‘accidental code completion’ violating conceptual
module boundaries as it happens when not using modules at all. Custom
ant builds can’t provide this help. Even if you don’t use a modular
runtime system, using a build system supporting modularity during
compile time is a good thing.
Then Kirk shows examples how to modularize a monolithic
sample application step-by-step into a modular application. First
everything is deployed in a single WAR file, including classes with
bidirectional relationships. Then, step by step and with the help of
abstractions he modularizes this war into multiple, hierarchical
dependent modules/jars.
After the break, in the second part of the talk Kirk introduces OSGi
as a runtime platform for running modules directly instead of being
packaged in an all-in-one war.
The second part was not much more than a basic introduction into OSGi
with uServices and OSGi Blueprint. A lot of repetitions here, leaving
somewhat the impression that Kirk was runing out content near the end
of the talk.
All in all, the talk was very well presented by giving a basic
introduction into modularity and OSGi. I hoped to hear a bit more
about concrete patterns as described in his book, but
well. Nevertheless it was good start into this week.
My main takeway, which I have put in my ammunition dump:
Conceptual modularity without physical modularity is nearly always
flawed because of subtle dependencies creeping in inevitably over
time.
NoSQLUnit is a test framework for testing NoSQL databases. Unit Test
should follow the FIRST principles (Fast, Isolated, Repeatable,
Self-Validated, Timely). Isolation is most often not possible, when
testing with database. For relational databases there already exist
various solutions, for NoSQL database NoSQLUnit was invented.
NoSQLUnit consists of two Junit Rules and two annotations:
@UsingDataSet for seeding contents@ShouldMatchDataSet for verifying contentsNoSQLUnit supports redis, mongoDB, Neo4j, Cassandra and HBase.
For each DB there exist two or more JUnit rules.
Two demos demonstrate how easy it is to write a unit test, in this
case for Redis and Neo4J. NoSQLUnit has also support for Spring Data.
Finally NoSQL is also usable for testing DBs provided as PaaS in
various clouds. In a demo it is shown, how a MongoDB in OpenShift is
easily accessed from within NoSQLUnit.
For the future, more databases will be supported and integration
into more build systems and testing frameworks.
The talks was very well structured and despite having only 30 minutes,
Alex managed to give a very good introduction in writing tests for
NoSQL databases.
Beside that I didn’t know NoSQLUnit (which was obvious why I attended
this talk ;-), JUnit Rules themselves where also new for me. Time to
revisit JUnit again, after doing tests exclusively with
TestNG for quite some time.
After a short introduction to CDI and OSGi, Weld-OSGi was
introduced. It provides a CDI programming model for OSGi, hiding all
the nifty details of OSGi service handling. This is done by exposing
CDI beans as OSGi services.
Weld-OSGi is implemented as an CDI extension and provides a handful of
new annotations: @Publish tells the CDI container to register an
OSGi service. Services can also be registered programmatically. The
consumer of an OSGi services uses @OSGiService for getting to the
service. This annotation is evaluated only during startup. In order to
get all services during runtime, a list of services can be
injected. Also @Filter can be used with an OSGi filter in order to
get a specific implementation. Alternatively, this can be nicely done
with CDI qualifiers which gets translated to OSGi filters for the
publisher as well as for the consumer.
OSGi events can be observed with the CDI @Observes annotation. Events
can be filtered with @BundleName or @BundleVersion. Service Events can
be observed as well and restricted with @Specification and/or
@Filter.
“Inter-bundle events” is a Weld-OSGi specific feature for broadcasting
events among multiple bundles. Listeners for events use the @Observer
CDI annotation for registering for certain InterBundleEvents.
The demo was very well crafted demonstrating all features with a nice
demo app (and someone finally was not stating um, you see, I’m
not a Web designer .. when presenting his web based demo. Thank you,
Bootstrap ;-)
Weld-OSGi looks quite similar to Spring Dynamic Modules, with Spring
injection replaced by CDI. However, as the programming model of CDI is
very elegant, Weld-OSGi fits very nicely into this space with its own
annotations. Very well done, Weld-OSGi will definitely in my toolbox
for my next OSGi based project.
CRaSH is a CLI shell framework. It has a similar client interface
like a Unix shell (history, completion, command line editing, pipes,
…), but is hosted by a JVM instead of the OS.
CRaSH can be emmbedded or can be run out of the box. It can even run
in a browser or attach to an existing process.
The demo was very impressive. I.e. you can connect to a running JBoss
(or supposedly any other JEE server), examine the deployed datasource
and connect to the DB via these datasources directly. So, no need for
an external SQL client anymore for examing and manipulating the
database on production systems !
JPA can be examined as well, and JPA queries can be executed from
within the Shell.
Next, it was shown how to embedd the shell in own applications. This
will open a telnet port which can be used for a remote
shell. (However, I wonder how this communication can be secured beside
user and password transported as plain text, SSH should probably also
possible).
For monitoring purposes, a VisualVM plugin exists. This plugins opens
the shell within VisualVM, which can use some quite simple JMX related
commands. JMX commands can be chained in pipelines. What I’m missing
here a bit is a help in navigating the JMX namespace as j4psh
does.
Version 1.2 will offer a dashboard with custom defined commands with
Groovy. Cool demo !
To summarize, this quite packed session was really impressive. Since
up to now I sticked to something different than Java when writing a
shell (j4psh or osgish). Now I’m currently seriously
considering CRaSH for an Java based implementation, especially because
I hope to be able to embedd it into a single jar file which is a huge
advantage compared to the installation marathon when it comes to Perl
modules.
It is my first Devoxx and i was and i am still pretty exited about
it. There were a lot of talks today, some of them were really
good. And i have to say, that i do not regret my decision to attend
not just the conference but also the Devoxx university days. The
first talk I want to talk about was about the new black, HTML5.
This talk was about mobile web development with HTML5 and JavaScript.
O’Reilly has shortly released a new book about
HTML5 by Wesley
Hales. In this talk he has introduced the new important ‘mobile’
features in HTML5 and has tried to pass on his experience with UI
mobile development. The interest on the topic was quite big and the
room was really full. Fortunately we have got some seats and didn’t
need to spend the next three hours seating on the stairs :)
The first part of the talk was about the importance of the web apps
for mobile devices and about the mobile browser. Wesley has tried to
point out what have to be taken in consideration when starting
developing a mobile web app. Here are some of the points:
HTML5 and W3C APIs have been introduced
‘One billion html5 capable mobiles will be sold in 2013’. And with all
this new ‘mobile’ features introduced within html5 you could develop
web apps which are competitive with native apps.
Wesley has demonstrated
slidfast.js, which is a
learning framework created for his book. This example shows that page
transition (in particular sliding) on the mobile device implemented
with css and javascripts feels almost like native sliding. For the
fast sliding the CSS3 accelerator has been used. The 360 degree flip
on the contact page of the test app has been implemented only with
css. You can test
it
on your own :)
‘mobile web is not write once run anywhere’ - i don’t think that a web
developer has expected something else here :)
Some other html5 features has been introduced like
Almost the whole second part was about HTML5 and W3C APIs and
demonstrating how they are working
The third part was not so long, it took just 15 minutes. It was about performance in the browser and a comparison between Client and Server UI. Here are some of the pros and cons of client side generation.
There were also some interesting examples about optimizing web apps
such as: “CNN removed jquery and protoaculous from concatenation and
added to cdn => improved site performance by 17% and reduced almost
1TB of bandwidth per day” - really impressive
At the end there was a really cool demo with
loadreport.js. “This handy
little script uses phantomjs to build a report of DOM and resource
load times. The reports are created one-at-a-time to deliver the most
accurate results - that’s why it takes a few seconds.” Loadreport
also generates a filmstrip, a bunch of png files, which are
illustrating the loading behavior of the tested web
page. Loadreport.js could be quite useful.
Since my last summary about HTML 5 has become quite long, i will try to keep this short :)
The question is: Why yet another stress test tool if there are already
so much such as JMeter, JCrawler, Siege, LoadUI, etc.?
The intention behind implementing a new stress tool was, that the
current available test tools didn’t meet the needs of the
Gatling-Developers due to
Here are some of the features of Gatling
Gatling is written in Scala. It is based on the Akka-Framework. It has no GUI.
It comes with a custom DSL based on Scala, which provides
Gatling is extendable and provides an expresion language. It also
provides a Recorder, which acts as a proxy to record the https
requests. It helps writing scenarios for Gatling. The recorder comes
with a GUI. It generates scala code which can be modified and reused
later. There is also a maven plugin available for it. The project
website is looking quite informative and i think it is worth trying
it.