SOA Integration Platform

Process flow diagram

Discussion

This is a comprehensive SOA platform with a canonical data model at its core. This allows all APIs to follow an OpenAPI standard for Integration connecting consumers to providers whilst working with data in a canonical data format.

Layers of processing

Ingest

There are two routes into the Integration platform, direct and proxy.

1)      The proxy is used to allow the consumer to pass in calls without conversion to canonical format. This is often used for legacy applications where they cannot easily be developed.

2)      The direct call to api can also have a version of the direct connection where the functionality is restricted to functionality needed by the consumer. This forms a layer of protection for the API such that, for example, its not possible to lookup a list of users in the system

Convert to/from Canonical model

1)      When using the proxy method the call still needs to get to the canonical compliant API so conversion is made to and from the proxy call so that the actual API can be called

2)      The reason for this is key to the whole architecture in that when all APIs talk in a canonical language they can then talk to each other as needed without constant conversions taking place

Enhance

1)      All the data being in a canonical format allows one API that needs extra data to make its call to the provider can call back into the API layer to get this information. Yes, there is recursion so yes care must be taken but its powerful in facilitating provider calls

2)      In theory, not that I made this happen, the enhance module should be able to work out what extra information is needed itself without bespoke coding

En-route

1)       Once the call to the provider is fully populated with data the call can be made. Some providers will give a synchronous interface and some will need the data provided to a queuing solution and hence become asynchronous

AWS Applied Process flow