Open-O Client Project Proposal Version 0.5 Reviewed Draft Client: Tao Shen (CMCC) GUI: Seshu Kumar M (Huawei ) CLI: Kanagaraj Manickam (Huawei)

Repository name : Client Project Description Overview Project Name : Client Repository name : Client Project Description This project aims to provide an unified GUI and CLI for the Open-O functionalities provided over RESTful API. In addition, it provides java & js sdk for Open-O services. Project Participants China Mobile, Huawei, ZTE

Architecture Alignment Client GUI CLI TOOLs JS sdk Java sdk Common Service Orchestrator Service Global Service-O SDN-O NFV-O Driver

One Portal to command whole Open-O !! GUI One Portal to command whole Open-O !!

GUI: Problem Statement OPEN-O Portal currently is not unified and no common framework is provided for the individual pages. No rules and restrictions defined on UCD or usability. Hence OPEN-O currently has a difference in look and feel between the pages from different partners.

GUI: Solution Strong extensibility of functional modules The Client project can add or delete function modules more easily. Portal applications can be decoupled from each orchestrator so that developers can work independently and integrate function modules into the Client system for no-interference. Low dependence on operation system The Client project adopts HTML and Javascript technology to reduce dependence on operation system. Portal applications can be deployed to the web server more simply and implement orchestrator services by calling RESTful APIs. Offering identical presentation style The common module defines coherent presentation style for other functional modules as the framework of Client system. Function modules can import defined style without concern of details to give users a sense of uniformity. Providing third-party software The common module can import open source third-party software as developers need. It means that the third-party software can be managed by Client framework to avoid repeated import.

GUI Single Dashboard Main page for all the views needed for the OPEN-O User Hop based interlinking between the different portals. Easy to integrate the new portal pages and plug & play OPEN-O Dashboard OPEN-O Server

(Widgets, like the combo, text box, check box, radio, tree, table,) GUI Framework Browser Event and error handling Message dialog Confirmation dialog Warn, error, info dialog Models (Widgets, like the combo, text box, check box, radio, tree, table,) HTML object CSS object Pre defined Operation Workflow, step1, step2, step3 Create , modify Delete

GUI Framework Browser as view GUI Templates Mustache js Angular JS Base for the MVC Browser as view Mustache js Templates User Operation GUI Update Data binding Model Controller Update Notify

GUI: Proposed Solution New GUI HTML CSS Existing Model Java Script (Angular JS) XmlHttpRequest based request GSO SGW (App Server on NodeJS) SDNO NFVO Driver REST request

GUI: Advantages We will have the look and feel everywhere in the OPEN-O application Easy to develop the Portal and will reduce the effort for the developers There is a defined place for all the functionality and if any error occur, stabilizing is much faster Even a non experienced person can use it better and can implement intended business logic We will have extension scope much better, i.e., if required portability of the UI will be much better to a new technology.

One Command to command whole Open-O !! CLI One Command to command whole Open-O !!

Why CLI/SDK needed ? CLI: SDK (java api): Helps to automation Helps to expand Open-O eco-system Existing operator environment New Business 3rd party integration operator-friendly concise/powerful SDK (java api): Helps to avoid code-duplication/re-implementation Detects the REST API version/schema changes at compile time itself, than run-time 1:1 mapping between REST API and java api

CLI: Problems faced in Sun release are addressed ! Problem: When micro-service (A) is used by more than one micro-services, say, B & C, both of these services re-implemented/repeated the integration code for service A. in sun release, ESR and DM services got integrated by many services and each of them re-implemented (copied) the code across. Solution: As every micro-service provides sdk jars, dependent micro-services could directly use it via maven dependency, instead of re-implement/repeating the code (copy & paste) This will completely avoid maintenance over-head introduced in sun release Problem: When a micro-service (A) depends on another micro-service (B), and when B changes the REST API, A will fail when user runs it. This has become a BIG blocker issue in CMCC lab during sun release time. Solution: As part of CLI project, each micro-service would provide an java client library jar (SDK), which is auto-generated from swagger.json of that micro-service. So when changes made in REST API of micro-service A, automatically B will fail as listed below: Now B uses A sdk to connect to A using mvn dependency, instead of re-implementing the integration. A changes REST API A sdk jar got auto-updated (changes in java method signature/model change, etc) Now Mvn build of B will break as dependent A sdk jar is changed. Developer will fix B to use updated A sdk jar. This problem is identified in compile time than run time. (early detection and recovery)

CLI: Birds-view Open-o GUI GSO SDNO Open-O API gateway Micro-service interface Preferred by CLI admin GUI user SDK (java lib) developer GSO SDK GSO Micro-service SDK user SDNO SDK Micro-service SDK SDNO Micro-service Micro-service developer Open-O API gateway MSB Micro-service Micro-service Micro-service NFVO SDK NFVO Micro-service SDK Open-o CLI Micro-service SDK ComSDK COMMON-O admin Sdk = java/js api library New Projects

CLIENT

Client: Project details Both CLI and GUI projects will be governed under new project called ‘client’ Following sub-projects are provided: Openo-gui : For GUI project Openo-cli : For CLI project Using swagger, each service would be enabled to generate version-specific-java library/jar (sdk) Contact person shentao@chinamobile.com (PTL) Initial Committers CMCC : shentao@chinamobile.com Huawei : seshu.kumar.m@huawei.com (GUI) kanagaraj.manickam@huawei.com (CLI) tian.ming@huawei.com quanzhong@huawei.com ZTE : huang.jian12@zte.com.cn li.zi30@zte.com.cn Developers committed to the project yangyanyj@chinamobile.com sukeshac@huawei.com yuhao10@huawei.com chenchuanyu@huawei.com sun.qi310@zte.com.cn wang.miao6@zte.com.cn lv.bo163@zte.com.cn wan.dong@zte.com.cn

Thanks Open-O Team