Mule
Mule is a middleware layer which decouples suppliers and consumers of information. It is a full Enterprise Service Bus which allows platform integration along with API management. It differs from offerings from Spring and other integration solutions, in the fact that it provides an ESB.
Assessment of Mule
Mule provides a platform and methodology to build decoupled architectures.
Mule Positive features:
-For multi-cloud deployments, or cloud apps integrated with legacy systems, it could be a good choice to manage/construct APIs
-Java engineers should be able to pick up Mule within 1-2 weeks through hands-on PoC
-Forces you to think about interface design and management (along with workflows)
-Lightweight Java (akin to RMI) with connectors to difficult-to-interface with-legacy systems eg. SAP BAPI
Mule Disadvantages:
-Cumbersome UI
-Reasonably disappointing documentation
-If you are ‘all in’ to AWS you don’t need Mule, it is just another layer, another cloud, another HA/DR to worry about
-FTP and other services can be handled within AWS
-Programmatic coding is better for complex tasks, APIs, systems
Mule APIs
Mule has 3 levels of API development: System, Process, Experience.
If you are just just migrating from a legacy system, or data centre, to AWS or a Cloud platform:
- The scope of work involved would therefore be lifting and shifting existing workflows and systems; into AWS or the Cloud; and ensuring connectivity and established links are deployed and operable.
- Migrating as-is workflows means you are not tasked with BPM, building event-driven architectures, or developing new DB schemas.
- You will abstract client from server using APIs and other techniques depending on the application and statement of work.
- You should not deploy FTP and file-based services in Mule. Use AWS or the cloud platform to handle file transfers, data inserts, etc.
Part A: API Definitions and Considerations
Definition of Mule APIs:
https://blogs.mulesoft.com/dev/anypoint-platform-dev/api-templates-reusable-system-process-apis/
System API:
System APIs abstract from an existing system and call to that system in its own language via SOAP, Direct Java calls, SAP-BAPI calls, etc. it is a wrapper to the DB or SaaS and does the heavy work of CRUD. Typically, a System API is a REST API with HTTP and JSON data output. A main purpose of System APIs is to allow engineers to change the underlying system, without changing the API (new system API would have a different adapter logic).
Process API:
This level of API focuses on business logic and provides application logic to validate search or query parameters. A process API calls one or several System APIs to complete its event. The Process API orchestrates different jobs (or events). Process API patterns will usually include:
- a System API where data resides before being executed
- a Destination System API where data will be inserted
- A Criteria where the scope of data to be copied, moved or replicated is determined
- Results capture, where the we compare the final state with the desired state
Experience API:
The name indicates the purpose. Experience APIs are used for specific consumers and exposing to them relevant data for their experience. These APIs fit on top of a Process or System APIs. An example could be to build an API on top a Process API which exposes a Rest/JSON interface to a mobile client with a particular interface, to serve a consumer’s needs; and then another Experience API for a SOAP interface for a legacy system.
They can also be used as a layer of indirection, where governance and controls are added (something like a Proxy service, security etc).
(https://forums.mulesoft.com/questions/46895/system-api-process-api-experience-api-design-princ.html)
Key Principle: Simplicity
An API-led design using Mule, will look at the above architecture and use the right APIs based on the systems to be migrated, or developed. A key principle is simplicity. The fewer the layers of APIs the easier and cheaper to build and manage.
Part B: Typical project
Main elements:
-Migrate apps into AWS
-Use Mule to abstract consumer from suppliers
-Use Mule to build and manage APIs and their life-cycles
-Recognize that most of the DB interactions are file updates, transfers, using FTP and other OS/App level services
Architecture:
Most firms have a few enterprise systems and many sub-and-feeder systems. The key repositories are either updated by these sub-systems, or they update the downstream application databases. Most of the work is database to database using OS and Application file transfer services such as Web Methods, File Mover, Tectia, or Tivoli work scheduler. FTP file transfers indicate a reasonably straightforward and generic architecture in which file transfers are being used to insert, update, or collate data information.
Summary of APIs to be used:
- Given the reality of most enterprise systems and Mulesoft’s definitions of APIs, most of the APIs you build will be System APIs.
- Some processes will involve more than 1 DB or event, and these will use Process APIs, wrapping System APIs.
- Rough estimation is that for legacy migrations into a cloud platform, 67% of APIs will be System APIs, 33% Process APIs.
- The above estimation conforms to the work involved which is basically lifting, shifting existing workflows into AWS and ensuring connectivity and established links.
- In such a scenario (4), you are not tasked with BPM, building event-driven architectures, or developing new DB schemas.
- There is no need for Experience APIs within this architecture tailored to ‘specific consumers’.
- Experience APIs may be added later, post the migration project, once some applications are rewritten to be cloud-native. However, this is outside the current project’s scope.