Selecting The Technology Stack for JCart

Selecting the right technology stack is very crucial and plays an important role in project success. Many of the architects (unknowingly??!!) try to make complex designs by trying to use all kinds of latest and greatest stuff. On the other hand some architects try to be in their comfort zone by limiting their technology stack to the technologies with which they are comfortable. Both approaches are dangerous. One should understand the business needs and pick the technologies that are necessary for project.

Java Platform: We will be using Java 8 for JCart so that we can leverage the good features introduced in Java8 like Streams, DateTime API etc.

Frameworks: This is where people go religious about their favourite frameworks. We should consider various factors while choosing the tech stack for any project.

  • Needs of the project requirements
  • Maturity and stability of the technologies
  • Team skills
  • Community/Commercial support

For JCart project we need:

  • Request-Response oriented MVC web framework for ShoppingCart site. I prefer stateless architecture for public facing web apps.
  • Component oriented MVC web framework for Administration site. I prefer UI Component Oriented framework for internal applications like Administration web apps.
  • Security framework supporting Role Based Access Control (RBAC)
  • A high-level Data Persistence framework
  • Other miscellaneous features like Emailing, Scheduling etc

In Java land, JavaEE and Spring are the most popular tech stacks for building applications. Both are very mature and have wonderful community support.

Spring provides:

  • Request-Response oriented SpringMVC web framework
  • Spring doesn’t provide any Component Oriented MVC framework. But we can integrate Spring with JSF or Vaadin which are Component Oriented Web MVC Frameworks
  • SpringSecurity provides RBAC security
  • Spring Data projects provides a very nice abstraction over various Data Access Technologies
  • Spring provides support for Emailing and Quartz Scheduler integrations as well.

JavaEE provides:

  • As of JavaEE7 there is no Request-Response Oriented framework provided by JavaEE. But in upcoming JavaEE8 version a new MVC framework will be released as JSR 371 . The reference implementation for MVC 1.0 is Ozark. You can find more details on it at
  • Component Oriented Web MVC framework JSF
  • IMHO, Security features provided by JavaEE 7 are not sufficient for many of the applications. But the good news is in the upcoming JavaEE8, JSR 375: Java EE Security API will be released.
  • JPA ORM framework which you can use with any of the popular implementations like Hibernate, EclipseLink etc. In addition to that you can use Apache DeltaSpike  modules to make things more easier.
  • JavaEE also provides support for Emailing and Scheduling features.

Coming to the Team skills, we are more hands-on with Spring technologies than pure JavaEE stack. We can work with both JavaEE and Spring, but we are more productive with Spring. If our team members are more hands-on with JavaEE we would have chosen JavaEE.

So, we are going to use Spring and some of its portfolio projects like Spring Security, Spring Data, Spring Boot etc.

Note: As I mentioned, a Component Oriented framework would be more suitable for JCart Administration web app, we will be using SpringMVC with Thymeleaf only. This is a compromise we are making considering the team skills and scope of the project.

Secret: Let me tell you a little secret. Come close. The reason I mentioned above for not using any Component Oriented Frameworks is not true. The actual reason is, after completing this application using Spring stack, I am planning to build the same app using pure JavaEE stack (CDI, EJB, JPA, JSF etc). There I am planning to use JSF/PrimeFaces for Administration web app. So we will be hands-on with both Thymeleaf and JSF/PrimeFaces 🙂

What are the tools we will be using?

  • Version Control System: We will be using Git VCS and host our code on Github.
  • Build Tool: I know Gradle is so hot these days but I am happy with Maven. We will be using Maven for our application.
  • IDE: As we are using Maven which is IDE agnostic we can use any of our favourite IDE. But our application is heavily depends on Spring technologies we will be using STS. Those of you Intellij IDEA fan boys can happily use Intellij IDEA 🙂
  • Server: Tomcat as embedded server.
  • Database: MySQL. But ideally we should be able to use our application with other databases like Postgres.
  • Tools: Jenkins for CI, SonarQube for code quality checking.
  • Production: While deploying our application in production we may want to use Apache or Ngnix as our load balancer and use monitoring tools like Zabbix. As I am not an expert in this area we will come back and spend some time to take a deep look at the options and pick the tools.

