Re: Functional Requirements for Services

[White, G. <gr...@sl...>]

Hi All, Right! - at SLAC we use the AIDA DS to help choreograph archive requests for both the use cases
discussed in this thread. AIDA can get data from the EPICS archivers (we have 4) or from 
the legacy control system (SLC) archiver. Its DS knows which service to ask for data for any 
given name. So, it's Jame's solution 1 (1 endpoint serving many "channels") but in fact we have 
6 or 7 endpoints serving millions of channels. On Ralph and Andrew's point about the time
range of each archive index - the AIDA EPICS archive service is composed, as I said, of 4 endpoint
servers, but each of those in fact contacts different EPICS archivers depending on the time
range they've been asked for data for. So a user doesn't need to know which EPICS archivers to 
ask for data, the AIDA servers took care of it. Also, they don't have to know if the data
came form an EPICS archiver at all (and it often doesn't for beamlines using non-EPICs controls), 
it may have come from an SLC archiver. What the user types
is identical in all cases, they just ask for the archive data of a device.

For instance, this the last 8 hours of rate of LCLS. Clearly we haven't been doing too well!

[softegr@lcls-builder greg]$ gethist -s '8 hours ago' IOC:IN20:MC01:LCLSBEAMRATE 
02-Nov-2011 16:54:27      10.000000
03-Nov-2011 03:13:08       7.000000
03-Nov-2011 03:13:10       0.000000
03-Nov-2011 08:55:02       1.000000
03-Nov-2011 08:55:04      10.000000
03-Nov-2011 10:00:38      10.000000
03-Nov-2011 10:00:39      10.000000
 
On 3 Nov 2011, at 17:32, Andrew Johnson wrote:

> Hi Ralph,
> 
> On 2011-11-03 Ralph Lange wrote:
>> But - careful: what if a channel is moved from one archive to another,
>> so the answer depends on the time span the client is interested in? That
>> depth of info should not really go into the DS - so maybe this is an
>> argument for one central archive service, which may relay or redirect
>> the client if necessary.
> 
> I think you can still sensibly do this with a directory service:  In these 
> circumstances the long-term archiver would update the DS with the latest time-
> stamp for which it holds data on each channel immediately after it finishes 
> retrieving that channel data from the short-term archive and publishing it.  
> Similarly just before the short-term archiver starts deleting old data it 
> would update the DS with the time-stamp of the oldest data it has for each 
> channel.  This does require that a DS query be able to compare time-stamps 
> though, which shouldn't be too hard to add if it can't already do so.
> 
> - Andrew
> -- 
> Optimization is the process of taking something that works and
> replacing it with something that almost works, but costs less.
> -- Roger Needham
> 
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1