You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pubscribe-dev@ws.apache.org by Glauco Ludwig <gl...@terra.com.br> on 2005/07/06 04:53:02 UTC

doubt about requests

Hi all,
the last days I was trying to deploy the filesystem example within Apollo and Pubscribe.

So far, I executed successfully the command "ant compile deploy" in the two cases (Apollo and Pubscribe), and now, I would like to ask you:


1) In the Apollo case:

How do I "set" some property of the filesystem example? 
I looked at the requests directory and saw, for example, the SetResourceProperties_updateMountPointProp.soap request. 

Could someone show me how do I use this request? Need to be passed a parameter with it? 


2) In the Pubscribe case:

I have executed successfully the Subscribe_updateMountPointProp.soap request, but, I did not understand 
when I gonna be notified about the occurrence of this event.

Could someone explain me the whole proccess of subscribe to an event and being notified about the occurrence of this event in the filesystem example?
    

That's it. I don't know if I was clear enough explaining my doubts.
Any help are very welcome.

Thank you all again,
Glauco

Re: a question about MUSE

Posted by Sal Campana <sc...@apache.org>.
Glauco Ludwig wrote:

> Hi all,
> here I am again.
>
> First, thanks to Ian and others for the very useful replies.
>
> Ok. After enjoying the features of Apollo and Pubscribe, I started 
> working on MUSE.
> I have built and deployed MUSE successfully and now I am enjoying it.
>
> Well, I would like to ask you one thing about MUSE:
>
> Let´s assume that a propertie called "BackupFrequency" has the value 
> "5" associated with it.
> After a set request it has it's value changed to "7" and, some days 
> after, a new set request
> change its value to "10".
>
> Question: is there a way through which I can get the historical values 
> of the "BackupFrequency" propertie?
> This means, in only one get request, I would get the results: "5", "7" 
> and "10".
>
> This is something similar to the funcionalitie that RMON (SNMP) offers 
> when it stores data in tables
> fore future historical requests.
>
>
> That's it by now.
> Really thanks again.
>
> []s
> Glauco Ludwig
>
>
>
Hi Glauco,

By default the previous values or your resource properties are not 
maintained.  The main reason for this is that you handle your resource 
properties, so it would be possible for you to implement this behaviour 
yourself.

You could do it by implementing a Callback object which will somehow 
store the values, either in another resource property or peristed.  
Depending on how you store the previous values, you can either provide a 
custom method in your service to retrieve the values, else if a resource 
property use a standard method like getResourceProperties...

-S

a question about MUSE

Posted by Glauco Ludwig <gl...@terra.com.br>.
Hi all,
here I am again.

First, thanks to Ian and others for the very useful replies.

Ok. After enjoying the features of Apollo and Pubscribe, I started working 
on MUSE.
I have built and deployed MUSE successfully and now I am enjoying it.

Well, I would like to ask you one thing about MUSE:

Let´s assume that a propertie called "BackupFrequency" has the value "5" 
associated with it.
After a set request it has it's value changed to "7" and, some days after, a 
new set request
change its value to "10".

Question: is there a way through which I can get the historical values of 
the "BackupFrequency" propertie?
This means, in only one get request, I would get the results: "5", "7" and 
"10".

This is something similar to the funcionalitie that RMON (SNMP) offers when 
it stores data in tables
fore future historical requests.


That's it by now.
Really thanks again.

[]s
Glauco Ludwig


Re: doubt about requests

Posted by Ian Springer <ip...@apache.org>.
Hi Glauco,

My responses are inline below.

Glauco Ludwig wrote:

>  
> Hi all,
> the last days I was trying to deploy the filesystem example within 
> Apollo and Pubscribe.
>  
> So far, I executed successfully the command "ant compile deploy" in 
> the two cases (Apollo and Pubscribe), and now, I would like to ask you:
>  
>  
> 1) In the Apollo case:
>  
> How do I "set" some property of the filesystem example?
> I looked at the requests directory and saw, for example, the 
> SetResourceProperties_updateMountPointProp.soap request.
>  
> Could someone show me how do I use this request? Need to be passed a 
> parameter with it?

Yes, to set properties you would use the SetResourceProperties
operation. This operation contains one or more "sub-operations". The
available sub-operations are Insert, Delete, and Update. Insert adds the
specified elements to a property, Delete removes all elements from the
property with the specified name, and Update replaces a property's value
with the specified elements. The WS-ResourceProperties spec provides
examples of all three sub-operations.

>  
>  
> 2) In the Pubscribe case:
>  
> I have executed successfully the Subscribe_updateMountPointProp.soap 
> request, but, I did not understand
> when I gonna be notified about the occurrence of this event.
>  
> Could someone explain me the whole proccess of subscribe to an event 
> and being notified about the occurrence of this event in the 
> filesystem example?

The easiest way to test property changes notifications is to do the
following:

1) start up Axis tcpmon to listen on port XXXX where XXXX is some free
port on your box; configure it to forward requests to localhost:8080 or
whatever port Tomcat is running on; tcpmon will act as the notification
consumer
2) edit Subscribe_updateMountPointProp.soap in a text editor and set the
address in the consumer EPR to localhost:XXXX where XXXX is the port
tcpmon is listening on
3) use the sendRequest Ant target to send the
Subscribe_updateMountPointProp.soap request; now localhost:XXXX is
subscribed to receive notifications whenever the MountPoint property is
modified
4) send the SetResourceProperties_updateMountPointProp.soap request; you
should see a property changed notification printed in tcpmon's receive
buffer.

We will have a tutorial available in the near future that explains all of 
this stuff . In the meantime, don't hesitate to keep asking questions!

Regards,
Ian

>    
>  
> That's it. I don't know if I was clear enough explaining my doubts.
> Any help are very welcome.
>  
> Thank you all again,
> Glauco
>  




---------------------------------------------------------------------
To unsubscribe, e-mail: wsrf-user-unsubscribe@ws.apache.org
For additional commands, e-mail: wsrf-user-help@ws.apache.org