The DSB provides an implementation of the ESManagement Management API as defined at [http://research.petalslink.org/display/esstar/Es-Management]. Details of this implementation is given below.
h2. Endpoints
Services are exposed by the DSB Web service kernel feature based on annotation introspection:
* *UserManagement*: [http://localhost:7600/petals/ws/UserManagement]
* *AdminManagement*: [http://localhost:7600/petals/ws/AdminManagement]
h2. Implementation
The ESManagement API implementation is based on the reuse of the [Core DSB Management API|petalsdsb:DSB Core Management] when operation are available by default. If not available, the operation are added to the core API and then exposed using the ESManagement component.
Most of the current operation are already available in the DSB Management API and are just translated by the ESManagement component:
* *WSN-Support:* The ESManagement API provides some Web service Notification operations; All the calls are forwarded to the DSB WSN kernel component.
** {info}NOTE that due to issues in the WSN library, the incoming subscribe and notify calls are modified to add topic namespace which is not available in the current CXF binding. This WSN channel is then not usable for other topics but just for the BSM ones. See below for details.{info}
* *Service Management:* Binding, exposing and proxifying services are based on the DSB Management API
* *Resource:* Get node resources (services, descriptions, ...)
h2. Sources
The ESManagement is implemented in the *{_}dsb-kernel-esmanagement{_}* module and configured in the final DSB distribution in the *{_}ManagementAPI\*_* fractal configuration files.
h2. Issues
The services are exposed using the Web service feature of the DSB which is based on CXF and JAXB bindings. Due to some design issue on the EBM WSN library, the way topics QName are defined in the subscribe and notify payloads is bad : The NS URL is disappears in the message we receive on the DSB side.
For now, this is hacked by adding the NS URL in the code itself: If we receive a message with a locally supported local name, we add the NS URL manually. Due to this fix, this ESManagement channel must only be used with care. For all other WSN related stuff, the best way is to use the standard WSN channel exposed by the DSB which supports these badly defined topics...
Supported topics for this esmanagement API are hardcoded in org.petalslink.dsb.kernel.esmanagement.NotificationProxy
{code:language=java} static final QName CREATION_TOPIC = new QName("http://www.petalslink.org/resources/event/1.0",
"CreationResourcesTopic", "bsm");
static final QName RAWREPORT_TOPIC = new QName("http://www.petalslink.org/rawreport/1.0",
"RawReportTopic", "bsm");{code}
h2. Endpoints
Services are exposed by the DSB Web service kernel feature based on annotation introspection:
* *UserManagement*: [http://localhost:7600/petals/ws/UserManagement]
* *AdminManagement*: [http://localhost:7600/petals/ws/AdminManagement]
h2. Implementation
The ESManagement API implementation is based on the reuse of the [Core DSB Management API|petalsdsb:DSB Core Management] when operation are available by default. If not available, the operation are added to the core API and then exposed using the ESManagement component.
Most of the current operation are already available in the DSB Management API and are just translated by the ESManagement component:
* *WSN-Support:* The ESManagement API provides some Web service Notification operations; All the calls are forwarded to the DSB WSN kernel component.
** {info}NOTE that due to issues in the WSN library, the incoming subscribe and notify calls are modified to add topic namespace which is not available in the current CXF binding. This WSN channel is then not usable for other topics but just for the BSM ones. See below for details.{info}
* *Service Management:* Binding, exposing and proxifying services are based on the DSB Management API
* *Resource:* Get node resources (services, descriptions, ...)
h2. Sources
The ESManagement is implemented in the *{_}dsb-kernel-esmanagement{_}* module and configured in the final DSB distribution in the *{_}ManagementAPI\*_* fractal configuration files.
h2. Issues
The services are exposed using the Web service feature of the DSB which is based on CXF and JAXB bindings. Due to some design issue on the EBM WSN library, the way topics QName are defined in the subscribe and notify payloads is bad : The NS URL is disappears in the message we receive on the DSB side.
For now, this is hacked by adding the NS URL in the code itself: If we receive a message with a locally supported local name, we add the NS URL manually. Due to this fix, this ESManagement channel must only be used with care. For all other WSN related stuff, the best way is to use the standard WSN channel exposed by the DSB which supports these badly defined topics...
Supported topics for this esmanagement API are hardcoded in org.petalslink.dsb.kernel.esmanagement.NotificationProxy
{code:language=java} static final QName CREATION_TOPIC = new QName("http://www.petalslink.org/resources/event/1.0",
"CreationResourcesTopic", "bsm");
static final QName RAWREPORT_TOPIC = new QName("http://www.petalslink.org/rawreport/1.0",
"RawReportTopic", "bsm");{code}