This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
lsoapi:documents [2015/08/10 17:07] Kevin Luehrs created |
lsoapi:documents [2015/10/02 02:17] (current) Kevin Luehrs |
||
---|---|---|---|
Line 1: | Line 1: | ||
==== Connectivity Services LSO Project Documents ==== | ==== Connectivity Services LSO Project Documents ==== | ||
- | === Requirements === | + | === Design Documents === |
- | | + | [[/lsoapi/documents/architecture|Architecture Documentation]] |
- | === Architecture === | ||
+ | [[/lsoapi/documents/apis|API Documentation]] | ||
+ | |||
+ | === Other Project Documents === | ||
+ | |||
+ | [[/lsoapi/documents/Meeting_Docs|Project Meeting Documentation]] | ||
| | ||
+ | === Considerations for Future Development === | ||
+ | |||
+ | The current version is a proof of concept prototype implementation of REST service layers enabling the creation and management of MEF EPL Services. Being a proof of concept prototype, there are areas, which intentionally received superficial coverage, or no coverage at all. Following are items to consider when evolving this to a production-oriented implementation. | ||
+ | |||
+ | __Representation of All MEF Services__ | ||
+ | Only EPL service has been implemented for the prototype. | ||
+ | * Currently, the service repo is hard coded to hold EPL services | ||
+ | * Moving forward it may make sense to model a general the MEFSvc class along with derived Eline/ELine/Tree classes | ||
+ | * Moving forward it may make sense to refactor the SvcMgr in order to handle multiple service types from a REST API perspective and from a persistence perspective | ||
+ | |||
+ | __Representation of all MEF Attributes__ | ||
+ | The prototype currently models an EPL, and EVC, an EVCPath, and a UNI. For each of these MEF entities, only a subset of the MEF attributes were included in the prototype. A more detailed analysis of the MEF attributes, and interrelations between these attributes will be needed to allow for complete representation and modeling of the MEF entities and associated MEF attributes. | ||
+ | |||
+ | __Multi Operator Service__ | ||
+ | The prototype is currently only representing a single operator scenario. As this software evolves, supporting multi-operator scenarios (i.e. ENNI's and OVCs) will be needed | ||
+ | |||
+ | __Exception Handling__ | ||
+ | For the prototype, exception handling is only superficially implemented. A production system should include a more robust exception handling and error reporting architecture | ||
+ | |||
+ | __Test Suite__ | ||
+ | The prototype includes a junit based set of tests. This test suite is reasonable, but not exhaustive. Production targeted version should include more thorough test coverage | ||
+ | |||
+ | __Configurability__ | ||
+ | Currently a number of pieces of information are hardcoded in the prototype ,and future efforts should consider adding configurability (for example via a config. file) | ||
+ | * IP/Port Information RE various servers in the system (ODL RESTCONF server and the cosmgr, evcmgr, svcmgr service layers). | ||
+ | * Rest paths for the various services (ODL RESTCONF server and the cosmgr, evcmgr, svcmgr service layers) | ||
+ | * ODL REST communications Authentication Credentials (currently admin/admin is hardcoded into all rest calls to ODL) | ||
+ | |||
+ | __Persistence__ | ||
+ | The service layers cosmgr, evcmgr, svcmgr currently store instances of created MEF entities via an in memory database (hashmaps). Production oriented evolution should implement disk based data persistence. | ||
+ | |||
+ | __Entity IDs__ | ||
+ | Currently IDs for EVC, and UNI are being generated via an internal counter. This of course does not scale nor survive restart. A proper unique ID generation approach will be needed for production. | ||
+ | |||
+ | Return to [[/lsoapi| main project page]] |