Adam Bien's Weblog

A Java EE Startup: Filtering Information with zeef.com

Arjan, could you please briefly introduce yourself? How did you started with Java SE/EE?

I've been working with computers and programming for a long time. Started on the commodore 64 when I was but a small kid and engaged with programming almost right away. I studied computer science at the University of Leiden, where I specialized in high performance computing.

I "started" with Java around 1997. I think my very first contact with Java was when helping out my sister who studied math at the Free University of Amsterdam. They used Java there. I was more of a C++ programmer at the time, but the syntax was close enough to be able to help.

After that I got curious about this new Java thing and started to look more and more into it. My jobs however were still mostly C++. I did a few applets for my homepage at the university, ported a few games that I made for myself from C++ to Java, and I had one job where I coded a small desktop application using Java, but that was about it.

It wasn't until 2003 that I really deep-dived into Java and started to use it daily at m4n.nl, which was a startup too back then using Java EE. 

Currently I'm a member of both the JSF EG as well as the Security EG.

What is the idea / business case behind zeef.com?

Zeef.com effectively tries to filter the world's information by adding a human element to search. A search engine like Google is of course unparalleled when you're searching for a very specific thing, like say a specific exception. But search engines don't actually say much or anything about the quality of links. Does a certain result appear at the first position of a search result because it's the best one, or just because it had the best SEO applied to it?

This is where zeef comes in. People who are knowledgeable about a certain field and are recognized by their community collect and rank all the best links for a certain subject. For example, Bauke Scholtz (BalusC) is a well known JSF expert and his zeef page at jsf.zeef.com/bauke.scholtz contains all the links for JSF that he thinks are the best ones, organized in blocks.

A distinguishing feature is that you can take those blocks and share them on the web, e.g. put them on your blog or in the side bar of your site. If you re-order the links in that block on your zeef page, these changes will be reflected wherever you shared that block.

A key element is that on zeef no one can exclusively claim a subject. If someone else thinks they can make a better page, or just a page that approaches the same subject from a different angle, they can do that.

What is the zeef.com architecture?

At the highest level we primarily have a server for the website itself, one that runs (overnight) jobs, one for our API, three servers that serve out the widgets and one for the database (PostGreSQL). Static resources, such as images and custom CSS are cached by the Apache frontend servers that proxy these via a separate cookieless domain (zeef.io). These servers are loosely clustered via an Infinispan cluster, which however doesn't send actual data through the cluster but only (async) invalidation messages.

For the implementation we use Java SE 8 and Java EE 7. The application server is WildFly 8.2, which we self-build and patch when needed. We always deploy one application (one archive) to one AS instance. Building a new AS and deploying it to a server is approximately the same process as building the application archive and deploying it.

The application archive we use is the EAR. We contemplated using the simpler WAR format when we started, but a rudimentary layering between business code in the EJB module and web code in the web module, as well as a straightforward conf/ directory in the root of the EAR swayed us to the EAR format.

The frontend is build using JSF, with CDI backing beans and Bean Validation constraints. Where Bean Validation constraints are not convenient we use native JSF validators. 

CDI backing beans are kept as lean as possible and we avoid usage of JSF specific collection types there in favor of standard Java SE collections. Those slim backing beans only collect input from the page and delegate to services which contain the actual business logic. Services are implemented as stateless EJB beans, which makes transactional concerns a breeze. We don't use interfaces for services, nor do we have separate DAOs. EJB beans are injected with JPA entity managers, which handle persistence. JPA entities are kept as slim as possible as well, just data + getters/setters and Bean Validation constraints.

JPA entity managers get their data from an (XA) data source, which we have configured inside the application using the standardized Java EE data-source element in application.xml. Switching between stages is then done using a data source wrapper that reads connection details for the configured stage (which is provided via a -D startup parameter) from the EAR's /conf directory. This switching of data sources and the conf/ directory itself is something we had to hack together though and is something we very much missed in Java EE.

