Введение

Проблема ASP-приложений: смесь HTML, SQL и VBScript, с трудом поддающаяся осмыслению

Появление Active Server Pages(ASP) для многих стало знаменательным событием. Технологии-конкуренты - Personal (в начале подразумевался Perl) Home Pages(PHP), Java Server Pages(JSP), ColdFusion Markup Language(CFML) и PL/SQL Server Pages (PSP) появились позднее и, частично, носили подражательный характер, что не уменьшает их достоинств. Наиболее интересными и полезными качествами, которыми привлекала технология ASP, можно считать:

• удобный способ объединение Server-Side Script c HTML;
• скриптовый подход (интерпретируемый язык) - т.е. файл с исходным кодом ASP одновременно является его исполняемым файлом, что упрощает процессы разработки и поддержки;
• концепция "Session" - переменные для каждого пользовательского соединения, как удачное решение вечной проблемы stateless-протокола HTTP;
• возможность организации распределенной архитектуры на основе инфраструктуры COM (Component Object Model), DCOM, COM+. Дополнительные возможности, предоставляемые Microsoft Transaction Server (MTS) - такие, например, как контекст объектов, пул и т.д.;
• удобный набор объектов-утилит: Server, Application, Request, Response, Session, ObjectContext.

Главной идеей и достоинством ASP сразу виделась возможность встраивать программный код, обрабатываемый сервером, непосредственно в HTML страницу (а не наоборот, как предлагал CGI). При всех больших возможностях этого подхода, он скрывает серьезную ловушку. ASP-файл, написанный подобным образом, может поддерживать только человек, хорошо владеющий как ASP-программированием, так и HTML, что накладывает жесткие требования на подбор кадров. Встроенный в ASP-страницы SQL усугубляет ситуацию, усложняя код и делая его непереносимым на другой источник данных.

К тому же, полученный подобным образом ASP-файл, в конкретный момент времени, может править только 1 человек. Грубо говоря, это означает, что если работает программист - то дизайнер спит. А если файл правит дизайнер - то спит программист. Т.е. наблюдается невозможность распределения труда там, где она потенциально возможна, и могла бы ускорить разработку.

Применяемый в быстро развивающемся Internet такой неоднозначный подход, как Rapid Application Development (RAD), еще больше обостряет ситуацию. Проекты часто разрабатываются на скорую руку - лишь бы что-то быстро показать инвесторам, а затем уже пересматривается архитектура, приглашаются профессиональные дизайнеры. Но эти дизайнеры совершенно бессильны что-либо исправить в той кошмарной смеси HTML, SQL и VB/J/PerlScript которая, в общем-то, разрабатывалась как прототип, и была, почему-то, принята за конечный продукт (по горячему желанию руководства), в котором надо всего лишь "немного улучшить дизайн".

Вышеописанное несколько напоминает распространенную ситуацию с популярными средствами RAD в области разработки обычных Standalone-приложений, такими как Delphi, C++Builder, Centura Team Developer, VisualBasic и т.д., когда код бизнес-логики оказывается "размазанным" по различным обработчикам элементов пользовательского интерфейса, навсегда связывая проект с имеющейся технологией и архитектурой и затрудняя поддержку и расширение кода. Масштабирование (т.е., например, вынесение бизнес-логики в объекты 2nd tier - COM,CORBA,EJB), фактически, становится невыполнимым, поскольку код бизнес-логики придется, в буквальном смысле, "соскабливать" с различных ComboBoxes, TextFields, Buttons, и т.п.

Таким "размазыванием" страдают и современные разработки на ASP. С другой стороны, представляется вполне возможным избежать подобной ситуации. Просто осознавая с самого начала возможные неприятности в будущем, и закладывая в проект дополнительные степени свободы. Например, всегда хорошо иметь, про запас, возможность быстро сменить инфраструктуру Web-приложения - т.е., например, перейти с ASP на JSP или PHP, без переписывания основного кода. И эта возможность - вполне реальный эффект хорошей организации проекта. Для начала, сформулируем проблемы, присущие многим ASP-проектам, с которыми мы будем бороться:

