perfsonar development work

[Cándido Rodríguez Montes <>]

Hi Andreas,

El 11/03/2008, a las 14:54, Andreas Hanemann escribió:

Hi Roman,

Thanks for your input. I have now added an additional interaction diagram to the document that depicts the interactions. It seems to me that your proposal is more flexible in the way how MAs can be combined with transformation services and it also helps to keep the complexity away from the client (which does not become aware that there is a transformation service involved). For DFN I did not want to make the MA address known to the outside world for security reasons, but I think that the access can be prevented by other mecanisms, too.

I have a question. At the moment the authorization will be available would you still need to hide the MA address? 

In summary, I would propose that your proposal is the way to go and I would then change the document accordingly. Are there further opinions?

Yes. In the JRA1 meeting in Seville, Jeff and me were talking about the actual specification of authentication and authorization doesn't include the case of perfSONAR services sending messages between them. In case that the TrS will be available for all services (like the interactions between all services and the LS), it doesn't affect to the AS, but, if you want to use the authentication or the authorization process in it, we will have to specify a new profile for this case (more AA work :-) ).

Regards

Best regards

Andreas

Roman Lapacz schrieb:

Andreas Hanemann wrote:

Hi all,

HI

In attachment I am providing a document about the Transformation Service. It contains a discussion about the scope of the service and also a description how the protocol for the service may look like. Some comments are left in the document which result from discussions involving few JRA1 people (Nina, Szymon and Nicolas).

Comments especially for the scope and the protocol would be desired.

If I remember correctly the idea of TrS was little bit different. Example scenario:

1. The client requests MA for data in specific format X

2. MA contains data in format Y so finds (in LS) TrS which can transform from format Y into X (TrS can be also specified in the request from the client so in this case there is no need to use LS)

3. MA sends the request and data to TrS

4. TrS transforms data into format X

5. TrS sends data back to MA (MA sends them to the client) or directly to the client

Roman

Best regards

Andreas

-- 

Dr. Andreas Hanemann      DFN-Verein

Stresemannstr. 78

10963 Berlin, Germany

Tel.:   ++49 30 884299 64

Fax:    ++49 30 884299 70

E-Mail: (Please do not use anymore)

<Transformation-Service_v5.doc>

--

Cándido Rodríguez Montes E-mail: 

Middleware warrior Tel:+34 955 05 66 13

Red.ES/RedIRIS

Edificio CICA

Avenida Reina Mercedes, s/n

41012 Sevilla

SPAIN