perfsonar development work

[Jason Zurawski <>]

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.

> > >
> > 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, are you just doing the same action no 
matter what the actual request message reports?

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.

> > 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.

-jason