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

2. 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

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

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

5. 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.

6. 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.

7. 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

8. (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

9. 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

10. 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

11. 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.

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

13. 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

14. 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)

15. 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

16. CLIENT

17. 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
(PTL)
Initial Committers
CMCC :
Huawei :
(GUI)
(CLI)
ZTE :
Developers committed to the project

18. Thanks
Open-O Team