Remote Development Center for Service-Oriented Architecture Platform

It was required to create a platform for the development of various kinds of products based on service-oriented architecture (SOA) for one of our customers. The essence is that a number of loosely coupled services are used and the application is built by combining these services that interact based on a specific interface. The services can be located on different operating systems. In one case of interaction, the endpoint can be on Windows, in the other – on Linux. This is shown schematically in Fig.1.

The platform we developed is an Enterprise Service Bus (ESB) with enhanced functionality. The user can use a universal set of tools for SOA building:

The work on the project was carried out in accordance with all SCRUM canons. The product backlog was created. Based on this product, each sprint was planned before the start. At this stage the team determined the goals of the sprint and formed the sprint backlog from the product backlog. Stand-ups were held every day, at the end of each sprint the team held a demonstration of the results and then a retrospective. Jira was used as a tracking system.

As mentioned, the developed system is based on SOA with its own set of services. Each service is a set of different endpoints. And here it was very important to write integration End-to-End tests to check the correctness of the application work and reproduce the maximum possible number of situations that can happen during the life cycle of the application. For more convenient work, our team developed its own framework for End-to-End integration testing. The developed framework allowed creating integration tests which help to monitor the state of the system at any level of the calls stack.

Figure 2 shows how the message is sent to the first component and then transferred to the second component when integration testing starts. The framework allowed specifying the required behavior in messages to be able to reproduce various situations. For example, it can be specified in the script that the second component should throw an exception, then the message informing of the occurred error (a specific exception was thrown) will be sent to the calling service. Then, after passing all the calls, the framework records a tree of calls and situations that happened, and the result is compared with the reference tree of calls.

In the process of integration testing and framework using, the team implemented the applying of DDT (Data Driven Testing). Subsequently, a similar approach to product integration testing, when the components are sequentially called and the obtained request-response result is compared with the reference one, was applied to develop our own Xml2Selenium product.

As a result of project implementation, our employees gained additional experience with huge code bases, complex architecture, and, of course, various runtimes: OSGI, Tomcat, SOA.

Stack:‌ Java, JBI, EJB, OSGI, SOAP.

Infrastructure: Git, IntelliJ IDEA, Jira.