What about MicroServices, Docker and Cloud stuff?

As I said earlier, we are choosing the technologies based on our project needs. We are not Netflix, we are not LinkedIn and we are not building the NextAwesomeTechProductOnEarch. Our project needs are simple, our team size is small and we are not going to deploy our application on 128 containers on Cloud, so we are not going to use any fancy container technologies like Docker/Kubertness. If at all we got scalability problems where we may need to deploy our application on hundreds of servers, that’s a good to have problem.

Remember: Adding new software/framework/library to a project is easy..Removing is lot harder than you thing. So be careful while adding another software/framework/library.

Developing a simple e-commerce application from scratch to production using SpringBoot

We can find plenty of information on any technical topic, be it Java, .NET, Python or any frameworks like Spring, Hibernate, CDI, JSF etc. You can find hundreds of well written blogs on many of these topics. For example, you can find lot of tutorials on how to use SpringBoot or how to use various mappings in JPA/Hibernate or how to do form validations in JSF etc. Also, there are plenty of books published by well established publishers on most of the technologies.

But once the “Junior Developer” stage is crossed, many developers would like to learn more about how to design an application, how to modularize the code, what security aspects should be considered, what measures we should take while deploying into production and how to handle the production issues etc.

We can find articles on these topics in bits and pieces but not in an organized manner. So, I thought of starting a series of articles covering “How to develop an application from scratch to production?“. What I am going to do is I will start developing an application (neither a simple HelloWorld app nor a NextGenerationAwesome product, but a decent size application) and write a series of articles explaining how we can develop the application in a step by step manner.

Why I am writing these article series?

To help junior developers:
Every week I receive at least couple of emails from software developers with 1 to 3 years of experiencing for a suggestion.

Those emails goes like this:

I joined in XYZ company as a fresher and I have been there for the last 2+ years. They put me in a maintenance project where I mostly work on defect fixes and I never really worked on anything from scratch. Now I am not at all confident about my technical skills as I have not implemented anything on my own apart from fixing defects here and there. Here we don’t see any new projects in near future. So I want to move to a different company, but I am having a very hard time in clearing the interviews.

So, could you please advise me how to learn Java the way people use it in real projects, not basic HelloWorld kind of samples? Could you suggest any books, blogs? Should I learn Spring, Hibernate to get a Job?

I feel very sad to see the people in this kind of situation because I know how painful it is. But also simply blaming the company for not giving an opportunity to build something from scratch won’t help. Teaching you latest and greatest technologies may not be your organizations top priority.

Some people told they even joined some training institutes to learn Java while working as Java developers!!. But again they are disappointed because they got basic HelloWorld kind of training only, not the way projects are developed in organizations.

So, I thought of helping them by writing a series of articles explaining how the project development from scratch looks like.

Material for my trainings
I do give trainings on Core Java, Spring and JavaEE. I hope the projects that will be developed for this series may also be helpful for my Java trainings as well.

I want to learn more
Teaching is the best way to learn.

What we are going to do?

We will develop an e-commerce application using Java technologies. We will start from the very beginning of Requirements Gathering and go through all the phases of Analysis, Design, Implementation and Deployment in a step by step manner.


Table of contents:

  1. Introducing the application JCart
    • High Level Requirements
    • Overview of System Architecture
  2. Requirements Analysis
  3. Selecting The Technology Stack
    • Platform, Frameworks
    • Application Server, Database
    • IDE, Build Tool, Version Control System (VCS)
    • Continuous Integration, Code Quality Checking
  4. Release Planning
    • Plan Iterations & UseCases
    • Estimations & Release Schedules
  5. Setting up the Development Environment
  6. Building Administration/ShoppingCart WebApps
    • Iteration – 1
    • Iteration – 2
    • Iteration – 3
    • Iteration – 4
    • Iteration – 5
    • Iteration – 6
    • Iteration – 7
    • Iteration – 8
  7. Deploying to Production
    • Clustering and Load balancing
    • Setting up Monitoring Tools


