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:38] Steven Saunders |
lsoapi:documents:architecture [2015/09/11 21:00] (current) Kevin Luehrs |
||
|---|---|---|---|
| Line 75: | Line 75: | ||
| __<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. | __<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** represents a MEF entity, specifically : cos, or evc, or svc, or uni) | (again, remember that **xxx** represents a MEF entity, specifically : cos, or evc, or svc, or uni) | ||
| Line 83: | Line 83: | ||
| <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.1440783530.txt.gz · Last modified: 2015/08/28 17:38 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