• Смесь бизнес-кода и HTML приводит к трудностям поддержки и того и другого;
• Наличие большого количества DB-зависимого кода в ASP-страницах привязывает их к источнику данных;
• Перегруженность ASP-страниц функциональностью приводит к перегрузкам IIS (хотя это можно решить кластеризацией IIS);
• Смысловая перегрузка ASP-страниц затрудняет их поддержку;
• Хранение бизнес-логики в ASP-страницах в "размазанном" виде приводит к затруднению ее вынесения в объекты 2-nd tier (при необходимости масштабирования и поддержки разных видов 1st tier-клиентов);
• Полная зависимость кода проекта от самой технологии ASP

Что предлагается делать в этой статье (кратко):

• Вынести HTML из ASP-страниц в отдельные файлы;
• Вынести SQL из ASP-страниц;
• Абстрагировать Microsoft ASP-специфические возможности в объекты общей библиотеки;
• Организовать все часто используемые функции в виде методов общей объектно-ориентированной библиотеки;
• Использовать JScript или PerlScript и отслеживать пути быстрого перехода на JSP/PHP, при возникновении подобной необходимости.

Общие вопросы

Приоритеты в Business Web Application

Так или иначе, нам придется делать выбор - что важнее в Business Web Application с точки зрения пользователя (как источника прибыли), в условиях ограниченных ресурсов на разработку (временных, финансовых, кадровых и т.д.). Предлагаемая иерархия такова:

1. Функциональная адекватность - Приложение корректно выполняет свои функции в идеальных условиях (один пользователь в единицу времени, идеальное функционирование аппаратуры и т.д.).
2. Надежность в условиях ограниченной загрузки - Приложение устойчиво и надежно обслуживает небольшое фиксированное число одновременно работающих пользователей. (Типичные проблемы интернет. такие, например, как сбой соединения, не нарушают работу.)
3. Удобство работы, интуитивно понятный интерфейс - пользователям удобно работать с системой.
4. Возможность обслужить максимальное расчетное количество одновременно работающих пользователей - система готова надежно обслужить всех потенциальных пользователей.
5. Высокая скорость работы - короткое время отклика системы
6. Красивый дизайн - дизайн системы эстетически приятен большинству пользователей.

Это спорная схема. Если первейшая задача - продемонстрировать что-то несведущим инвесторам, что пункты 5 и 6, например, можно вынести на первые места. Но для долгосрочного Business Web-проекта приведенная схема, вероятно, близка к реальности. И она хорошо показывает, почему существует так много медленных и не очень эстетичных Web-приложений. Современные условия разработки интернет-проектов - это спешка. А в спешке существует склонность не задумываться о вторичных приоритетах до момента выполнения первичных. Требуется "побыстрее что-то сделать". А когда это сделано, оказывается, что надо все переписывать - либо с нуля, либо по частям. Однако, даже если, допустим, пункты 3-6 не имеют изначально большого приоритета, о них все равно следует помнить, и закладывать в проект возможности их решения в будущем. Тогда это решение будет на порядок меньшим по затратам. Большинство аналитиков сходятся в том, что только распределенная архитектура способна решить все вышеперечисленные приоритеты в условиях ограниченных ресурсов. Рассмотрим эту архитектуру подробнее.

Распределенная архитектура, как наиболее подходящая для Business Web Application

В этой схеме собраны почти все варианты названий трех уровней распределенного приложения. Чтобы избежать путаницы, будем именовать уровни так: 1st tier, 2nd tier и 3rd tier, по причине краткости написания. Выбирать названия по другим критериям слишком сложно. Называть 3-х уровневую архитектуру N-уровневой вероятно не стоит, т.к. эти N уровней, обычно, появляются как более детальное изображение той же 3-х уровневой схемы, не внося принципиально новых идей. N-уровневые схемы удобны, чтобы показать систему с точки зрения развертывания и администрирования. Но с точки зрения разработки эти дополнительные уровни малоинтересны. Три уровня (с позиции программирования) - это хранение, обработка и представление информации. Идея заключается в том, чтобы не смешивать эти три составляющие. Грубо говоря, 3-х уровневый подход - это просто хороший стиль программирования. Его можно применять при разработке практически любых приложений. Новизна же и идея распределенных приложений в том, чтобы иметь возможность распределить эти три уровня физически на различных компьютерах, а также возможность иметь несколько взаимозаменяемых вариантов каждого уровня.

