Модели распределенных систем
Поможем в ✍️ написании учебной работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

1. Модели архитектуры. Модель архитектуры распределенной системы должна содержать решение двух проблем: физическое размещение компонентов между узлами и взаимодействие между компонентами.Реальные функции отдельных компонентов не указываются, указываются:

o Расположение (размещение по узлам).

o Шаблоны распределения данных и задач по их обработке.

o Взаимодействие компонентов (роли компонентов, шаблоны взаимодействия).

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

Архитектура

· Определяет разделение системы на наиболее крупные составные части.

· Определяет конструктивные решения, которые после их принятия с трудом поддаются изменению.

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

Основные принципы архитектуры

n Согласованность.Частичное знание системы позволяет предсказать остальное.

n Ортогональность. Функции независимы и специфицированы по отдельности.

n Соответствие. Включаются только функции, соответствующие существенным требованиям к системе, нет ненужных функций.

n Экономичность. Отсутствие дублирования.

n Прозрачность. Функции должны быть известны пользователю.

n Общность. Если функция должна быть введена, ее следует вводить в таком виде, чтобы она отвечала как можно большему числу назначений.

n Открытость. Можно использовать функцию иначе, чем это предполагалось при проектировании.

n Полнота. Введенные функции должны с учетом экономических и технологических ограничений как можно полнее соответствовать требованиям и пожеланиям пользователя.

Преодоление сложности:

1. Использование типовых решений - образцов проектирования.Каждое типовое решение описывает некую повторяющуюся проблему и ключ к ее разгадке, причем таким образом, что вы можете пользоваться этим ключом многократно, ни разу не придя к одному и тому же результату.

Структура типовых решений

n Название решения.

n Назначение (аннотация).

n Мотивация, применимость.

n Принцип действия (структура, участники, отношения).

n Результаты.

n Реализация.

2. Разделение системы на слои (расслоение).Основная идея: независимость нижележащих уровней от вышележащих. Основная задача: уменьшать сложность систем, разделяя их на слои и сервисы:

o Слой (уровень): группа сильно связанных и закрытых элементов, реализующих одну функциональность.

o Сервис: функциональность, обеспечиваемая для вышестоящего слоя.

Рисунок 1 – Монолитная система

Логика представления
Бизнес-логика
Логика доступа к данным
База данных

Рисунок 2 – Двухслойная система

Логика представления
Бизнес-логика
Логика доступа к данным
База данных

Рисунок 3 – Трехслойная система

Логика представления
Бизнес-логика
База данных
Логика доступа к данным

Три основных слоя

n Слои:

o представление (presentation).

o домен (domen) – предметная область, бизнес-логика.

o работа с данными (datasource).

n Рекомендуется различать:

o Слой (layer) – логическое разделение.

o Уровень или Ярус (tier) – физическое разделение.

Итоги

n Распределенная система – это автономные (но соединенные средой передачи данных) узлы. Взаимодействие осуществляется посредством передачи сообщений.

n Много доводов в пользу того, что распределенные системы нужны и их нужно уметь строить.

n Распределенные системы существуют и их нужно уметь развивать и поддерживать.

n При разработке распределенных систем возникают специфические проблемы.

n Используется модель слоев для снижения сложности системы. Middleware обеспечивает дополнительное удобство и дополнительные сервисы.

n Выбор модели архитектуры зависит от особенностей задачи.

o Клиент – сервер.

o Модель предоставления услуг пулом серверов.

o Модель прокси- и кэш-серверов.

o Модель равных процессов.



JDBC

В 1996 году компания Sunвыпустила первую версию интерфейса для организации доступа Java – приложений к базам данных (БД)JDBC(Java DataBase Connectivity). Настоящий интерфейс позволяет программистам соединяться с БД, запрашивать и обновлять данные с помощью языка SQL(StructuredQueryLanguage), который фактически стал стандартным средством взаимодействия с реляционными базами данных.

Javaи JDBCимеют весомое преимущество по сравнению с другими инструментами для работы с БД. Программы, созданные с помощью Javaи JDBC, не зависят от используемой платформы и поставщика программного обеспечения.

Средства JDBC неоднократно обновлялись. В состав JDK 1.2, выпущенной в 1998 году, была включена версия 2 JDBC. В JDK1.4 и 1.5 была включена версия 3 JDBC и т.д.

С самого начала поставщики программного обеспечения для БД поддерживали идею создания компанией Sunстандартного сетевого протокола доступа к БД, но при условии, что за основу будет принят их собственный протокол. В конечно итоге поставщики СУБД и инcтрументов доступа к базам всё-таки согласились с тем, что сотрудники Sunсоздали JavaAPIдля SQL-доступа к данным и диспетчер драйверов, который позволил бы подключать к базам драйверы независимых производителей. Такой подход позволял производителям СУБД создавать собственный драйверы, которые подключались бы с помощью диспетчера и должны лишь соответствовать требованиям APIдиспетчера драйверов.

