==============================================
Mediator Brainstorming Session (EGEE JRA4 F2F)
==============================================

Date:  9th May 2005
Venue: DANTE, Cambridge

Glossary
========
CE = compute element
MP = monitoring point
SE = storage element

Summary
=======

Major components to be worked on for MJRA4.6:
  Web service interface
  Discovery (static)

Other components that may be worked on if we have time (in priority
order):
  Discovery (dynamic)
  Aggregation in Space
  
Future work (i.e. not for MJRA4.6. In no order):
  Cancel functionality
  Response Cache


Actions
=======

[RA] determine if web service stubs created by Axis are fully document
     literal complient (to investigate whether method name is ignored
     - as it should be).

[RA] Find out who keeps the GLUE schema up-to-date in the r-gma
     repository.


Discussion
==========

Mediator Web Service Interface
------------------------------

All requests entering the mediator will have source and destination
based on measurement points. NOTE: no mapping happens in the mediator.

Clients talk to name mapper service 
  - for Diagnostic Tool, NOC/GOCs will know which MP they want to talk
    to
  - MW needs to map CE/SE to MPs. This can be done through additions
    to the GLUE schema in the R-GMA database.

Should add "Cancel" function to Mediator. This is a good idea, but
will require different approach to submission and reply to requests -
we would need an asynchronous scheme, so that on request would recieve
a request id that we can use in the call to "Cancel".

Because of this the "Cancel" functionality will be marked as future
work.

No objections to object model. Loukik raised the issue that it may not
be able to use Axis stubs with a service that has changed the name of
the method on the web service interface. We need to ascertain if this
is the case.

It was noted that there may be more than on MP per CE/SE.

NMWG web services will collect data on one or more MP pairs. The
Mediator allows access to more than one NMWG web service. The
discovery component within the Mediator will be have access to the
list of all possible MP. This list should be made available through
the Mediator interface to allow clients to present users will a list
of MPs from which to choose src/dest pairs from.


Discovery
---------

The discovery component in the Mediator will access discovery
information through an external entity (e.g. R-GMA database). The data
within the external entity will be static for NMWG. There will be a
central external entity for the whole of EGEE, plus one backup entity
for robustness.

One example of how to make this information dynamic is to have
secondary producers on each NMWG web service that publishes the
discovery information into the central R-GMA database. But this
requires a lot of work to be done at the NMWG web service layer. This
work is not scheduled for MJRA4.6, but may be done if there is time.

It was discussed later that to make the Mediator more flexible the
discovery component could be a web service that the Mediator talks to
through a backend agnostic interface (e.g. input NM-WG request schema,
output web service URI). The discovery component could then talk what
ever protocol it needed to the central information repository
(e.g. R-GMA).


Aggregation in Space
--------------------

This component is a very low priority. But it was noted that as the
mesh of MPs increases within EGEE, this facility becomes more
important, as the ability to make full mesh active measurements
becomes detrimental to the network.

Individual router backbone data is not that useful for Grid
users. Grid users would prefer an aggregated value for information on
the backbone. This is a use for aggregation in space.

The way aggregation in space would be used is:
  1. take a traceroute from source to destination
  2. extract the backbone part of the traceroute
  3. aggregate in space over the backbone traceroute

This then provides a general representation of what is happening on
the backbone - which makes more sense to Grid users.

Some of the problems with aggregation in space:
  - it is theoretical
  - implementations are experimental
  - difficult to analyse traceroute (mapping of router address to MP)
  - requires lots of data to be manipulated in the aggregation in
    space component


Response Cache
--------------

Caching has been removed as a priority for MJRA4.6.

For aggregated (in time) It is very unlikely that two different users
will ask exactly the same request (the request timeperiod is the main
variable). Raw data has more of a chance of being useful in a cache,
but it is still very unlikely.

Submission of duplicate requests would probably come from the same
user during an analysis session with the Diagnostic Tool. In this
case, it is likely that the Diagnostic Tool will cache the data rather
than requesting it again from the Mediator.

RA 10/05/2005