2-x уровневая архитектура (клиент-сервер) В классической архитектуре клиент-сервер, бизнес-логика может располагаться как у клиента, так и на сервере. В результате существует тенденция смешивания бизнес-логики с интерфейсом пользователя и/или со структурой БД.
3-x уровневая архитектура (идеальный вариант) 3-х уровневая архитектура подразумевает четкое выделение бизнес-логики. Интересно отметить, что сервисы для вызова бизнес-логики (2nd tier), относятся к 1st tier. А вот интерфейс с базой данных (или любым источником данных) - сразу к 3rd tier. Такой подход позволяет четко очертить границы уровня бизнес-логики и отличие 3-х уровневого подхода от 2-х уровневого (клиент-сервер).
3-x уровневая архитектура (фактический вариант) На практике, мы имеем нечто подобное. По различным причинам бизнес-логика остается на 1st и 3rd tier. Это может быть оправдано, если не приведет к перегрузке уровня, на котором находится ненормированный код. И если этот код легко можно перенести в 2nd tier объекты. Например, поместив бизнес-логику в хранимые процедуры в 3rd tier, мы можем получить большой выигрыш в производительности. Если же эти хранимые процедуры написаны на Java, то перенести их в 2nd tier будет несложно. А вот бизнес-логика на 1st tier, как уже упоминалось, распространена повсеместно и, обычно, связана с неудачной архитектурой. Вопрос о бизнес-логике в ASP-страницах мы рассмотрим позднее.

Теперь, попытаемся выявить основные критерии идеальной распределенной архитектуры:

• Каждый уровень распределенного приложения может взаимодействовать только со смежным уровнем. Это означает, что: 1st tier не должен иметь прямого доступа к 3rd tier и наоборот; 2nd и 3rd tiers не должны иметь прямого интерфейса с пользователем; обращение к источнику данных из 1st tier происходит только через объекты 2-nd tier;
• Вся сложная бизнес-логика находится в объектах 2nd tier. Как уже упоминалось, это условие часто нарушается, снижая возможность масштабирования. Хотя подобные решения иногда оправданы.
• Взаимодействие уровней организовано так, чтобы они могли взаимодействовать по сети, находясь физически на различных компьютерах. Это означает, что распределенная архитектура не зависит от способа развертывания (deployment) приложения - все уровни могут быть размещены физически как одном компьютере, так и на разных, в условиях заданной сетевой структуры;
• Сущности данных независимы от способа их хранения, уникально идентифицируемы по какому-либо ключу, и независимы от способа и места хранения других сущностей. Это, в частности, иногда означает отсутствие в некоторых таблицах связей по внешним ключам, что позволяет хранить группы таблиц, имеющих отношение к одной сущности, в разных базах данных. Однако тогда необходимо отслеживать целостность данных дополнительным кодом.

Проблема ASP заключается в том, что смесь скрипта бизнес-логики, HTML и SQL представляет собой 2-х уровневую архитектуру (клиент-сервер), которая с задачами Web-приложений не справляется. Поэтому мы предложим способ, как разделить ASP на три составляющие - ASP-код с бизнес-логикой, HTML и SQL.

ASP-программирование: сравнение VBScript, JScript, PerlScript

ASP-страницы, почему-то, всегда связывают со скриптом VBScript. Хотя это, наверное, худший из возможных вариантов. ASP могут быть написаны на любом WSH (Windows Scription Host)-совместимом скриптовом языке. Рассмотрим 3 варианта - VBScript, JScript, PerlScript. Первые два - VBScript & JScript поддерживаются Miscrosoft, и не требуют дополнительных инсталляций. PerlScript автоматически устанавливается при инсталляции ActivePerl. Сравним эти три варианта.