В результате было создано два интерфейса. Разработчики приложений используют JDBCAPI, а поставщики БД и инструментальных средств – JDBCDriverAPI. Подход, используемый при создании JDBC, основан на модели ODBC(OpenDatabaseConnectivity) —интерфейса доступа к БД, разработанного фирмой Microsoft: программы, соответствующие API, могут взаимодействовать с диспетчером драйверов JDBC, который, в свою очередь, использует присоединенные драйверы для организации взаимодействия с БД.

Типы JDBC – драйверов:

1. Драйвер типа1. Транслирует JDBC в ODBC и для взаимодействия с БД использует драйвер ODBC.Sunвключила в состав JDKодин такой драйвер – мост JDBC/ODBC. Но для его использования требуется соответствующим образом установить и конфигурировать ODBC драйвер. В первом выпуске JDBC этот мост предполагалось использовать только для тестирования, а не для рабочего применения. В настоящее время имеется большое количество более удачных драйверов.

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

3. Драйвер типа 3.Создается только на основе библиотеки Java, в которой используется независимый от БД протокол взаимодействия сервера и базы. Этот протокол позволяет транслировать запросы в соответствии со спецификой конкретной базы. Если код, зависящий от БД, находится только на сервере, доставка программ существенно упрощается.

4. Драйвер типа 4.Представляет собой библиотеку Java, которая транслирует JDBC-запросы непосредственно в протокол конкретной БД.

Большинство поставщиков БД применяют драйверы типа 3 или 4. Кроме того, некоторые компании специализируются на создании драйверов, которые позволяют добиться более полного соответствия принятым стандартам, поддерживают большее количество платформ, обладают более высокой производительностью или надежностью, чем драйверы, предлагаемые производителями СУБД.

Основные цели интерфейса JDBC можно сформулировать следующим образом:

1) Разработчики создают программы на языке Java, пользуясь для доступа к БД стандартными средствами языка SQL, при этом они следуют только соглашениям языка Java.

2) Производители СУБД и инструментальных средств поставляют драйверы только низкого уровня.

Примеры использования JDBC

Согласно традиционной модели клиент/сервер, графический пользовательский интерфейс реализуется на стороне клиента, а БД располагается на стороне сервера. В этом случае драйвер JDBC находится на стороне клиента(рис.1).

Сервер БД
Клиент  
JDBC
                                                                                                                        Протокол БД

S FNZf6APPu9CIWEJcGA1tCEMhJdctOsMzPyDF7OhHZ0I8x0ba0VxiuevlIkmepDMdxYXWDPjSYv29 OzkN8vi6zd6HbL9Zzx+Y072yKW+0vr+b1s8gAk7hD4arflSHKjod/Iksi16DUvkyojHIMxARyHKV gjhoWKglyKqU/z+ofgEAAP//AwBQSwECLQAUAAYACAAAACEAtoM4kv4AAADhAQAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQA4/SH/1gAAAJQBAAAL AAAAAAAAAAAAAAAAAC8BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBLXCkasAIAAG4FAAAO AAAAAAAAAAAAAAAAAC4CAABkcnMvZTJvRG9jLnhtbFBLAQItABQABgAIAAAAIQBaxfM04AAAAAkB AAAPAAAAAAAAAAAAAAAAAAoFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABADzAAAAFwYAAAAA " adj="343" fillcolor="#5b9bd5 [3204]" strokecolor="#1f4d78 [1604]" strokeweight="1pt"/>RКлиент

 

Рисунок 4 – Традиционная структура приложения клиент/сервер

Однако современная тенденция развития программного обеспечения заключается в переходе от архитектуры клиент/сервер к «трехуровневой модели» (рис.2).

Клиент (визуальное представление)
                       HTTP, RMI, …                               Протокол БД

Промежуточный уровень (бизнес-логика)
JDBC
B pSxRSxfQCPgyCfbD/V0vOx1ueDTXMU+MRjB1UoDNeek4T8oaL9MmLAapO4foZaYYJ66jvNG4d7wq ioZ7OSNdsHIxB2vU53jxAoqDVWOIOH9L9XE8u8K329oL8fiwvjwDy2bNfzD86pM6DOR0ChfUiTkB bV3VhAqoSmDU79qG8onAbdkAH3r+/4PhBwAA//8DAFBLAQItABQABgAIAAAAIQC2gziS/gAAAOEB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADj9 If/WAAAAlAEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAFqc +G/BAgAAhgUAAA4AAAAAAAAAAAAAAAAALgIAAGRycy9lMm9Eb2MueG1sUEsBAi0AFAAGAAgAAAAh AJ5cDcPaAAAACQEAAA8AAAAAAAAAAAAAAAAAGwUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAE APMAAAAiBgAAAAA= " fillcolor="#5b9bd5 [3204]" strokecolor="#1f4d78 [1604]" strokeweight="1pt">
Сервер БД

 


Рисунок 5 – Приложение, созданное в соответствии с трехуровневой моделью

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

Взаимодействие между клиентом и промежуточным уровнем может быть реализовано на основе протокола HTTP (прииспользовании Web-браузера в качестве клиента), средств RMI (при использовании приложений или апплетов) или с помощью какого-либо другого механизма. JDBC используется для управления взаимодействием между промежуточным уровнем и БД.


Дата: 2019-02-19, просмотров: 303.