Skip to end of metadata
Go to start of metadata

SMO - Model Catalog

The Model Catalog provides a list of Applications that are onboarded to the SMO after delivery of an "Application Package" from a vendor. It presents a Model-View-Controller for management of the data.

For the purposes of this implementation we will assume the following:

  • The Controller will be RESTful from the service endpoint of {apiRoot}/ModelCatalog/v1. The initial REST resource tree is show below. Additional resources may be added to represent aspect of ML Applications which have additional data elements.

 Click here to view PlantUML...

scale 1.5

  • The Model is represented in the class diagram below

 Click here to view plantUML


Class Application {
   applicationVersionID : string
   vendor : string
   applicationName : string
   version : string
   serviceModels : ServiceModel[]
   state : string
   revisionID : string

Class ServiceModel {
   serviceModelID : string
   modelName : string
   modelDescroption : string
   resources : ServiceResource[]

Class ServiceResource {
   resourceID : string
   resourceType : string
   resourceVendor : string
   resourceName : string
   resourceVersion : string
   deploymentDescriptor : DeploymentDescriptor
   descriptorVariableOverrides : Tuple[]
   applicationConfigurationSchema : string
   policyTypes : PolicyType[]
   dataFeeds : DataFeed[]
   publications : Publications[]
   requiredImages : ImageID[]

Class Tuple {
   key : string
   value : string

Class DataFeed {
   sharedDataName : string
   mandatory : boolean

Class Publication {
   sharedDataName : string
   mandatory : boolean

Class PolicyType {
   policySchema : string
   policyStatusSchema : string

Class DeploymentDescriptor {
   descriptorType : string
   descriptor : string

Application "1" *-- "1..*" ServiceModel
ServiceModel "1" *-- "1..*" ServiceResource
ServiceResource "1" *-down- "1" DeploymentDescriptor
ServiceResource "1" *-down- "0..*" Tuple
ServiceResource "1" *-down- "0..*" PolicyType
ServiceResource "1" *-down- "0..*" DataFeed
ServiceResource "1" *-down- "0..*" Publication


  • The View will be JSON.

The Application record in the Model Catalog follows a Stateful lifecycle. The State can be updated with a partial update (PUT) as long as the current revisionID is supplied as a query parameter. Upon a successful update the revisionID will be changed by the system to a newly generated value.

The valid values for State are "VALIDATED", "TRAINING_REQUIRED", and "AVAILABLE". The state transitions allowed are:

 Click here to view plantUML...

VALIDATED : The validated package is sequestered into the catalog. This protects the process from a
VALIDATED :  non-validated package from being supplied to the cataloging step that is different from the
VALIDATED :  one provided on the validation step.


TRAINING_REQUIRED : Training Iteration is tracked. It is initialized with a zero at validation.
TRAINING_REQUIRED : During training multiple training iterations may be applied.
TRAINING_REQUIRED : Therefore the count returned from training may increment by
TRAINING_REQUIRED : more than one. How we manage the availablity for different
TRAINING_REQUIRED : trained instances is FFS. For now only the latest trained

AVAILABLE : This is an application in which the Run-Time can create a configuration for.
AVAILABLE : However, we may need to consider training iteration count as after a
AVAILABLE : configuration is created, additional training might become required
AVAILABLE : a determination needs to occur as FFS if we invalidate existing configuration
AVAILABLE : which raises a question on "RUNNING" instances. Or do we allow the
AVAILABLE : deployment of any iteration that reaches the AVAILABLE state.


  • No labels