1. Using the MEF Core Model in ONAP John Strassner, Ph. D. Andy Mayer, Ph
Using the MEF Core Model in ONAP John Strassner, Ph.D. Andy Mayer, Ph.D. Chair, Modelling Projects, MEF PTL ONAP ExtAPI TMF Distinguished Fellow MEF Legato API Lead
12/12/2017

2. Models That the MEF Has to Offer for ONAP
A robust core information model (MCM) that defines common concepts that other models use
Based on a set of standard patterns as well as novel new patterns
A robust and novel policy information model that provides abstractions to enable imperative, declarative, and intent policies that are represented and managed using a single model
Enables any policy programming paradigm to be abstracted as a set of statements that make up a program
A resource model, harmonized with ONF TAPI, for working with connectivity, inventory, and management of resources
ONF TAPI can thus be reused
A generic metadata model

3. Benefits of Using MEF Models
Extensibility
Based on standard patterns (some 20+ years of proven usage)
Based on new patterns needed to support ICT applications
Providing an Integrated View
Fragmented views make it difficult to follow common architectural guidelines and use multiple data models
Model-driven Engineering
Models are used for everything – design, development, implementation, documentation, testing, …
APIs and Domain-Specific Languages (DSLs) are Supported
The model defines a common lexicon that defines the elements of the API and the grammar of the DSL
MEF Models can be used out of the box to improve ONAP models

4. Examples of Existing Problems and How to Fix Them (1)
Recursive relationships are dangerous:
All subclasses inherit this, so you must be careful to follow Liskov substitution when using it
Cannot differentiate between an atomic instance and a composite instance (i.e., fails to provide a single responsibility)
Must implement additional constraints to prevent cycles (e.g., your grandfather cannot be your grandson)
Cannot differentiate between a tree and a forest
Inconsistent
A Whole-Part Relationship cannot have this multiplicity!

5. Examples of Existing Problems and How to Fix Them (2)
Solution: Use the Composite Pattern
Note: The MEF Core Model defines Product, Resource, and Service using this pattern
Example
Common Interface Definition
Standalone Objects
Composite object; container-specific operations can precede or follow child operations

6. Examples of the Composite Pattern Used in the MCM
Composite pattern usage in MCM for Product, Service, and Resource (other places not shown)

7. Examples of Existing Problems and How to Fix Them (3)
Which version applies to which contained object?
Creates cycles X
Violates encapsulation!
This does NOT change the cardinality of the aggregation!
The properties in xxxValue are not a function of the relationship
EVERYTHING in the shaded area must be repeated FOR EACH CHARACTERISTIC!
Properties should be inherited. If there are no standard characteristics, how are new ones recognized?

8. If the Goal of the Previous Slide was Dynamicity…
This pattern is fundamentally static
Builds a class to contain attributes to substitute into another object
Attribute control requires additional relationships to other classes
This pattern creates a large number of classes and relationships to provide a small increase in functionality
The functionality is limited to choosing among pre-defined values
The decorator pattern is far more flexible
Defined in 1995
Used (for example) in Java and most windowing toolkits
Enables all or part of an object to be used to construct a new object at runtime

9. The Decorator Pattern Extension via composition
Uses a base interface to create variations on a specific object that can be composited to add specific attributes and/or behavior
Enables functionality of an object to change dynamically

10. The MEF Decorator Provides Object Consolidation and Additional Extensibility
Feature
Existing Approach
Using a Decorator
Number of Classes Required to Implement ONE Feature
ELEVEN Service + 5 Classes; ServiceInstance + 1 class; 3 Association Classes
FOUR Service, ServiceInstance, a Decorator Class, and a DecoratedFeature Class
Number of Relationships Required to Implement ONE Feature
TEN Association between Service and ServiceInstance; 5 for Service*, 4 for ServiceInstance**
TWO Association between Service and ServiceInstance; Aggregation to implement the Decorator
Number of Total Objects to Implement ONE Feature
TWENTY ONE
SIX
Number to Implement FIVE Features
FORTY SEVEN CLASSES
FORTY SIX RELATIONSHIPS
NINE CLASSES
SIX RELATIONSHIPS (really method calls)
Change attributes values
YES, by pre-defining values
YES, can also use class methods
Change behavior NO
YES (execute methods before and/or after decorator is called)
Using a Decorator
1 Decorator
1 or more classes for decoration
1 relationship to decorate object
Total number of objects (same assumptions)
1 decorator
1 aggregation
Have the flexibility to:
Add all or part of an object
Execute methods at the beginning or the end of the delegation
Key point: no compilation needed
* Not counting recursive aggregations
** Not counting association marked for deletion

11. Business Applications Business Applications
REFERENCE ARCHITECTURE
Customer Domain
SP Domain
Partner Domain
Cantata
(CUS:BUS)
Business Applications
Business Applications
Sonata
(BUS:BUS)
Customer
Application Coordinator
LEGATO
(BUS:SOF)
LEGATO
(BUS:SOF)
Service Orchestration Functionality
Interlude (SOF:SOF)
Service Orchestration Functionality
Allegro
(CUS:SOF)
Presto
(SOF:ICM)
Presto
(SOF:ICM)
Infrastructure Control and Management
Infrastructure Control and Management
ADAGIO (ICM:ECM)
ADAGIO (ICM:ECM)
Element Control and Management
Element Control and Management
Network Infrastructure

12. SOF Interface Reference Points
Service feasibility;
Service provisioning configuration & activation;
Request fallout;
Usage events & metrics;
License accounting;
Service performance & quality (e.g., KPI);
Service trouble management;
Service policy;
Capacity engineering;
Address allocation management;
SOF Interface Reference Points
LEGATO
Dynamic service control;
Service state info;
Service performance & quality;
Service related alerts;
Service Orchestration Functionality
Dynamic service control;
Service parameter config;
Service state info;
Service performance info;
Service problem alerts
ALLEGRO
INTERLUDE
PRESTO
Connectivity and network function feasibility;
Configuration, activation, and management of connectivity and logical network functions;
Topology and routing;
Performance and Fault;
Connectivity policy

13. Work in Progress
Work jointly with MEF and ONAP External API Project in defining Use Cases and Information Model for Legato and Interlude
Leverage MEF Operational Threads and revise MEF 56, Interface Profile Specification: Service Configuration and Activation, to reflect consistent Use Cases
The Service Descriptor Model is key to Model Driven Orchestration
Work with ONAP and TM Forum define the Service Catalog and Service Instantiation API is a model driven and extensible fashion