Первоисточник:http://www.sei.cmu.edu/str/descriptions/clientserver_body.html
Автор: Дарлен Садоски
Перевод с английского: Резниченко В.Л.
Цель и происхождение
Термин клиент-сервер впервые был использован в 1980 году в ссылке на персональные компьютеры (PCS) в сети. Фактически модель клиент-сервер была принята позднее 1980 года. Архитектура клиент-серверного программного обеспечения многосторонняя, основанная на сообщениях и модульной инфраструктуре, которая намеревается улучшить практичность, гибкость, совместимость, и масштабируемость по сравнению с централизованной универсальной ЭВМ, работа в режиме разделения времени.
Клиент определен как заказчик услуг, а сервер определен как поставщик услуг. Единая машина может быть как клиентом, так и сервером в зависимости от состава программного обеспечения. Для более конкретной информации об архитектурах клиент-серверного программного обеспечения, смотрите Schussel и Edelstein [Schussel 96, Edelstein 94].
Это описание технологии обеспечивает краткий обзор некоторых общих клиент-серверных архитектур и, для завершенности, также суммирует универсальною ЭВМ и архитектуры совместного использования файла. Детальное описание для многих из индивидуальных архитектур изложено где-нибудь в другом месте в документе.
Технические детали
Архитектура универсальной ЭВМ (не клиент-серверная архитектура). С архитектурой программного обеспечения универсальной ЭВМ все сведения находятся в пределах центрального главного компьютера. Пользователи взаимодействуют с хостом через терминал, который захватывает нажатия клавиши и посылает ту информацию хосту. Архитектура программного обеспечения универсальной ЭВМ не привязана к платформе аппаратных средств. Пользователи могут использовать рабочие станции PCS и UNIX. Ограничение программного обеспечения архитектуры универсальных ЭВМ в том, что они не поддерживают графический интерфейс пользователя (см. Graphical User Interface Builders) или доступ к многопользовательским базам данных от географически разобщённых участков. За последние несколько лет универсальные ЭВМ нашли новое использование как серверы в распространяемых клиент-серверных архитектурах (смотрите архитектуры клиент-серверного программного обеспечения).
Архитектура совместного использования файлов (не клиент-серверная архитектура). Оригинальные сети ПК были основаны на архитектурах совместного использования файла, где сервер загружает файлы с локального окружения к настольному окружению. Архитектура совместного использования файлов работает так: если разделенное использование низко, утверждение обновления низко, и объем данных, которые будут переданы низок. В 1990-х, LAN PC (локальная сеть) изменилась, потому что способность разделения файла стала ограниченной из-за того, что число пользователей онлайн, росло (это могло удовлетворить только приблизительно 12 пользователей одновременно), и стали популярными графические пользовательские интерфейсы (GUIs) (создание универсальной ЭВМ, и терминальные показы стали устаревшими). PC сейчас используются в клиентских/серверных архитектурах [Schussel 96, Edelstein 94].
Клиент-серверная архитектура. В результате ограничения использования архитектуры совместного использования файлов, появилась клиент-серверная архитектура. Этот подход ввел сервер базы данных, чтобы заменить файловый процессор. Используя систему управления реляционной базой данных (DBMS), пользовательским запросам можно было бы ответить непосредственно. Клиент-серверная архитектура сократила трафик сети, обеспечивая ответ запроса вместо полной передачи файла. Это улучшает многопользовательское обновление через клиентскую часть системы в разделенной базе данных. В клиент-серверных архитектурах чтобы общаться между клиентом и сервером обычно используются, вызовы удаленных процедур (RPCS) или стандартный язык запросов (SQL).
Остаток этой статьи показывает примеры клиент-серверных архитектур.
Двухуровневые архитектуры. С двухуровневыми клиент-серверными архитектурами интерфейс пользовательской системы обычно расположен в настольном окружении пользователя и услуги управления базой данных находятся обычно на сервере, который является более мощной машиной, которая обслуживает много клиентов. Обработка управления разделена между окружением интерфейса пользовательской системы и окружением сервера управления базой данных. Сервер управления базой данных обеспечивает сохраненные процедуры и триггеры. Есть целый ряд продавцов программного обеспечения, которые разрабатывают инструменты, чтобы упростить разработку приложений для двухуровневой архитектуры клиент-сервера [Schussel 96, Edelstein 94].
Двухуровневая архитектура клиент-сервера - хорошее решение для распределенного вычисления, когда дюжина групп людей по 100 человек, взаимодействуют на ЛВС одновременно. Это имеет целый ряд ограничений. Когда число пользователей превышает 100, производительность начинает портиться. Это ограничение - результат работы сервера, поддерживающего связь через "keep-alive" сообщения с каждым клиентом, даже, когда никакая работа не выполняется. Второе ограничение двух уровневых архитектур - это то выполнение услуг управления используя составляющие собственно процедуры базы данных, что ограничивает гибкость и выбор системы управления базами данных для приложений. Наконец, текущее выполнение двухуровневой архитектуры обеспечивает ограниченную гибкость в перемещении (переразделении) функциональных возможностей программы от одного сервера до другого, вручную не восстанавливая процедурный код.
Трёхуровневые архитектуры. Трёхуровневые архитектуры появились, чтобы преодолеть ограничения двух уровневых архитектур. В трех уровневых архитектурах, средний уровень был добавлен между окружением клиента интерфейса пользовательской системы и окружением сервера управления базой данных. Есть множество способов осуществить средний уровень, как например мониторы диалоговой обработки запросов, сервер сообщений, или сервер приложения. Средний уровень может выполнить организацию очереди, прикладное выполнение, и организацию базы данных. Например, если средний уровень обеспечивает организацию очереди, клиент может доставить его запрос к среднему слою и освободиться, потому что средний уровень обратится к данным и вернет ответ клиенту. Кроме того, средний слой добавляет планирования и приоритетности для работы в прогрессе. Ограничение трёхуровневой архитектуры в том, что её разработка является более трудной, чем визуально-ориентированная разработка двухуровневых приложений. Недавно, универсальным ЭВМ нашли новое применение, как серверам в трехуровневых архитектурах.
Трёхуровневый сервер сообщений. Передача сообщений - другой способ осуществления трёхуровневой архитектуры. Сообщения расположены по приоритетам и обрабатываются асинхронно. Сообщения состоят из заголовков, которые содержат приоритетную информацию, адрес и идентификационное число. Сервер сообщений соединяется с реляционным DBMS и другими источниками данных. Система сообщений - это хорошие решения для беспроводных инфраструктур.
Трёхуровневый сервер приложений. Архитектура трёхуровневого сервера приложений локализуется в теле приложения и запускается на отдалённом компьютере, вместо того чтобы системой пользовательского интерфейса клиента. Сервер приложения не управляет GUIS; скорее это разделяет деловую логику, вычисления, и двигатель выборки данных. Преимущества в том, что с меньшим программным обеспечением на клиенте меньше беспокойства, приложения более масштабируемы, и затраты поддержки и установки на едином сервере меньшие, чем поддержка каждого настольного клиента. Дизайн сервера приложения нужно использовать, когда безопасность, масштабируемость, и стоимость - это главные требования.
Трёхуровневая ORB архитектура. В настоящий момент промышленность работает над разработкой стандартов, чтобы улучшить совместимость и определить, каким будет общий Объектный Брокер Запроса (ORB-
Object Request Broker
). Разработка технологий использования клиент-серверных систем, которые поддерживают распространяемые объекты многообещающие, так как эти технологии поддерживают совместимость через языки и платформы, как и увеличение ремонтопригодности и применимости системы. В настоящий момент есть две выдающиеся распространяемые объектные технологии:
• CORBA
• COM/DCOM
Промышленность работает над стандартами, чтобы улучшить совместимость между CORBA и COM/DCOM. Объектная Группа Управления (OMG-
Object Management Group
) разработала карту между CORBA и COM/DCOM, которая поддерживается несколькими видами продукции.
Архитектура распределенной/совместной организации. Архитектура распределенной/совместной организации появилась в 1993 году. Эта архитектура программного обеспечения основана на технологии Объектной Брокера Запроса (ORB), но идет дальше чем CORBA, используя разделенный, повторно используемый бизнес модели (не только объекты) на широком для организации масштабе. Выгода этого архитектурного подхода в том, что стандартизированные деловые объектные модели и распространяемые вычислительные объекты объединены, чтобы предоставить гибкость организации, чтобы оперативно и технологически улучшить эффективность. Организация определена здесь как система, состоящая из многоразовых деловых систем или подсистем. Архитектура распределенной/совместной организации ограничена отсутствием коммерчески-доступного объектного анализа, ориентации и инструментов метода дизайна, которые сосредоточены на приложениях.
Использование
Клиент-серверные архитектуры используются в промышленности и армии. Они обеспечивают многостороннюю инфраструктуру, которая поддерживает замену более раннего программного обеспечения, вставкой новой технологии.