RFC: 3402
Оригинал: Dynamic Delegation Discovery System - Part Two: The Algorithm
Предыдущие версии: RFC 2168, RFC 2915
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 3402, Страница 10 из 12

6. Примеры

Приведенные ниже примеры служат лишь для учебных целей. Рассмотренные приложения не специфицированы в каких-либо реальных документах.

6.1. Система идентификации автомобильных деталей

В этом примере рассматривается воображаемая система, в которой собраны воедино все производители автомобилей и используется стандартизованная система кодирования различных деталей (болты, гайки, шайбы, инструменты и т. п.), которая применяется в процессе производства и ремонта автомобилей. Проблема такого рода систем заключается в том, что автомобильная промышленность является сильно распределенной и многие детали производятся различными фирмами, расположенными по всему миру. Для того, чтобы найти информацию о какой-либо детали, система должна быть способна выяснить производителя этой детали и контактировать с ним.

Для облегчения задачи идентификационные номера выделяются как часть иерархической системы, в которой первые 5 цифр являются идентификатором производителя. Следующие 3 цифры идентифицируют линейку автомобилей (например, Ford, Toyota). Остальные цифры присваиваются производителями деталей по своему усмотрению.

Автомобильная промышленность приняла решение об использовании DDDS для создания распределенной системы поиска информации, которая маршрутизирует запросы к реальным держателям данных. Отрасль специфицировала базу данных и синтаксис запросов для отыскания правил перезаписи (APIDA Network) и Приложение Auto Parts Identification DDDS Application (APIDA).

Спецификация APIDA будет определять следующее:

  • Application Unique String — код детали;
  • First Well Known Rule — принимает первые 5 цифр (идентификатор производителя) и использует их в качестве Ключа;
  • Valid Databases — APIDA Network.
  • Expected Output — информация EDIFAC об интересующей детали.

Спецификация Базы данных APIDA Network будет определять следующее:

  • General Specification — сеть поддерживающих EDI баз данных и служб, которые по заданному субномеру детали будут возвращать правила перезаписи в формате XML;
  • Lookup Procedure — следует обычным протоколам APIDA Network, запрашивая в сети правило перезаписи для Ключа;
  • Key Format — преобразования не требуется;
  • Rule Format: см. документацию APIDA Network для XML DTD.
  • Rule Insertion Procedure — определяется агентством, которое контролирует каждую часть кодов деталей; например, для получения идентификатора производителя нужно быть членом Auto Parts Manufacturers Association.

В качестве иллюстрации рассмотрим деталь с кодом 4747301AB7D. Система будет брать первые 5 цифр 47473 и запрашивать в сети Правило перезаписи (Rewrite Rule). Это правило будет предоставляться базой данных о производителях деталей и позволит производителю передать полномочия далее или напрямую возвратить запрашивающему информацию EDIFAC.

Предположим для примера, что производитель возвращает Правило, которое говорит, что следующие 3 цифры нужно использовать как часть запроса к их сервису для получения нового Правила. Это новое Правило позволит производителю деталей передать полномочия на заводы по производству деталей для каждой линейки автомобилей. В нашем примере цифры 01A означают автомобили Toyota. Правило, которое возвращает производитель передает полномочия далее производителю в Японии. Это правило также означает, что данное Правило является завершающим и, таким образом, результатом последнего запроса будет информация о детали.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.