Fintech Success Story

In 2017 PLEUS Consulting supported Yareto GmbH in the development of their new independent comparision site for the automotive finance industry.
Yareto is a fintech company that specializes in automotive financing. In 2016 the corporate startup was founded to build a brand new comparision site for the automotive finance industry. The site enables car dealers to compare credit offers in the areas of sales financing and purchase financing. Lenders get access to sales channels they couldn’t serve before.

PLEUS Consulting supported Yareto in setting up a Creative Software Workbench. The Creative Software Workbench aligns technology, processes and people in a way that creates an environment in which high quality digital products can be developed in short time.

The front-ends were developed using modern web technologies such as Java-/Typescript, HTML5, CSS and Angular. For the backend Java Enterprise (JEE) and a Sustainable Service Design approach was utilized to design and build a backend with a high degree of reuse and scalability. The service landscape was established using Domain Driven Design principles. Operations was performed using cloud platforms.

On the technical side, PLEUS Consulting supported the teams as Lead Developer. In the area of agile techniques, PLEUS Consulting supported the development teams as Agile Coach. The combination of those roles worked quite well especially in the phases of seed and growth. With these roles the company received thorough support in the areas of technology and methodology.

The project has shown that with a combination of modern technologies, agile approaches and the right people a very short concept to market cycle can be achieved, creating competitive advantages. This is what the Creative Software Workbench is all about.

You can read more details about the project in the official success story. More info about the Creative Software Workbench can be found on the official website.

Sustainable Microservices with Spring Boot

In my article series about Sustainable Service (SSD) design I described a design and implementation approach to develop services with technical decoupling to improve reuse.

At the level of IT infrastructure sustainable means that service implementations can be used in different technical environments without a major rewrite. Technical decoupling is a key factor to achieve that. In the second part of the article I have provided an example on how to implement SSD with a JEE stack. Part of this example is a  calculator service which performs simple arithmetic operations.

Due to the technical decoupling, services can be moved with little effort, for example from a JEE Server to other runtimes like Apache Karaf (OSGi) or Spring Boot, just to name a few.

In this blog post I would like to demonstrate how to move the Calculator JEE example from Wildfly JEE Container to Spring Boot. The main difference in the Spring Boot deployment is the fact that each service is bundled with its own HTTP server. The deployment unit is not a JEE EAR which is deployed on a JEE Server, but a so-called über-jar which includes the complete HTTP infrastructure. The über-jar just requires a Java runtime and no additional infrastructure. This kind of deployment creates a high level of service autonomy which is often used in Microservice architectures.

Let me tell you a little story:

Assume Peter is an IT professional who is working on a fictitious software project for a large insurance company. One day a colleague, let’s call him Max, from another project enters Peterʼs office and starts the following conversation:

Max: I’ve heard you’ve implemented some very useful services. I saw them on your service repository Wiki and think we could use some of them in our new project.

Peter: Yes, that’s right. I am glad we’ve created something valuable.

Max: But…I also heard that you are using a full blown JEE Applicationserver to run your services.

Peter: Yes, this is the best runtime for our project, as it helps us to manage centralized deployment. Each service is deployed in its own EAR file, which gives us great flexibility.

Max: For our project we decided to use Spring Boot and deploy each service together with its own HTTP Server. I guess we can’t use your service without a major rewrite then?

Peter: You don’t have to rewrite the services because we’ve implemented them based on Sustainable Service Design.

Max: Sounds great, could you please show me what we have to do to run your services?

Peter: Of course. Let’s start by downloading the Calculator Example, which demonstrates how to build SSD-Services for JEE. First, build the example like so:

mvn clean install

Peter: Now you have the following maven artifacts (jars) in your local maven repository.

net.pleus.services.calculator:calculator_api
net.pleus.services.calculator:calculator_impl

Peter: You can use this artifacts without any modifications.

Max: Ok, I can see that api and impl form the core service. Our project decided to just use JSON/HTTP as the protocol for service interaction. I saw that in the orignal example REST, EJB and SOAP are provided.

Peter: No problem, just add the bindings when you need them. With SSD you can add additional bindings any time. So you can start with the bare minimum and expand later. This gives you great flexibility. Add the JSON/HTTP-binding first.

Max: In the original example I saw that it was called REST-Binding.

Peter: Although the original calculator example uses the term REST-Binding, I prefer to call it JSON/HTTP-Binding because it better describes what it is. An SSD-Service can manage multiple resources (nouns) and can support arbitrary operations (verbs). This representation is very well suited to modelling the real world (the domain) which is important for proper service design and reuse. If you really have the requirement to create REST-Style APIs, you can do it in the respective binding. But be aware that in this case you create a variation of your service contract (subcontract) which also relies on HTTP-Verbs instead of the verbs in the primary contract. Although it is possible, I would not recommend it. Ok, let’s not digress but move on with Spring Boot.

