Файл: Варианты архитектуры «клиент - сервер»..pdf

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

3.5.Интеграция распределенных объектов.

Интеграция распределенных объектов — механизм, реализуемый промежуточным программным обеспечением, позволяющий интегрировать объекты, расположенные на удаленных платформах [12].

В результате развития объектно ориентированной-парадигмы возникло два стандарта, имеющих отношение к распределенным приложениям — общая архитектура брокеров объектных запросов CORBA (Common Object Request Broker Architecture), разработанная группой OMG и COM/DCOM (Common Object Model/Distributed COM), созданный компанией Microsoft.

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

В DCOM взаимодействие удаленных объектов основано на спецификации DCE RPC, в то время как CORBA содержит представление брокера объектных запросов (ORB), в котором реализован синхронный механизм, имеющий сходство с механизмом вызова удаленных процедур (RPC).

ORB реализует отправку объектных запросов, обеспечивает поиск требуемых сервисов и возврат результата. Одним из базовых компонентов стандарта CORBA является язык описания интерфейсов IDL, который обеспечивает «контрактные» отношения между терминалом и сервером и реализуется независимость от конкретного объектно-ориентированного языка [14].

В CORBA IDL реализованы основные принципы объектно-ориентированной парадигмы: инкапсуляция, полиморфизм, наследование. DCOM также предполагает использование собственной версии IDL разработанной Microsoft, но в рамках этой модели он выполняет вспомогательную функцию и применяется для упрощения описания объектов. Реальная интеграция, при применении данной технологии, происходит на уровне бинарных кодов, а не абстрактных интерфейсов, что составляет одно из основных отличий между двумя стандартами.

В соответствие с объектно-ориентированной парадигмой обе модели предоставляют возможность динамического связывания удаленных объектов, при этом клиентское приложение может выполнить обращение к серверному объекту на этапе исполнения, не обладая информацией о данном объекте на этапе компиляции). С этой целью в CORBA реализован интерфейс динамического вызова DII, в модели COM существует механизм OLE Automation [13]. При необходимости предоставляется информация о доступных объектах сервера из хранилища метаданных об объектах: Type Library при использовании стандарта COM и Interface Repositary в случае применения CORBA. Данный механизм обладает особой ценностью при реализации больших распределенных приложений, поскольку предоставляет возможность изменять функциональность серверов без существенной модификации клиентской части приложения.

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

3.6.Промежуточное ПО, ориентированное на обработку сообщений.

Промежуточное ПО, ориентированное на обработку сообщений — сравнительно новая технология, при использовании которой между приложениями происходит обмен байтовыми строками, называемыми сообщениями, путем обращения к API- интерфейсу Message Oriented Middleware (MOM) [12]. Это позволяет изолировать приложения от операционной системы и сетевых протоколов. Данный тип промежуточного программного обеспечения поддерживает не только клиент-серверную модель, но и приносит элементы равноправного взаимодействия (модель peer-to-peer) между отдельными компонентами архитектуры.

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

Все примеры данной архитектуры принято классифицировать на три типа, в зависимости от выбранного типа обмена сообщениями:

• очереди сообщений,
• подписка/публикация,
• передача сообщений

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

Модели иного типа представляет асинхронный механизм очереди сообщений (Рис.8). Подобная реализация не требует поддержки непосредственного соединения одного компонента с другим, при этом осуществляет гарантированную доставку сообщения, даже при условии, что конечное приложение на данный момент недоступно. Приложение-отправитель передает сообщение механизму очереди и продолжает свое выполнение. Сообщение помещается при этом в промежуточное хранилище, расположенное на диске или в оперативной памяти, откуда передается приложению получателю немедленно, или спустя какое-то время, когда получатель будет доступен.

Рисунок 8. Механизм очереди сообщений.

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

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

Очереди сообщений могут быть долговременного типа. В этом случае, при возникновении сбоя в работе менеджера сообщения восстанавливаются после его перезапуска. Подобный тип менеджера предпочтителен для систем с критичными данными, например банковских распределенных приложений [14].

Кроме того системы на основе очередей сообщений можно разделить на следующие три типа:

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

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

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

Для обеспечения стандартизации в области промежуточного программного обеспечения ориентированного на обработку сообщений с целью эффективного взаимодействия решений от разных поставщиков в 1994 году был создан консорциум Message-Oriented Middleware Association (MOMA), в кторый вошли такие компании, как IBM и Sun Microsystems. Позже она была переименована в Iternational Middleware Association, которая занимается общим развитием систем промежуточного слоя [12].

ЗАКЛЮЧЕНИЕ

В данной работе было дано определение понятия «архитектура «клиент-сервер», рассмотрены факторы, способствующие ее возникновению, история развития, приведены ее основные характеристики и компоненты. Были изучены типы серверов и основные клиент-серверные технологии.

Это позволило рассмотреть различные виды архитектуры «клиент-сервер», сравнить их между собой, определив достоинства и недостатки. Были рассмотрены различные варианты архитектуры, в зависимости от количества уровней, а также используемого промежуточного программного обеспечения.

Цели и задачи курсовой работы считаю выполненными.

Подводя итоги, можно сделать вывод, применение многоуровневой модели архитектуры «клиент-сервер» является наиболее рациональным при решении большинства бизнес-задач. Свойства системы, ее преимущества и ограничения во много определяются не только количеством звеньев, но и используемым типом промежуточного программного обеспечения. Его дальнейшее совершенствование во многом определит последующее развитие всей технологии и позволит более точно соответствовать заявленным требованиям.

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

БИБЛИОГРАФИЯ

1. Баканов В.М. Программное обеспечение компьютерных сетей и информационных систем.— М., 2003.
2. Дуглас Камер Сети TCP/IP, том 1. Принципы, протоколы и структура.
   М.: Вильямс, 2003. — 851 с.
3. Когаловский М.Р. Энциклопедия технологий баз данных.—М.:Финансы и статистика, 2005. — 800 с.
4. Программное обеспечение компьютерных сетей: Учебное пособие / О. В. Исаченко. — М.: ИНФРА-М, 2012. — 117 с.
5. Руденков Н.А., Долинер Л.И. Основы сетевых технологий: Учебник для вузов. Екатеринбург: Изд-во Уральского Федерального ун-та, 2011 – 300 с.
6. Руководство Microsoft по проектированию архитектуры приложений. 2-е издание. — 2009. 529 с.
7. Соммервилл Иан. Инженерия программного обеспечения 6-е изд., пер. с англ. — М.: Вильямс, 2002. — 624 с.
8. Таненбаум Э., М. ван Стеен. Распределенные системы. Принципы и парадигмы/ — СПб.: Питер, 2003. — 877 с.
9. Фаулер, Мартин. Архитектура корпоративных программных приложений.: Пер. с англ. — М.: Издательский дом "Вильямс", 2006 — 544 с.
10. Хьюз Камерон. Параллельное и распределенное программирование на С++ Издательский дом ISBN, 2004.
11. Эбберс М. Введение в современные мейнфреймы: основы z/OS., пер. с англ. - М.: 2007
12. Дубова Наталья. Все про промежуточное ПО. // Открытые системы. СУБД. - 1999. - NN 07-08.
13. Касаткин Александр. Средства Middleware и их классификация. // PCWeek, 1999. - N19.
14. Эйнджел Джонатан. Промежуточное программное обеспечение. // Журнал сетевых решений. - 1999. - N11