Design with Mule - 101

How Integrations have Progressed

1990 - 2000s (ERPs, Java , Dot Net, RPCs)
Couple of decades ago, when data has to flow from one system to another, we will do three things, we will take source system as origin point, destination system as another point and develop the data mapping. We call these kinds of integrations as point to point. Symbolically, you as data is going from Station A to Station B by a train medium.

Mulesoft realized that there is lot of donkey work, and it can be handled by pre-built configuration and incubated an open source ESB project on spring framework, MULE ESB.

2000 - 2010 (SOAP, WSDL, XML, SOA)
Sometimes, in first half of 2000, SOAP protocol provided standardized approach to Interface through WSDL definition, and architects applied patterns like SOA, ESB, PUB-SUB to create layered services and data started flowing from multiple sources to multiple destinations. Symbolically you as data is going from Station A to Station B through a junction by train as a medium.

Mule Architects understood that webservices will primarily address real-time scenarios and we need a different approach for large data volumes, and created extensions to ESB framework, chunking large dataset into sizable batches, and enabled reporting capabilities of Success, Failures, Error Handling and Reprocessing which was quite manual & custom developed before 2000s.

2010 & Onwards (REST, Cloud, SAAS, Mobile, APIs)
Sideways, there was an interesting development started in the second half of 2000, with cloud computing and really from the integration perspective, source and target systems getting established into the cloud along with 3 decades of on-premise implementations. ESBs & other Integration frameworks started implementing REST architectures to connect to Web APIs, SAAS applications (Salesforce, Workday, NetSuite) through enterprise APIs.

Leadership at Mulesoft, opened up several initiative and asked integration consultants to take an API Led Connectivity approach & use standards like RAML to cloud based implementations, which I think is an extension to SOA Architecture approaches, and provided CloudHub and Anypoint Platform as a deployment engine in the cloud.

Last I know is that Salesforce has acquired Mulesoft to enhance their Integration Cloud offering, and I am quite eager to participate in Microservices implementations to enable next generation trends like IOT, Containers, Blockchain etc.

Understanding API Led Connectivity

Experience generally starts from an interaction by a user, customer, system, device etc, and data travel multiple layers or boundaries to create an impact or impression.

In bottom up approach, we start with a System Layer, where contracts either don't exist or not really consistent. Usually intricacies involved are different authentication, formats, protocols & deployments. So we create a layer of System APIs standardizing these differences.

We then connect multiple systems by using a layer of core system assets without worrying about the connectivity & network issues, to define a layer of Process APIs to define processes that uses capabilities across multiple systems. These process APIs can then create value for Line of Businesses (LOBs).

Experience APIs are your answer to the digital economy ecosystem that orchestrates Enterprise Process APIs to really create revenue generating businesses like AWS, Google Maps etc.

Muleys, at a system layer create flows by using connectors dataweave transformation engine to generate System APIs, and API Designer uses RAML standards to help designers iterate through an API lifecycle.
Methodology [Iterate with Design, Dev / Test, Deploy, Operate]



API Lifecycle

Application Networks, as I heard it is based on the semantics of web architecture and a lot of it goes beyond my understanding. But simply it has to do with engage module which may mean extending reusable assets of an enterprise.

As an offering of Anypoint Platform, designers can use Design Center, API Designer, API Console & Notebook, ApExchange to create simulated specifications with the help of mocking service.

Developers can then identify connectors and scaffold mule flows from the specification artifacts which can be extended in Anypoint Studio with components, filters and simultaneously support cross cutting concerns related to performance, reliability, security, infrastructure. MUnit can be leveraged for testing flows and mocks really facilitate faster integration testing.

APIs can then be deployed using Runtime Manager on the cloudhub / or other infrastructure cloud providers, policies can be enabled using API Manager and command line CLI can be used to establish DevOps capabilities.



Two Cents

Let's say as a consultant, you would have to understand the requirements, systems, processes, people and then use Mulesoft Anypoint Platform expertise to deliver value on mule projects along with honing your skills, as the Integration Ecosystem is changing quite a bit.