Composite applications use a variety of existing services to provide a unique set of information for users, often in real time.
The advent of always-connected systems via the internet has transformed how applications are written. Nowadays, very few applications are self-contained; instead, most of them leverage existing services. There is a good reason for this: There are services for pretty much anything you need. Some of them are free and some are subscription services or pay per use.
This is what a composite application is: one that uses various services and APIs to deliver a unique experience.
Benefits of Composite Applications
Fundamentally, the benefits of composite apps are to provide a best-in-class user experience and delighting your customers. For example, by integrating services from different vendors, your users do not have to switch applications and copy data to get additional information. And by accessing data on the fly, your application can provide real-time information.
Examples of Composite Applications
Let’s look at two easy-to-understand examples:
For a great user experience, a real-estate application needs to integrate with:
- A street view service so that the user can immediately see the neighborhood, as well as the house
- A school rating service
- A map service for directions and time to travel to a workplace from the property
- A public tax service to show a history of taxes paid on property
- A loan service for pre-approval and estimated monthly payment
A solar installation application needs to integrate with:
- A service to access the current electricity price for a given location as well as average hours of sun per day. This allows the app to compute what the buyer would save based on current data.
- A service from another vendor to access the current solar panel price as well as installation costs to compute what the buyer would pay.
- A service from yet another vendor to access a list of possible loans to offer.
The key characteristics we see in these composite applications are that:
- They use “outside” services.
- The business logic uses data from these services at various points in the workflow of the application; for example, you can’t compute savings one would realize on a solar installation without current pricing on panels and electricity rate for a given location.
- The use of these services and business logic needs to be orchestrated.
So, the term “composite applications” can be understood both as the fact that the app is “composed” by using external services and as well as the fact that the internal business logic and the calling of these external services needs to be orchestrated (a synonym for composed).
Let’s look at our second use case example in a little bit more detail to have a more concrete view of such an application. The application is best understood with a picture of the workflow it implements:
We will get into the details of each step and the technologies behind this application in a subsequent blog post.
All boxes prefixed with “DS_” are internal decision services (DS); in other words, they are implementing our own business logic. The boxes prefixed with “Rest_” are calling third-party services—e.g., to get current electricity price for a given location or to get a list of loans the user is entitled to.
In this example, we see how multiple steps need to take place and how they are coordinated in a simple workflow. Note how some of these steps can run in parallel. For example, here the second step computes the solar rebate while making a REST call to get solar pricing data. We also see that the data from one step is used in the next step to finally arrive at a full quote with rebates as well as a real-time computation of the savings and some loan offers.
In this blog, we have seen the key characteristics of composite applications and why they are so powerful. Stay tuned for a follow-up blog, where we will see how to:
- Implement such applications in a fraction of the time it typically takes using Corticon.js, a no-code/low-code business logic development tool that provides a powerful interface to express business logic using a spreadsheet model.
- Leverage the cloud and Serverless technologies to achieve scale.
Thierry Ciot
Thierry Ciot is a Software Architect on the Corticon Business Rule Management System. Ciot has gained broad experience in the development of products ranging from development tools to production monitoring systems. He is now focusing on bringing Business Rule Management to Javascript and in particular to the serverless world where Corticon will shine. He holds two patents in the memory management space.