Основы проектирования корпоративных систем - Сергей Зыков

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

При использовании тонкого клиента вся бизнес-логика, которая была сосредоточена на каждом из сотен тысяч клиентов, переносится на сервер и централизованно управляется там. Она взаимодействует с данными и SQL-серверами. Клиент снабжается только пользовательским интерфейсом. Администрирование и централизованная миграция производятся на сервере, поэтому изменения с точки зрения сроков и стоимости происходят более эффективно. Бизнес-логика может быть расположена на одном и том же сервере с БД, а может быть перенесена на один или несколько серверов. Коррективы в таких системах можно вносить как на нижнем уровне, так и на более высоком. Например, в семействе Oracle Applications на нижнем уровне расположен сервер базы данных Oracle Server, а на более высоком уровне существует Application Server, на котором и располагаются все компоненты, выполняющие прикладные задачи. Это ERP-системы Oracle Applications или Oracle Business Suit, которые осуществляют прикладную логику: учет, планирование и управление основными видами корпоративных ресурсов.

Для производства корпоративных приложений нужно эффективно пользоваться специализированными инструментальными средствами, которые этот цикл поддерживают. Речь идет о средствах автоматизированного проектирования корпоративных приложений, или CASE-средствах. При этом если говорить о базах данных, необходимы специфические CASE-средства. В чем же заключаются эти особенности применительно к распределенным системам клиент-серверного типа? Эти средства являются достаточно универсальными, так как обеспечивают возможность соединения с различными серверами БД и позволяют разрабатывать графические интерфейсы (формы ввода данных, отчеты), чтобы пользователи могли взаимодействовать с данными в этих графических интерфейсах. Речь идет о том, что взаимодействие с базой данных может осуществлять не только программист, но и опытный пользователь, системный, бизнес-аналитик. Более того, если правильно построить цикл разработки корпоративной системы, можно обеспечить возможность взаимодействия этого бизнес-аналитика с существующей системой и развитие этой системы бизнес– аналитиком. Он сможет строить в терминах бизнес-логики, почти естественных языковых терминах, необходимые запросы и отчеты. При этом в почти автоматическом режиме происходит соединение с сервером БД, и графический интерфейс во многом набирается из тех примитивов, которые есть в распоряжении такого продвинутого пользователя.

Особенность систем проектирования взаимодействия корпоративных систем с базами данных – это в первую очередь объектная ориентированность. Речь идет о наборе компонентов для взаимодействия с серверами, основанных на технологиях ODBC (Object Database Connectivity), соединении с базами данных на основе объектных технологий либо более старой технологии OLE (Object Linking and Embedding). Кроме того, это визуализация, основанная на объектных библиотеках, средство командной разработки (например, Visual Studio Team System/Team Suit), а также языки четвертого поколения, которые поддерживают возможность написания программ в терминах скрипт-языков или во многом визуальной разработки.

К CASE-поддержке систем с базами данных можно отнести такие средства, как:

• Oracle Developer;

• Borland Delphi;

• MS Visual Studio (MSVS);

• Sybase PowerBuilder.

В Oracle Developer есть расширения для создания веб-приложений Oracle Web Developer, кроме того, также как и в MSVS, в нем может быть использовано подключение к другим базам данных на основе открытых интерфейсов (например, ODBC). Эти средства являются конвейерами для интеграции с различными SQL-серверами.

Средства, поддерживающие разработку персональных СУБД, с которых начинались небольшие системы, – это были, по сути, CASE-средства и серверы базы данных в миниатюре. Они также поддерживают SQL-запросы и разработку бизнес-логики, независимую работу клиентского приложения и в ряде случаев имеют специализированные форматы хранения данных, основанные на специфических СУБД (например, в семействе приложений Lotus на основе Lotus Domino сервера и персональной СУБД Lotus Approach речь может идти о нереляционной БД, многозначной структуре данных, когда речь идет о неатомарных атрибутах в БД). Рассмотрим основы того, из чего выросли современные средства. Атрибутами настольных систем были легкий удобный графический интерфейс, интеграция с пакетами офисных приложений (MS Office в том числе), визуальные средства, которые позволяют вести быстрое построение приложений и отчетов. В MS Access есть набор визардов для экспресс-построения отчетов, и среда реализации основана на объектном подходе (ODBC, COM, OLE). В MS Access можно встроить макросы на Visual Basic, который во многом является объектным. Эти средства хоть и в нестандартном виде используют язык SQL, с помощью которого осуществляется запрос к локальной БД.

Усовершенствование этих средств и выделение явного уровня клиента и сервера привели к появлению определенных особенностей в двух– и трехуровневой архитектурах клиент – сервер.

Если говорить о двухуровневой архитектуре клиент – сервер, можно выделить следующие особенности применительно к сетевым средам Интернет и интранет. Интернет важен для корпоративных сетей. В данном случае мы разделяем уровни веб-браузера и вебсервера. Речь идет о взаимодействии по протоколу HTTP. Сервер предоставляет клиенту HTML-страницу, а браузер отображает страницу, обрабатывая HTML-теги (рис. 6.7).

Рис. 6.7. Двухуровневая архитектура клиент – сервер в сетях Интернет/интранет

При переходе к трехуровневой системе возникает промежуточный слой, связанный с JSP (Java Server Pages) или ASP (Active Server Pages). Промежуточный слой в виде веб-сервера, сервер БД, осуществляющий SQL-взаимодействие с БД, и клиент в виде веб-браузера.

Основные протоколы – HTTP, или HTTPS. Преимуществами являются снижение трафика, большая взаимозаменяемость компонентов за счет стандартных интерфейсов и протоколов, а также увеличение безопасности. Недостаток связан с тем, что HTTP – это протокол без состояния (stateless). В связи с этим сложно организовать транзакционную обработку БД, что крайне важно для систем корпоративного размера, поскольку многопользовательская работа подразумевает транзакционность и изоляцию пользователя. Осуществляется псевдопараллельная работа со сложным управлением транзакциями.

При трехуровневой архитектуре обобщенное взаимодействие между клиентом и сервером выглядит следующим образом (рис. 6.8). Клиент в виде веб-браузера отсылает серверу запрос на доставку веб-страниц, данных в рамках протокола HTTP. Выполняется передача данных в определенном формате. После того как веб-сервер получает запрос на отображение веб-страницы от сервера БД, он передает после перекодирования HTML-страницы клиенту. Вебсервер – это промежуточное звено между клиентом и БД. Он получает от клиента в сыром виде запрос на получение информации и обращается к серверу БД по средствам запросов. Существуют программы расширения серверной части, которая получает от вебсервера запрос на получение данных и общается с сервером БД. Она принимает запрос, переформулирует его на языке SQL и передает его серверу БД. Сервер БД специализируется исключительно на выполнении SQL-запросов. Он выполняет запрос в форме определенного количества записей из БД программе-расширению. После чего происходит передача информации веб-серверу с преобразованием в формат веб-браузера. Затем происходит передача клиенту страницы с результатом. Таким образом, происходит двухуровневое взаимодействие.