Mark: thought we should thrash out a design, remembering that we have to do something for the Summer. Ratner: certainly. Otherwise we might look stupid, and not have anything to build upon. Mark: hopefully we can get a little structure in. Start with something as abstract as possible. Ratner: so start on what the client will do, and work it through. We need a demo to impress whoever it is shown to. For example, Pete. Loukik: thinks that Pete though: an interface, once that is designed that can definitely be used later. If the client can already talk to two or more interfaces, then that can definitely be used. Is this optimistic? Ratner: probably not that optimistic. If the client is designed to do what it has to do, the internals can be abstracted out later. Loukik: the client will have to improve later, as functionality gets added. Ratner: the middle of the client is the bit we want to work on. The front end can be done later, or by Ahmed. The wrapper is the bit we need to concentrate on. The front-end just requires data. Loukik: the terminology is confusing: the Wrapper is a client to the stuff. Argh. YTL: we can write the backend of the client and the wrapper as one single thing. Mark draws a diagram: Client - whoever | v NMWG ^ | Wrapper / | \ / NMWG \ / | \ Perfmonit WP7 ? Loukik draw a diagram: Client - - - - - Internal API (DOM-tree passing?) Wrapper / | \ / NMWG \ / | \ Perfmonit WP7 ? We think we prefer the latter because it has fewer web services to prototype YTL: Thinks, that for the demo, there should be a client like Mark's diagram, which does some visualisation. Ratner: Prefers not to do that, as it requires writing the extra. Language? Java! Internet2 has done some Perl stuff. What about the GUI? Swing? + Impressive: shove a jar on someone's machine, it does loads of magic - Requires... either libraries or large Jar - Require java JSP Web page? + Ultra-portable. Just need a web page. - It's on a remote machine somewhere, maybe things might go wrong. Command-line + Really simple + Can add extra stuff later - dull? So: we have the separate interfaces Then a command-line client, which has some locator piece. Security: Ratner will be seeing Sophie in Paris. Then get Pete to get someone to do something about it. Maybe Gloria? YTL: security for the prototype might be too ambitious. Ratner: maybe Pete has said them that, that is, in the deliverable. Loukik: so there are two levels of security: user->client and wrapper->services Ratner: with Loukik's model, though, there's no delegation. Ytl: really simple authorisation: allow certain IP addresses to access. Mark: none of us know about security. We should wait until Ratner's been to Paris. If they've already found out how to make it work, then excellent. Mark: maybe we could say that we've screwed down the services using something simple, and say that the reason we've not done something sensible is that we have too many options. Afternoon session ================= For the prototype: just querying for historic data. Loukik can do: One way delay Available layer 3 (IP) bandwidth We can do RTT TCP Throughput UDP Throughput Interface is a command-line tool. So we provide a list of options for the user to retrieve. We also provide a list of *valid* hostnames once you've chosen a metric. Ratner: Argument against using a proper discovery mechanism. -> it's too complicated. We can do it later. So the mappings we need (on a UI level only): Human-readable name -> name (in the Wrapper): sourceName:destName:metric -> endpoint Workflow for the user: 1) Ask the user what metric they want 2) Then present all the pairs for which data on that metric is (probably) available Mark: actually, we should present every source and destination Ratner: for the time being we will present every ordered pair available 3) Time period and statistic Mark: present five options: last result, average over an hour, daily average over last week, all data between two times, min and max on a particular day Ratner: should we have a crap lookup in the table, to ensure that there's a host-broken thing Statistics that get supported: min,max,average Loukik: stuff like an average over a week will time out Ratner: excellent, this is a demonstration of some brokenness. What's Ahmed going to do? Maybe get him to write the interface bit, then... somehow present the data he collected to us. Big rant on my part about where translation to the interface name should be done. That is: you should only assume that only the MP names advertised by endpoints are understood by it. Therefore, the client has to convert whatever it has to an understood MP name. For middleware, this is SE/CE->MP For Grid users, this is probably similar For NOCs they already know what the MPs are called, and where they are. And so this is done. Hurrah. Except for exceptions: Dante have lots of exception messages already. So errors are easy? NMWG have some business logic in the requirements (the bits in green). There are also some error types listed. Loukik: we should define a load of errrors here, then match the list in the NMWG request document * No data available * Security, that is AAA * Request is malformed or impossible * System * Communication * Discovery Ytl: Tomorrow we should describe who gets what Mark: nope. We aren't at that stage yet. We need to describe components tomorrow. Day 2 ============== Assigning tasks: ---- NPMClient } (Ahmed) NameToMPMaper } Interfaces (RA, done as part of the Prototype System Design, which we will then rip apart) NPMRequest NPMResponse NPMWrapper NPNService RA therefore also writes dummy interfaces for use elsewhere. NMWGRequest (LK) NMWGReport (YL) NPMWrapperImpl (LK) NPMDiscovery (YL/PM) NMWGService (PM) Deployment: ---- Perfmonit: you can make a request, using doc/lit. The report is then required. Two domains, Dante and Geant. Couple of measurement points are open on Dante. Measurement points on Geant are private, we won't see them. The interface they let us use will be called Dante (Geant). For Geant we get 12 routes.