Hi, wsn-consumer sample specifies "NotificationConsumer" port type for muse resource in "WS-BaseNotification-1_3.wsdl" file. If you want to extend this sample by exposing more operations to client then you have to modify this wsdl file and include your operation definition in the same port type. So you have to add two wsdl operations "subscribe" and "getMessages" in "NotificationConsumer" port type. You needed to modify the "wsa:action" attribute for these two new operations, and finally if you are using Axis-2 as your soap engine then you needed to modify "services.xml" and include this "wsa:action" uri in that services file.
thanks With best regards, Saurabh Dravid, Staff Software Engineer - Autonomic Computing, India Software Lab, IBM Software Group Embassy Golf Links, 'B' Block, 4th Floor, Bangalore Phone: +91-80-51055494, e-mail: [EMAIL PROTECTED] About India Software Lab crichmond <[EMAIL PROTECTED]> 26/09/2007 03:42 Please respond to [email protected] To [email protected] cc Subject extending wsn-consumer with other webservice methods Hello, I'm having trouble determining how to go about extending the wsn-consumer sample. I have built, deployed, and tested the wsn-consumer, producer, and test client no problem but I want to do a small proof of concept which adds additional methods to the wsn-consumer webservice that are accessible to a small demo desktop application. Essentially I want to modify the wsn-consumer to add things like subscribe(), getMessages() etc, so that it can be polled by desktop applications and act as a subscriber proxy for those applications. I know that in theory I could be using PullPoint implementation, but baby steps first. So essentially I am not sure what wsdl's or xml files i need to modify in addition to the sample wsn-consumer classes(ConsumerCapabilityImpl?) to do this(essentially add in standard axis webservice methods that the custom clients can call. So if the client calls subscribe() web service call the consumer will act as a proxy and subscribe much the way the sample does, but it will then pool received notifications that can then be retrieved when the clients call a getMessages() of some sort. Again, this is a simple proof of concept to show how a proxy server that participates in the WS-* standards in MUSE could be built to serv custom applications that do not. Thanks for any help.... -- View this message in context: http://www.nabble.com/extending-wsn-consumer-with-other-webservice-methods-tf4518830.html#a12890108 Sent from the Muse User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
