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.

BiPRO takes SOA to the next level!

The advocates of Service Orientation always pointed out that SOA comprises 50% technology and 50% business. At BiPRO this vision becomes true.
BiPRO is a standardization organization for the insurance industry. BiPRO has members from the entire market including well known insurance companies and agents. By standardizing services at the business level using proven technical standards, BiPRO really takes the SOA idea to the next level. BiPRO conformant services are reusable and highly interoperable. Development is contract first, based on open standards such as WSDL and XSD. It is really impressive to see what BiPRO already achieved.

On 25.6.-26.6. June BiPRO-Day 2014 is going to take place in Düsseldorf Germany.

BiPRO-Tag2014_Signet_col

At the event I am going to give a live coding session. In particular I am going to show how to implement and secure BiPRO services using current Web Service standards such as JAX-WS, SAML, WS-Security and WS-SecureConversation. Attendees can see how the implementation works with JBoss Wildfly, Apache CXF and .NET. Moreover they can take a peek into the future of BiPRO standards in the area of security.
I hope to see you there!

Integrated Process Management with Open Source

If you ever tried to create an execution environment to automate business- or integration processes based on Open Source products, you know that this is not an easy task. Although Open Source products like Activiti or Apache Camel are of high quality, they do not run with production grade quality out-of-the-box. For serious usage scenarios typically a lot of work is required to integrate those products into a sound platform. This fact hinders companies to use those great products and turn to closed source alternatives from Oracle, Appian or Inubit, just to name a few.

Now there is an interesting alternative called oparo. oparo is an integrated process automation platform based on rock solid Open Source products. oparo is not limited to BPMN processes only. It rather focuses on the entire process spanning business, workflow, mediation and integration.

The platform does all the plumbing required to turn single products such as Activiti, Apache Camel, Apache ActiveMQ, Lucene/Solr, etc. into a platform that can be used out-of-the box. Even better, oparo is entirely ASF2.0 licensed (today and tomorrow) which offers broad usage options and does not involve any hidden costs for enterprise features.
oparo shields the process engineer (the guy who analyses and automates processes) as much as possible from low level technical tasks such as connecting and transforming Camel and Activiti message payloads. It offers a unified development approach for the process engineer to focus on business functionality instead of technical plumbing. Moreover it comprises additional valuable services such as process flow tracking, humantask integration or a registry. Due to oparos service binding approach, those services can be easily integrated in existing IT landscapes using almost any technology (e.g. .NET, JEE, HTML5/JS/CSS). The runtime is scalable (in terms of technology and licenses), the set up is automated and the whole platform is based on proven standards.

If that sounds promising, you can give it a try. You can find more information and a downloadable jumpstart distribution at oparo – the efficient process platform (German only)

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. 😉