VBScript

К немногим преимуществам (весьма неоднозначным) VBScript можно отнести то, что он прост для использования VisualBasic-программистами. Если объекты 2nd tier пишутся как COM-объекты на VisualBasic, это может служить оправданием использования VBScript. Т.к. образуется некий "корпоративный стандарт". Язык Basic, сам по себе, является прекрасным языком для обучения программированию, на котором выросло не одно поколение программистов. Однако, непосредственно VBScript, не способствует появлению хорошего стиля программирования и потому стимулирует крах проектов средней и большой сложности. Наверное, худшим ограничением является отсутствие возможности объектно-ориентированного программирования, что очень критично для крупных проектов. Если, все-таки, решено использовать VBScript, следует уделить тщательное внимание аккуратности при написании кода, комментариям, отступам, понятным названиям процедур, функции и переменных, хорошему документированию. Это важно при любом программировании, но для VBScript это актуально вдвойне. Не следует также пользоваться независимостью от регистра языка VBScript.

JScript (JavaScript)

Одним из новаторских изобретений фирмы Netscape стал скриптовый язык JavaScript. Его синтаксис официально основывается на чрезвычайно популярном сейчас языке Java. А это, в свою очередь, говорит о схожести с C и C++. Особый интерес в JavaScript представляет оригинальная система динамического создания объектов, что позволят применять объектно-ориентированный подход. Несмотря на отсутствие инкапсуляции, странное наследование и неограниченный полиморфизм (проверки типов в JavaScript нет), применение объектов выводит программирование ASP-страниц на более высокий уровень, позволяя использовать стандартные паттерны проектирования, упрощая код, и делает его более логичным, расширяемым и переносимым. Можно, например, создавать оболочки (которые еще называют адаптерами или врапперами) COM-объектов (того же ADODB), более удобные для применения, и абстрагирующие основной ASP-код от этого-самого COM-объекта (позволяя, при необходимости, легко заменить его на другой объект 2nd tier).JScript является клоном языка JavaScript от Microsoft. Отличия JavaScript и JScript минимальны, однако их следует знать (отличия описаны в документации по JScript) и обходить (или абстрагировать), поскольку применение JScript в ASP открывает уникальную перспективу - возможность простого перевода Web-приложения, почти без переписывания основного кода, на технологию JSP (Java Server Pages). Это не означает, что мы собираемся бросать ASP и срочно переходить на JSP. Просто, в современных условиях, быть не привязанным к единственной платформе и/или технологии - очень ценное свойство проекта, которое, быть может, спасет его от гибели. Если грамотно абстрагировать ASP- и Windows-зависимый код в общие библиотеки, то, переписав только эти библиотеки, мы, теоретически, получим JSP-сайт. (JSP страницы могут быть написаны на JavaScript, а конструкции <%...%>, <%=...%> схожи и в ASP и в JSP). Это, однако, не относится к объектам 2nd tier, которые переводить придется отдельно. Достоинством JavaScript можно считать его применение на стороне клиента (DHTML в Web-броузере), что позволяет создать "корпоративный стандарт". Т.е. программист-разработчик может применять единую технологию на стороне клиента и сервера (VBScript также можно использовать на стороне клиента, для броузера Internet Explorer, но это, обычно, не практикуется). Если разработки в компании ведутся на Java, С или С++, то JavaScript весьма гармонично впишется в рабочую среду. Недостатком конкретной реализации JScript можно считать отсутствие аналога VBScript-функции chrB(), что ограничивает возможность работы с однобайтовыми потоками данных. Что, с другой стороны, стимулирует вынесение сложного кода в объекты 2-nd tier.

PerlScript (ActivePerl)

