Friday, August 17, 2012

Book Review: “Real World Java EE Patterns Rethinking Best Practices”

Recently I finished reading the book “RealWorld Java EE Patterns Rethinking Best Practices” by Adam Bien. Generally speaking, the book is nice. It contains plenty of useful information, but you have to strain yourself to understand this. The book is not easy to read. It is divided into six parts. The brief description of each part follows.

The first part of the book gives you a brief history of the J2EE. It starts with the description of applets, J2EE application server predecessor JWS (the latter stands for Java Web Server which I wasn’t even aware of before reading this book) and driving forces which gave birth to EJB, JMS and single-threaded programming model. Then author gives a nice introduction to core enterprise application development principles and discusses them in the context of Java EE 5/6. This lesson of history is useful enough to establish a clear understanding of what J2EE was from the very beginning, why it had been considered “heavyweight” and how Spring, Hibernate and other frameworks pushed the standards to the new “lightweight” development model – Java EE. Also this part develops the basic terminology to build upon in the next chapters.

The second part of the book is called “Understanding Java EE Core Concepts”. But I would rather call it “Understanding EJB 3.1 Core Concepts” or “Understanding EJB 3.1 and JPA 2.0 Core Concepts” because these are the topics this part is actually about. It gives you the understanding of Convention over Configuration (aka Configuration by Exception) principle, Dependency Injection (aka Inversion of Control) principle and gives you the basic knowledge about interceptors, stateless and stateful session beans and JPA persistence context modes. It doesn’t give you any kind of information about for example SOAP or RESTful web-services which are both the important parts of Java EE spec. The title of the chapter and its content makes me think that Java EE is all about EJB and JPA which is certainly not the case. But anyway, despite the misleading title the second part gives you the basic knowledge about EJB and JPA you need to proceed with the book.

The third part of the book helps to “rethink” the principles of business tier architectural design. It describes many business-tier-related patterns and best practices using well-defined approach which is kept for the rest of the book. The problem description comes first followed by the properties (or “forces” as the author used to call them) which are the distinguishable signs of successful pattern application. The solution (the pattern itself) goes next. The author compares the original pattern description (targeted to J2EE) with the modern one (targeted to Java EE) quite often. This is the biggest part of the book which adds many valuable instruments to the toolset of a Java EE developer.

If you’re working on an enterprise application which has been started from scratch – you are lucky. It’s not a secret that the vast majority of modern enterprise applications must be integrated with legacy information systems. This often implies writing some ugly code and communicating with Java EE-incompliant resources. The fourth part of the book describes patterns and best practices which would streamline the integration code and make it seamless. The text contains a lot of interesting ideas. One of them is a Generic JCA implementation example which demonstrates how to communicate with a file system in a transactional way (i.e. how to seamlessly integrate a Java EE-incompatible resource with the Java EE ecosystem). Another one, taking to account the huge amount of legacy J2EE code, is EJB 2 Integration and Migration which shows how to evolve the code to use EJB 3 in a step-by-step fashion.

The fifth part of the book tells the reader about infrastructural patterns and utilities. These patterns cannot be related to any specific application layer. Actually they are not parts of the application architecture but rather implementation artifacts. Each of them is carefully crafted to provide an elegant solution for a specific kind of problem. One of my favorite patterns in this part of the book is Dependency Injection Extender. It shows how to tie together Java EE dependency injection capabilities with the ones from other frameworks (for example, how and when Guice dependencies in EJB should be resolved to fit Guice dependency resolution process in the EJB lifecycle correctly). These patterns are probably not the ones to be used on day-by-day basis, but they worth your attention, because as soon as you encounter one of the problems covered by them you will be pleased to know that you already have an effective solution.

The sixth part of the book is about pragmatic Java EE architectures. It describes two radically different application design approaches: service-oriented and domain-driven. This is the place where pieces of puzzle come together at last. The thing is that you can find patterns contradicting to each other while reading the book (e.g. Service Façade and Gateway). To understand the reason of this contradiction you have to be strong enough to get to the final part of the book: the aforementioned patterns belong to different application design approaches. This part of the book helps to stop thinking in terms of fine-grained self-contained patterns. It gives you the high-level view of how the patterns work together. In my opinion this part should be made the third one, not the sixth. In this case a reader may not understand all the material of this part in detail during the first reading of the book, but the high-level view would be established from the very beginning. This is the approach taken by Bjarne Stroustrup in his book “The C++Programming Language: Special Edition”. The second and the third chapters give you a quick tour (high-level view) of C++ and standard library while the rest of the book fills in technical details. So my suggestion is to read the sixth part of the “Real World Java EE Patterns Rethinking Best Practices” right after the second one.

Summary

To summarize, the book is nice, but it has its shortcomings. They are mostly related to poor editing of the text and could be easily fixed. Despite plenty of disadvantages I would recommend to read this book to every software developer who encounters Java EE in the day-to-day work. The list of pros and cons follows.

Advantages:
  • The book contains a lot of useful design patterns which can enrich the toolset of every Java EE developer. A lot of them are general enough to be applied even outside Java EE ecosystem.
  • Pattern descriptions often contain comparison of J2EE version with Java EE version. This helps to understand not only how to apply the pattern in the Java EE context but also why it has been evolved to the new form.
Disadvantages:
  • The text contains a lot of grammatical, syntactical, and lexicographical mistakes. That’s why the book is not as easy to read as it should.
  • There are a lot of errors in source code (but if you read carefully and understand the subject you could easily cope with them).
  • Personal opinion: I would put the sixth part of the book between the second and the third to develop the high-level view as early as possible.

I hope this review was helpful.
See you soon!

Wednesday, August 15, 2012

Introduction

Hi there!

My name is Andrii Polunin. I’m a software developer. I decided to create this blog to publish my personal thoughts and different kinds of technical information related to software development. I’m doing commercial enterprise software development using mostly Java technologies for six years and I like many other seasoned software developers concluded that it can be quite a burden. We all know lots of reasons why commercial software development is pain, so I won’t bother you by repeating them (for young software developers who believe in the bright future I would recommend a book “Death March” by Edward Yourdon, which clearly describes the actual state of affairs in the field).

But I’m still strongly convinced that computer programming is more than that. I believe that it’s an art. I believe that every software developer is a creative person to some extent who can unleash the creativity despite the commercial programming pain. That’s why I decided to post here everything I considered useful and interesting when it comes to software development.

Ok, that’s enough for the intro :)
See you soon!