Chris, your very last point is one that crossed my mind too. The
createPullPoint interface creates and subscribes a newly PullPoint resource
to all messages. It seems it would be useful/efficient to have another
signature of the interface which can take a Filter argument (similar to how
the subscribe() interface works).
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 28, 2007 4:43 AM
Subject: RE: extending wsn-consumer with other webservice methods
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
