========================================================
Middleware status and plans
EGEE JRA4 Face to Face meeting, Pisa, 24-25 October 2005
========================================================

Present
-------

UEDIN: Alistair Phipps (AP), Andy Jackson (AJ), Kostas Kavoussanakis (KK)
CNRS:  Benjamin Vial (BV)

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

[AKP] Clarify requirements with RBMW: interface schema (NM-WG version); static 
vs. dynamic configuration, and pre-request vs. high latency first request;  
publisher deployment with RBMW; publisher discovery method

Discussion
----------

getData - NM-WGv1 or NM-WGv2?  NM-WGv2 may take more effort due to needing
additional translation, but may encapsulate the request properly in the schema.
Should use whatever the middleware prefers.

Static vs. dynamic (special operation to request pre-caching, or start
pre-caching on first request).  AJ said that in QCDGrid for data, they had a
special operation to notify intent to retrieve data and this worked well.  AJ
points out that this special operation allows the middleware to control the
latency of the first request (i.e. if they make the pre-request far enough in
advance, the request will be fast).  AP agrees that this would likely be ideal.
Will raise with RBMW - but we may just do static config due to time constraints.

Publisher deployment.  Disk space is cheap and latency requirements are strong,
so 1 publisher per RBMW entity may make sense - this puts the Publisher close to
the source of requests and improves latency.

Publisher discovery - gLite service discovery may be useful.  Perhaps static
discovery is OK for now - talk to RBMW.

Security - RBMW has the user's proxy, but the network monitoring data is never
returned to the user.  Does not make sense to use the user's credential to
access data - e.g. PerfSONAR will allow middleware to use raw data in
resource-brokering decisions, but does not want users other than ROC admins to
see this data.  Can RBMW use a service certificate of some sort to access the
Publisher (future)?  For now, specific Publisher installations can be granted
access to the Mediator by opening the firewall protecting the Mediator.  Each
Publisher will be trusted to only request data for paths for which data access
is permitted.  This assumes that there is no (TLS) security in the MJRA4.6
components - if the PerfSONAR TL requires a user's credential then this will be
inadequate (though RBMW does not require PerfSONAR data at the moment anyway).
It should be noted that although "each Publisher will be trusted to only request
data for paths for which data access is permitted", Publisher clients cannot
request data for other paths anyway unless there is a misconfiguration in the
CE/SE->NMP lookup.

CE/SE->NMP lookup.  We can't get this from the glue schema for the moment (see
glue schema minutes), but could add a table to R-GMA which would do the same
thing.  For now, we can do a static look-up configured within a Publisher - and
ensure the design is general enough to allow R-GMA lookup to work.

AKP 28/10/2005