Building Server Monitoring Tools ...and Blogs With Java EE 7 📎
Geoff please introduce yourself
I have been working with Java for 2 years. Before becoming a Java Software Developer, I worked as a Front-end Web Developer for 4 years. I find the two skill sets combined well, particularly when carrying out Web Application development activities.
Currently I work at ReStart Consulting. ReStart Consulting are a software integration company that specializes in Health Care systems. I work within the Java Software development team, where we create distributed software products and software tooling. This is my first Java Software Developer job since graduating from a part-time Computer Science degree. And, when I am not at work I like to tinker with hobby projects.
What are you building with Java EE? Why Java EE?
At work, I created the first iteration of our greenfield server statistics monitoring tool. As it was a greenfield project, I was keen to use Java EE right from the start.
Our greenfield, statistics tool has been a fantastic opportunity to use Java EE and has proven to be a good fit. The tool provides an API for the in-production deployments of our core product to report in with raw data. The tool then turns the data into information and alerts to aid our support staff.
Why Java EE for this project? We needed an enterprise framework to support an enterprise problem. And as this project will only get updated periodically, we need a framework that has a proven record of backwards compatibility so that future updates can benefit from newer versions of Java EE and its features. Thus the risk of the project becoming legacy and prematurely is reduced with Java EE over other Enterprise Frameworks that make breaking changes.
Outside of work, I created my own blog website and my wife's website, both with Java EE 7 (see blog-platform). My blog has been going since 2012 (originally a Joomla website). I decided to do the rebuild with Java EE since I am keen to use Java EE wherever possible. Why Java EE for websites? JSF 2.2 is a fantastic templating engine and easy to use. Java EE also takes care of the plumbing of the backing beans. For example, JSF needs only the name of a RequestScoped bean, hence the developer does none of the plumbing. In both these website projects all the code, when written with Java EE, has emerged as pure business logic.
You mentioned on twitter that the effectivejavaee.com workshop inspired you to delete some code. How much was it?
Yes, I found your Effective EE video course very inspiring. The Effective EE course inspired me to refactor lots of code, in several projects, to use the Entity Control Boundary structural pattern that you have been teaching and talking about. Before, using this structural pattern my code had fallen into the organisation by 'technical function' trap such as having an exceptions package and an interfaces package. Now, the code I have refactored is organised around business names.
How big is your WAR? Which runtime dependencies are you using?
The server statistics monitoring tool has a WAR size of: 10,925 KB and has the following runtime dependencies:
- javaee-web-api
- org.eclipse.persistence.nosql
- rewrite-servlet
- rewrite-config-prettyfaces
- omnifaces
- mongo-java-driver
- joda-time
The front-end of my blog has a WAR size of: 3,331 KB and has the following runtime dependencies:
- javaee-api
- rewrite-servlet
- rewrite-config-prettyfaces
- omnifaces
- commons-lang
It's worth noting that backend of my blog is a separate Java EE project.
In all cases, given here, the CSS, fonts and JavaScript in the Bootstrap distribution are included in the WAR files. I should add the backend of my website has not been refactored yet. I have to admit that, before understanding ECB, I had heard the name and thought I was using it. Since watching your Effective Java EE course and going to your Devoxx Poland Talk, I realised I had just split everything into 3 packages named Entity Control Boundary - woops.
What was the impact of the refactoring on your productivity and deployment times?
After doing the initial work on our server statistics monitoring tool, I had to explain to team members the way the packages had been arranged. Often team members asked questions when they needed to add their own development work. Since refactoring the code to use the ECB pattern, no one has needed to ask me these types of questions. I would say the code base is now user friendly (with developers being the users).
Also, narrowing down where to fix bugs is now super quick because you can easily follow the code execution paths now; mainly because you know where the code in question starts and ends. That is to say: the starting point (the boundary) and the ending point (the boundary) is unambiguous when using the ECB structural pattern.
Do you have any dependencies on server-specific libraries? (e.g. com.something.*)
My blog and my wife's website are free from server-specific libraries. However, our server statistics tool, at work, is using EclipseLink NoSQL. EclipseLink NoSQL let's us use JPA with MongoDB which is super cool, but has the side effect of adding a dependency that is outside of Java EE's spec. This in effect couples the project to any Java EE server that uses EclipseLink.
Which tools, IDEs, and Application servers are you using?
The tools I use are very mainstream: Maven, GIT, JMeter. I like to work with the Netbeans IDE. And for Application servers the projects I been working on are using: Payara, GlassFish, and WildFly.
I am the main pusher for Java EE at work, so I always get given the Application server configuration tasks. I cannot decide what my choice Application server is yet; they are all great. But there is something very enjoyable about getting a WildFly 9 HA domain configured. So, there is a good chance WildFly may become my favourite.
What is your opinion about Java EE?
My first introduction to Java EE was during my undergraduate studies. However, my eyes were opened up to Java EE's power properly during a postgraduate module in Software Development that I studied in 2014. The module introduced many of the modern Java EE 7 APIs. In particular, we covered: JSF, JPA, and JAX-RS, JAX-WS, EJBs, and CDI.
Synthesising what I have learnt then and since: I think Java EE makes the process of software development far more predictable when it comes to outcomes and the time to reach outcomes. Without an enterprise framework teams of developers can waste time, for example, on exploring implementation options or even worse implementing their own frameworks (an expensive deviation). Exploration by nature is far less predictable and thus, difficult to include within the boundaries of an output driven process, such as software development.
With Java EE what would have been exploration time can then be better spent as training time. Java Developer's learning Java EE APIs is also a predictable process in itself. I think the awareness of this power of Java EE to facilitate control over the software development process needs to be more widely known. Once a process becomes predictable, tools from other disciplines can be applied to it such as Functional Point Analysis, Statistical Process Control, etc. Consequently, a team's output can be of a higher quality with a greater yield.
In other words an enterprise framework allows teams to concentrate on the 'what business logic needs implementing' and less on the 'how to do it'. Java EE 7, is a good fit because it's lean, well documented, standards based, and does not make breaking changes (that I am aware of).
Any resources, links (your github, twitter account etc.) and cool stuff you would like to share with us?
Thanks Adam for this opportunity. I would like to share my blog with your readership geoffhayward.eu where I comment on things like Java, IoT and Joomla, my twitter account is twitter.com/GeoffreyHayward and my GitHub page is github.com/GeoffHayward.
I would also like to share my wife's website ewa-hayward.co.uk. I created the website using Java EE behind the scenes so it is a Java EE good example. My wife Ewa is a Certified Translator so if anyone is in the market for the localisation of PL and EN properties files, please feel free to send the work her way.
In the meantime I am off to delete code and be happy.
Geoff, thank you for the interview!