The Era of Open APIs Demands a New Type of Application
With the rapidly increasing adoption of SaaS, integration Platform as a Service (iPaaS) has become the preferred way to connect SaaS applications. However, with the explosion of Open APIs on the Web connecting APIs together is becoming the norm for application development. However, typical application containers and even application PaaS offerings don’t help in this new era where applications compose APIs together from many different sources.
In the iPaaS world composing APIs together is modus operandi. An application built on an iPaaS is focused on connecting 2 or more systems together via APIs in order to synchronizing data between them. However, we’ve taken this new breed of applications much further with the concept of Integration Apps.
Integration Apps exist in a world where everything needs to connect. Open APIs define thousands of new endpoints for exchanging data and leveraging new functionality and Integration Apps are optimized for dealing with working with many different data sources, focusing on composition rather than just coding.
To explain Integration Apps lets take a look at the anatomy of a traditional Web application.
This will be familiar with any developer; it’s the traditional 3-tier application model that defines how most applications to date have been built. There are a few problems with this architecture in today’s API-centric world:
- The database has traditionally been the source of truth, but now applications work with many data sources. Increasingly apps need to read and write from APIs from different 3rd party providers.
- The App Server is just an HTTP container. It doesn’t provide much in the way of capabilities other than hosting code and mapping HTTP requests to an application.
- Custom logic is a big bucket where the application logic resides. This is where data access and application code is hosted. Developers often use open source frameworks such as Ruby on Rails and the Spring Framework to make creating applications easier. But these frameworks don’t provide much for dealing with connecting to lots of data sources or working with different data formats.
When people move their traditional applications to the cloud, hosting them on Platform as a Service offerings such Heroku, CloudBees or Open Stack the picture looks very similar.
Even when running on PaaS, applications don’t change. This is deliberate since PaaS has focused on getting existing applications into the cloud. However, this does nothing for dealing with the explosion of Open APIs.
Introducing Integration Apps
In contrast Integration Apps embrace the need to connect to APIs and work with multiple data sources, data formats and mediating between different applications. The iPaaS platform provides completely new types services for dealing with interactions for other remote systems including monitoring, tracking, governance and mediation. This is needed because Integration Apps take an message-driven approach to connecting APIs. This means rather than making only synchronous calls in code, interactions are defined through messages being passed between components. This will be familiar to developers that understand newer languages such as Node.js or Scala were messages are passed to listeners or between Actors.
With Integration Apps there are more capabilities built in so the developer doesn’t have to do heavy lifting.
Connectivity is focused on working with lots of different APIs, this layer manages the security, session management and monitoring of connections.
The ‘Custom Logic’ is joined by new capabilities to deal with composing different APIs together using Orchestration. Data Mapping is needed since the data exchanged via APIs comes in differentformats, so being able to work with XML, JSON, RSS, ATOM, CSV and legacy formats is really important. There is also more focus on Error handling since interactions between different systems needs to be clear and visible.
iPaaS offers the same services as PaaS such as database, storage. But because these applications are message-driven there is a whole new set of platform services that help you track information between systems, set up alerts and error handling with message replay.
Integration Apps don’t only connect with Open APIs on the Web, often connecting with on-premise applications and data sources is needed so the notion of a data gateway is important.
One element missing from the above picture is the User Interface. This is because increasingly, applications are being built to serve machines not people, making UI optional. Synchronizing data between a few applications doesn’t need human interaction; nor do many automated business processes. However, Integration Apps natively support publishing ReST APIs so that other applications and mobile devices can interact with an Integration Apps.
Integration Apps in the wild
Without iPaaS and Integration Apps capabilities this application would have taken months to build from the ground up with all the monitoring, management, error handling and connectivity, instead we built it in 4 weeks. And now it serves 1,000s of Salesforce users per day.
Faster, more Productive
The combination of iPaaS and Integration Apps is very powerful, and enables a new type of application that responds to changes in real-time. Pushing more services and functionality into the platform drives a configuration over coding approach which means developers can focus on composing their application rather than coding everything from the ground up. If necessary the developer can insert custom logic into their App but for most scenarios it isn’t necessary, with orchestration and data mapper providing the tools to work with APIs and different data formats.
The applications that take advantage of these new capabilities will create richer, more engaging applications. This new breed of applications will further fuel the Open API explosion adding new APIs that can be consumed people and machines. Open APIs power a world where everything needs to connect, its time for a new platform that embraces this.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)