For this whole exercise we will build a ShoppingCart application “JCart” using SpringBoot, SpringMVC, Thymeleaf, JPA(Hibernate). I too have this habit of prefixing with J for everything I built with Java :-).

If everything goes as planned and once we finish this application, then probably I will try to implement the same application using JavaEE stack (CDI, EJB, JPA, JSF etc).

Stay tuned 🙂

SpringBoot: Introducing SpringBoot

SpringBoot…there is a lot of buzz about SpringBoot nowadays. So what is SpringBoot?

SpringBoot is a new spring portfolio project which takes opinionated view of building production-ready Spring applications by drastically reducing the amount of configuration required. Spring Boot is taking the convention over configuration style to the next level by registering the default configurations automatically based on the classpath libraries available at runtime.

Well.. you might have already read this kind of introduction to SpringBoot on many blogs. So let me elaborate on what SpringBoot is and how it helps developing Spring applications more quickly.

Spring framework was created by Rod Johnson when many of the Java developers are struggling with EJB 1.x/2.x for building enterprise applications. Spring framework makes developing the business components easy by using Dependency Injection and Aspect Oriented Programming concepts. Spring became very popular and many more Spring modules like SpringSecurity, Spring Batch, Spring Data etc become part of Spring portfolio. As more and more features added to Spring, configuring all the spring modules and their dependencies become a tedious task. Adding to that Spring provides atleast 3 ways of doing anything :-). Some people see it as flexibility and some others see it as confusing.

Slowly, configuring all the Spring modules to work together became a big challenge. Spring team came up with many approaches to reduce the amount of configuration needed by introducing Spring XML DSLs, Annotations and JavaConfig.

In the very beginning I remember configuring a big pile of jar version declarations in <properties> section and lot of <dependency> declarations. Then I learned creating maven archetypes with basic structure and minimum required configurations. This reduced lot of repetitive work, but not eliminated completely.

Whether you write the configuration by hand or generate by some automated ways, if there is code that you can see then you have to maintain it.

So whether you use XML or Annotations or JavaConfig, you still need to configure(copy-paste) the same infrastructure setup one more time.

On the other hand, J2EE (which is dead long time ago) emerged as JavaEE and since JavaEE6 it became easy (compared to J2EE and JavaEE5) to develop enterprise applications using JavaEE platform.

Also JavaEE7 released with all the cool CDI, WebSockets, Batch, JSON support etc things became even more simple and powerful as well. With JavaEE you don’t need so much XML configuration and your war file size will be in KBs (really??? for non-helloworld/non-stageshow apps also :-)).

Naturally this “convention over configuration” and “you no need to glue APIs together yourself, JavaEE appServer already did it” arguments became the main selling points for JavaEE over Spring. Then Spring team addresses this problem with SpringBoot :-).

Now its time to JavaEE to show whats the SpringBoot’s counterpart in JavaEE land 🙂 JBoss Forge?? I love this Spring vs JavaEE thing which leads to the birth of powerful tools which ultimately simplify the developers life 🙂.

Many times we need similar kind of infrastructure setup using same libraries. For example, take a web application where you map DispatcherServlet url-pattern to “/”, implement RESTFul webservices using Jackson JSON library with Spring Data JPA backend. Similarly there could be batch or spring integration applications which needs similar infrastructure configuration.

SpringBoot to the rescue. SpringBoot look at the jar files available to the runtime classpath and register the beans for you with sensible defaults which can be overridden with explicit settings. Also SpringBoot configure those beans only when the jars files available and you haven’t define any such type of bean. Altogether SpringBoot provides common infrastructure without requiring any explicit configuration but lets the developer overrides if needed.

To make things more simpler, SpringBoot team provides many starter projects which are pre-configured with commonly used dependencies. For example Spring Data JPA starter project comes with JPA 2.x with Hibernate implementation along with Spring Data JPA infrastructure setup. Spring Web starter comes with Spring WebMVC, Embedded Tomcat, Jackson JSON, Logback setup.

Aaah..enough theory..lets jump onto coding.

I am using latest STS-3.5.1 IDE which provides many more starter project options like Facebbok, Twitter, Solr etc than its earlier version.

