ws-muse-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kam K. Yee" <open.zource...@gmail.com>
Subject Re: extending wsn-consumer with other webservice methods
Date Fri, 28 Sep 2007 18:27:45 GMT
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: <Chris.Twiner@swisscom.com>
To: <muse-user@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)" <vinguye2@cisco.com>
To: <muse-user@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 <chrisr@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


Mime
View raw message