Hello OpenWSMan world.
Allow me to introduce myself. My name is Norm Paxton and I work at Novell.
Many of you may know me from the OMC project (http://www.omc-project.org)
I have been working on a new project in OpenWSMan: a requesthandler plugin to OpenWBEM to handle WSMan protocol requests directly.
You'll find this project at .../[project-root]/requesthandler/openwbem
OpenWBEM was architected to allow plugins for extensibility in many places. One of those places is in request handlers. OpenWBEM ships with two default request handlers: cim-xml and binary. However, it supports a plugin interface to allow openwbem to support other protocols as well. When the request handler loads (openwbem.conf tells openwbem where to load request handlers) it registers to handle specific content-types. In the case of wsman, the request handler registers to handle the 'application/soap+xml' content type. All of the http stack are handled by the openwbem server, and the request handler is called with the payload.
The request handler I have been writing will enable the openwbem server to 'internally / pseudo-natively' handle wsman requests, rather than having to have an app make cim client calls. A primary goal of this implementation is to use as much from the openwsman libraries as possible, so as to not 'reinvent the wheel.' This will make much of the maintenance and bug fixes central, not in multiple sources. So, the architecture of this request handler is to mirror as closely as possible a plugin to the wsmancli client, registering a "plugin," calling 'dispatch_inbound_call' and supporting the EndPoint callbacks.
Currently implemented are the enumerations. I am working on the 'Get' action. The code is still 'working code' - I don't claim it to be clean of bugs, or even all the xml to be compliant yet.
If you'd like to try to get it working, here are some tips:
* To get it to build, will need to move several .h files from library to include path. (Anas is currently addressing how to minimize the number of files needed, yet still providing all the necessary interfaces)
* In openwbem.conf, modify the 'owcimomd.request_handler_path' option to include path to the wsman request handler (or put the wsman request handler in the openwbem/requesthandlers folder
* in openwbem.conf, modify the 'http_server.http_port' to the wsman port (8889) or make sure to tell your wsman client of choice to make the request to port 5988 (openwbem default). If using wsmancli, add '--port 5988' to your command line.
* run openwbem in debug mode: 'owcimomd -d' to view output. You should (currently) see lots of debug messages (if configured with --enable-debug-mode option)
* currently will only support requests of 'http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/' resource. ie, following is sample wsmancli commandline to enumerate the OpenWBEM_UnitaryComputerSystem:
wsman enumerate -T http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/OpenWBEM_UnitaryComputerSystem~ --port 5988
note that the OpenWBEM_UnitaryComputerSystem is not part of the dmtf.org schema. I'm aware of this. Need to determine proper way to address this: Do I require a configuration of schemas that this requesthandler will support? How to do so? etc. Any thoughts would be appreciated.
Just thought to give a heads up on this work. Please contact with any questions or suggestions.
Software for the Open Enterprise
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Openwsman-devel mailing list
|Free forum by Nabble||Edit this page|