perfsonar development work

[ulisses <>]

Hi again Jason

On 2006-08-28 07:21:16, Jason Zurawski wrote:
> Ulisses;
> 
> >>As I said in the previous e-mail I see no errors when doing a simple 
> >>conversion using the Handler class and the toDOM() routine, but I am 
> >>curious to see what method you are using that invokes these problems.
> >>    
> >
> >In my performAction method, I only return a message.
> >
> >
> >  
> 
> Then perhaps one of the other developers could answer the question as to 
> how the 'conversion to DOM' happens in your service.  If you are not 
> implicitly calling a routine (like toDOM()) then I am not sure I really 
> know where your problem lies or how I could help you any further.

who I should contact?

> >>By message sequences Loukik means what the purpose of the request and 
> >>the response are, and what they general format should be.  I don't 
> >>believe you have ever roughed out an 'expected' sequence of exchanges to 
> >>this service (i.e. a request document format and the resulting response 
> >>document format).  
> >>    
> >
> >for now, it's only one request:
> >
> >     - "please dump me the entire topology" 
> >
> >and one reply:
> >
> >     - "just dump all elements"
> >     
> >that are the current requirements
> >
> >  
> 
> 
> Even though these are simply enough, an attempt should be made to define 
> the request and the response formats.  How does 'dumpt the entire 
> topology' get translated into XML, 

That is the xml I was sending in mails last days

> are you just doing the same action no 
> matter what the actual request message reports?

yes, full download of the database doesn't need parameters now, but I recall 
now 
that in the future this request (can/will include a timestamp value) which 
means download the topology that existed at that date. Other requests can use 
this parameter too. 

> In the future these will no doubt change, and there may be a need to 
> have various request/response messages.  In the interest of expansion 
> these issues should be dealt with.
> 
> >>Even though you have already started the physical 
> >>service, it would be nice for me to see what your request and responses 
> >>would look like.  
> >>    
> >
> >future developments can include:
> >
> >- Retrieval specific elements of the topology, that is do partial download 
> >of the database
> >
> >     From 
> >     
> > http://wiki.perfsonar.net/jra1-wiki/index.php/Topology_Service_resources 
> > # Required interactions
> >     #  Retrieval of topology information: Clients need to have the 
> >     possibility to retrieve network topology information. It needs to be 
> >     discussed which granularity is needed (whole networks, a component 
> >     and all neighbors, etc).
> >
> >- Register at the Tops in order to be notified when the topology or an 
> >specific element of the topology has been updated
> >
> >     From 
> >     
> > http://wiki.perfsonar.net/jra1-wiki/index.php/Topology_Service_resources 
> > # Required interactions
> >     # Client notification: It might be interesting for clients to 
> >     register themselves at a ToS and to be informed about changes in the 
> >     topology automatically. 
> >
> >  
> 
> 
> OK, then along with the previous request/response messages, examples 
> should be designed for these as well.

what rules should I follow? it is not clear for me

> >>That way we could decided how many data elements you 
> >>would need, and if your metadata blocks need to be blank or not. 
> >>    
> >
> >please tell me what steps I have to do.
> >  
> 
> 
> Like I said in the last e-mails, you need to look at all of the other 
> request/response pairs in the LS/MA or other maturing services.  Try to 
> pattern your own needs after those.  We can help you make them more 
> proper, but you need to get us to a starting point first.
>
> >>Yes, you are using the topology elements from that particular schema, 
> >>but the actual exchanges that this service will have between client 
> >>applications or other services is very important as well.  Take a look 
> >>at the (many) examples of exchanges that exist for the LS, or the 
> >>various MAs.  Each request example is followed by an appropriate 
> >>response instance document. 
> >>    
> >
> >I don't know what that means in my case. Could you tell me an specific 
> >example.
> >
> >  
> 
> Look in the svn repository for XML examples 
> (perfsonar/schema/example-instances/sonar) there are numerous examples 
> for the MA and for the LS in there.  For example a SetupData-Req and a 
> SetupData-Resp.  Even though you may not understand the mechanics of how 
> these these two work the idea is the same: request something from the 
> service, the service responds in some way.  The Topo service must work 
> the same way, and it will need to have all of it's interactions designed 
> in a similar way.
> 
> 
> >>Message sequence would be TOPOQueryRequest -->  TOPOQueryResponse or 
> >>something similar.  Once the actual messages are rouged out, then a 
> >>specific schema (beyond the general topology elements) could be created 
> >>just for your service. 
> >>    
> >
> >ok, that is what I understand with a sequence, but because now I only have 
> >a single message an reply I was confused.
> >
> >well, It is the first time I develop with java/web services but maybe the 
> >following could be an starting point:
> >
> >     ---> means request
> >     <--- means reply
> >
> >full database download (being implemented)
> >
> >     ---> TOPSDownloadDBRequest
> >     <--- TOPSDownloadDBResponse
> >
> >partial database download, I understand that is downloading nodes or links 
> >that matches some criteria.
> >
> >     ---> TopsDownloadNodesRequest
> >     ---> TopsDownloadLinksRequest
> >
> >     <--- in both cases the output could be the same as in 
> >     TOPSDownloadDBResponse
> >          but only showing the matching elements.
> >
> >register for database change, entire, nodes or links database respectively.
> >
> >     ---> TopsRegisterDBModification
> >     ---> TopsRegisterNodesModification
> >     ---> TopsRegisterLinks Modification
> >
> >     the client should include an URL for which the topology should issue 
> >     a GET
> >     method if the modification is done. The client, upon a GET method 
> >     request, should
> >     issue a TOPSDownloadDBRequest, TopsDownloadNodesRequest or 
> >     TopsDownloadLinksRequest
> >
> >     <--- The reply would be an absolute time reference which the 
> >     register is value.
> >
> >does this looks right for you?
> >
> >     
> 
> The ideas seem ok, so the next step is to make some instance documents 
> in XML that match these ideas.  Follow what the others have done in svn 
> so far.

ok, I will try but I don't have clear the rules 


        Ulisses