📄 rfc2970.txt
字号:
RFC 2970 Architecture for IDS - Result from TISDAG October 2000
4.0 Proposed service architecture
Pictorially, the DAG architecture is as follows:
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
+-------------------------------------------+
Note that the bounding box is conceptual -- all components may or may
not reside on one server, or a set of servers governed by the
provider of the service.
As we saw in the TISDAG project, the provider of this DAG-based
service may be only loosely affiliated with the remote services that
are used (Whitepages Directory Service Providers (WDSPs) in this
case).
4.1 Using the architecture
Building a service on this architecture requires:
Service implementation:
1. definition of the overall application to be supported by the
system -- whitepages, web resource indexing, medical
information
2. requirements
3. expected behavior
System architecture:
1. nature of deployment -- distributed, security requirements,
etc.
2. identification of necessary CAPs -- in terms of access
protocols to be supported, different service levels to be
provided (e.g., secure and unsecure connections)
Daigle & Eklof Informational [Page 7]
RFC 2970 Architecture for IDS - Result from TISDAG October 2000
3. identification of necessary services -- e.g., proxying to
remote information search services, lookup services, "AAA[A]"
(Authentication, Authorization, Accounting, [and Access])
servers, etc
4. definition of the transaction process for the service: insofar
as the CAPs represent the service to client software, CAP
modules manage the necessary transactions with other service
modules
Data architecture:
1. selection of schemas to be used (in each protocol)
2. definition of schema and protocol mappings -- into and out of
some DAG/IP representation
5.0 Illustrations
5.1 Existing TISDAG Project
Consider the TISDAG project in the light of the above definitions.
Service implementation:
1. A national-scale subset of Whitepages lookups, with specific
query types supported: only certain schema attributes were
permitted in queries, and the expected behavior was limited in
scope.
2. Requirements: the service had to support multiple query
protocols (from clients and for servers), and be capable of
searching the entire space of data without centralizing the
storage of records.
3. Given a query of accepted type, provide referrals to whitepages
servers that might have information to fulfill the query; if
necessary, proxy the referrals (chain) to retrieve the
information for the client.
System architecture:
1. distributable components
2. publicly accessible CAPs in HTTP, SMTP, Whois++, LDAPv2, and
LDAPv3
3. referral proxies to Whois++, LDAPv2 and LDAPv3 WDSPs, as well
as a referral query service
4. the basic transaction process, uniform across all CAPs, is:
- query the RI for relevant referrals
- where necessary, chain referrals through SAPs of
appropriate protocol return, in the native protocol, all
remaining referrals and data
Daigle & Eklof Informational [Page 8]
RFC 2970 Architecture for IDS - Result from TISDAG October 2000
Data architecture: see the spec.
In the TISDAG project, the above diagram could be mapped as follows:
CAP a LDAPv2 CAP
SAP A the Referral Index (RI) interface
Server i the Referral Index (RI)
SAP B LDAPv3 SAP
Note that, in the TISDAG project specification, the designation SAP
referred exclusively to proxy components designed to deal with
external servers. The Referral Index was considered an entity in its
own right. However, generalizing the concepts of the TISDAG
experience lead to the proposal of regarding all DAG/IP-supporting
service components as SAPs, each designed to carry out a particular
type of service functionality, and whether the server is managed
internally to the DAG system or not is immaterial.
5.2 Operator service
Consider the case of "number portability" -- wherein it is necessary
to determine the current service provider of a specific phone number.
The basic assumption is that phone numbers are assigned to be
globally unique, but are not in any way tied to a specific service
provider. Therefore, it is necessary to determine the current
service provider for the given number before being able to retrieve
current information. For the sake of our illustration, let us assume
that the management of numbers is two-tiered -- suppose the system
stores (internally) the mapping between these random digit strings
and the country in which each was originally activated, but relies on
external (country-specific) services to manage the updated
information about which service provider currently manages a given
number. Then, the service data need only be updated when new numbers
are assigned, or national services change their access points.
We can look at a grossly-simplified version of the problem as an
illustration of some of the concepts proposed in this service
architecture. We couple it with the "name search" facet of the
TISDAG example, to underscore that a single service ("operator") may
in fact be supported by several disjunct underlying activities.
Service implementation:
1. Retrieving service information for a particular (unstructured)
phone number digit sequence, or searching for numbers
associated with a particular name (or fragment thereof).
2. Requirements: support IP-telephony through HTTP-based
requests, wireless device requests through WAP [WAP].
Daigle & Eklof Informational [Page 9]
RFC 2970 Architecture for IDS - Result from TISDAG October 2000
3. Expected behavior: given a name (fragment), return a list of
names and numbers to match the fragment; given a phone number,
return appropriately-structured information re. the current
service mapping for that number.
System architecture:
1. Publicly accessible through CAPs; components widely
distributed.
2. Need one CAP for HTTP, one for WAP.
3. Support services include: an internal service for lookup of
number strings (to identify nation of origin of the number), a
proxy to access national services for registration of numbers
and service providers, and a proxy for remote service provider
for retrieval of detailed information regarding numbers. For
the name searching, we also need a referral index over the
names, and a proxy to whatever remote servers are managing the
whitepages directories.
4. Now, 2 different types of transaction are possible: search for
name, or look-up a number. In the name search case, the CAP
receives a name or name fragment, looks it up in the internal
referral index, and finds associated numbers through external
whitepages services (WDSPs). To look-up a number, the CAP
first uses the internal look-up service to determine the
country of origin of the number, and then uses a SAP to access
that nation's number-service provider directory, and finally
uses a different SAP to access the current service provider to
determine the information required to make the call.
Data architecture:
[Out of scope for the purposes of this illustration]
Note that some elements of the system architecture are
deliberately vague. Per the requirements, no structure is
expected in the number string, and therefore the lookup server
must maintain an index of number-to-country mappings and relies
on an external number-to-service mapping service (in each
country). However, were there any structure to the numbers, the
lookup server could make use of that structure in the indexing,
or in distribution of the index itself. This would have no
effect on the CAPs, which have no inherent reliance on how the
lookup server performs its task.
Daigle & Eklof Informational [Page 10]
RFC 2970 Architecture for IDS - Result from TISDAG October 2000
Pictorially, the example can be rendered as follows:
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
| +--------+ | "C"
|---------+ | SAP C <-------------->
"b" | | | | |
<-----> CAP b | +--------+ |
| | |
|---------+ +--------+ |
| | SAP D | |
| | | |
| +-+------+---+ |
| |(Internal)| |
| | Server j | |
| +----------+ |
| |
| +--------+ | "E"
| | SAP E <-------------->
| | | |
| +--------+ |
+-------------------------------------------+
where
CAP a HTTP CAP
CAP b WAP CAP
SAP A the number-nation lookup interface
Server i number-nation lookup server (what country)
SAP B nation-service lookup SAP (what service provider)
SAP C service-number information lookup SAP (current
service details)
SAP D referral index interface
Server j referral index service
SAP E proxy for chaining queries to remote WDSPs
Daigle & Eklof Informational [Page 11]
RFC 2970 Architecture for IDS - Result from TISDAG October 2000
5.3 Medical application
The service architecture is useful for applications outside the scope
of "telecoms". In another hypothetical illustration, consider the
case of medical information -- records about patients that may be
created and stored at a variety of institutions which they visit. It
is not unusual to need to access all information concerning a
patient, whether or not the person can recollect (or communicate)
conditions that were treated, procedures that were performed, or
medical institutions visited. The data may include everything from
prescriptions, to X-rays and other images, to incident reports and
other elements of medical history, etc. Typically, the information
is stored where it is collected (or by an agency authorized by that
institution) -- not in a central repository. Any service that looks
to provide complete answers to queries must deal with these
realities, and clearly must function with a strong security model.
Service implementation:
1. Retrieving all medical information for a particular person.
2. Requirements: must retrieve, or at least locate, all
available information, regardless of its storage location;
cannot require central repository of information; must
implement authorization and access controls. Must
support a proprietary protocol for secure connections
within hospitals, wireless access for personnel in
emergency vehicles (not considered secure access).
3. Expected behavior: given a patient's national ID, and
authorized access by medical personnel in secure locations,
determine what kinds of records are available, and where;
given a request for a specific type of record, retrieve
the record. Given a patient's national ID, and authorized
access from a wireless device, provide information re.
any known medical flags (e.g., medicine allergies,
conditions, etc).
System architecture:
1. Only 2 CAP types are needed, but instances of these will
be established at major medical institutions.
2. Need one CAP to support the proprietary protocol, one
to support wireless access.
3. Support services include: an internal server to support
security authentication and access control determination;
an internal server to act as referral index for finding
information pertinent to a particular patient, and one
or more proxies for accessing remote data storage servers.
4. The basic transaction requires that the first step be
to authenticate the end-user and determine access privileges.
In the case of wireless access, this last will not involve
Daigle & Eklof Informational [Page 12]
RFC 2970 Architecture for IDS - Result from TISDAG October 2000
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -