Per-Entity Metadata Working Group

[David Walker <>]

I've been thinking about a couple of things...

• Setting an expectation that MDQ client software should protect itself from failures of the server infrastructure.  We've talked a good amount about the pros and cons of this.
  
• Another risk to per-entity metadata distribution we haven't discussed, that the server infrastructure may not be able to handle peak loads.

A federation-provided MDQ service must be able to handle two types of load, 1) metadata updates, and 2) queries from client IdPs and SPs.  The first of these is slow and fairly predictable at a federation level, but the latter is not.  Queries from IdPs and SPs will vary rapidly and unpredictably, based on the workload demands of individual federation members, but all federation members bear the impact.  The UK approach puts the unpredictable load on the web servers, which is better than putting it on the MDQ server, but it's still unpredictable.

The next thing I realized is that the UK's approach of creating an Apache-like web server layer between the MDQ server and the client IdPs and SPs doesn't require that the web servers be run by the federation.  They can be run by the member institutions:

Doing things this way lets each member institution decide what level of availability and scalability they want to provide to their community and deploy the necessary infrastructure without affecting the rest of the federation.  The federation is responsible only for the scalability and availability of the MDQ server behind the web servers.

Make sense?

David

Attachment: signature.asc
Description: OpenPGP digital signature