At DSR, our expertise with Java Enterprise technologies, Java application servers, and servlets containers is often called upon by a wide array of software development projects. Our trials and tribulations in software development are many, but today we have adopted the Spring Application Framework as the DSR standard for enterprise level applications.
Let me explain why.
In the Beginning, there was Glassfish v 2.0 with SOA and ESB
In 2008, DSR was asked by the digital media industry to create a distributed solution that allowed users to work simultaneously with video editing software tools like Final Cut Pro, and a digital media archive that housed a vast amount of content.
To develop the solution, we started with Glassfish v2.0 having Service-Oriented Architecture (SOA) using the Enterprise Service Bus (ESB), and Business Process Execution Language (BPEL). DSR released several product versions and successfully supported consumers through 2012.
From an engineering point of view, we were satisfied with the technology stack but found that it was too complex of a configuration when using huge XML documents.
From a project management point of view, I believe we could have chosen better after reviewing the cost/efficiency ratio. In hindsight we realized project objectives could have been met with less engineering effort if a less complex stack would have been chosen.
Just a Few Years Ago, There was Spring, GWT, and Tomcat
In 2011, DSR was engaged to create a web-based service with stock exchange logic in the background. Taking into account our earlier learning experience with XML documents, we looked for a powerful, less complicated Java stack that allowed us to build a modern and scalable web-application.
Several server-centric technologies were tried, including, JSF (Java Server Faces) that is provided as par of Java Enterprise Application Server. However, we soon realized our approach didn’t meet the project needs for a good user experience and scalability. We quickly uncovered a client-centric technology and determined the GWT (Google Web Toolkit) showed the most promise in our tests.
For the back-end, we had to fit the integration with a relational database (MySQL or Oracle) and provide a solid infrastructure to manage the solution. After extensive research, we chose the Spring Framework in conjunction with Hibernate, and Tomcat as a servlet container.
From both an engineering and a project management standpoint, we were satisfied with the technology stack and found Spring Framework to be an integration solution that embeds the best parts of Java Enterprise libraries in tandem with a high degree of flexibility to add additional components.
Today, Evolution to Spring and Jetty
In 2012, DSR participated in developing an aircraft engineering configuration software used by workgroups. The engagement had a huge domain model (from a device down to a network package), concurrent versioning functionality with branches, dynamic ACL and rich client side UI to create and manage an Aircraft Engineering configuration.
Initially Glassfish v3 with EJB 3 was chosen for the project. Eclipse Modeling Framework was selected to deal with the domain model, while Eclipse Rich Client Platform provided a client side application. We created a custom JPA persistent provider implementation allowing for a persistent EMF based model through Hibernate. We also used a continuous integration approach based on Jenkins server.
For integration testing, we selected Arquillian technology and after six months of active development, we faced a speed issue in which our integration tests simply took too much time to execute. With a team of 10 engineers, we had several hundred integration tests with 4-hour run cycles that completely blocked our continuous integration approach. In short, our continuous integration server tested the project slower than it was developed.
While investigating solutions (including embedded Glassfish) we uncovered no viable answer. We found the issue could be solved by migrating with Spring while employing a standard Sprint testing approach. Fortunately, EJB 3 is very similar to Spring (actually EJB 3 shows a clear influence by Spring) and we only spent about 2 single-engineer work weeks to port the solution to Spring and its test approach.
Glassfish v3.0 was also replaced with Jetty since we didn’t need a Java EE server to run our server application despite us still using Java EE components. After migration, we continued to develop the solution for almost 2 years, and after successful acceptance procedures, passed the results to the customer.
To conclude, I’d say that with several years of experience using Java Enterprise technologies we have proven that the Spring Framework is a very good choice in engagements where using Java EE platform is not a strict requirement. With Spring, we have satisfied all engineering and project needs faced thus far. Despite Java Enterprise Edition being a good standardization for most popular platforms, (Glassfish and JBOSS application servers used & tested) we found Spring allowed us to provide best in class results.
Spring for a Java Enterprise level solution has become our recommendation of choice, although we remain open to support our partner’s needs and use a Java EE platform where Spring cannot be.