lsoapi:documents:architecture
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
lsoapi:documents:architecture [2015/08/28 17:33] Steven Saunders |
lsoapi:documents:architecture [2015/09/11 21:00] (current) Kevin Luehrs |
||
|---|---|---|---|
| Line 73: | Line 73: | ||
| __<xxxbase>__ | __<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 results in in a __xxxbase.jar__ file. This .jar file for each of these directories, that can be (and is) used by any of the service layers, which is why the are packaged in a seperate .jar file. | + | __<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>__ in general is structured as follows: | + | The contents of the __<xxxbase>__ directory in general is structured as follows: |
| - | (again, remember that **xxx** = cos, or evc, or svc, or uni) | + | (again, remember that **xxx** represents a MEF entity, specifically : cos, or evc, or svc, or uni) |
| - | <xxxbase>/src/main/java/com/cablelabs/vcpe/**xxx**/**xxx**base/ | + | <xxxbase>/src/main/java/com/cablelabs/vcpe/xxx/xxxbase/ |
| - | <client> ...... code supporting the sending of REST messages to the **xxx** server | + | <client> ...... code supporting the sending of REST messages to the xxx server |
| - | <model> ....... defines the **xxx** class with accompanying MEF attributes | + | <model> ....... defines the xxx class with accompanying MEF attributes |
| - | <repository> .. data store for **xxx** entities | + | <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]] | ||
| + | | ||
lsoapi/documents/architecture.1440783214.txt.gz · Last modified: 2015/08/28 17:33 by Steven Saunders
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