Create a SpringBoot starter project by going to File -> New -> Spring Starter Project -> select Web and Actuator and provide the other required details and Finish.

This will create a Spring Starter Web project with the following pom.xml and

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi=""


 <description>Spring Boot Hello World</description>





package com.sivalabs.springboot;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

public class Application {

    public static void main(String[] args) {, args);

Go ahead and run this class as a standalone Java class. It will start the embedded Tomcat server on 8080 port. But we haven’t added any endpoints to access, lets go ahead and add a simple REST endpoint.

public class Application {

    public static void main(String[] args) {, args);
 public String bootup()
  return "SpringBoot is up and running";

Now point your browser to http://localhost:8080/ and you should see the response “SpringBoot is up and running”.

Remember while creating project we have added Actuator starter module also. With Actuator you can obtain many interesting facts about your application.
Try accessing the following URLs and you can see lot of runtime environment configurations that are provided by SpringBoot.
SpringBoot actuator deserves a dedicated blog post to cover its vast number of features, I will cover it in my upcoming posts.
I hope this article provides some basic introduction to SpringBoot and how it simplifies the Spring application development. More on SpringBoot in upcoming articles.

Clean Code: Don’t mix different levels of abstractions

We spend more time on reading code than writing. So if the code is more readable then obviously it will increase the developer productivity.

Many people associate readability of code with coding conventions like following standard naming conventions, closing file, DB resources etc etc. When it comes to code reviews most of the people focus on these trivial things only, like checking for naming convention violations, properly releasing resources in finally block or not.

Do we need “Senior Resources” in team (I hate to call a human being as a Resource) to do these things?Tools like Findbugs, PMD, Checkstyle, Sonar can do that for you. I agree that following a standard naming convention by all the team members is a good thing. But that doesn’t increase the readability of code.

Let us take a simple example. I would like to implement Fund Transfer usecase and following are the rules to implement:

