Differences

This shows you the differences between two versions of the page.

--- lsoapi:documents:architecture [2015/08/24 20:18]
Steven Saunders
+++ lsoapi:documents:architecture [2015/09/11 21:00] (current)
Kevin Luehrs
@@ Line 10: / Line 10: @@
   * **MEF 6.2**: EVC Ethernet Services Definitions Phase 3, August, 2014
   * **MEF 10.3**: Ethernet Services Attributes Phase 3, October 2013
-  * **MEF 26.1**: External Network Network Interface (ENNI) – Phase 2, January 2012
 __Secondary MEF References__
+  * **MEF 26.1**: External Network Network Interface (ENNI) – Phase 2, January 2012
   * **MEF 4**: Metro Ethernet Network Architecture Framework - Part 1: Generic Framework, May 2004
   * **MEF 11**: User Network Interface (UNI) Requirements and Framework, November 2004
@@ Line 28: / Line 28: @@
 {{ lsoapi:documents:lso-service-layers.png?500 |}}
+=== Technology Dependencies ===
+The lsoapi service code is dependent upon the following technologies
+  * **Java**
+  * **Maven** to buid the lsoapi .war and .jar files
+  * **tomcat** to serve lsoapi .war files
+  * **JAXRS/Jersey** for REST interactions
+  * //see lsoapi/README.md for detailed instruction on installing these technologies//
+In addition of you need to run the OpenDaylight UNI-Manager emulator, the following dependencies come into play
+  * **nodejs/npm** to install dependencies for and run the UNI-Manager emulator nodejs app
+  * //see lsoapi/README.md for detailed instruction on installing these technologies//
+Finally, if you decide to run the demo-ui, the following dependencies come into play
+  * **nodejs/npm** to install dependencies for and run the nodejs serving the UI
+  * **bower** to install front end web UI dependencies (like angular)
+  * **grunt** for front end web UI preprocessing tasks (like less to css)
+  * //see lsoapi/demo-ui/README.md for detailed instruction on installing these technologies//
 === Code Organization ===
-lsoapi
+The **lsoapi** services code is organized into the following directory structure (directory names enclosed in <>).  Each directory identified below contains to a unique maven .pom file.
-|
-|_ common (common utilities packaged in __common.jar__)
+  <lsoapi> ........ project root directory
-|_ common
+    <common> ...... common utilities
+    <cos>
+      <cosbase> ... CoS code unrelated to providing REST services
+      <cosmgr> .... code for providing REST services to CRUD CoS instances
+    <svc>
+      <svcbase> ... MEF Services (EPL) code unrelated to providing REST services
+      <svcmgr> .... code for providing REST services to CRUD MEF Services (EPL) instances
+    <evc>
+      <svcbase> ... EVC code unrelated to providing REST services
+      <svcmgr> .... code for providing REST services to CRUD EVC instances
+    <uni>
+      <unibase> ... UNI code unrelated to providing REST services
+      <unimgr> .... OpenDaylight UNI Manger Emulator
+== A closer look at the directory structures ==
+In general, the <xxxbase> and <xxxmgr> directories (where **xxx** is __cos__, __svc__, __evc__, and __uni__, are organized in the same manner, as described below.
+__<xxxbase>__
+__<xxxbase>__ directories contain code that supports the definition and management of MEF entities, but contain no code specific to providing the REST service layer for that entity.  The build result in a __xxxbase.jar__ file for each <xxxbase> directory that can be (and is) used by any of the service layers, which is why they are packaged in a seperate .jar file.
+The contents of the __<xxxbase>__ directory in general is structured as follows:
+(again, remember that **xxx** represents a MEF entity, specifically : cos, or evc, or svc, or uni)
+  <xxxbase>/src/main/java/com/cablelabs/vcpe/xxx/xxxbase/
+    <client> ...... code supporting the sending of REST messages to the xxx server
+    <model> ....... defines the xxx class with accompanying MEF attributes
+    <repository> .. data store for xxx entities
+__<xxxmgr>__
+__<xxxmgr>__ directories contain code that supports the actual RESTFUL service for each MEF entity.  The code in contained in __<xxxmgr>__ may have dependencies on any of the __<xxxbase>__ .jar files (for example __<evcmgr>__ is dependent upon __<cosbase>__ in order to make rest calls the the **cosmgr** REST server.
+The contents of the __<xxxmgr>__ directory in general is structured as follows:
+  xxxmgr/src/main/java/com/cablelabs/vcpe/xxx/xxxmgr/*.java ... contains code for serving xxx rest requests
+== UNI manager emulator ==
+The one exception the the directory structures defined above is <unimgr> directory.  The lsoapi service layers do NOT include a UNI service layer (i.e. UNI manager), but rather, the UNI Manager will be contained within OpenDaylight.
+However, the lsoapi code base does provide a nodejs UNI Manager Emulator, which can receive and process all REST messages defined by the ODL UNI Manager northbound interface.  The emulator can be useful if you do not have OpenDaylight installed on you development machine, but you would like to test the UNI Northbound REST API messaging.
+Specifically, the <evcmgr> code consumes the ODL Uni manager northbound REST interface (i.e. it makes NETCONF REST calls to OpenDaylight, which can be alternately served by the emulator).
+The details for configuring and running the emulator can be found in the lsoapi/README.md file
+Return to [[https://wiki.opnfv.org/lsoapi| main project page]]

Wiki

User Tools

Site Tools

Differences

Page Tools