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 strazpdj@gmail.com am803u@att.com 12/12/2017

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

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

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!

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

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

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?

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

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

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

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

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

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