Buildingup client/server applications architecturewith generalized data transfer protocol.pdf С развитием информационных технологий все большее количе-ство разрабатываемых программных продуктов приобретают статускорпоративных приложений. Такие программные системы являют-ся большими и сложными [1]. Это означает, что разработчикидолжны постоянно следить за всем имеющимся кодом, контролиро-вать изменения и т.п. - делать все, что входит в понятие «управле-ние проектом». В таком контексте критически важным являютсявопросы устойчивости [2] архитектуры разрабатываемой про-граммной системы - ее способности в целом противостоять техно-логическим изменениям и дополнению функциональности.В настоящей работе предлагается каркас устойчивой архи-тектуры многоуровневых приложений клиент/сервер. Этот эф-фект достигается благодаря сильной изоляции технологическихэлементов связи между программными модулями системы имеханизмов, поддерживающих логику пакетов передаваемыхданных. Такая изоляция достигается благодаря введению поня-тия «обобщенный протокол передачи данных» и решения во-просов, связанных с его реализацией, что позволяет локализо-вать не только вопросы использования различных средств связии логики пакетов данных, но и возможности переключения содного на другой даже во время работы системы.ПОНЯТИЕ НАДСТРАИВАЕМОЙ СИСТЕМЫРассмотрим задачу создания программной системы снадстраиваемой функциональностью. Под надстраиваемо-стью будем понимать возможность подключения к готовойфункционирующей системе законченных программныхмодулей, имеющих общее объектное пространство с сис-темой. Понятие надстраиваемости напрямую связано с по-нятием устойчивости архитектуры [2] программной систе-мы. В нашем случае речь идет о системах, новая функцио-нальность которых приобретается за счет создания новыхпрограммных модулей без какой-либо модификации илидоработки уже функционирующих.Рассмотрим общий каркас трехуровневых клиент/серверных приложений (рис. 1).Рис. 1. Компоненты трехуровневого клиент/серверного приложенияТакие системы базируются на трех программных мо-дулях (исполняемых файлах): Client - клиентское прило-жение, Business Logic Server - сервер бизнес-логики иDatabase Server - сервер базы данных. Взаимодействиемежду приложениями происходит на уровне единогопространства имен и команд посредством передачи паке-тов данных по определенному протоколу передачи. Об-щая схема взаимодействия программных модулей выгля-дит следующим образом: клиент посылает запрос серверубизнес-логики, который (возможно, после некоторых дей-ствий) организует запрос серверу базы данных, а затем(опять же - после некоторых действий), если необходимо,возвращает ответный пакет клиенту.Поскольку каждый компонент такой системы являетсядостаточно независимым приложением и с некоторой сте-пенью точности может проектироваться самостоятельно, тов дальнейшем будем использовать термин «архитектура»как для понятия общей архитектуры всей системы, так и дляее частей, соответствующих отдельным компонентам илиподсистемам. В первом случае будем использовать термин«общая архитектура (системы)», а во втором - «локальнаяархитектура подсистемы (компонента)».Следуя поставленной цели создания общей архитек-туры «надстраиваемой» программной системы, можноутверждать, что, имея определенную локальную архитек-туру ее компонентов, добавление нового модуля не по-влияет на общую функциональность системы. Таким мо-дулем может быть как клиент сервера бизнес-логики, таки новый сервер, который будет занимать место междусервером бизнес-логики и клиентом либо между серверомбизнес-логики и сервером базы данных. Более того, этотсервер может быть частично внешним, т.е. иметь собст-венных клиентов или собственный сервер базы данных(либо не иметь его вообще). В таком случае обычно гово-рят о четырех- и более звенной архитектуре клиент/сер-вер. При этом количество добавляемых «промежуточ-ных» серверов или клиентов не должно быть ограничено,а расположены они могут быть на различных узлах ло-кальной или внешней сети.ОБОБЩЕННЫЙ ПРОТОКОЛПЕРЕДАЧИ ДАННЫХОсновное предназначение клиент/серверных систем -это обмен информацией между клиентским и сервернымприложениями. Находясь на разных узлах, они отсыла-ют друг другу информационные пакеты, совершенно незаботясь о том, как они дойдут до адресата. Это являетсязадачей служб, обеспечивающих выход в локальную илиглобальную сети. Любой пакет, отправленный этойслужбой, преобразуется к виду, соответствующему про-токолу передачи данных, по которому взаимодействуютприложения. В настоящее время существует достаточномного способов передачи данных. В данной работе ак-центируем внимание на самих пакетах данных, но дляначала выделим основные типы протоколов коммуника-ций между приложениями.1. Объектный (к данному типу относятся механиз-мы COM/DCOM, CORBA). Обмен данными при такомпротоколе передачи для разработчика выглядит как об-ращение к определенным методам интерфейсных объ-ектов сервера. Передача данных на сервер производит-ся через входные параметры этих методов, а возвратрезультата - через выходные. В случае использованияобъектных механизмов разработчик должен в кодепрограммы (статически) фиксировать имена (иденти-фикаторы) сервисных объектов и их методов, а также,чаще всего, в определенном порядке перечислять па-раметры вызова.2. Двоичный (TCP/IP). Данная группа протоколовподдерживает передачу произвольных данных, обязуяразработчика программно обрабатывать формированиеи расшифровку пакетов данных. Чаще всего при этомпакеты соответствуют некоторым внутренним для сис-темы структурам данных или их массивам, в которыхважны не только сами данные, но и их порядок.3. Текстовый (например формат XML). Протоколыэтого вида обычно функционируют на основе двоич-ных и отличаются только тем, что пакет имеет четкуюсимвольную структуру. Обычно такие пакеты могутбыть прочитаны «как есть», т.е. вполне понятны длячтения человеком. Порции данных в таких пакетахобычно описываются макроопределениями, вложенны-ми в сам пакет, а порядок их следования не играет ро-ли. В данном случае для формирования и расшифровкипакета программным системам достаточно знать толь-ко идентификаторы макроопределений.Отсюда видим, что основой передачи информации меж-ду приложениями кроме транспортных механизмов являют-ся пакеты данных. На первый взгляд, исключение составля-ют объектные механизмы коммуникаций. Однако для того,чтобы построить более гибкую систему, позволяющую сде-лать независимым ядро приложения от вида связи и дажеиметь возможность изменять его во время выполнения при-ложения, все функции коммуникаций между модулями сле-дует выделить в отдельную, достаточно изолированную под-систему. Таким образом, актуальной для любых видов про-токолов является локальная архитектура подсистемы по-строения и распознавания пакетов данных.Рис. 2. Подсистема построения пакетов данныхМы предлагаем архитектуру данной подсистемы,реализованную по шаблону «Строитель» [3]. На диа-грамме (рис. 2) изображены следующие классы: PackageBuilder(абстрактный) − построитель пакетов, невключающий реализации каких-либо методов, кромесвязи с ассоциированным с ним объектом класса Parser.Последний реализуется по шаблону «Абстрактная фаб-рика» [3] и включает описание общих методов, обеспе-чивающих создание пакетов, добавление в них новыхэлементов и считывание информации. Класс Parser также является абстрактным и, следовательно, не содер-жит реализации этих данных методов. Горизонтальнойчертой отделены уровень интерфейсов (сверху) и уро-вень их конкретной реализации (снизу).Основное назначение классов-потомков Package-Builder - формирование логики пакета («что должновходить в пакет»), а классов-потомков Parser - под-держка технологического уровня («как это записать впакет»). В частности, класс ConcreteParser (рис. 2)представляет интерфейс Parser с реализацией методовобработки данных конкретного формата: двоичных,текстовых или даже конкретных текстовых (например,XML с собственным описанием типа документа). ConcreteBuilder- класс, реализующий методы, позволяю-щие с помощью какого-либо объекта Parser, строить ираспознавать пакеты данных на уровне макроопреде-лений, не заботясь о технологической базе пакета.Поскольку данный подход применим при использованиилюбых механизмов передачи и форматов самих данных, назо-вем его обобщенным протоколом передачи данных. Вопросыже самих механизмов связи будут обсуждаться ниже.НАДСТРАИВАЕМАЯ АРХИТЕКТУРАКЛИЕНТ/СЕРВЕРРассмотрим архитектуру клиент/серверных приложе-ний с использованием обобщенного протокола передачиданных (рис. 3). Здесь пунктирными линиями разделеныразличные подсистемы. Причем движение по диаграммесверху вниз соответствует переходам от уровня описанияинтерфейсов к уровням их реализации. Часть, касающая-ся объектов Parser, для упрощения опущена, так как, какбыло описано выше, связь с ними поддерживают непо-средственно объекты PackageBuilder.Любые приложения, использующие обобщенный про-токол передачи данных (как клиент, так и сервер), должныиметь не только механизмы формирования пакетов дан-ных, но и средства связи между приложениями, а такжеподсистемы управления внутренними объектами. В даннойархитектуре выполнение указанных задач возлагаем наобъекты PackageBuilder, ClientConnection/ServerConnectionи Controller соответственно. Объекты класса Controller реа-лизуются по шаблону «Контролер» [4].Основные функции объекта ClientConnection - установкасоединения с сервером, передача исходящих и прием входя-щих (ответных) пакетов данных. Для объекта ServerConnection- это прием входящих пакетов от клиента и отправкаисходящих (ответных) пакетов. Эти функции заранее опреде-лены и не требуют изменений при надстраивании системы.Рис. 3. Архитектура надстраиваемых клиент/серверных приложений с обобщенным протоколом передачи данныхТаким образом, функциональность по управлениювнутренними объектами программных модулей и фор-мированию пакетов предлагается вынести на уровень«Приложение общего вида», так как она является общейдля построения программных модулей любого вида.Функциональность связи и специфические методы уп-равления объектами в клиентских и серверных прило-жениях разделяются и выносятся на уровни «Клиентскаячасть» и «Серверная часть» соответственно.Таким образом, три описанных уровня (компонента)предоставляют нам каркас клиент/серверной программ-ной системы. На его основе, дополняя подсистемы управ-ления объектами (ClientController, ServerController) и под-систему построения пакетов данных (PackageBuilder), мыможем построить программную систему с произвольнойклиент/серверной структурой (см. пример далее). В част-ности, на диаграмме показаны программные модулиConcreteClient и ConcreteServer, реализующие некоторыеконкретные приложения клиента и сервера, а также объ-ект ConcreteBuilder, необходимый для поддержки единогопространства макроопределений пакетов.ПРИМЕР РЕАЛИЗАЦИИТРЕХУРОВНЕВОГО ПРИЛОЖЕНИЯРассмотрим классическую модель трехуровневогоклиент/серверного приложения типа «клиент - сервербизнес-логики - сервер базы данных». На диаграмме(рис. 4) изображены компоненты, составляющие осно-ву такого приложения, а также объекты, входящие в ихсостав. Рассмотрим эту диаграмму подробнее.Рис. 4. Пример использования каркаса архитектуры надстраиваемых клиент/серверных приложенийс обобщенным протоколом передачи данныхДля того чтобы акцентировать внимание на общихи различающихся частях отдельных приложений сис-темы, используем дополнительное цифровое обозначе-ние в именах классов. Причем число 1 будет соответст-вовать компоненту «Клиент», 2 - компоненту «Сервербизнес-логики», 3 - компоненту «Сервер базы данных».Например, ClentController2 - класс, отвечающий функ-циональности класса ConcreteClientController (рис. 3) длякомпонента «Сервер бизнес-логики». Имена некоторыхклассов в разных компонентах совпадают (например,PackageBuilder1 в компонентах «Клиент» и «Сервер биз-нес-логики»). Это означает, что соответствующие объек-ты в точности реализуют одинаковую функциональность.Почему это так, объясняется ниже.При необходимости выполнить действия, связанныес обращением к серверу бизнес-логики, клиентское при-ложение через интерфейс (Client Interface) передает со-общение (обозначено числом «1») объекту :Client-Controller1. Последний, с помощью объекта :Package-Builder1, строит исходящий пакет данных (2) и переда-ет его объекту :ClientCon-nection1 (3). Далее объект:ClientConnection1 посредством выбранной внешнейслужбы связи передает этот пакет серверу бизнес-ло-гики (4, 5). Объект :ServerConnection2 передает входя-щий пакет объекту :ServerController2 (6), который с по-мощью объекта :PackageBuilder1 расшифровывает при-нятый пакет данных (7). Обратите внимание на то, чтоклиентское приложение и сервер бизнес-логики ис-пользуют построители пакетов одного и того же класса(PackageBuilder1). Это необходимо для поддержкиидентичности макроопределений пакетов.Далее, возможно, после некоторых действий, объект:ServerController2 передает управление объекту :ClientController2(8). То есть в данной ситуации сервер бизнес-логикивыступает в роли клиента сервера базы данных :Client-Controller2 с помощью объекта :PackageBuilder2 формируетисходящий пакет с запросом к серверу базы данных (9) иотправляет его посредством объекта :ClienConnection2 (10,11, 12). Здесь специально указан другой класс объекта ClientConnection,так как связь между сервером бизнес-логики исервером базы данных может производиться с использова-нием средств коммуникаций, отличных от средств, исполь-зующихся для связи клиента с сервером бизнес-логики.Затем объект :ServerConnection3 передает входящийпакет данных объекту :ServerController3 (13), который,используя объект :PackageBuilder2, расшифровываетпринятый пакет (14) и реализует запрос к базе данных(15). Здесь также использован принцип одного классапостроителя пакетов для двух взаимодействующих при-ложений (PackageBuilder2). Теперь проанализируем над-страиваемость архитектуры данного приложения. Дляэтого рассмотрим различные ситуации, когда к систе-ме добавляется новый программный модуль.1. Добавляется клиент сервера бизнес-логики (рис. 5).Соответствующий компонент должен иметь базовуюлокальную архитектуру, аналогичную первому клиен-ту. Поэтому при обращении к серверу бизнес-логикипроисходят те же действия, что и рассмотренные выше.Нет необходимости производить какие-либо измененияв архитектуре системы.Рис. 5. Добавление к системе нового клиента сервера бизнес-логики2. Добавляется клиент сервера бизнес-логики, вы-ступающий в роли сервера для других приложений(рис. 6). Такой программный модуль должен включатьв себя структуры, соответствующие как локальной ар-хитектуре серверной части (для клиентов), так и ло-кальной архитектуре клиентской части (для серверабизнес-логики). Такое построение аналогично структу-ре сервера бизнес-логики. В данном случае система со-ответствует типичной четырехуровневой модели кли-ент/сервер.Рис. 6. Добавление к системе нового сервера, являющегося клиентом сервера бизнес-логики3. Добавляется новый сервер бизнес-логики парал-лельно уже существующему (рис. 7). Оба сервера бизнес-логики обращаются к одному серверу базы данных. Кли-енты серверов бизнес-логики могут обращаться как к од-ному из них, так и к двум одновременно. Структура ново-го сервера бизнес-логики аналогична существующему, аклиентское приложение в случае различий в пространст-вах макроопределений серверов должно включать в себяеще один объект PackageBuilder и, возможно, ClientConnection- в случае новых механизмов связи.4. Добавляется новый сервер бизнес-логики, кото-рый является клиентом уже существующего серверабизнес-логики (рис. 8). Архитектура системы анало-гична случаям 2 и 3 только с учетом того, что новыйсервер бизнес-логики обращается к существующему ине связан с сервером базы данных.5. Добавляется новый сервер бизнес-логики, кото-рый может быть клиентом уже существующего серверабизнес-логики и сервера базы данных (рис. 9). Архи-тектура аналогична предыдущей ситуации, к тому женовый сервер бизнес-логики включает в себя необхо-димые подсистемы для связи с сервером базы данных.6. Добавляется новый сервер бизнес-логики и сер-вер базы данных, работающие параллельно с сущест-вующими модулями (рис. 10). Очевидно, что и в этомслучае архитектура системы не претерпевает глобаль-ных изменений и легко реализуется на предлагаемом вданной работе каркасе.Рис. 7. Добавление к системе нового сервера бизнес-логики, параллельно существующемуРис. 8. Добавление нового сервера бизнес-логики,который является клиентом уже существующего сервера бизнес-логики и сервером уже существующего клиентаРис. 9. Добавление нового сервера бизнес-логики,который может быть клиентом уже существующего сервера бизнес-логики и сервера базы данныхРис. 10. Добавление новых серверов бизнес-логики и базы данных, параллельно существующимВЫВОДЫПредложенный в работе каркас надстраиваемогообъектного многоуровневого приложения с обобщен-ным протоколом передачи данных позволяет проекти-ровать программные системы с устойчивой архитек-турой. При этом на архитектуру построенных прило-жений вновь вводимая функциональность, оформлен-ная в виде новых компонент (клиенты, серверы), ока-зывает локальное влияние. К тому же подход обобще-ния протокола передачи данных позволяет локализо-вать как изменения в технологиях связи, так и в про-странствах макроопределений пакетов данных.

Скачать электронную версию публикации