1) the producer pushes to subscribers (well the SubscriptionManager does).
2) the default impl in muse only keeps the messages in memory, but it may be something i fix (store to db / flat file) later. 3) the app which requested that a PullPoint be created subscribes to the producer with the PullPoint EPR as its subscription endpoint. !!! The important thing about PullPoints is that the current Muse implementation doesn't actually work as expected (see other posts on the subject by me and others) as it subscribes to everything a producer might send. Via 3) it is just another resource that must subscribe. Before subscribing it should do/collect nothing. -----Original Message----- From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 9:05 AM To: [email protected]; Kam K. Yee Subject: RE: extending wsn-consumer with other webservice methods Yep, that's also possible. But now you get into the "stateful" realm, which gets a little more complicated. 1) Will the PullPoint resource subscribe to the producer for notifications, or must the producer push to the PullPoint? 2) The PullPoint will either require configuration/fine-tuning (i.e. where will messages be stored, for how long, etc), or require custom code to pull notifications directly from the underlying layer (assuming the underlying layer keeps a history of the notifications). -----Original Message----- From: Kam K. Yee [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 11:05 PM To: [email protected] Subject: Re: extending wsn-consumer with other webservice methods Along the same thread of discussion, could another possible implementation pattern be to have a stand-alone client application which periodically polls a producer resource (residing on the server) for its available, stored notification messages. I'm thinking this could be done by having the producer resource provide the operations from PullPoint, DestroyPullPoint and CreatePullPoint. The stand-alone client application would request the resource to create a new PullPoint resource (via createPullPoint() operation which returns an EndpointReference) which the client could periodically poll for new messages (via the getMessages() operation). ----- Original Message ----- From: "Vinh Nguyen (vinguye2)" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, September 28, 2007 12:35 AM Subject: RE: extending wsn-consumer with other webservice methods Yes, what you want to achieve is possible and not difficult to do at all. There are two general designs: 1) Create a client app which acts as a simple stand-alone broker (as the Muse samples show). The client calls the producer resource, and subscribes another resource as the consumer. The client app itself doesn't have to reside on a server at all. 2) Combine both your client code and consumer resource into a single server application. Put your client code into a custom capability and attach it to your consumer resource. When you invoke this capability operation, it would then contact the remote producer and subscribe the consumer for notifications. Just make sure your consumer app includes the necessary client jars. You will also have to create a custom wsdl that imports the operations of WS-BaseNotification-1_3.wsdl, and add your custom operation to your wsdl (i.e. like the wsn-producer sample wsdl, which also imports operations it needs from the WS-BaseNotification-1_3.wsdl). In general, you can do anything you want in a capability. The Muse samples just happen to separate the client code into a separate app. Remember, in web services, a server application can also be a client itself. Not only does it receive requests from other web apps, but it can also send requests to other apps. How much client behavior you want your server app to have...depends on your design requirements. -Vinh -----Original Message----- From: crichmond [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 6:43 PM To: [email protected] Subject: Re: extending wsn-consumer with other webservice methods So let me ask you this...using the sample wsn-producer...is it possible to build a regular web services remote client that does the subscribe and publish actions that the WsnTestClient does..only remotely via web service call rather than using the programming model like the sample does. It seems to me that generating subscriptions from a remote system and publishing messages from remote systems is a common scenario, but I can't figure out how that fits into the sample..being that the samples have that test client that runs on the local server using the api callss. Is there a sample of doing what the WsnTestClient does only using remote webservice calls from a custom client rather than the object model. Thanks, Saurabh Dravid wrote: > > 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-met > hods-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] > > > > -- View this message in context: http://www.nabble.com/extending-wsn-consumer-with-other-webservice-metho ds-tf4518830.html#a12933360 Sent from the Muse User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