  • Source and target accounts should be valid accounts
  • Check whether source account has sufficient amount
  • Check whether source account has provision for Overdraft and check whether this transaction exceeds the overdraft limit
  • Check for duplicate transaction with last transaction. If source, target accounts and amount is same with last transaction consider it as a duplicate transaction
  • If everything is fine then transfer amount to target account

Assume we have the following implementation for the above usecase:

The above code is readable..right??…because:
1. We have followed naming conventions like camel casing variable names
2. We have all the open braces ({) on the method definition line
3. We have closed DB Connection in finally block
4. we have logged exception instead of using System.err.println()
and most important, it is working as expected.

So is it readable and clean code?? In my opinion absolutely not. There are many issues in the above code from readability perspective.
1. Mixing DB interaction code with business logic
2. Throwing IllegalArgumentException, RuntimeException etc from business methods instead of Business specific exceptions
3. Most importantly, the code is mixed with different levels of abstractions.

Let me explain what I mean by different levels of abstractions.

Firstly, from business perspective fund transfer means validating source/target accounts, checking for sufficient balance, checking for overdraft limit, checking for duplicate transaction and making the fund transfer.

From technical point of view there are various tasks like fetching Account details from DB, performing all the business related checks, throwing Exceptions if there are any violations, properly closing the resources etc.

But in the above code everything is mixed together.

While reading the code you start looking at JDBC code and your brain is working in Technical mode and after getting Account object from ResultSet you are checking for null and throwing Exception if it is null which is Business requirement. So immediately you need to switch your mind to Business mode and think “OK, if the account is invalid we want to abort the operation immediately”.

Though you managed to switch between Technical and Business modes, what about making an enhancement to one perticular subtask like “Fund transfer is considred duplicate only if it matches with the last transaction that happened with in an hour only”. To make that enhancement you have to go through the entire method because you haven’t modularised your sub-tasks and there is no separation of concerns.

Lets rewrite the above method as follows:

The above improved method do exactly what the initial verson is doing but now it looks lot better than earlier version.

  • We have divided the entire task into sub-tasks and implemented each sub-task in a separate method.
  • We have delegated DB interactions to DAOs
  • We are throwing Business specific Exceptions instead of Java language Exceptions
  • All in all we have separated the levels of abstractions.

At the first level we have highest level of abstraction in transferFunds(FundTransferTxn txn) method. By looking at this method we can understand what we are doing as part of Fund Transfer operation without worrying much about implementation or technical details.

At the second level we have business logic implementation methods checkForOverdraft, checkForDuplicateTransaction etc which performs business logic, again without worrying much about technical details.

At the lowest level we have technical implementation details in AccountDAO and TransactionDAO which contains DB interaction logic.

So the reader(future developer/maintainer) of your code can easily understand what you are doing at the high level and can dig into method which he is interested in.

As I said earlier, if we have to make the change to consider the transaction as a duplicate transaction only if it happened with in an hour, we can easily understand that checkForDuplicateTransaction() is the one we have to look into and make change.

Happy coding!!

Drools JBoss Rules 5.X Developer’s Guide Book Review

We all start our new projects by promising to follow best practices and good design principles etc.
But over the time business rules change and developers keep adding new features or updates existing logic.
In this process the common mistake done by many teams is putting if-else conditions here and there instead of coming up with better design to support enhancements. Once these feature turn on/off flags and behavior branching logic started creeping into code then overtime it might become un-maintainable mess. The original developers who design the basic infrastructure might left the organization and the current team left with a huge codebase with if-else/switch conditions all over the code.

So we should be very careful while designing the classes holding the business rules and should be flexible for changes. No matter how much care you take you might still need to touch the code whenever a business rule changes.

This is a problem because we are burying the business logic in the code. Drools framework tries to address this problem by externalizing the business rules which can be authored or updated by non-technical people as also (at least theoretically :-)).

Recently a new book is published by Packt Publishing titled “Drools JBoss Rules 5.X Developer’s Guide“.

Drools JBoss Rules 5.X Developer’s Guide

I was asked to review the book and here it goes.

Chapter 1: Programming declaratively
I would strongly suggest to read this chapter even if you are already familiar with Drools.
Author Michal Bali explained the problems with putting business rules in code and how Drools addresses these problems.
This chapter also has When not to use Drools section which I find very useful to determine whether you really need Drools for your project or is it overkill.

Chapter 2: Writing Basic Rules:
Here you can start getting your hands dirty by familiarizing yourself with Drools syntax and trying out simple examples.
This chapter also introduces various concepts and terminology of Drools, so don’t skip this.

Chapter 3: Validating
This chapter covers building a decision service for validating domain model. Any concepts can be explained better with an example rather than lengthy explanations.
Here author did a good job of taking a real world (if not completely real world, but non-trivial) banking domain model and explained how to build the validation rules with several examples.
In this chapter you can find plenty of example code snippets that are commonly used in many of the projects.

Chapter 4: Transforming Data
This chapter covers transforming data from legacy system to new systems and applying various rules in the transformation process.
Author explained how to use IBatis for loading data which I find as outdated topic, now it is MyBatis with cool new features.
But actually I doubt if any legacy system with huge volumes of data can really use this feature at all because if needs all the data to be loaded in memory.
I prefer Kettle(Pentaho Data Integration) kind of tools for this purpose.

Chapter 5: Creating Human-readable Rules
One of the main promises of Drools is you can configure business rules in human readable format.
Ofcourse developers are also human beings(:-)) but here the meaning is non-technical people also should be able to understand the rules and with little bit of training they should be able to configure new rules or update existing ones. This chapter covers authoring the rules using Domain Specific Language (DSL). Author covered wide variety of rules configuration options using DSL including configuring and uploading rules  from CSV or XLS files.

The rest of the chapter go in-depth of Drools covering advanced topics which I haven’t yet gone through.

Chapter 6: Working with Stateful Session
Chapter 7: Complex Event Processing
Chapter 8: Defining Processes with jBPM
Chapter 9: Building a Sample Application
Chapter 10: Testing
Chapter 11: Integrating
Chapter 12: Learning about Performance

Appendix A: Setting Up the Development Environment
Appendix B: Creating Custom Operators
Appendix C: Dependencies of Sample Application

So far I feel it is good read and I would strongly suggest to read this book if you are building an application with complex business rules.