<-Security API Go to ToC Data Types ->

This chapter is informative. It explains how MPAI as a Service (MPAI-MAS) relates to MPAI-AIF. MPAI-MAS is specified in its own Technical Specification.

1 What MPAI-MAS does

Figure 1 depicts MPAI as a Service in the terms of MPAI-AIF.

Figure 1 - MPAI as a Service in the terms of MPAI-AIF

Figure 1 – MPAI as a Service in the terms of MPAI-AIF

MPAI-MAS lets a client run a Module of MPAI-AIF on a machine it does not own. A Service offers Applications; a client uses one of them from its device, and the AIMs run in the Service. Seen from MPAI-AIF, MPAI-MAS is the Controller API carried over HTTPS, together with what a network adds: the creation and deletion of Controllers, the discovery of what a Service offers, and the provisioning of the machines on which AIMs run.

Table 1 – MPAI-MAS in the terms of MPAI-AIF

MPAI-MAS MPAI-AIF
Remote Client Application A remote User Agent: its Workflow, its Physical Layer and its Controller API client, on the device of the client.
MAS API Service The endpoint of the Service. It creates and deletes Controller Instances and forwards to them the requests of the Controller API.
Service Controller Instance A Controller, running one Module for a client.
MPAI Store The MPAI Store, from which a Service obtains the approved AIM Instance Metadata of its Modules and the Implementations it names.
Deployment Controller and deployed resources The machines a Service provisions for the AIMs of a Module. An AIM placed on another machine runs there on an AIM host, under the one Controller of its Module.

2 A session, step by step

The life of a Service Controller Instance is: create it; start a Module; exchange Messages with the boundary Ports of the Module as often as needed; stop the Module; delete the Instance. Each step is one function of the Controller API (Basic API) carried over HTTPS (Table 2).

Table 2 – The life of a Service Controller Instance

Step MPAI-MAS request Controller API function
Create the Instance POST /MPAI/AIFU/Controller MPAI_AIFU_Controller_Initialize
Start a Module POST /MPAI/AIFU/{cid}/MODULE/Start MPAI_AIFU_MODULE_Start
Pause, resume, status .../MODULE/{mid}/Pause, /Resume, .../MODULE/{mid} MPAI_AIFU_MODULE_Pause, _Resume; MPAI_AIFU_AIM_GetStatus
Send an input POST .../MODULE/{mid}/Input/{pid} MPAI_AIFU_MODULE_Input_Write
Receive an output GET .../MODULE/{mid}/Output/{pid} MPAI_AIFU_MODULE_Output_Read
Stop the Module .../MODULE/{mid}/Stop MPAI_AIFU_MODULE_Stop
Delete the Instance DELETE /MPAI/AIFU/Controller/{cid} MPAI_AIFU_Controller_Destroy

In these requests, {cid} identifies the Controller Instance, {mid} the Module, and {pid} a boundary Port, by its Data Type and, where needed, its Port Number – for example OSD-BTO-V1.5:2. The body of an input or an output is the JSON form of the Data Type. Over MPAI-MAS a Module runs by exchange: the first output read after one or more inputs are sent runs the Module on those inputs (Execution).

3 From an Implementer to a client

MPAI-MAS describes how an AIM made by an Implementer reaches a client. In the terms of MPAI-AIF:

  1. The Implementer registers with the MPAI Store and submits the AIM Instance Metadata of its Implementation, which names where the Implementation is.
  2. The Service offers Applications built on approved Metadata. A client discovers them – by search, by category, through their descriptors – and chooses one.
  3. The client asks the Service to create a Controller Instance and to start the Module of the Application.
  4. The Controller obtains the approved Metadata of the Module from the MPAI Store and has resources provisioned for its AIMs where their Relation places them elsewhere.
  5. The Implementation is obtained from the Implementer’s repository and verified against its fingerprint before it runs.
  6. The client exchanges Messages with the boundary Ports of the Module, as its Workflow states.
  7. The client stops the Module and deletes the Controller Instance.

4 Control plane and data plane

MPAI-MAS separates the creation and termination of infrastructure – the control plane – from the exchange of Messages – the data plane – so that application data is not exposed to the control plane. It is the distinction MPAI-AIF makes inside a Controller, which decides which AIM may reach which Port and need not carry the data. MPAI-MAS applies it between machines: whoever provisions and manages the infrastructure does not see what the Application exchanges.

5 Sessions and clients

One Service serves many clients at once. Each client has a session; what a Module keeps for a session – for example, what a person registers – belongs to that client, and is deleted when the session ends, when the client leaves or after a period of silence set by the Service (MPAI_AIFU_Session_Serve, MPAI_AIFU_Session_End). A Controller Instance, and a Module within it, answer only the client that created them.

6 Security

The crossing between a client and a Service is a crossing between machines, and Zero Trust applies to it in full: TLS on every request, with no exception for a loopback address, a private network or a tunnel; authentication of each client on every request, by an identity of that client rather than a secret shared by all; authorisation per request; the control plane authenticated to the Service Controller Instance and never given application data; and every Implementation verified before it runs.

7 An example

The Applications of the MPAI-MAS Reference Software include a conversation with a machine that has a face and a voice (MMC-MAD), a personal digital assistant that answers questions about pictures, and a newspaper reader. A browser on a phone or a desktop is the Remote Client Application: it acquires speech, text and pictures through its Physical Layer, sends them to the boundary Ports of the Module, and presents what the Module returns – speech and the face descriptors that animate an avatar. All the AIMs run in the Service.

<-Security API Go to ToC Data Types ->