Max: Ok, please show me how to create the bootable service.

Peter: Sure, start with the following Maven-POM , which is based on the tutorial Building a RESTful Web Service with Spring Boot.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.3.5.RELEASE</version>
    </parent>

    <groupId>net.pleus.services.calculator</groupId>
    <artifactId>calculator_boot</artifactId>
    <version>1.0-SNAPSHOT</version>
    <name>Services :: calculator :: boot</name>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
        </dependency>
        <dependency>
            <groupId>net.pleus.services.calculator</groupId>        
            <artifactId>calculator_api</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
        <dependency>
            <groupId>net.pleus.services.calculator</groupId>        
            <artifactId>calculator_impl</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
    
    <properties>
        <java.version>1.8</java.version>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

Peter: From lines 25-34 you can see the existing calculator jars. The rest is required to create a minimal Spring Boot über-jar. Now we create a JSONHTTP-Binding using Spring MVC.

@RestController
@RequestMapping(value = "/services/calculator/rest/api", method= RequestMethod.POST)
public class CalculatorJSONHTTPBinding {

    @Autowired
    private Calculator service;

    @RequestMapping(value = "/performcalculations", method= RequestMethod.POST)
    @ResponseBody
    public PerformCalculationsResponse performCalculations(@RequestBody PerformCalculationsRequest request) {
        return service.performCalculations(request);
    }
}

Peter: To add this binding we need some boilerplate code. First an application class.

@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        ApplicationContext ctx = SpringApplication.run(Application.class, args);
    }
}

Peter: And second a little factory to create a service instance, so that it can be injected using @Autowired in the binding.

@Configuration
public class Factory{
    @Bean public Calculator createCalculator(){
        return new CalculatorImpl();
    }
}

Peter: That’s all. Build it and run the über-jar with the following command.

mvn clean install
java -jar target/calculator_boot-1.0-SNAPSHOT.jar

Max: Wow, that’s all? Can you prove that it works?

Peter: Of course. For example fire up SOAP-UI and send this request to the service at http://localhost:8080/services/calculator/rest/api/performcalculations

{
	"correlationid":"4711",
	"calculations": {
	 "value": [
	   {
	     "operation": "ADD",
	     "inputs": {
	       "value": ["1","2"]
	     }
	   }]
	}
}

Peter: This is what you get.

{
   "correlationid": "4711",
   "calculations": {"value": [{"result": 3}]}
}

Max: Can I reuse the existing binding from the original example instead of the one we created?

Peter: Yes, but it is technically coupled to JAX-RS. If you want to use it please read the blog Using JAX-RS With Spring Boot Instead of MVC.

Max: I saw that the original example contains a handy Java client to access the service. Can I reuse it?

Peter: You mean net.pleus.services.calculator:calculator_binding_rest_client. Yes, you can use it as it is. And it makes sense, as it gives you a nice fluent Java-API to access the service. First add the following Maven artifact to your pom.xml.

        
            net.pleus.services.calculator        
            calculator_binding_rest_client
            1.0-SNAPSHOT
        

Peter: Now you can use the Java client in your tests like this.

@Before
public void setUp() throws Exception {
  client = new CalculatorClient("localhost",port);
}
    
@Test
public void add() throws Exception {

  // Create calculation inputs
  Calculation calculation = new Calculation()
   .withOperation(Operation.DIVIDE)
   .withInputs(new ArrayOfInt()
     .withValue(9,3,2)
   );
				 
  // Create request
  PerformCalculationsRequest request = new PerformCalculationsRequest()
    .withCorrelationid(UUID.randomUUID().toString())
    .withCalculations(new ArrayOfCalculation().withValue(calculation));
		
  // Call service	
  PerformCalculationsResponse response = client.performCalculations(request);

  // Check correlation
  Assert.assertEquals(request.getCorrelationid(), response.getCorrelationid());
		
  // Check result
  Assert.assertEquals(new BigDecimal(1.5), response.getCalculations().getValue().get(0).getResult());	
}

Peter: When you run the test Spring Boots starts the HTTP Server and calls the service.

Max: It seems that I can easily run your service and even use the Java client within Spring Boot. We have a sustainable service and a lightweight runtime. Perfect! That saves us a lot of time and money. Maybe we should try to evolve the service together? This way we could create further value for other projects.

Peter: Good idea! If you want to try the example I’ve packaged it for download. For convenience it also contains identical copies from the original calculator example.
Feel free to use it as you like.

Schema first contract design

