|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (2)
View Page History
...
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. * *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, ...)
* *Resource:* Get node resources (services, descriptions, ...)
...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...