=======================================================
Minutes from GN2:JRA1 Transation Layer session
EGEE JRA4 Face to Face meeting, Edinburgh, 13 July 2005
=======================================================

Present
-------

DANTE:  Loukik Kudarimoti (LK)
DL:     Mark Leese (ML)
UEDIN:  Ahmed Abdelrahim (AA), Ratnadeep Abrol (RA), 
        Kostas Kavoussanakis (KK), Alistair Phipps (AKP)

Actions arising
---------------

[LK] Come up with modifications to the object model needed to support the subset
of NM-WG v2 needed for the TL to talk to PerfSONAR.

[RA] Talk to NS about getting TL deployed 1:1 with measurement archives at
PerfSONAR sites.

[AKP] Determine how different client certificates can be set in concurrent
threads

Minutes
-------

LK wants to change the stubs, autogenerated by Axis from the NM-WG schemas, to
retrieve the information from the beans in a more sensible way than that
provided by Axis.  However, RA points out that changes such as changing type
names in WSDL would change class names, causing all core code to have to change
as well.  LK says he was planning to convert everything to strings to avoid
relying on the types generated by Axis.  RA says that using a separate object
model gives us type safety whilst isolating core code from whatever stub/XML
parsing mechanism we use.  LK agrees that an object model is a good approach.

The object model defined by AKP was written with reference to the NM-WG v1
schema, though does not reflect it exactly.  LK says we could have two object
models (one for v1, one for v2) and then convert between them.  AKP suggests
instead changing the object model to make it suitable for conversion to/from
both NM-WG v1 and v2.  LK points out that NM-WG v2 has some features that cannot
be implemented with v1, such as specifying a key to use for repeated requests.
However, RA/LK/AKP agree that we do not have to cover all v2 (or v1) features,
just the subset of v1 we use to talk to NMWG4RGMA and the GN2:JRA1 TL, and the
subset of v2 the TL uses to talk to PerfSONAR.  LK will look at the v2 schema
and examine how the object model can be modified to allow it to support the
needed parts of v2.

There are 3 options for operation of the TL:

1) Does the request come in to the TL with a PerfSONAR measurement archive URI
 - this would mean storing an opaque data blob in the Discoverer that is then
   passed with the request to the TL
 - not favoured by anyone - we don't want NPM to care about the insides of a
   framework

2) Does the TL do Discovery, to look up the measurement archive URI based on the
source and destination measurement points
 - this involves an additional discovery step in the TL; TL effectively becomes
   a Mediator for PerfSONAR
 - Discovery would be statically configured for now as GN2:JRA1's Lookup service
   is not ready

3) Do we have a 1:1 mapping of TLs to Measurement Archives
 - issue with this is deployment - the TLs then have to be deployed along with
   the measurement archives, and the TL is an EGEE service rather than a GN2
   service
 - favoured by LK/RA as it avoids having to do discovery in the TL
 - RA will talk to NS about getting the TL deployed 1:1 with measurement
   archives at PerfSONAR sites

Agree to investigate (3) while proceeding on the assumption that we will have to
do (2).

LK points out that there is a more flexible way of doing translations:
- call translator with two URIs (one for each service) and find a translation
  service that can translate between them
- in our case, there would just be one URI (destination service) as the invoker
  would be the source service
- the Mediator would then call the translation service
- LK/RA agree that this would be a good path to pursue in the future, however it
  is overly complicated for what we need at the moment.  Also, GN2:JRA1 is
  proceeding along this path so for EGEE2 it may be possible to make use of
  their service.

With method (2), the flow of information within the TL is:
- Request comes in, translated into object model types
- Role extracted from requester certificate
- Role mapped to PerfSONAR user, correct user certificate loaded
- Based on the user, determine if request authorised (done in the TL since
  security not yet in PerfSONAR but data disclosure policy requires it)
- Call internal Discovery module to get URI for measurement archive
  corresponding to specified source/destination measurement points
- Convert call to v2 and invoke on measurement archive

RA/LK/AKP agree on an overall design for the TL, and it is documented by LK.

RA raises the issue that multiple user certificates will have to be loaded at
once for concurrent requests.  AKP/RA agree this is an issue as setting of
client certificate is done by setting a system property.  AKP will look into
this and try to find a solution, though it will not be a problem for MJRA4.6 as
GN2:JRA1 will not have security in place by the end of September.

AKP 14/7/2005