<- References Go to ToC Data Types ->
| Architecture | Operation | The Actors in the Scenario | Sequence Diagram | Life cycle |
1 Architecture
MPAI as a Service specifies a remote HTTPS-based protocol that exposes the MPAI AIF Basic API functionality for use by a Remote Client (a remote HTTPS 1.1 Client). The following API specification describes the minimum profile of Request and Response Messages.
Figure 1 depicts the global architecture of an System enabling MPAI as a Service (MaaS) allowing Remote Client Application (RCA) to select and run AI Mo instances.
Figure 1 – Reference architecture of MaaS
The RCA issues HTTPS Requests to the Server API through the local API Client. These Requests comprise AIF Controller instance management and AIM instance management and AIM Port message exchange as required to satisfy the MPAI as a Service needs of the RCA.
The Server API, in response to the received Requests, negotiates through the Store API the selection of appropriate AIM Descriptions and with the SCI performs subsequent AIM instance management using the AIF API (Start/Pause/Resume/Stop). SCI retrieves Descriptions and Components of AIMs from the MPAI Store for instantiation as requested by the Server using the AIF API.
2 Operation
2.1 Creation of infrastructure
Creation of infrastructure is the responsibility of the deployment/control plane to avoid access to the application data plane by the control plane and vice-versa.
2.1.1 Creation of an AIF Controller instance
RCA requests creation of one or more SCIs receiving in return SCI identities for use in subsequent API requests to identify the SCI to which the message is directed.
2.1.2 Launch of the desired AI Modules
RCA submits a request to the SCI(s) for the launch of the desired AIM(s).
The objective of AIM launch is the acquisition of an AIM identity for use in subsequent API requests to identify the AIM with which input/output messages may be exchanged.
2.2 Message Exchange
Application data exchange is the responsibility of the application data plane thus ensuring non-exposure of application data to the control plane.
2.2.1 Delivery of messages to the input ports of the AI Module
RCA submits requests to the SCI for the delivery of AIF application data messages to the desired input Port(s) of the launched AIM(s).
2.2.2 Reception of messages from the output ports of the AI Module
RCA may submit requests to the SCI for the reception of AIF Messages from the desired output Port(s) of the launched AIM(s). The RCA may make provision for asynchronous delivery of the response when required.
2.3 Termination of infrastructure
2.3.1 Termination of the AI Module
RCA submits requests to the SCI for the termination of the launched AIM(s).
2.3.2 Release of the AIF Controller
RCA requests termination of the SCI(s).
3. The Actors in the Scenario
A – MPAI Store Service: Provides a package validation, registration and verification service for MAI AIM Bundles, Metadata and Packages
A – MPAI Store Service: Provides a package validation, registration and verification service for MAI AIM Bundles, Metadata and Packages
C – MAS API Servic: Exposes a REST API allowing Remote Client Applications to use AI Modules ‘As a Service’
D – Remote Client Application: A Remote Client Application desires to launch and use known MPAI AIMs for data processing and result retrieval.
E – Controller Instance: Is created by the MAS API Service for the management of AIM’s launched for a Remote Client application.
F – Deployment Controller: Is responsible for the provisioning and life cycle management of resources required for the running of Controllers and AIMs.
G – Deployed Resources: The deployed VM and / or Containerised resources required for the running of AIMs.
The Actions in the Scenario
1 – Implementer requests registration and creation of an Implementer Account on MPAI Store and receives Implementer ID.
2 – Implementer submits an AIM bundle (AIM Metadata containing implementation package URLs, and fingerprints) for conformance validation and subsequent publication.
3 – Remote Client consults the MPAI Store to Select an AIM for their needs.
4 – Remote Client application sends a Create Controller request to the MAS API Service.
5 – MAS API Service creates the new Controller Instance and notifies the Remote Client Application of its ID .
6 – Remote Client application issues a Start Module request to the MAS API Service for the AIM selected in point 3.
7 – MAS API Service forwards the Start Module request to the identified Service Controller Instance.
8 – The Service Controller Instance requests the list of matching AIMs from the MPAI Store.
9 – The Service Controller Instance retrieves the selected AIM Metadata from the MPAI Store.
10 – The Service Controller Instance creates deployment description template and management structures for the resources required for the AIM launch.
11 – The Service Controller Instance initiates provisioning and Life Cycle management of the resources required for the AIM through the Cloud Management Service.
12 – The Deployment Service provisions the resources for the AIM and accompanies installation, configuration and through to operation.
13 – The installation and configuration procedures of the provisioned resources Retrieve the required Package(s) from Implementer’s repository.
14 – The Received Packages are checked for Validity, submitting the calculated fingerprint to the MPAI Store, prior to their ultimate activation.
At this point the Requested Module is running and ready to exchange messages.
15 – Remote Client application issues an Input Port Message request to the MAS API Service providing the Data Object for delivery to the indicated Port of the identified Module of the specified Controller.
16 – The MAS API Service resolves the Controller and corresponding Module and request delivery of the Data Object to the corresponding Input Port of the deployed Module.
17 – Remote Client application issues an Output Port Message request to the MAS API Service for retrieval of the Data Object from the indicated Port of the identified Module of the specified Controller.
18 – The MAS API Service resolves the Controller and corresponding Module and requests retrieval of the Data Object from the corresponding Output Port of the deployed Module.
19 – The MAS API Service returns the received Output Data Object to the requesting Remote Client Application.
The exchange of messages may continue as required to satisfy the needs of the Remote Client Application.
20 – The Remote Client Application issues a Stop Module Request to the MAS API Server.
21 – MAS API Service forwards the Stop Module request to the identified Service Controller Instance.
22 – The Service Controller Instance requests termination of the resources provisioned for the AIM through the Cloud Management Service.
23 – The Remote Client Application issues a Terminate Controller Request to the MAS API Server.
24 – MAS API Service terminates the indicated Service Controller Instance.
4 Sequence diagram
5 Life cycle
Figure 2 – The life cycle of an MPAI as a Service Instance
