В наше время практически во всех сферах жизни человеческого общества применяются те или иные системы обработки данных. Это могут быть банковские системы, промышленные программные комплексы, средства автоматизации торговли и многие другие приложения. Постоянное расширение областей применения вычислительной техники и все возрастающая сложность решаемых задач требуют совершенствования методов создания современных информационных систем.
С начала 90-х годов XX века известна такая технология реализации программных приложений как архитектура "клиент-сервер". Ее основная особенность состоит в том, что приложение делится на два уровня - представление данных (клиент) и хранение данных (сервер БД). Обработка информации происходит на клиенте, на сервер посылаются запросы и обрабатываются полученные в ответ на них данные. Такой подход оправдывает себя при создании небольших, относительно несложных систем. Но по мере развития приложений, по мере роста объемов данных и ужесточения требований к скорости их обработки, становятся видны недостатки двухуровневой архитектуры. На смену ей приходит новая архитектура - трехуровневая. Она характеризуется тем, что деловая логика системы выносится на отдельный уровень и обособляется от пользовательского интерфейса и хранения данных. В трехуровневой модели выделяются следующие уровни:
уровень представления данных (клиентский компьютер);
уровень деловой логики (сервер приложений);
уровень хранения данных (сервер БД).
Рисунок 1. Трехуровневая архитектура
Клиент предназначен только для представления информации пользователю, вся обработка данных осуществляется на сервере приложений. Деловая логика на этом сервере реализована в виде компонентов, и через вызовы методов этих компонентов клиентская программа получает необходимые пользователю данные. Сервер приложений обслуживает поступающие от такого клиента обращения, осуществляет запросы к серверу базы данных и обрабатывает их результаты.
Актуальность трехуровневой архитектуры обусловлена следующими причинами :
Поддержка распределенных архитектур и Интернет Построение Интернет-систем невозможно без выноса деловой логики на средний уровень. Понятие "тонкого клиента" подразумевает использование серверов приложений, так как сервер БД не предназначен для обработки http-обращений, а HTML-клиент с броузером не может обсчитывать данные. В отличие от клиент-серверной трехуровневая модель позволяет обеспечить доступ к данным клиентам самых различных типов - Windows-клиент через ЛВС, HTML-клиент через Интернет, наладонный компьютер (PDA) через беспроводный доступ.
Снижение затрат Отделение обработки данных от пользовательского интерфейса позволяет изменять деловую логику приложения не затрагивая клиента. При создании новой версии бизнес-логики нет необходимости обновлять все клиентские места - необходимые изменения осуществляются на одном-единственном сервере приложений. За счет этого удается снизить как финансовые, так и временные затраты на обслуживание используемых систем.
Масштабируемость При повышении требований к быстродействию возможен перенос деловой логики системы на более производительную платформу, что обеспечивается кроссплатформенной совместимостью сервера приложений. При необходимости наращивания вычислительных ресурсов становится возможным приобрести только один мощный компьютер для сервера приложений, а не много быстродействующих клиентских станций.
Отказоустойчивость Технологии, лежащие в основе сервера приложений, позволяют строить такие отказоустойчивые системы, которые могут работать даже в случае выхода из строя одного или нескольких компьютеров. При этом используется кластеризация - объединение в единую логическую группу нескольких серверов приложений. Для клиентов такая группа выглядит как единый сервер, и в случае выхода из строя какого-либо из серверов кластера нагрузка динамически перераспределяется между оставшимися серверами.
Инструменты разработки трехуровневых систем - подход Sybase
Используя свой многолетний опыт в области выпуска инструментов построения корпоративных приложений, корпорация Sybase предлагает законченное решение для реализации систем в трехуровневых архитектурах. В качестве сервера приложений предлагается Enterprise Application Server (EAServer) - высокопроизводительная среда для исполнения компонентов, реализующих деловую логику информационной системы. Отличительной чертой EAServer является открытость - он поддерживает широкий перечень различных типов компонентов, таких как Java, C/C++, COM/ActiveX, PowerBuilder Non-Visual User Object (PB NVUO). Впечатляет набор операционных систем, поддерживаемых EAServer - это как все варианты 32-разрядных ОС семейства Windows, так и наиболее известные UNIX-платформы (Sun Solaris, Hewlett Packard HP-UX, IBM AIX, а также LINUX). Более подробную информацию о возможностях EAServer можно найти в статье [1].
В качестве средства разработки приложений для трехуровневой архитектуры предлагается PowerBuilder - инструмент, который без преувеличения можно назвать классикой систем, предназначенных для работы с SQL СУБД. Начиная с первых версий PowerBuilder был средством разработки клиент-серверных приложений, и средством достаточно успешным. Основой его успеха стала удачная технология работы с данными через механизм DataWindow, а также открытость и масштабируемость. Мало какой иной инструмент позволяет работать с таким широким спектром источников данных - от DBF-файлов до корпоративных БД масштаба Sybase SQL Server или Oracle.
Первые возможности для разработки трехуровневых приложений появились в PowerBuilder в середине 90-х годов. С течением времени эта функциональность развивалась и наращивалась, и текущая версия продукта - PowerBuilder 8.0 - предлагает широкие возможности для разработки многоуровневых информационных систем. Одна и та же деловая логика, реализованная средствами PowerBuilder и функционирующая в виде компонентов на EAServer, доступна для использования в любых типах архитектур - как клиент-серверных, так и распределенных, а также и в Интернет. Такие технологии как DataWindow и PowerScript могут использоваться как при разработке обычных Windows-программ, так и при создании бизнес-компонентов, предназначенных для работы в среде EAServer. Более того, предлагаются специальные методики переноса двухуровневых приложений, написанных в прежние годы на PowerBuilder, в трехуровневую архитектуру. Деловая логика таких приложений выносится из клиентских программ и реализуется в виде компонентов для EAServer. Эти компоненты развертываются на сервере приложений, и клиентские программы настраиваются для вызова их методов. За счет того, что в EAServer реализована полная функциональность PBVM (PowerBuilder Virtual Machine), достигается возможность исполнения написанного на PowerBuilder кода на сервере приложений без каких-либо ограничений. Ни один из других представленных на рынке серверов приложений не предлагает разработчикам на PowerBuilder такой возможности. Необходимо отметить, что связка PowerBuilder + EAServer является в настоящее время полнофункциональным и хорошо отлаженным решением, предлагаемым компанией Sybase для реализации многоуровневых информационных систем.
Создание распределенных приложений на PowerBuilder
Основные понятия, используемые при разработке трехуровневых приложений в среде PowerBuilder:
Сервер приложений (application server) - среда исполнения бизнес-компонентов, реализующих деловую логику приложений. Компоненты могут вызываться не только клиентскими программами, возможен вызов методов одного компонента другим компонентом, расположенном на том же самом или на другом сервере приложений.
Клиентское приложение (client application) - программный модуль, вызывающий методы удаленных компонентов. При работе с сервером приложений клиент может вызывать методы удаленных компонентов таким же образом, как если бы эти компоненты были расположены локально.
Компоненты (components) - невизуальные пользовательские объекты PowerBuilder (Non-Visual User Objects, NVOU's). В этих объектах в виде пользовательских функций (User Object Functions) пишутся методы, реализующие бизнес-логику системы на языке PowerScript. В таких методах доступна любая программная функциональность PowerBuilder, в том числе и работа с DataWindow (точнее с его невизуальным вариантом DataStore, специально предназначенном для использования в распределенных архитектурах).
Прокси-объект (proxy object) - описание сигнатур методов компонента, расположенного на сервере приложений. Proxy генерируется по такому компоненту и помещается в библиотеку PBL того клиентского приложения, которое будет вызывать методы этого удаленного объекта. Под термином 'сигнатуры методов' понимаются названия пользовательских функций, типы возвращаемых ими данных, а также типы и названия аргументов, которые должны передаваться этим функциям при их вызовах.
Коммуникационный объект (connection object) - объект для установки соединения клиентской программы с сервером приложений. Необходимая для такого соединения информация, такая как адрес сервера приложений или имя пользователя, содержится в свойствах данного объекта. Рассмотрим подробнее компонентную модель трехуровневого приложения, создаваемого средствами PowerBuilder. При разработке такого распределенного приложения необходимо всю его деловую логику реализовать в виде методов (User Object Functions) невизуальных пользовательских объектов (PB NVUO's). Такая модель представления деловой логики является основной идеей создания трехуровневых приложений средствами Powerbuilder и EAServer. Реализованный в этой модели бизнес-компонент (он же PB NVUO) размещается на сервере приложений EAServer и для такого компонента генерируется прокси-объект, помещаемый в клиентское приложение. После этого клиент с использованием данного прокси может вызывать методы работающего на сервере приложений удаленного компонента.
Создание реализующего деловую логику компонента осуществляется в User Object Painter - создается невизуальный пользовательский объект (Non-Visual User Object), и в его методах (User Object Functions) на языке Powerscript реализуется необходимая деловая логика.
Для развертывания (deploy) созданного компонента на EAServer из среды PowerBuilder используется EAServer Component Wizard.
С его помощью создается проект (Project), в котором указывается, какой компонент на каком EAServer развертывать, в какой пакет (Package) его помещать, какие установки и как использовать.
При нажатии кнопки Deploy происходит собственно процесс развертывания (то есть переноса) компонента на EAServer :
Далее необходимо создать объект Connection, который позволит клиентскому приложению установить связь с EAServer.
В свойствах данного объекта указывается информация о том EAServer, с которым необходимо работать - адрес и порт сервера, имя пользователя и пароль.
Следующий шаг - генерация прокси-объекта, который позволит клиентскому приложению обращаться к методам размещенного на EAServer компонента. Делается это через EAServer Proxy Wizard. В качестве места для размещения прокси-объекта указывается PBL-библиотека того клиентского приложения, которое будет обращаться к методам указанного компонента.
Далее в клиентском приложении пишется код, осуществляющий присоединение к EAServer:
// задаем глобальную переменную типа n_jaguar_connect, // это сгенерированный ранее Connection Object n_jaguar_connect gn_connect long ll_rc // создаем экземпляр данного Connection Object gn_connect = CREATE n_jaguar_connect // осуществляем присоединение клиента к серверу приложения ll_rc = gn_connect.ConnectToServer() // проверяем, успешно ли прошло соединение IF ll_rc <> 0 THEN // Если произошла ошибка MessageBox("Connection Error", "Return Code: " + string(ll_rc)) ELSE // Если ошибок нет, то можно работать дальше Open(w_loan) END IF
Следующий шаг - инициализация прокси-объекта, необходимого для вызова методов компонента, функционирующего на EAServer:
// Декларируем переменную для работы с прокси, // где n_loan - название сгенерированного ранее прокси-объекта n_loan in_loan long ll_rc // Создаем экземпляр прокси-объекта ll_rc = gn_connect.CreateInstance (in_loan, "finance/n_loan") // Проверка успешности создания экземпляра прокси IF ll_rc <> 0 THEN MessageBox("Error creating proxy instance", "Return Code: " + string (ll_rc)) END IF
Если предыдущий шаг прошел успешно, то можно осуществлять вызовы методов компонентов:
double ld_amount, ld_payment int li_months ld_amount = 1500 li_months = 6 // Вызов метода компонента // // in_loan - название экземпляра прокси-объекта // calculate() - название вызываемого метода ld_payment = in_loan.calculate(ld_amount, li_months)
После окончания использования методов компонента необходимо удалить из памяти клиентского приложения экземпляр прокси-объекта и отсоединиться от сервера приложений:
Destroy(in_loan) gn_connect.DisconnectServer()
PowerBuilder 9.0
В конце марта 2003 года вышла в свет новая, девятая версия PowerBuilder. Среди ее новых возможностей необходимо отметить следующие:
поддержка XML в Datawindow - экспорт / импорт данных из Datawindow или Datastore в XML-формат. Экспорт возможен как через использование функции SaveAs: dw_1.SaveAs("C:\TEMP\Temp.xml", XML!, True) так и через путем применения объектного синтаксиса: ls_xmlstring = dw_1.Object.Datawindow.Data.XML. Импорт осуществляется через функции ImportFile и ImportString или через DataWindow Painter;
PowerBuilder Native Interface (PBNI) - программный интерфейс, позволяющий вызывать методы реализованных на PowerBuilder невизуальных пользовательских объектов (NVUO) из C++; PowerBuilder Document Object Model (DOM) - поддержка возможности работы с XML-документами из кода на Powerscript;
Разработка JSP-страниц - возможность использования PowerBuilder в качестве RAD-инструмента для создания JSP-приложений;
Клиентская поддержка EJB - позволяет осуществлять вызовы компонентов EJB серверов приложений третьих фирм;
Экспорт DataWindow в PDF-формат - возможность сохранения подготовленных на PowerBuilder отчетов в Portable Document Format (PDF).
Более подробно о выпуске PowerBuilder 9.0 можно почитать в статье [2].
Заключение
На современном этапе использования информационных технологий распределенные вычисления являются одним из наиболее перспективных направлений их развития. Рассмотренное средство разработки PowerBuilder является полнофункциональным инструментом для быстрого и эффективного создания распределенных трехуровневых приложений. Если Вас заинтересовали описанные в данной статье программные средства, демонстрационные версии PowerBuilder и EAServer вы можете скачать из Интернет по адресам http://www.sybase.com/pb8_eval или http://www.sybase.ru/download/prodreview/powerbuilder.htm