Появившись как язык для написания UNIX-скриптов, Perl обрел новое призвание в Web-разработках благодаря своей простоте, уникальным возможностям для работы со строками, большому количеству библиотек и своей бесплатности. Использовать Perl как PerlScript в ASP несколько эффективнее, чем в качестве CGI или ISAPI, поскольку открывает доступ к стандартным и весьма полезным ASP-объектам (Server, Application, Session, etc.). Perl поддерживает объектно-ориентированное программирование, что дает ему преимущества, описанные выше для JavaScript. Недостатком (условным) использования PerlScript является необходимость его установки на сервер (усложнение deployment), а также то, что это свободно-распространяемый продукт, безо всяких гарантий. С другой стороны, для стран СНГ эта характеристика присуща большинству программных продуктов, и потому этот недостаток неактуален. Решать, кто дольше просуществует и будет продолжать выпускать обновленные версии своих продуктов - Microsoft или ActiveState (разработчик ActivePerl) - тоже дело неблагодарное. Поэтому стоит изначально закладывать в проект возможность для перехода на конкурирующую технологию. Для ASP+PerlScript эта технология - PHP. Так же, как ASP+JScript можно перевести на JSP, так и ASP+PerlScript можно перевести на PHP, поскольку скриптовый язык PHP по синтаксису близок к Perl. Этот переход видится немного более сложным, чем ASP+JScript->JSP, но вполне осуществимым. К неоднозначным фактам можно отнести наличие у Perl большого количества библиотек. Несмотря на кажущееся явное преимущество, концентрация слишком большой функциональности в ASP-страницах (к чему склоняют Perl-библиотеки) приводит к нарушению баланса распределенной системы. Вместо того, чтобы выносить функциональность в 2nd tier объекты, разработчики размещают сложный и ресурсоемкий код в ASP-файлы, в результате система становится немасштабируемой, а IIS - перегруженным. Решением этой проблемы выглядит разработка 2nd tier COM-объектов на том же Perl (возможность писать COM-объекты на Perl ActiveState предлагала, на момент написания статьи, за 110$). Опять же, мы имеем корпоративный стандарт - ASP+PerlScript & COM-объекты на Perl, со всеми преимуществами корпоративных стандартов.

Общие сравнительные характеристики:

ASP Script:	VBScript	JScript	PerlScript
Объектно-ориентированное программирование	Нет	Да	Да
2nd tier на COM	Да	Да	Да
2nd tier на CORBA	Только через мосты	Только через мосты	Да
2nd tier на EJB	Только через мосты	Только через мосты	Только через мосты
Схожие языки (для формирования корпоративного стандарта)	MS Visual Basic, any Basic	JavaScript, Java, C, C++	Perl, PHP
Проект может мигрировать на другую Web-технологию	Нет	Да, на JSP	Да, на PHP или Perl CGI/ISAPI
Проект может мигрировать на другую платформу	Нет	Да, JSP на любой JSP-совместимой платформе	Да, PHP/Perl на любой PHP/Perl-совместимой платформе

Критериями выбора скрипта разработки для ASP могут стать:

• возможности этого скрипта, как языка программирования
• корпоративные стандарты компании
• возможности простой миграции проекта на конкурирующие технологии
• простота поддержки

В свете вышеописанных критериев, можно порекомендовать выбор в пользу JScript.

Общая объектно-ориентированная библиотека: Project ASP API

Для упрощения использования любой новой технологии (и для описанных выше конвертаций ASP проекта в проект JSP/PHP) жизненно необходимо абстрагировать системные средства ASP в библиотеку общего пользования. Эту библиотеку можно специально приспособить под конкретный проект, для значительного упрощения ее применения. Рассмотрим типичных кандидатов на помещение в общую, объектно-ориентированную, библиотеку.

Config - это объект, который хранит все настройки, общие для сайта в целом. Реально, они будут записываться при старте сайта в ASP коллекцию Application(), например из конфигурационного XML или INI-файла или просто из global.asa. Но весь остальной ASP-код работает с конфигурационными параметрами исключительно через этот объект и к способу хранения/чтения этих параметров никак не привязан. Параметры конфигурации могут быть представлены, в объекте Config, как атрибуты объекта и/или как методы getStr("Section","Entry","Default"), getInt(...), getBool(...), и т.д.

