Распределенные программные системы java

Источник

1. Распределенные приложения. Введение

Зачастую для предоставления телекоммуникационных услуг требуется создание распределённых приложений (распределённых информационных систем). Распределённое приложение – это программа, состоящая из нескольких взаимодействующих частей, каждая из которых, как правило, выполняется на отдельном компьютере (или другом устройстве) сети: Например, одна часть приложения, выполняющаяся на компьютере пользователя, может поддерживать специализированный графический интерфейс вторая работать на мощном выделенном компьютере и заниматься статистической обработкой введенных пользователем данных, а третья — заносить полученные результаты в базу данных на компьютере с установленной стандартной СУБД. Распределенные приложения в полной мере используют потенциальные возможности распределенной обработки, предоставляемые вычислительной сетью, и поэтому часто называются сетевыми приложениями Распределённая система – программно-аппаратное решение, состоящее из компонентов, функционирующих на физически удаленных и независимых друг от друга гетерогенных узлах, представляющееся пользователям единой объединенной системой. Распределенные вычислительные системы обладают такими общими свойствами, как:

• управляемость — подразумевает способность системы эффективно контролировать свои составные части. Это достигается благодаря использованию управляющего программного обеспечения (ПО);
• производительность — обеспечивается за счет возможности перераспределения нагрузки на серверы системы с помощью управляющего ПО;
• масштабируемость — при необходимости физического повышения производительности распределенная система может легко интегрировать в своей транспортной среде новые вычислительные ресурсы;
• расширяемость — к распределенным приложениям можно добавлять новые составные части (серверное ПО) с новыми функциями.

Недостатки распределённых систем:

• коммуникационная среда – слабое место распределённых систем, поэтому ошибки в таких системах возникают чаще, чем в монолитных;
• архитектура распределённого приложения сложнее чем монолитного.

Требования к разрабатываемым распределённым системам:

• использование открытых стандартов для обеспечения независимости от конкретной платформы и работы программных систем в гетерогенной среде;
• безопасность, включает в себя:
  • конфиденциальность,
  • целостность,
  • доступность.

  1 Типовые архитектуры распределённых приложений

  • Клиент-сервер;
  • Мобильные агенты;
  • Тонкий клиент;
  • Архитектура peer-to-peer (P2P).

  1.1 Архитектура клиент-сервер

  Данный вид архитектуры распределённых приложений является в настоящее время наиболее распространённым для информационных систем. Существует мнение, что все остальные архитектуры могут быть представлены вариациями данной базовой архитектуры.

  

  Данная информационная система представляет собой совокупность взаимодействующих компонент двух типов: клиентов и серверов. Как правило, данные компоненты разнесены по узлам двух типов: узлам-клиентам и узлам-серверам.

  Клиенты обращаются к серверам с запросами, которые те обрабатывают и возвращают результат. Один клиент может обращаться с запросами к нескольким серверам. Серверы также могут обращаться с запросами друг к другу. Таким образом, типичный протокол взаимодействия может быть представлен в виде обмена сообщениями: запрос клиента – ответ сервера.

  Наиболее часто встречающийся класс приложений, выполненных в архитектуре клиент-сервер, – это приложения, работающие с базами данных. В данном случае в качестве сервера выступает СУБД, обеспечивающая выполнение запросов клиента, который реализует интерфейс пользователя.

  Далее представлены несколько моделей, реализующих архитектуру клиент-сервер.

  1.1.1 Модель сервиса

  Модель сервиса реализует ситуацию, когда услугу выполняет не один, а несколько серверов, представляемых клиенту как единое целое. Т.е. сервер имеет сложную структуру.

  

  Данный вариант хорош для критичных сервисов, когда недопустима приостановка обслуживания. Для прекращения обслуживания необходима остановка всех серверов системы. Кроме того, такая система позволяет сбалансированно распределять нагрузку между серверами. Таким, образом, может быть повышена как производительность, так и устойчивость к сбоям.

  С другой стороны такая модель требует более сложной реализации по сравнению с базовой, и могут возникнуть проблемы с репликацией обрабатываемых на нескольких серверах данных или с поддержанием целостности распределённых данных.

  1.1.2. Технология Proxy

  Примером данной модели является привычная для нас структура: браузер – proxy-сервер — web-сервер.

  Отличие от предыдущих моделей заключается в том, что клиент соединяется не с сервером, а с некоторым промежуточным компонентом (посредником).

  

  Посредник может сам решать, какому из серверов передать запрос клиента (можно с его помощью распределять нагрузку). Кроме того, посредник может сохранять последние запросы клиента, чтобы при следующем обращении вернуть ему ответ, не обращаясь к серверу.

  Недостаток: при неправильном построении посредник может стать узким местом системы в целом.

  При работе в интернет чаще всего используется именно такой подход.

  1.2 Мобильные клиенты

  Идея рассматриваемой модели состоит в том, что зачастую, как это ни парадоксально, клиент сам в состоянии выполнить ту задачу, решение которой он запросил у сервера, более того, данные, необходимые для решения этой задачи, располагаются на клиенте. В таком случае для разгрузки сервера (и очень часто — для снижения сетевого трафика) целесообразно решать эту задачу на клиенте. Но как это сделать, если у клиента нет соответствующего программного модуля, содержащего необходимую функциональность? Ответ таков — этот модуль нужно клиенту отправить. Клиент, получив модуль (этот модуль называется мобильным агентом), может выполнить его локально, решив таким образом задачу.

  

  В качестве примера можно рассмотреть взаимодействие браузера и веб-сервера, возвращающего страницу, которая содержит апплет. Апплет также передается клиенту и выполняется в браузере (т.е. на клиенте), выполняя какие-то значимые для пользователя действия. Основная проблема для такого подхода состоит в сложности реализации механизма передачи и выполнения мобильных агентов, а также контроля безопасности. Однако, современные средства middleware1 (Java, например) такими возможностями обладают.

  1.3 Тонкий клиент

  В течение нескольких последних лет наблюдается постоянное увеличение количества применяемых портативных устройств — сотовых телефонов, PDA, планшетов и т.д. Возникает естественное желание использовать такие устройства как средства для работы с информационными системами (например, зайти на wap-сайт туристического агентства и заказать путевку прямо с сотового телефона). Однако, интерфейс, предоставляемый браузерами, весьма ограничен. С другой стороны, в силу ограниченной мощности мобильных устройств в них пока не удается размещать приложения со сложной бизнес-логикой.

  Решить эту проблему можно, используя технологию «тонкого клиента». Суть этой технологии состоит в том, что клиент выполняет очень ограниченную по функционалу задачу (часто — только прием ввода с клавиатуры и других устройств и обработка команд рисования). Схема работы подобных систем в простейшем случае следующая. Клиентская программа передает весь ввод пользователя (нажатия клавиш, движение мыши и т.д.) по сети серверу.

  

  Таким образом, сервер фактически берет на себя не только задачу управления данными, но и вообще все задачи по логике клиентского интерфейса.

  1.2 Архитектура P2P (Peer to Peer)

  Другой архитектурой, встречающейся, в основном, в специальных областях, является архитектура P2P. Приложение, выполненное в такой архитектуре, не имеет четкого разделения на серверные и клиентские модули — все его части равноправны и могут выполняться на любых узлах.

  

  Таким образом, на одном и том же узле в один момент выполняются части системы, обрабатывающие запросы других частей (и узел выполняет «серверную» часть), а в другой момент времени — части системы, посылающие запросы (и узел выполняет «клиентскую» часть). Причем приложение может быть устроено так, что вызывающая часть не знает, локально или удаленно расположена вызываемая.

  Построенные таким образом приложения обладают уникальными свойствами — их части никак не привязаны друг к другу и к узлам, на которых они исполняются. Таким образом, от запуска к запуску может меняться состав модулей, расположенных на узле. Это позволяет организовывать очень изощренные политики распределения нагрузки, а также обеспечивать очень хорошие показатели масштабируемости и отказоустойчивости.

  В отличие от архитектуры клиент-сервер, такая организация позволяет сохранять работоспособность сети при любом количестве и любом сочетании доступных узлов.
  Такая архитектура активно используется для разработки параллельных вычислительных систем для решения сложных вычислительных задач.

  Помимо чистых P2P-сетей, существуют так называемые гибридные сети, в которых существуют серверы, используемые для координации работы, поиска или предоставления информации о существующих машинах сети и их статусе (on-line, off-line и т. д.). Гибридные сети сочетают скорость централизованных сетей и надёжность децентрализованных благодаря гибридным схемам с независимыми индексационными серверами, синхронизирующими информацию между собой. При выходе из строя одного или нескольких серверов, сеть продолжает функционировать. К частично децентрализованным файлообменным сетям относятся, например EDonkey, BitTorrent.

  Источник