Helping a Client with SOA based Java Solution
We worked with a leading manufacturer of construction and mining equipment in the European markets.
Project: System Oriented Architect Solution
Industry: Heavy Machinery and Capital Goods
The Client
With a strong international presence, the company was looking for a near-shore partner that could offer excellent technical skills in addition to round the clock support. We were selected as a preferred partner after a thorough process.
The Challenge
Due to a long history of operations, the Client inherited a number of legacy systems that were not fully integrated and that did not use consistent technologies, thus becoming extremely resource-intensive and costly to maintain and improve.
Another issue cropped up when the Client started a penetrating into other geographies and faced information fragmentation due to different versions of these legacy systems and a coherent view of a Customer, their Orders and their Services turned impossible to obtain.
As a result of these challenges, our customer decided to engage us to re-design its internal applications using a state-of-the-art Service Oriented Architecture (SOA) based on Web Services.
These Web Services would provide a centralized and consistent view of all the business verticals including Sales, Customers, Services and Orders that other applications would leverage thus also eliminating the closed coupling that existed before between the different systems that made upgrades to any component or interface a big challenge.
The Solution
Our team was deployed to identify the best possible way to integrate and implement these business verticals. One of the constraint in offering solutions was to build a central SOA repositories of main business verticals using Open Source technologies while keeping the solution and architecture as simple as possible both from a systems architecture and deployment perspective.
With these constraints in mind, our team assessed several technologies and decided to implement SOA RESTful Web Services. Adaptability, low overhead and existing applications were the main reasons for this choice.
The Technology Stack
Once RESTFul Web Services were adopted, a thoughtful consideration was required to decide which implementation to use and we decided to go withJersey
Data persistence was, at first, implemented as a MySql database as we progressed through the iterative agile development process, the Client requested a more flexible data model to be able to handle frequent model changes so we agreed to implement a sort of XML database on MySql. Even though this innovative approach had many advantages, it proved to have query limitations, so after a careful research, we decided to adopt MongoDB for persistence. This decision has proven to be a wise one as it has achieved all the goals related to model flexibility while avoiding the limitations seen with XML-based storage on MySQL.
When using data models that do not validate data formats, data must be validated somewhere else in the system’s stack. That was the case when persisting data as XML fields: we implemented validation using XML Schemas and Schematron. With MongoDB, a similar approach is being used to validate JSON data with JSON Schema. We chose an open source implementation of JSON Validator.
As part of system auditing features, we implemented a Notification Service to send emails to selected recipients in case specific events triggered. This service is configured easily through XML files. Mail templates are based on Chunk Templates library.
Logging is done through Log4J library, almost a de-facto standard for Java solutions.
Project Management and Methodology
We used Agile Software Development using Scrum for this project to leverage necessary support tools for seamless project management.
Testing the Web Services was an interesting challenge since the solution had almost no UI. Thus Developers’ manual unit tests were done using Firefox add-ons: POSTER and JSONView. The project’s Quality Assurance Engineers conducted their testing using POSTER, some with Jersey Test Framework and, recently, with the aid of the Fitnesse tool. No module was delivered to the client for approval without full QA approval and sign-off.
The source code was maintained in several GIT repositories: one for development, other for testing and a production one, too.
The building tool was Maven. We implemented a continuous build and integration framework linking GIT, Hudson and Tomcat. After each commit, GIT would launch a Hudson job that built the project and, if successful, deployed it to Tomcat. So, builds and integration were done after each commit, thus ensuring the source code stayed operational and as bug-free as possible at all times.
