This blog post is based on the internal work of Thomas Baumgart, former MuleSoft Client Architect, and is now being published by MuleSoft.
In previous blog posts, we’ve discussed business agility, the various types of architectures, and an API-led approach with Anypoint Platform. In this blog post, we’ll cover the differences between MuleSoft’s unique API-led approach and an SOA-based architecture.
Most available documentation will bring to light the commonalities between SOA and API-led connectivity. The three recommended service layered APIs — System APIs, Process APIs, and Experience APIs — remind many of the different SOA service layers. At this point, it is important to note that SOA is not what it used to be 10-15 years ago, and with some adjustments, it might deserve a second look.
The below graphic deepens this concept, as it shows a concrete example that composes multiple services across the three layers in a clear orchestration-driven way.
Three-layer API-led connectivity example
So what has changed?
First and foremost, the layering should not be considered rigid as a way to constrain your architecture, or that it describes a strict, orchestrated way of communication. Rather, see it as a logical attribution of groups of services that have a common set of functionalities.
Even if we assign focus areas to these different service types in a Gartner Pace Layer sense, it does not speak to the way these services communicate with each other, nor if they follow a monolithic, SOA, or microservices philosophy.
MuleSoft’s pace layer focus area mapping
While Anypoint Platform resolves many of the problems that arose from the central, non-distributed approach of a service bus, there is still the problem with the naturally growing dependencies when sharing services with a larger set of consumers, especially when using them in an “orchestrated” way.
The C4E operating model — when implemented correctly — addresses many of these problems on an organizational level. However, this can still be challenging in light of experiences with previous SOA projects.
But is dependency management still as much of a problem than it used to be? One of the most important and often overlooked benefits of Anypoint Platform is the accelerated pace of delivery. This drastically improves the development lifecycle of new APIs and integrations. The ability to create new APIs and integration services in a fast and agile way drives innovation and reduces the dependency management problem described above.
The impact of “accelerated delivery” for multi-layered service networks
The sum of direct and indirect service dependencies typically increase the higher a consumer is in the API hierarchy. A higher “speed of delivery” allows the lifecycle of higher-level services to be aligned to innovation and agile development component characteristics. The dependencies become less relevant when it comes to changes as the difference between the lifecycle frequencies of the upper-level layers (typically innovation-focused Experience APIs) and the lower-end APIs (backend and service integration focused System APIs) gets higher. This prevents problems and makes the adoption of SOA architecture constructs easier than before. By introducing a dedicated API layer that to a certain degree decouples the API lifecycle from the SOA service component lifecycle makes SOA an option once again.
Advanced API-led connectivity beyond orchestration
There is a diverse set of use cases where an orchestration-based approach is the best choice to manage the inter-component /-process communication, and there are situations where a choreography-based approach is more appropriate.
Anypoint Platform has the ability to call REST interfaces and system connectors in a choreographed fashion, it also allows API-nodes to publish and subscribe to various messaging systems and schedule processes.
event/schedule triggered Mule apps
The above image shows an example use case that is based on a customer/lead data management scenario that has to adapt to the circumstance of having multiple active customer data stores (internal and external) that provide their own data processing and timing. The flexibility of the Anypoint Platform supports synchronous and asynchronous communication patterns simultaneously, catering for this type of use case that requires flexibility and agility. In this case, the setup allows you to start using customer leads even when they are not fully processed by the different customer-related backend systems (which are likely monolithic in nature).
In the next blog of this series, we will go one step further and discuss an architecture that covers monolithic, SOA, and microservices elements.
To learn more about how API-led connectivity is the next step in the evolution of SOA, download our whitepaper.