One of the most important artifacts in Service-oriented Architecture (SOA) is the service contract. The contract defines how service producers and consumers interact with each other. Most people agree that a contract first approach is the preferred way of creating service contracts. WSDL based service contracts are very common. In many projects they are generated by the respective frameworks, such as Apache CXF or Microsoft WCF. This is dangerous, as the developer looses control over the contract. This can result in missing interoperability and limited reusabilty expecially in cross platform scenarios.
From what I see, most developers know how to work with their favourite IDE, but only a few know how to create a proper service contract from scratch. I think that is caused by the tool vendors, which in most cases have better support for code based approaches.
In this post I would like to show how to create a portable contract from scratch and share some best practices.

The domain model

The first thing to think about is the domain or entity model that the service should expose. The model should be modeled in XML Schema. XML Schema is standard, portable and supported on all platforms. In fact it is a good idea to use XML Schema as the single source of model information.

The following listing defines the entity Product:
 



  
    
      
        
          Name of the product
        
      
      
        
          Quantity on stock
        
      
    
  

The entity Product has two attributes name and quantity. Please note that the xml elements (line 10 and 15) are abbreviated. This helps to reduce the message size on the wire, expecially important in WANs. The downside is obviously reduced readability. That is not really a problem as the contract should be documented anyway using the standard XML Schema annotation elements as shown in line 11 to 13.
This is the result:

Wouldn’t it be nice to have a common base class in order to create a more generic service contract?
Luckily XML Schema allows that. Let’s create another schema BaseTypes.xsd in which we define the base types.



  
    
      
      
    
  

  
    
      
      
      
      
    
  

  
    
      
        
          Unique key
        
      
      
        
          Status of the entity
        
      
    
  

This base type Entity (line 24) defines common attributes for all entities. In XML Schema one can define enumerations as well (line 8 and 15). The enumeration EntityStatus defines the state of the entity. This is important in scenarios in which the entities are detached from the database. By marking the entities, it is easy to implement change tracking on the consumer side and just return the changed or deleted parts to the server. This saves network and processing time. EntityType is used later in our service interface to request different types of entities.
We can now import the base types into Types.xsd and change the Product type:





  
    
      
        
          
            
              Name of the product
            
          
          
            
              Quantity on stock
            
          
        
      
    
  

You can see the import in line 9. In line 12 and 13 the base type is added to the Product type.

This is the result:
Entity with base class

Now we have our model completely defined in XML Schema. By using imports and type inheritance one can create very modular entity models. Those models can be reused without any change by interface definitions such as WSDL and WADL for SOAP or REST services. Moreover the code models (Java, C#, etc.) can be fully generated from the schema. Every good framework has a generator tool on board. For instance Apache Axis/wsdl2java, Apache CXF/wsd2java, Silverlight/slsvcutil, .NET/svcutil, etc. The schema can be stored in a service repository in order to increase reusability amongst the organisation.

The messages
Every service operation receives a message and returns a message to the sender. Those messages should also be defined using XML Schema. The following snippet shows the message definitions. The fault messages are ommitted for the sake of simplification.


    
      
    
  

  
    
      
    
  

    
        
            This represents a request to read business entities
        
        
            
                
                    
                        Type of the entities to read
                    
                
                
                    
                        Unique keys of the entities to read
                    
                
            
        
    

    
        
            This represents the read response
        
        
            
                
                    
                        List of entities
                    
                
            
        
    

Those are our messages:

ReadEntitiesRequest and ReadEntitiesResponse are bulk operations that allow to read multiple entities with one call. As you can see ReadEntitiesResponse does not return Products but Entities. Do you remember? This is our base class type for all entities. By using the base class, the message can return arbitrary entity types in the same message. This is an example for a strongly typed but yet extensible interface.

The schemas can be reused in WSDL files:



  
  
  
  
      
  
  
    
  
  
  
    
      
      
    
  

  
        
    
      
      
        
      
      
        
      
    
  
  
    
      
    
  

The type information and message definitions are completely externalized to individual schemas. As a result the WSDL is small. The imported types (line 4) are used to define the WSDL messages (line 7 and 10). A WADL file would look like this:



  
    
    
  

  
    
      
        

            
              
                This is the product id
              
            
          
        
        
          
        
      
    
  

The types are imported (line 8 and 9) and used to define the return message (25).
By using the respective tool, such as wsdl2java or svcutil, we can completely generate the model and messages for the client and server on JEE, .NET and other platforms.

Summary
As you can see it is not too difficult to create schema based service contracts in a platform agnostic way. If you do, you will be rewarded with a great level of control, portability and reusability. Powerful features of XML Schema, such as inheritance, allow to create robust and extensible service contracts, which are the basis for interoperability. And if you want, you can even use an XML editor. 😉