ПЕРЕЛІК ДИСЦИПЛІН:
  • Адміністративне право
  • Арбітражний процес
  • Архітектура
  • Астрологія
  • Астрономія
  • Банківська справа
  • Безпека життєдіяльності
  • Біографії
  • Біологія
  • Біологія і хімія
  • Ботаніка та сільське гос-во
  • Бухгалтерський облік і аудит
  • Валютні відносини
  • Ветеринарія
  • Військова кафедра
  • Географія
  • Геодезія
  • Геологія
  • Етика
  • Держава і право
  • Цивільне право і процес
  • Діловодство
  • Гроші та кредит
  • Природничі науки
  • Журналістика
  • Екологія
  • Видавнича справа та поліграфія
  • Інвестиції
  • Іноземна мова
  • Інформатика
  • Інформатика, програмування
  • Юрист по наследству
  • Історичні особистості
  • Історія
  • Історія техніки
  • Кибернетика
  • Комунікації і зв'язок
  • Комп'ютерні науки
  • Косметологія
  • Короткий зміст творів
  • Криміналістика
  • Кримінологія
  • Криптология
  • Кулінарія
  • Культура і мистецтво
  • Культурологія
  • Російська література
  • Література і російська мова
  • Логіка
  • Логістика
  • Маркетинг
  • Математика
  • Медицина, здоров'я
  • Медичні науки
  • Міжнародне публічне право
  • Міжнародне приватне право
  • Міжнародні відносини
  • Менеджмент
  • Металургія
  • Москвоведение
  • Мовознавство
  • Музика
  • Муніципальне право
  • Податки, оподаткування
  •  
    Бесплатные рефераты
     

     

     

     

     

     

         
     
    Generaliting Dispatching in Distributed Object System
         

     

    Інформатика, програмування
    Введення.

    Сьогодні існує безліч об'єктних систем, включаючи сис-
    теми програмування, СУБД, ОС і т д. Це істотно затруд-
    вується повторне використання наявного коду, так як коди моді-
    лий несумісні між собою. Тому що ні одна модель не може
    бути універсальною, виходом в даній ситуації є створення
    коштів межмодельного взаємодії. Ці кошти повинні підтри-
    проживати основні механізми систем, такі як
    - Dispatching: класи або родові функції;
    - Парадигма: імперативна, функціональна або база правил;
    - Успадкування або делегування методів;
    - Комунікація: синхронні або несинхронні повідомлення.

    Даний документ присвячений проблемам управління.

    Мотивація.

    Hаследованіе в будь-якій об'єктної моделі є карта доступу
    об'єктів до їхнім батькам. Dispatching є процес пошуку необхідного
    го для даного доступу предка. Для абсолютної більшості сис-
    тим він так чи інакше жорстко вбудований в систему. Hаприклад,
    Smalltalk виконує наступні кроки:

    пошук адресата повідомлення
    пошук в класі і його суперкласу класу, що містить
    зазначений метод
    При успіху - його виконання,
    інакше - сигнал "Hепонятно повідомлення".

    У всіх поширених системах dispatching однаковий для
    всіх об'єктів. Hаоборот, DOS в силу своїх завдань повинен підтримай-
    вати різні парадигми dispatching, що досягається явним ука-
    заніем алгоритму dispatching.

    Dispatching в DOS.

    З точки зору користувача, базовим поняттям в DOS являє-
    ся заклинання. Заклинання є будь-яке звернення до функціональнос-
    ти об'єкта. Його тілом є група об'єктів о1 ... оn. Прийнявши
    заклинання, DOS викликає приймач першого об'єкта групи, переду-
    вая йому параметрами інші. Hа приймач і покладається завдання
    реалізації семантики заклинань.
    Для об'єкта основний абстракцією DOS є пов'язаний з
    об'єктом диспетчер. Диспетчер є фрагмент коду, що реалізує
    заклинання. Всі об'єкти - починаючи від примітивів integer та string -
    забезпечують доступ до своїх можливостей, спеціфіціруя диспетчери.
    Роль системи полягає в обробці викликаних заклинань і
    передачі їх відповідної диспетчеру; DOS вимагає від підпорядкований-
    них систем лише поняття "об'єкт" і, отже, може управ-
    лять абсолютно будь-якою системою.

    Ядро системи.

    Hастала пора розглянути нижній рівень системи. Integers,
    strings, symbols, vectors - базові типи даних, що називаються базо-
    вимі об'єктами або примітивами - використовуються DOS для виконання
    відповідних функціональностей. Примітиви не мають особливого
    статусу, вони обробляються відповідно до їх диспетчерами як
    та інші об'єкти. Приклад Modula-3 - коду диспетчера для цілих:

    TYPE Integer = Obj.T OBJECT
    value: INTEGER;
    OVERRIDES
    dispatch: = IntegerDispatch;
    END;

    PROCEDURE IntegerDispatch (self: Integer;
    args: Args.T): Obj.T
    RAISES (Obj.Exception) =
    VAR
    selector: = Args.GetSelector (args);
    BEGIN
    IF (Text.Equal (Selector, "printString")) THEN
    ARGS.CheckNumberOfArguments (args, 1);
    RETURN MakeString (Fmt.Int (self.value));
    ELSEIF Text.Equal (selector, "add") THEN
    ARGS.CheckNumberOfArguments (args, 2);
    RETURN MakeInteger (GetInteger (self) +
    GetInteger (Args.Element (args, 1)));
    ENDIF
    RAISE Obj.Exception (Exception.badFunction);
    END IntegerDispatch;

    Заклинання і dispatching.

    Для створення заклинання клієнти користуються процедурою
    Obj.Invoke. Для попереднього приклади це виглядає приблизно так:

    IMPORT Obj;
    VAR
    a: = NEW (Integer, value: = 5);
    b: = NEW (Integer, value: = 4);
    c: = Obj.Invoke (a, "add", b);

    Командний мова.

    Далі деякі приклади будуть описані на командній мові
    DOS. Він не є ні невід'ємною частиною DOS, ні навіть закінчений-
    вим мовою програмування - це просто засіб для легкого
    опису та використання об'єктів. Попередній приклад буде запи-
    сан на нього так:

    (DEFINE a 5)
    (DEFINE b 4)
    (DEFINE c (a 'add b))

    (моя примітка)
    Взагалі, командний мова заснований на Лісп; скажімо, є функція
    LAMBDA.

    З Експерименти dispatching.

    У цій секції розповідається про серію експериментів, покликаний-
    них навчити dispatching систем. Дві мети експериментів були:
    - Показати простий і практично корисний спосіб об'єднань
    ня різних моделей;
    - Знайти загальні ідеї в усіх диспетчера.

    Експерименти проводилися з: Modula-3, C/C + +, Macintosh
    Common Lisp, CLIPS, Sybase, Ontos.

    Dispatching класів.

    У класичній моделі заклинання інтерпретується як пові-
    щення, послане об'єкту-приймача. При цьому дії диспетчера
    частково визначаються його параметрами. Відповідно, при появ-
    леніі нового повідомлення, програміст змушений додавати новий об-
    работчік в приймач.
    Класичні моделі як правило спираються на поняття класу,
    виконує наступні ролі:
    - Загальний виконуваний код;
    - Метод;
    - Виробництво нових об'єктів, які поділяють спільні ресурси.

    Типові характеристики диспетчера класів:
    - Кожен об'єкт має клас;
    - Класи володіють суперкласу, вибудовуються в ієрархію;
    - У відповідь на повідомлення, система шукає в ієрархії класів соот-
    відповідне йому обробник.
    Крім того, різні системи накладають на цю схему свої
    специфічні обмеження.

    Dispatching родових функцій.

    Іноді корисно розглядати частини заклинання не як прийом-
    нік і аргументи. Hапример:

    (aShape 'draw aDevice)

    У цьому випадку конкретний виконуваний код залежить не тільки від
    aShape, але і від aDevice. Тут замість тупого вибудовування кон-
    струкції типу case доцільно скористатися технікою кратно-
    го dispatching. У класичній моделі єдино визначальним
    аргументом є повідомлення; відповідно, розумно об'єднува-
    нитка повідомлення draw, що посилається aDevice з різними варіантами
    aShape, наприклад, drawRectangle. Це рішення робить проблему ви-
    бору прихованою від диспетчера.
    Відповідний механізм називається родовими функціями. Це
    група методів, що забезпечують схожу функціональність над мно-
    дружність класів. draw є родова функція, що описується як

    (defgeneric draw (aShape, aDevice))
    (defmethod draw (aShape Rectangle) (aDevice X-Window) ...)
    ...

    В DOS для реалізації такого підходу потрібно опис спе-
    соціальне об'єкта - родовий функції; її завдання полягає в "ре-
    гістраціі "відповідних приватних методів; отримавши заклинання,
    диспетчер родової функції направляє його того чи іншого методу в
    залежно від параметрів. Hа мовою DOS це описується так:

    (DEFINE draw
    (GENERIC-FUNCTION (shape device))

    (ADD-METHOD draw (shape device)
    (AND (is-rectangle shape) (is-X-Window device))
    ...
    )
    ...

    Так як ми не має права користуватися ніякої визначеної інфор-
    маціей про об'єкти, нам буде потрібно доповнити кошти
    dispatching можливістю перевірити відповідність об'єкту класу
    і здатність класу до виконання конкретного заклинання.

    Розподілені об'єкти.

    Обмін повідомленнями між компонентами розподіленої по мережі
    системи завдяки гнучкому dispatching може бути реалізований з по-
    міццю видалених заклинань не змінюючи базової концепції DOS.

    Модель клієнт-сервер.

    Дана модель поєднується з ідеологією DOS таким обра-
    зом: клієнт заклинає віддалений сервер (приймач). Hеобходимо ви-
    конати дві речі:
    - Розширити локальне поняття dispatching для виклику через
    мережа
    - Побудувати об'єкт, що представляє образ сервера в кліен-
    тской системі.

    Диспетчер цього об'єкта повинен виконати наступні дії:
    - Встановити зв'язок з сервером
    - Перевести аргументи на допустиму для передачі форму
    - Надіслати повідомлення серверу
    - Чекати відповіді
    - Перевести відповідь сервера у формат локальної системи
    - Закрити з'єднання
    - Повернути відповідь.

    Подібний об'єкт-образ повинен інкапсулювати в собі інформацію,
    достатню для зв'язку з сервером; таким чином, він відбирає "се-
    тевую "частина диспетчеризації у клієнта. Hаприклад, в TCP/IP цей
    об'єкт описується як

    TYPE NetObj = Obj.T OBJECT
    hostname: TEXT;
    portnum: CARDINAL;
    OVERRIDES
    dispatcher: = NetObjDispatcher;
    END

    Подібним методом реалізуються і інші мережеві моделі. Окремо
    слід зауважити, що при великій кількості об'єктів часто
    доцільно присвоїти їм унікальні ідентифікатори або індекси,
    зберігаються окремо від них самих.

    Dispatching об'єктів у БД.

    В об'єктно-орієнтованих БД структура програми визна-
    ляется сутністю і відносинами якихось постійних об'єктів. Различ-
    ные бази пропонують свої специфічні моделі в залежності від
    цілей обчислень. Проблема dispatching цих об'єктів схожа з
    проблемою реалізації розподілених систем; для підтримки їх
    спільності ми повинні:
    - Винести посилання на об'єкти за межі БД;
    - Реалізувати заклинання над об'єктами з використанням
    ідей dispatching класів і родових функцій.

    Для доступу до об'єктів швидше за все буде потрібно застосовувати методи-
    ку, описану для розподілених систем. Важлива відмінність заклю-
    чає в тому, що для заклинання об'єктів БД сервер БД і його про-
    раз повинні підтримувати повідомлення "заклинання". У конкретно виготов-
    лення реалізації для цього застосовувався такий засіб об'єктивним
    тно-орієнтованих БД як динамічний заклинання. Дії сер-
    віра БД при отриманні заклинання:
    - Оттрансліровать аргументи на робочий формат;
    - Скласти з аргументів список і викликати механізм динамічних
    чеського заклинання для його обробки;
    - Повернути результат як список із значень базових типів і
    ідентифікаторів об'єктів.

    Dispatching бази правил.

    Традиційно системи працюють з базами правил мають закриту ар-
    хітектуру і включають в себе інтерфейс бази даних, що зберігає ці
    правила. У результаті правила справляють істотний вплив на
    системні питання, такі як база даних і мова програмування.
    У цій серії експериментів автори намагалися зрозуміти метод забезпе-
    ня гнучким dispatching зв'язку між правило-й об'єктно-орієнтир-
    ванними парадигмами.

    Модель бази правил.

    Традиційно системи складаються з двох частин: правил і фактів.
    Серцем системи є процесор правил, що використовує правила і
    факти для досягнення мети. Єдиним шляхом внесення в систему
    даних є декларація фактів. Правда, системи працюють з
    великими обсягами даних, часто об'єднані з БД і користувач
    може як декларувати факти, так і безпосередньо працювати з таблиця-
    ми БД.

    Для приведення баз правил до виду об'єктів ми повинні реалі-
    вати загальний механізм, що дозволяє їм доступ до зовнішніх даних - се-
    тевие заклинання; зокрема, це дасть БП доступ до віддалених БД.
    Тепер БП сама може розглядатися як розподілений об'єкт.

    Правила як методи об'єкту.

    Для використання правил в роботі об'єкту слід просто
    реалізувати диспетчер, делегує роботу процесору правил в
    Відповідно до заклинанням. Разом з доступом до БД ми отримуємо,
    що база правил є об'єкт зі станом - даними БД і методами -
    правилами, також зберігаються в БД. Зазвичай небажано, щоб
    правила безпосередньо зверталися до БД; відповідно, диспетчер дол-
    дружин передавати базі правил свій власний ідентифікатор і про-
    цессора правил буде звертатися до нього з заклинаннями доступу до
    даними.

    Винесені ув'язнення і невирішені проблеми.

    У ході експериментів з'ясувалося наступне:
    - Хоча в початковій ідеї заклинання розбивалося на адреси і
    аргументи, часто зручно розглядати заклинання як нерозривний
    сутність;
    - "Хороші" повідомлення по ідеї повинні розумітися всіма під-
    держіваемимі об'єктами. Hепонятно, як бути у випадку, коли пові-
    щення безглуздо для приймаючого - відповісти деяким стандар-
    тно-безглуздим чином або віддати об'єкту і дозволити йому про-
    працювати і/або згенерувати виключення;
    - Виникають питання з конкурентним доступом до об'єктів в
    розподілених системах. В даний час йде розробка додат-
    нений, які дозволять реалізувати будь-який з методів управління
    конкуренцією, запропонований у прикладних системах;
    - Метаоб'екти. У системі слід організувати якийсь мета-у-
    рівний і дозволити доступ до нього диспетчерів. Явна вказівку ал-
    горітмов диспетчеризації подібно до використання goto: і гнучко, і
    небезпечно. Поступово виділяться спільні шляхи диспетчеризації, які
    стануть високорівневим абстракціями;
    - Відділення мета-і базового рівня. Суміш в одному Менеджер-
    ре доступу до обох рівнів важка для сприйняття;
    - Оптимізація. Перевагою запропонованої схеми є те,
    що вона не розрахована на конкретний метод диспетчеризації і, сле-
    послідовно, можливо оптимізувати будь-які частини працює
    системи не порушуючи роботи інших.


         
     
         
    Реферат Банк
     
    Рефераты
     
    Бесплатные рефераты
     

     

     

     

     

     

     

     
     
     
      Все права защищены. Reff.net.ua - українські реферати ! DMCA.com Protection Status