ConfigUser - этот объект хранит переменные текущей сессии пользователя. Абстрагируя переменные сессии в этот объект, мы получаем независимость от способа хранения переменных сессии. Мы можем как угодно менять и комбинировать способы хранения этих переменных: коллекция Session(), Cookies, Database, поля HTML формы - что угодно. При этом основной код будет оставаться неизменным. Доступ к переменным можно организовать аналогично объекту Config, но уже с возможностью модификации этих переменных - getStr(...)/setStr(...), и т.д.

Тут возникает весьма неоднозначный вопрос - об именовании объектов. Как в ASP, так и в сервлетах/JSP общую конфигурацию рекомендуется записывать в коллекцию Application (application), а пользовательскую - в Session (session). Проблема в том, что концепции коллекций Application и Session подразумевают то, что туда можно записать все, что угодно и время жизни этих коллекций ограничено. Они универсальны, и не приспособлены специально для хранения конфигураций.

Поэтому назвать наши конфигурационные объекты надо как-то по-другому (не application и session). Например: ConfigApp/ConfigUser, AppProperties/UserProperties, GlobalProperties/SessionProperties и т.п. Еще один фактор - это сокращения в названиях. Это не очень хороший стиль, поскольку многие сокращения могут оказаться непрозрачны для некоторых разработчиков.

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

ObjectFactory - если задуматься о будущем, то запись Server.CreateObject(...) в основном ASP коде покажется весьма ограничивающим фактором. Если понадобится использовать J2EE CAS COM Bridge (мост от Sun для использования EJB и обычных Java-классов через COM), то процесс создание объекта уже будет отличатся, и запишется так (JScript):

_factory = Server.CreateObject("J2EECAS.JavaClassLoaderFactory");_classloader = _factory.CreateClassLoader();_class = _classloader.FindClass("java.lang.String");objJavaStr = _class.New();

И основной ASP код придется переписывать. Для мостов CORBA придется использовать другую запись. Нет, конечно, может быть не все так плохо, и возможно для данного конкретного проекта никогда не понадобится связь ни с EJB, ни с CORBA. Но кто знает... Если вы все же решились абстрагировать и эту сторону проектной реальности, то ObjectFactory, минимально должен предоставлять 2 метода - создание и удаление объекта. Не важно, что обычно удалением объектов занимался сборщик мусора. Пусть даже наш метод удаления объекта на самом деле ничего не делает - это не важно. Пусть он будет и пусть он вызывается когда нужно - будущее нас рассудит. У каждого объекта 2-nd tier должен быть псевдоним для его идентификации при обращении к ObjectFactory. Например, в основном коде будет запись ObjectFactory.CreateObject("MailSender"). И только ObjectFactory на самом деле будет знать, что это COM объект с AppId "com.sa.soft.utils.SendMail005". Параллельно ObjectFactory можно нагрузить мелкими функциями - контролем всяческих пулов и кэшей, проверкой валидности объекта и т.д. И, чтобы уж совсем по-модному, доступ к вышеописанным объектам должен осуществляться через единственный объект-ядро:

Core - этот объект должен присутствовать во всех ASP страницах основного кода в единственном экземпляре (синглетонами также должны быть объекты Config, ConfigUser и ObjectFactory. а вот DB-объекты - необязательно). Главная задача объекта Core - создавать и возвращать все описанные выше объекты написанной вами библиотеки, гордо именуемой Project ASP API. Например, Core.getConfigApp() создаст объект ConfigApp и вернет на него ссылку. Повторный вызов не будет создавать объект повторно, а вернет ту же ссылку (чтобы гарантировать, что ConfigApp останется синглетоном). Помимо того, что основной ASP-код станет более понятным, мы получим весьма полезный эффект. Core может запоминать ссылки на все созданные им объекты. И вызвав в конце ASP-страницы метод, например, Core.close(), мы получим гарантированное закрытие всех объектов, даже если мы забыли закрыть их в основном коде. Для объектов работы с базой данных это особенно критично.

Конечно, стандартным должен быть и объект для работы с источником данных, но о нем позднее.