Security of the website is handled via JASPIC and the native security mechanisms of Servlet and EJB. As zeef.com is a standalone application that does not need to integrate with internal enterprise infrastructure it handles its own security. We have two authentication mechanisms, the first is a variant of Servlet FORM, but better suitable for usage with JSF (allows JSF to validate the username/password and provide feedback before authentication is attempted) and one that uses OAuth for authentication (technically, authorization) via providers such as Google and Facebook. Those mechanisms delegate to an identity store, which is implemented as a CDI bean that uses an EJB service and JPA for the actual credential processing and fetching of user details.

The overnight jobs are handled by fairly simple EJB timers. They do things like validating links and precalculation of some of the statistics that you see on the subject pages. Since these jobs run on a separate server it's particularly important that it participates in the same Infinispan cluster that the website is also using.

ZEEF also features a RESTful API, which is implemented by JAX-RS and also runs on a separate server. Here too security is based on JASPIC, but uses a different authentication mechanism; a stateless header based token one. Stateless here means that the result of authentication is not stored in a session per user and not even in a cookie. The client is simply re-authenticated with each request. To keep this reasonably fast an authentication cache is used, which unlike a session can be purged at any time without the client really noticing anything but a small delay when it does the next request. 

The JAX-RS resources are mostly very lean and delegate to the same EJB services that the JSF backing beans are also using. Those EJB beans however are not clustered or remote; each application instance uses its own local instances.

How many developers are working on zeef.com?

We have 3 core developers; Bauke Scholtz, Jan Beernink and myself. Additionally our scrum master and system administrator also do programming and are technically part of the developer team as well, but they obviously don't have an IDE open full time.

Is Java EE productive?

Absolutely! We all know J2EE 1.4 had a name of being heavyweight and unproductive, with its focus on the over-complicated EJB 2 model and at times unintelligible vendor specific configuration for security and data sources, which wasn't just unintelligibly but had a tendency of changing between every release of an implementation. And let's not forget the slow start up times.

Java EE 7 however is for the most part immensely productive. JBoss itself without anything deployed starts up in about a second on our workstations and with the zeef website deployed it's roughly 15 seconds. CDI + EJB are now extremely simple classes with often just a single annotation that gets a lot done. And modern JSF (2.0 and beyond) allows for a programming style that can be very close to the web, but still offers you higher level abstractions when needed.

However, security is a nightmare out of the box. Historically the idea was that you set it up outside of your application at the application server level with vendor specific tools. While this is great for application independent security that covers many different applications, it's a cumbersome and poor fit for our use case. Our saving grace was this small little gem called JASPIC. Without it we wouldn't have been able to stay with Java EE for security. But JASPIC itself is just a low-level hook into the container, so we had to build a lot of higher level functionality on top of it. These struggles are what motivated me to join the Java EE 8 security EG. Hopefully we can make the experience better.

Another thing is that the @Asynchronous annotation lets you do one or more actions concurrently with a minimal amount of effort in a container safe way. This is by itself very productive, but it's unfortunate that there's no support for choosing a specific thread pool. Java EE does have a spec that deals with this (Java EE Concurrency utils), but additional thread pools have to be defined outside the application and they don't work in conjunction with @Asynchronous. 

