По умолчанию каждая SQL-команда выполняется в своей транзакции, но можно это отключить:
con.setAutoCommit(false);
con.commit();
con.rollback();
CORBA (common object request broker architecture) – технология удаленной работы с объектами. CORBA, в отличие от RMI, обеспечивает взаимодействие между объектами, написанными на разных языках. Для этого используется брокер объектных запросов (ORB), который работает и на клиенте, и на сервере.
Сначала описывается интерфейс на языке IDL. Потом это описание компилируется в классы-заглушки и вспомогательные классы на целевых языках. Затем реализуются и компилируются объекты-серверы, после чего они регистрируются в программе-сервере (наиболее удобны способ регистрации – использование службы имен CORBA, аналогичной реестру RMI). После этого уже можно создавать программу-клиент и запускать клиент и сервер.
2. Общие положения теории РСОИ
РС содержит компоненты, которые распределены по разным компьютерам.
РС – набор независимых компьютеров, представляющихся их пользователям единой системой. Пользователи и приложения единообразно работают в РС, независимо от того, где и когда происходит их взаимодействие.
Хост – компьютер, на котором размещены компоненты вычислительной системы: аппаратура и сетевая ОС.
Взаимодействие РС
А – головная боль для программистов.
РС содержит несколько хостов и более одного компонента. Компоненты должны взаимодействовать друг с другом.
Взаимодействие компонентов:
Предоставляет доступ к своим службам
Компонент может запрашивать обслуживание у других компонентов
Для взаимодействия используется тот или иной вариант промежуточного уровня, который решает проблему неоднородности и распределения. Промежуточный слой располагается между компонентами и сетевой ОС
Промежуточный слой.
Хост – компьютер, на котором выполняются компоненты, составляющие часть распределенной системы.
Распределенная система – группа автономных хостов, соединенных при помощи компьютерных сетей.
На каждом хосте:
выполняются компоненты
функционирует промежуточный слой. Компоненты, которые координируют свои действия, таким образом, что пользователь воспринимает систему как единое интегрированное вычислительное средство.
Распределенная система вычислений от Google.
РС Nutch построен на основе Hadoop — это фреймворк, реализующий идею MapReduce. Термины map и reduce пришли из функционального программирования, где они означают следующее: reduce это функция типа α -> β, map — функция типа (α -> β) -> [α] -> [β]. То есть map применяет переданную ей первым аргументом функцию reduce к списку элементов типа α и на выходе получается список элементов типа β. Например, если мы определим функцию square x = x ∗ x, вызов map square[1,2,3] вернет [1,4,9]. Если reduce функция без побочных эффектов (то есть она не изменяет ничего за пределами своей области видимости), то применять ее можно одновременно к нескольким элементам входного списка. Гугловый фреймворк MapReduce позволяет прозрачно для программы разносить эти вычисления по многим машинам. Hadoop представляет собой open-source реализацию этой же идеи на Java.
Распределенная система синхронизация кода.
Отличие таких систем - отсутствие центрального репозитория, к которому обращаются клиентские программы; репозиториев может быть много и между ними существует возможность синхронизации. Такой механизм работы даёт больше свободы разработчику, вместо получения рабочей копии и её отправки обратно в центральный репозиторий разработчик может получить репозиторий в своё полное владение - вносить изменения на своё усмотрение и только отдельные изменения синхронизировать с основным репозиторием.
Распределенные системы обнаружения спама.
Сбор информации в различных репозитариях (параметры приходящей почты, сигнатуры), анализ информации (анализ технической информации сообщения, анализ тела сообщения (контентный анализ) методами лингвистики, либо статистики), на основании анализа публикация в репозитарии признаков спама и синхронизация этой информации с другими распределенными точками сбора информации.
Распределенная система управления сетями.
Сбор и анализ информации о сети. Управляющая станция со специальным ПО, центральная БД. Агенты на различных устройствах и службах – собирают информацию, сохраняют себе на лок. БД, отсылают информацию в определенные моменты управляющей станции.
Распределенная файловая система (Distributed File System – DFS) для OL Windows 2000 Server представляет собой одну из сетевых служб, которая упрощает поиск и администрирование данных в корпоративных сетях.
Когда вы пользуетесь распределенной файловой системой, ее реальная структура скрыта от вас и в действительности может иметь динамический характер. Так, можно создать иерархическую файловую структуру, корневой каталог которой будет находиться на NT-сервере, а все ее узлы будут распределены на различных носителях в сети. DFS представляет собой инструмент, позволяющий пользователям корпоративной информационной системы получить единообразное представление данных и файлов, распределенных по сети так, как будто все они находятся на его машине.
Требования бывают: функциональные и нефункциональные.
Функциональные – поддаются локализации при реализации
Нефункциональные – относятся к качеству системы – носят глобальный характер и оказывают существенное влияние на выбор общей архитектуры системы на этапе проектирования:
Масштабируемость
Способность системы адаптироваться к будущему росту нагрузки. Проблемы: узкие места по обслуживанию (один сервер для множества клиентов), по данным (один файл с общей информацией), по алгоритмам (централизованный алгоритм и перегрузка коммуникационной сети). Свойства децентрализованных алгоритмов:
· Никто не обладает полной информацией о системе
· Решения принимаются на основе лекальной информации
· Сбой в одном месте не вызывает нарушения работы алгоритма
· существования единого времени не требуется
· Прозрачность (в следующем билете)
Открытость
Систему можно легко расширять и модифицировать (интеграция новых компонентов, отвечающих новым функциональным требованиям => компоненты должны иметь четко определенные интерфейсы) Правильный интерфейс обеспечивает возможность правильной совместной работы одного процесса с другим, представляющим интерфейс. Самодостаточность и нейтральность. Переносимость характеризует, насколько приложение, сделанное для одной системы, может работать в составе другой. Способность к взаимодействию характеризует, насколько две разные реализации системы в состоянии работать совместно.
Гибкость – легкость конфигурирования системы, состоящей из различных компонентов, и легкость подключения новых компонентов.
Неоднородность
В распределенных системах, компоненты должны объявлять о предлагаемых услугах. Заявки могут быть синхронными/асинхронными. Клиент и сервер могут быть неоднородными. Причины неоднородности:
· Компоненты могут приобретаться в готовом виде
· При создании нового компонента, на него могут накладываться требования взаимодействия с существующими компонентами
· Компоненты создаются разными разработчиками
· Используются различные технологии
Разделение ресурсов
Ресурс – аппаратура, ПО, данные. Требуется определить, кому будет разрешен доступ к ресурсу => требуется вести учет пользователей. Менеджер ресурсов – компонент, предоставляющий доступ к разделяемым ресурсам.
Модели взаимодействия:
· Клиент-серверная (сервер предоставляет доступ к ресурсам)
· Концепция распределенных объектов, предоставляющих доступ к имеющимся у них ресурсам при обращении других компонентов
Отказоустойчивость
Система может продолжать работу даже в случае неисправности => избыточность => применение репликации (при отказе компонента, начинает работать его копия и обслуживание не прекращается)
Имеет несколько различных аспектов:
1. Прозрачность масштабируемости (обеспечивается 4, 5) - программист не должен знать, как достигается масштабируемость распределенной системы.
2. Прозрачность производительности (обеспечивается 4, 5) – пользователь и программист не знают, как поддерживается хорошая производительность.
3. Прозрачность отказа (обеспечивается 5, 6) - пользователям и программистам не требуется знать, как ВС справляется с отказами.
4. Прозрачность миграции (обеспечивается 7, 8) – перемещение компонентов незаметно для пользователей и без специальных действий со стороны разработчиков этих компонентов
5. Прозрачность репликации (обеспечивается 7, 8) – пользователям и разработчика не требуется знать, кто предоставляет услугу – реплика или основной компонент. Разработчики компоненты не должны учитывать возможность его репликации
6. Реплика – копия, которая остается синхронизированной с оригиналом
7. Прозрачность одновременного выполнения. Означает, что пользователи программы не знают, что компоненты запрашивают услуги одновременно. Несколько компонентов могут запрашивать обслуживание одновременно с сохранением его услов-ти. Пользователи и разработчики не видят, как организуется одновременно обслуживание.
8. Прозрачность доступа – одинаковость интерфейсов для локальной и удаленной связи (интерфейс заявки на обслуживание должен быть одним и тем же для связи между компонентами одного хоста и разных хостов)