Changes between Version 4 and Version 5 of UniformClearinghouseAPIV2


Ignore:
Timestamp:
11/12/13 09:49:09 (8 years ago)
Author:
mbrinn@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UniformClearinghouseAPIV2

    v4 v5  
    348348The Registry implements the SERVICE service and supports the SERVICE object.
    349349
    350 The following table describes the default fields for services (aggregates and authorities) provided by Registry API calls:
    351 
    352 
    353 || ''' Name ''' || ''' Type ''' || ''' Description ''' || ''' Required ''' ||
    354 || SERVICE_URN || URN || URN of given service || Yes ||
    355 || SERVICE_URL ||URL || URL by which to contact the service || Yes ||
    356 || SERVICE_CERT || Certificate || Public certificate of service || No ||
    357 || SERVICE_NAME || String || Short name of service || Yes ||
    358 || SERVICE_DESCRIPTION || String || Descriptive name of service || No ||
     350Services have a particular type that indicates the kind of service it represents. The full list of supported services should be provided by a TYPES key in the Registry get_version call, for example:
     351
     352{{{
     353    {
     354       …
     355       "TYPES" : ["SLICE_AUTHORITY", "MEMBER_AUTHORITY", "AGGREGATE_MANAGER", "LOGGING_SERVICE"]
     356       …
     357    }
     358}}}
     359
     360This table contains a set of example services types (of which only SLICE_AUTHORITY, MEMBER_AUTHORITY and AGGREGATE_MANAGER are required for any given federation):
     361
     362|| ''' Service ''' || ''' Description ''' ||
     363|| SLICE_AUTHORITY || An instance of the Slice Authority Federation service described in this document ||
     364|| MEMBER_AUTHORITY || An instance of the Member Authority Federation service described in this document ||
     365|| AGGREGATE_MANAGER || An instance of an Aggregate Manager satisfying the Aggregate Manager API ||
     366|| STITCHING_COMPUTATION_SERVICE || A toplogy service for supporting cross-aggregate stitching ||
     367|| CREDENTIAL_STORE || A service holding credentials for the federation, typically for supporting federation authentication services ||
     368|| LOGGING_SERVICE | A service to support federation-level event logging ||
     369
     370The following table describes the default fields for services (aggregates and authorities) provided by Registry API calls ('Required' indicates whether the field must be present for a valid service, 'match' indicates whether the field can be used in a lookup match criterion):
     371
     372
     373|| ''' Name ''' || ''' Type ''' || ''' Description ''' || ''' Required ''' || ''' Match ''' ||
     374|| SERVICE_URN || URN || URN of given service || Yes || Yes ||
     375|| SERVICE_URL ||URL || URL by which to contact the service || Yes || Yes ||
     376|| SERVICE_TYPE || STRING || Name of service type (from Registry get_version.TYPES) || Yes || Yes ||
     377|| SERVICE_CERT || Certificate || Public certificate of service || No || No ||
     378|| SERVICE_NAME || String || Short name of service || Yes || No ||
     379|| SERVICE_DESCRIPTION || String || Descriptive name of service || No || No ||
     380|| SERVICE_PEERS || URLs and version info for other running version of same service (see below) || No || No ||
     381
     382The SERVICE_PEERS field is similar to that in the AM API: a list of {version", 'url'} dictionaries for other supported peer services. An example would be as follows:
     383{{{
     384[
     385{'version" : '1', 'url' : 'https://example.com/xmlrpc/v1'},
     386{'version" : '2', 'url' : 'https://example.com/xmlrpc/v2},
     387]
     388'
     389}}}
    359390
    360391{{{