[Arjan, you should test https://github.com/AdamBien/porcupine/. I'm already curious about your opinion]

Do you have any external dependencies in your WAR? If yes, which purpose do they serve?

We have a couple of external dependencies, not only in the WAR but in the EAR as well.

In the war we use OmniFaces, PrimeFaces and PrettyTime.

OmniFaces is our own library that makes working with JSF a lot easier. It's not a visual component library, but it contains a lot of utilities and API enhancements that could have been in the JSF core as well. In fact, part of our job at the JSF EG is looking at which parts of OmniFaces make sense to be transferred to JSF itself.

PrimeFaces is another essential library when working with JSF. PrimeFaces is in a way what gives JSF the attraction that it has; a great set of beautiful visual components with which you can easily assemble your UI. It must be said though that PrimeFaces couldn't really do what it does if it wasn't for the foundation that JSF provides.

Then we use PegDown for the processing and rendering of Markdown that users can use in our text blocks. JSoup for parsing HTML, ROME for RSS/Atom parsing which is needed for the so-called feed blocks that we display, Image4J, Imgscalr and Batik for handling the images on our site, the Google API client library for interaction with Google analytics and a few other things, Infinispan for explicit caching of various things that are not JPA entities and finally Hibernate Search for powering the site's search functionality.

What about the performance, is Java EE fast enough?

Java EE is incredible fast. The website itself is now doing over 120k views a month and as mentioned above is running on a single server basically, which is not even that powerful.

You occasionally hear that JSF is supposedly not suited for public web sites, since it would be slow and using a lot of memory. We found however that this is absolutely not the case. Leonardo Uribe did some interesting performance benchmarks (see http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html), and JSF came out as one of the fastest that also puts less strain on the GC than some of the other frameworks. Various other benchmarks like the World Wide Wait one came pretty much to the same conclusion. We did some testing of our own as well, and for a very basic page JSF can easily handle 5500 requests/second on a single server (see http://jdevelopment.nl/wildfly-8-benchmarked). In reality you'd not send so many request to one box and more complicated pages with database queries etc will reduce that number of course, but it does give a base line of performance.

The memory issue, specifically the session usage per user, is another source of confusion. Before JSF 2.0 this was indeed enormous, but ever since JSF 2.0 and its partial state saving, the actual amount of state saved is really low. JSF tracks the state and only stores changes instead of everything. Where in extreme cases JSF 1.x would use maybe a megabyte per user, JSF 2.x reduces this to something that's between a few bytes and a few KB.

As far as the UI is concerned, we had some challenges were it concerned the client-side JavaScript. Calling the wrong method there at times could easily introduce large delays in page rendering, sometimes up to a second or more. Changing this to an almost similar method would e.g. prevent a massive amount of events to be fired. Java EE and JSF could also help to speed up things here by making use of things like the OmniFaces' o:deferredScript and combined resource handler.

As in most web applications the database plays an important role in the performance of the site. In case of Java EE there are some concerns when using JPA. 

In an ideal object model, an entity often has references to all other entities it's logically associated with. If the object graph that is formed this way is of non-trivial size an ORM can induce a perform issue if one is not careful. Setting all relations to eager loading means you'll fetch almost the entire DB for every little operation which will destroy your performance, but setting everything to lazy will either give you exceptions all the time because data is not loaded, or will cause many additional small queries to be fired, which also destroys performance. 

The key, as in plain SQL as well, is to fetch just the right amount of data. JPA has some mechanisms to help with this, like fetch graphs, but these are still not optimal. You can for instance specify per query what you want, but you can't say what you DO NOT want (see https://java.net/jira/browse/JPA_SPEC-96). In practice we also found that the interaction between fetch graphs and caching can be weird or sometimes even downright broken. If an entity was cached without fetching relation X, then when using a fetch graph that says X should be loaded, you still get the entity without X.

So our strategy has been to reduce the number of relations between entities to what is strictly necessary, and occasionally to use JPA DTOs when a subset of data is needed for a rather complex entity. Such DTOs are populated using the constructor selector syntax in JPQL queries and JPA is generally smart enough to generate far more optimal queries then. A limitation is that these are limited to single-valued path expressions (e.g. no collections, see https://java.net/jira/browse/JPA_SPEC-69).

Another strategy is to fire a number of queries in parallel. Using the aforementioned @Asynchronous this is rather trivial to do from a backing bean. The returned Futures are then stored and only resolved when a backing bean's property is actually used on the page. Besides doing DB work in parallel, this can give a small performance boost since the DB operation and initial rendering of a page (up till the location where the value is actually needed) can overlap.

What is your favorite IDE?

With some reservations I'd say Eclipse in combination with JBoss tools. I've been using this for a long time, some 12 years now I think.

I do dislike the fact that Eclipse doesn't really seem to be focused anymore on delivering an IDE, but from the outside seem to be more busy with being a platform for anything and an organization for everything. I'd wish they'd just be an IDE and nothing else, and focus on polishing the IDE experience above all.

Would you choose Java EE again?

100% yes!

Do you have any secret ideas for new Java EE startup?

Despite not being that old yet, zeef.com has reached a level where we feel a lot of the functionality is there. We therefor are somewhat starting to think about our next step. Ideas are always welcome, so I'd like to return the question by saying that if anyone has a great idea they can always contact us. No promises though ;)

Arjan, thank you for the interview!

I just "zeefed" Java and found this: https://java.zeef.com/jan.beernink. Enjoy zeefing!


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

Java FX Will Outlive Most Of The JavaScript / CSS Frameworks

Java FX or HTML 5? at jax.de I was interviewed about this topic:

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

Upcoming Java EE / Java / Testing / HTML 5 / Persistence Workshops Talks and Events


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

Java EE 7 on Java 8 Devcrowd.pl Conference Session Video

Playing with Java EE 7 (async JAX-RS, Concurrency Utilities, CDI, EJBs and porcupine) and Java 8 (method handles) at the 2015.devcrowd.pl conference at 19.04.2015:

The sample app and slides are available for download.

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

13th Airhacks.tv Questions and Answers

13th airhacks.tv, or answers for the questions:

Accidentally, I forgot to answer the questions 9 and 10. I will cover them soon, probably in a 13/2 show.

Any questions left? Ask here.

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

A Java EE Startup: Getting Lucky With DreamIt

Norman, could you please introduce yourself?

I am CTO and co-founder of dreamIT where we especially built and keep building up an entire gambling platform for a world-wide lottery provider from scratch. Since then I have accepted several key responsibilities, piling up more than 15 years of experience in the gambling and technology sectors. I worked across many gambling verticals including Sports- and Horse Betting, Casino, and Lottery. Through my career I have worked with many of the (world's) leading gambling operators where I developed and deployed strategies, products and solutions across Europe for both B2B and B2C customers.

Until now I have been improving my skill set continuously - especially in the web, mobile and interactive world to build high-performance, scalable and maintainable - but not over-engineered - solutions. I believe that simplicity of a solution ensures protection of investments for the ever-changing requirements in today's fast-paced world and is one of the most important - but almost underrated - challenge in coding. With deep understanding on both B2C and B2B sides of the Gambling Industry, I was driven by my passion to superior systems, excellent user experience and, of course, innovation in the gambling.

What is dreamIT? What are you building?

dreamit.de is a Hamburg-based software engineering company delivering individual software solutions tailored to very specific clients’ needs. We are focusing on large, transaction-based B2C platforms, and we develop all elements of such tailor-made solutions (database-/back end systems, frontend, mobile (iOS/Android)). We consequently use agile software development methods with short sprints and a continuous deployment approach. We have a strong and proven ability to architect, design, develop, implement and operate SaaS solutions. Our senior architects address typical challenges with proven best practices, which enables us to quickly find the right solution for our clients’ needs.

One of our teams' largest projects so far has been the development of an entire gambling platform for a foreign secondary lottery provider from scratch, following the client's very specific requirements. We helped this client to really identify, articulate and document any technical product specific needs, based on their business needs. Strictly following these customer specifications, we built an entire website-/desktop-/admin tool system that currently processes an 8-digit number of transactions each month.

You started straight with Java EE 6. Are you still happy with this decision?

Yes, we are still happy.

How much traffic (peek e.g transactions per second, concurrent users etc.) your application has to handle?

In the lottery business we tend to have quick surges in user traffic, resulting in big peeks. On high jackpots we get about 4000 to 5000 concurrent users.

What about the performance? Is Java EE fast enough?

Java EE is really fast and solid as a rock. Job applicants often say that they've never seen a faster web site before.

Are you happy with Java EE's productivity?

Java EE is great. It doesn't restrict you in anything. We are working domain driven and it seems that Java EE is built for it. You have bean validation, CDI, JSF, which all works very well together. So you can build perfect domain models with very good cohesion. Especially CDI fits well in the whole Java infrastructure, because you can use every visibility as you would without a container. This is a big advantage over classical EJBs, where you need everything public, which should be handled by the container.

We are using the full stack of Java EE only. And we try to avoid third party libraries. Simplicity is our key to success. And Java EE gives you almost everything out-of-the-box, so we can concentrate on business logic.

Any plans to migrate to Java EE 7?

We are planning to migrate to Glassfish 4.1 or even Payara in the next few weeks. Java EE 7 is not the key reason for migration as Java EE 6 is quite cool for us, but our developers are waiting to use "revolutionary" Java 8. In general we try to be up-to-date with our technology stack as soon as possible.

What application servers, tools etc. UI technologies are you using?

We are using Glassfish 3.1.2.2 right now. Our database is mongoDB, our frontend is JSF. The IDE is IntelliJ IDEA. The continuous integration server is TeamCity from JetBrains. Other tools are: haproxy, nginx, hazelcast, SonarQube.

Should architects code?

Absolutely. We think, they work basically for the development team. And developers usually understand code very well. An architect must be present his ideas for the developers in source code. Though they also must be able to do some nice diagrams both for developers and the management. But management compatibility is only a side aspect of the architect's job.

How many developers are working on the application?

Currently we have about 15 developers and the team keeps growing fast.

Are there any pain points with Java EE? What could be simplified?

Unfortunately the CDI spec changed with Java EE 7. Things that were possible with EE 6 don't work any longer. Another problem is Oracle's policy of Glassfish updates. But Payara is a hot candidate to fill the gap.

Will you choose Java EE for the realization of your ideas again?

For sure. The technology is mature, but still let's you do whatever you want.

I really enjoyed to work with you and your team--we had lots of fun. What in your opinion is more important, having fun with hacking and be passionate, or the actual experience?

It's a mixture of both. You need experienced developers in the team (at least the architect). But they all need to be passionate including the experienced developers.

Do you have any demos, links etc. for the readers?

We do not promote our customers' web sites, so unfortunately I am not able to give you any demo link here. But visit our web site http://dreamit.dein contact with us.

Or visit us on the code.talks developer conference where we act as a sponsor too http://www.codetalks.de/2015/sponsoren

We will starting soon our github repo. And in general we try to establish us as a brand -- at least here in Hamburg. Just to be a cool developer company. We now organize our first meet-ups. Hopefully with your support too. I count on you.

Additionally, here is a link to our chief architect: http://frankcaputo.de. He is a member of the JSF and 
MVC-Ex pert-Groups, where we e.g. have a chance to help improving upcoming JSF versions directly. Frank participates in JSF improvements significantly. E.g. make JSF more HTML5 markup friendly with pass-through attributes or adding resource library contracts.

You always ask me whether I know passionate Java EE developers. How to apply? :-)

Simply send us an email to jobs@dreamit.de, take a look at http://dreamit.de/it-jobs-in-hamburg or contact me directly on Xing https://www.xing.com/profile/Norman_Schoeneich

Norman, thank you for the interview!


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

Questions For 13th Airhacks Q&A Easter Egg Edition at Tuesday 7th April

Last chance to ask questions. We will discuss them at 7th April (exceptionally at Tuesday), 6.PM. CET: http://www.ustream.tv/channel/adambien:

  1. I have never used Spring ,hibernate and struts ,I build my web app's using Jsf, ejb,cdi ,jpa ,is the same ? what's the difference? [@SoyRoji]
  2. Do you follow any java or software development related blogs? If so, would you share some with us. [matlach]
  3. JPA 2.1 has properties to drop and create the database but not to update it. How do you usually handle database schema updates and rollbacks? [xavistp]
  4. For multi tenancy application I am using JAVA EE 7. I need to change schema dynamically based on customer.Since there will be a lot of customer so multiple EntityManager will be insufficient. So I am using Hibernate's EmptyInterceptor along with ThreadLocal and changing schema dynamically which is working fine.Since, my solution is tightly couple with Hibernate, could you suggest me some generic way so that it will be vendor independent .

    Also Like to ask which application server( full java EE 7 support) will be best for production Glasfish(payara) or Wildfly or Liberty.

    [surajchhetry]
  5. In a JAVA EE 7 web application with an highly and dynamic configuration settings for the persistence tier, what will be your way? NoSQL or an entity abstraction layer like Atlassian JIRA (Apache OfBiz)? [riccardomerolla]
  6. Your thoughts on java ee "extensions" like deltaspike and picketlink as you always advocate slim "war"-files. i.e. few external dependencies?
I, for one, would miss for example "deltaspike data" or the powerful, though complicated, security features of picketlink (like build in JWT).

    I also noticed that you are a member of the JSR 375 (Java EE Security API) expert group. Do you have any infos/plans about that JSR?

    [haisi]
  7. Having read about the so called "onion architecture" as opposed to the traditional layered architecture I am wondering about how to realize that with Java EE. The onion promotes an application core, which is independent of libraries and infrastructure. With Java EE's POJOs I have a feeling that we are already close to that onion idea, right? Regards, Michael [micgn]
  8. How would you implement "RPC like" API between microservices using your Java EE approach? Do you think that JAX-RS can be used for that (especially with JAX-RS client API)? if not, what else could be used in Your opinion? Regards, Piotrek [pkucia]
  9. It's been announced a new MVC framework with Java EE 8. What do you see in the future of JSF? Do you think JSF will become obsoleted by this MVC framework? Thank you Antonio Varela.[antoniovl]
  10. Do you use JSF for the presentation layer of your projects, or you use someting else? Thank you again. Antonio Varela. [antoniovl]
  11. Why JNDI expose implementation bean name in global namespace? Why the caller must know name of bean for standardized JNDI java:global/appname/modulename/beanname!interfacename [n4noman]
  12. What are your recommended strategies for achieving zero downtime under continuous delivery principles? My team has a good pipeline in place for automated verification: from unit tests to functional tests to code coverage checks to corporate compliance checks to user acceptance tests. At the end of the pipe though, we still have to take a downtime while the application is redeployed. This can range from 1-5 minutes depending on the application, our current Java EE container is Apache TomEE. Thank you! jieryn
  13. Do you think there is value in having a JDBC driver wrapper which populates its configuration parameters (e.g. jdbc.url) from a distributed configuration management system like etcd (by CoreOS)? The idea being that a customer would stand up many instances of a JavaEE server, probably through Docker, and configure the database endpoint through etcd. Then the database could be dynamically migrated and update the etcd configuration. This might allow database migration without restarting all web layer microservices. Is this pathologically dangerous? Is there some alternative to this? Thank you! [jieryn]
  14. What is the best way to achieve a singleton JPA @Entity? I find I often I want to create a singleton object which holds runtime configuration data, configurable within the application itself, and persistently stored within the JPA environment for that application. In order to maintain that only one ApplicationConfiguration will ever exist within the application, I have to jump through hoops for all CRUD operations within my DAO layer and play tricks with the @Id (checking if @Entity exists, then remapping the CxUD with the getId() of the originally persisted entity, yuck). Would you please recommend a strategy for a JPA @Entity which follows @Singleton semantics. Thank you! [jieryn]
  15. Are cross-view (cross-rectangle) Presenter something valuable? Did you ever miss that? In JEE application I used to freedom in EJB assembly, for example: I have 3 EJB A,B,C. I can freely assembly other EJBs:
    
    @Stateless class AddressBean {
    @Inject A a;
    @Inject B b;
    }
    @Stateless class PaymentBean {
    @Inject B b;
    @Inject C c;
    }
    
    
    In JavaFx view is constructed in FXML with rectangles. For example one top rectangle is attendeeinput.fmxl and bottom rectangle is workshops.fxml. And bottom rectangle has inside other rectangle day.fxml. That is OK. What is hard to accept to me is that Presenter is tied to rectangles. I would like to have freedom with Presenter assembly, i would like to inject by @FMXL gui components from many rectangles. For example if checkbox from top rectangle is checked then textfield from bottom rectangle is disabled. It will be natural to me to have a dedicated Presenter, not tied to any rectangle, with injected by @FXML checkbox from top and textfield from bottom view. Conclusion: I want Presenter freedom. I didn't found the freedom in JavaFX so checked afterburner.fx. but there isn't also. My questions: 1. Is Presenter freedom something valuable or it is a wrong thinking. Bad analogy with JEE. 2. If valuable, is it possible to apply that concept to JavaFX, with or without afterburner.fx? [michaldo]

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

First Greenbar With JavaScript

Unit testing a UI-leass "hello world" JavaScript application (like e.g. Nashorn) with npmjs.com, mochajs.org and chaijs.com:

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

Counting Lines With Java 8


import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

Path path = Paths.get("./readme.txt");
long lineCount = Files.lines(path).count();

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

A Java EE 7 Startup: Virtualizing Services with hubeo.com

Could you please briefly introduce Hubeo.com and yourself?

My name is Wojciech Ozga. I am 25 years old, living currently in Krakow, Poland. I am interested in different areas of Computer Science, starting from software engineering going through computer networks and finishing on cloud computing and linux system administration.

I started my adventure with programming when I was kid, I got Microsoft Visual Basic 6 Pack from my father. Then I was experimenting mostly with c/c++ till 2004 when I entered the path of PHP. After one year I finished works on Cracow-Apartments.com, one of the first online booking system of apartments in Poland.

Since 2009 I have spent most of my time in the JVM world with small exceptions for python and shell scripting languages. In mid 2012 I started the design and the implementation of Hubeo.com. I decided to keep as close as possible to Java EE stack, and it was good ;)

Hubeo.com is a global web platform for virtualization of services like: accommodation, tours, transportation, medical treatments etc. Complex system logic is hidden behind user friendly web page with modern and fresh design.

What makes hubeo.com stand out from other booking platforms is the ability of its users to advertise, promote, find and book a wide range of services in one place. Main features are:

  • selling own services
  • buying services of other users
  • affiliation
  • automatic booking settlements (with anti-fraud protection)
  • reviews

You told me, you read the book realworldpatterns.com and used the ideas to implement a prototype. What is exact the story behind?

I started to take a deeper look into Java EE on my studies. We had classes where outdated ways of coding and usage of Java EE were introduced to students. That time I was thinking that programming in Java EE is a nightmare. I found some online tutorials to give it a try and I remember one which scared me a lot.

The simple code was surrounded by all the patters coming from "old j2ee times". I had to write the same thing 3 times, encapsulating everything. Moreover I was shown to use ale the xml configurations which I just had to "click and fill" in Eclipse. I was really happy passing the exam and being able to forget about Java EE world. But then I found your books. I read two of them: "Real World Java EE Patterns - Rethinking Best Practices" and "Real World Java EE Night Hacks". The second one made so big impression on me that I decided to give it a try implementing the first prototype version of "cloud market" (the antecedent name of hubeo.com). What I liked the most reading them is that they are written from the programmer point of view: keep it simple, stupid, do not repeat your self. Skip the unnecessary boiler code, write it the simple way so every one can understand. Some times I had an impression that you are more agile then Agile :) Since that time I recommended them to few friends of mine. I think it is obligatory to read them!

You also told me that your colleague was fascinated by the simplicity of the code and wanted to join forces with you. Could you tell the story to the readers?

One friend of mine - Mateusz Krzyszton - was working previously in a big company as JSF programmer. They had a lot of issues with it, large views and server was responding slowly. They were implementing a lot of hacks to make it work. I needed someone to take care of implementing the front-end part, and I knew Mateusz is a brilliant, experienced programmer. That time we met in Lisbon. I told him the basic idea and I showed the very early mock-ups. He was not convinced. Months later we met again in Warsaw where I showed him the skeleton of the web project, implemented in JSF 2.0 with Primefaces and Omnifaces. He browsed through the source code, looked at the implementation of business logic and he decided to reinforce the team! He was really impressed about, how things can be easily done using modern version of Java EE and JSF following patterns from your books.

What surprised you in Java EE the most?

What I like the most is avoiding of writing the boiler code again and again. At the beginning I created few classes, I wrote few lines of code and I added annotations. The very simple, but working, 3 layer application has been implemented! With no magic I had a simple CRUD application with MySQL engine behind! Every programmer with a bit of experience in linux administration can quickly make business application accessible to everyone in a very easy way.

On the other hand I was really disappointed about the security models. I could not find any suitable for hubeo.com. I read official Oracle tutorials 20 times and I did not find JASS as a good solutions for modern web applications. I took a deep look into Apache Shiro but it did not convinced me neither. Modern web systems require much more complex management of roles and permissions. I hope that it will be done with Java EE 8.

What about the Java EE performance? Did you have to perform particular measures to improve the performance?

Performance! Yes, we did several measurements, using JMeter, Selenium and VisualVM. We found few issues but they were mostly related to our implementation. We focused also on the memory usage of our front-end application. I can say that creating complex views, with many components and ajax is not a way to go with JSF. Between requests, JSF stores the component tree of views on the server. Depending on configuration, JSF can store even few hundreds views per user. Having views build with many components we can finish up with few Mb of memory taken by an individual user. That made us thinking about the number of users we can handle during the duration of the user session.

For now we did not find important issues related to the JPA performance, but in the business logic we avoid eagerly loading of collections.

What were the most interesting challenges?

Designing Hubeo.com from scratch was really interesting challenge :) Considering the principles, the design of the database was a really difficult part. I needed a good common schema to store information about services like apartments, tours, dentist treatments and many more. All of those services had to be represented in a similar way to allow design of the algorithm to calculate availability and prices.

