You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by crichmond <ch...@hawaii.rr.com> on 2007/09/26 00:12:28 UTC
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: extending wsn-consumer with other webservice methods
Posted by "Kam K. Yee" <op...@gmail.com>.
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: <Ch...@swisscom.com>
To: <mu...@ws.apache.org>
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:vinguye2@cisco.com]
Sent: Friday, September 28, 2007 9:05 AM
To: muse-user@ws.apache.org; 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:open.zourcerer@gmail.com]
Sent: Thursday, September 27, 2007 11:05 PM
To: muse-user@ws.apache.org
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)" <vi...@cisco.com>
To: <mu...@ws.apache.org>
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:chrisr@hawaii.rr.com]
Sent: Thursday, September 27, 2007 6:43 PM
To: muse-user@ws.apache.org
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: sadravid@in.ibm.com About India
> Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: extending wsn-consumer with other webservice methods
Posted by Ch...@swisscom.com.
hiya,
according to the standard interfaces (wsdl) this shouldn't be part of
the create, but the subscribe. Just like you'd normally subscribe you
do it with a pullpoint. When created a pullpoint shouldn't be listening
for anything at all. Each subsequent subscription should do that.
The code I posted a month or so ago works that way, fits the muse model
and the wsn better I think. Actually I haven't raised a Jira on this
yet as I was waiting for confirmation on the solution (that simply
returning true on the accept function is sufficient given that the
subscribe sets the relation up, not the pullpoint). Perhaps I should
just do that.
NOTE I haven't actually tried doing multiple subscriptions to a
pullpoint and then destroy() ing one of them, but it should work as its
just the extra subscription epr that is destroyed not the pullpoint.
-----Original Message-----
From: Kam K. Yee [mailto:open.zourcerer@gmail.com]
Sent: Friday, September 28, 2007 8:28 PM
To: muse-user@ws.apache.org
Subject: Re: extending wsn-consumer with other webservice methods
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.
----- Original Message -----
From: <Ch...@swisscom.com>
To: <mu...@ws.apache.org>
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:vinguye2@cisco.com]
Sent: Friday, September 28, 2007 9:05 AM
To: muse-user@ws.apache.org; 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:open.zourcerer@gmail.com]
Sent: Thursday, September 27, 2007 11:05 PM
To: muse-user@ws.apache.org
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)" <vi...@cisco.com>
To: <mu...@ws.apache.org>
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:chrisr@hawaii.rr.com]
Sent: Thursday, September 27, 2007 6:43 PM
To: muse-user@ws.apache.org
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: sadravid@in.ibm.com About India
> Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: extending wsn-consumer with other webservice methods
Posted by "Kam K. Yee" <op...@gmail.com>.
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.
----- Original Message -----
From: <Ch...@swisscom.com>
To: <mu...@ws.apache.org>
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:vinguye2@cisco.com]
Sent: Friday, September 28, 2007 9:05 AM
To: muse-user@ws.apache.org; 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:open.zourcerer@gmail.com]
Sent: Thursday, September 27, 2007 11:05 PM
To: muse-user@ws.apache.org
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)" <vi...@cisco.com>
To: <mu...@ws.apache.org>
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:chrisr@hawaii.rr.com]
Sent: Thursday, September 27, 2007 6:43 PM
To: muse-user@ws.apache.org
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: sadravid@in.ibm.com About India
> Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: extending wsn-consumer with other webservice methods
Posted by Ch...@swisscom.com.
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:vinguye2@cisco.com]
Sent: Friday, September 28, 2007 9:05 AM
To: muse-user@ws.apache.org; 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:open.zourcerer@gmail.com]
Sent: Thursday, September 27, 2007 11:05 PM
To: muse-user@ws.apache.org
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)" <vi...@cisco.com>
To: <mu...@ws.apache.org>
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:chrisr@hawaii.rr.com]
Sent: Thursday, September 27, 2007 6:43 PM
To: muse-user@ws.apache.org
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: sadravid@in.ibm.com About India
> Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: extending wsn-consumer with other webservice methods
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
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:open.zourcerer@gmail.com]
Sent: Thursday, September 27, 2007 11:05 PM
To: muse-user@ws.apache.org
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)" <vi...@cisco.com>
To: <mu...@ws.apache.org>
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:chrisr@hawaii.rr.com]
Sent: Thursday, September 27, 2007 6:43 PM
To: muse-user@ws.apache.org
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: sadravid@in.ibm.com About India
> Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: extending wsn-consumer with other webservice methods
Posted by "Kam K. Yee" <op...@gmail.com>.
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)" <vi...@cisco.com>
To: <mu...@ws.apache.org>
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:chrisr@hawaii.rr.com]
Sent: Thursday, September 27, 2007 6:43 PM
To: muse-user@ws.apache.org
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: sadravid@in.ibm.com About India
> Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: extending wsn-consumer with other webservice methods
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
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:chrisr@hawaii.rr.com]
Sent: Thursday, September 27, 2007 6:43 PM
To: muse-user@ws.apache.org
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: sadravid@in.ibm.com About India
> Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: extending wsn-consumer with other webservice methods
Posted by crichmond <ch...@hawaii.rr.com>.
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: sadravid@in.ibm.com
> About India Software Lab
>
>
>
>
>
> crichmond <ch...@hawaii.rr.com>
> 26/09/2007 03:42
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> muse-user@ws.apache.org
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
--
View this message in context: http://www.nabble.com/extending-wsn-consumer-with-other-webservice-methods-tf4518830.html#a12933360
Sent from the Muse User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: extending wsn-consumer with other webservice methods
Posted by Saurabh Dravid <sa...@in.ibm.com>.
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: sadravid@in.ibm.com
About India Software Lab
crichmond <ch...@hawaii.rr.com>
26/09/2007 03:42
Please respond to
muse-user@ws.apache.org
To
muse-user@ws.apache.org
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org