Architecture Documentation

API Documentation

Project Meeting Documentation

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 main project page