Probably the most difficult part of the implementation was the business component responsible for service order and booking management.

Moreover I was really excited discovering Amazon Cloud. Two years ago, together with Jose Java EE Coarasa Perez (blog, @coarasa, LinkedIn), we build one of the biggest implementation of cloud using OpenStack on CMS farm (one of the experiments at CERN) It was a great adventure but after using Amazon services I see how immature OpenStack was that time.

Which IDEs / tools are you using?

At the beginning of my Java EE journey I was using Eclipse. It was a nightmare. After reading your books I switched to NetBeans and I was really happy. Things were just working! Right now I am using IDEA IntelliJ. We use maven and Nexus to store artifacts. For continuous integration server we have Jenkins. The application runs on WildFly 8.2. We also use the relational database: MySQL. Hubeo.com is hosted in Amazon Cloud. We use EC2 to run VMs, S3 to provide common storage for all VMs and RDS for the database. CloudFront helps us to make our static resources easily accessible around Europe and US.

If you had the chance to start-over, would you use Java EE again?

Definitely yes. I could rethink the usage of JSF for that kind of application, but the business logic would be definitely implemented in Java EE.

Do you have any other (secret) startup ideas, which you would like to share with the readers? :-)

I was asked to implement the idea of a simple web page, where people can see the map with different trails indicating interesting points in the city, related to some topics. User can select the trail, search for places, and select specific marker to read details. This is the classical CRUD application. I decided to implement it with Java EE 7 and it took me one day. It runs on WildFly on some really small server (1gb of memory), waiting for a better times - some investor to push it forward.

Any web links / resources?

  • Hubeo.com - virtual market of "real world services". Register your service and start earning money with us ;)
  • Szlaki miejskie - urban trails, application implemented in 1 day using Java EE 7 and Wildfly

Wojciech, thank you for the interview and good luck with your next project!


NEW Workshops: From Java EE 7 Bootstrap, Effective Java EE 7 over Architectures to NoSQL, Testing and Microservices
Online workshop: Java EE 7 Bootstrap

Newsletter: airhacksnews.com

A book about rethinking Java EE Patterns

realworldpatterns.com
...the last 150 posts
...the last 10 comments
License