Asp active server pages

Содержание

ASP – Скрипт Active Server Page

Расширение ASP

Чем открыть файл ASP

В Windows: Любым браузером, любым текстовым редактором, Internet Explorer, FireFox, Opera, Chrome, Microsoft IIS, Adobe Dreamweaver CS5, Adobe Fireworks CS5, Microsoft Visual Studio 2010, Microsoft Visual Web Developer, ES-Computing EditPlus.
В Mac OS: Любым браузером, любым текстовым редактором, Adobe Dreamweaver CS5, Adobe Fireworks CS5.

Описание расширения ASP

Популярность:

Разработчик: Microsoft

Тип файла ASP связан прежде всего с «Active Server Pages». Active Server Pages – это язык программирования от Microsoft для динамических веб-страниц, созданных с помощью Visual Basic или JScript. Страницы, написанные с помощью этого языка имеют расширение .asp и похожи на CGI скрипты, которые генерируют код на лету. ASP страницы могут комбинировать HTML, скрипты и компоненты ActiveX сервера.
Примечание: Этот тип файла может быть заражен вирусами и должен быть тщательно проверен, если кто-то посылает вам файл с таким расширением.

Программирование | ASP (Active Server Pages)

ASP (англ. Active Server Pages — «активные серверные страницы») — технология, предложенная компанией Microsoft в 1996 году для создания Web-приложений. Эта технология основана на внедрении в обыкновенные веб-страницы специальных элементов управления, допускающих программное управление.

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

Для реализации приложений ASP используются языки сценариев (VBScript или JScript). Также допускается применение COM-компонентов.

Технология ASP разработана для операционных систем из семейства Windows NT и функционирует под управлением веб-сервера Microsoft IIS.

Технология ASP получила своё развитие в виде ASP.NET — технологии создания веб-приложений, основанной уже на платформе Microsoft .NET.

ASP в своём развитии прошёл через несколько версий:

ASP 1.0 (распространяется с IIS 3.0) в декабре 1996 года.
ASP 2.0 (распространяется с IIS 4.0) в сентябре 1997 года.
ASP 3.0 (распространяется с IIS 5.0) в ноябре 2000 года.

ASP.NET MVC — это инфраструктура для разработки веб-приложений от Microsoft, которая сочетает в себе эффективность и аккуратность архитектуры «модель-представление-контроллер» (model-view-controller — MVC), новейшие идеи и приемы гибкой разработки, а также все лучшее из существующей платформы ASP.NET. Она представляет собой полномасштабную альтернативу традиционной технологии ASP.NET Web Forms, предоставляя преимущества для всех проектов веб-разработки, кроме самых тривиальных.

На момент своего появления в 2002 г. платформа ASP.NET оказалась огромным шагом вперед. На рисунке ниже показано, как выглядел на то время стек технологий Microsoft.

В Web Forms разработчики из Microsoft попытались сокрыть как протокол HTTP (с присущим ему отсутствием состояния), так и язык HTML (который на тот момент был незнаком многим разработчикам) за счет моделирования пользовательского интерфейса в виде иерархии объектов, представляющих серверные элементы управления. Каждый элемент управления отслеживает собственное состояние между запросами (с помощью средства View State (состояние представления) ), по мере необходимости визуализируя себя в виде HTML-разметки, и автоматически соединяя события клиентской стороны (например, щелчки на кнопках) с соответствующим кодом их обработки на стороне сервера.

Фактически Web Forms — это гигантский уровень абстракции, спроектированный для предоставления классического управляемого событиями графического пользовательского интерфейса через веб-среду. Идея заключалась в том, чтобы веб-разработка выглядела подобно разработке с применением Windows Forms. Разработчики больше не должны были иметь дело с последовательностями независимых запросов и ответов HTTP. Они могли мыслить терминами пользовательского интерфейса, поддерживающего состояние, и в Microsoft появилась возможность переместить армию разработчиков настольных Windows-приложений в новый мир веб-приложений.

Источники:
professorweb.ru
ru.wikipedia.org

Программирование | ASP (Active Server Pages)

ASP-страница читает и обрабатывает нужный шаблон, а затем посылает результат клиенту одной командой Response.Write().
Этот подход лучше предыдущего, поскольку позволяет полностью разделить ASP и HTML, причем HTML-файлы остаются удобными для редактирования дизайнером. Однако неспособность выводить таблицы с неизвестным заранее числом строк делает этот подход малоприменимым (ASP+, судя по имеющимся сведениям, имеет встроенные решения этой проблемы).

2.2 Вынесение цельной HTML-страницы в отдельный файл

Учитывая недостатки вышеперечисленных способов, можно предложить следующее решение. Разделим ASP-файл на 2 файла. Первый будет содержать только ASP-код и никаких посылок результатов клиенту. В этом файле должно полностью отсутствовать HTML-форматирование. Файл будет включать в себя (SSI) второй файл, который будет цельной HTML-страницей с минимальным количеством четко выделенного ASP-кода. Второй файл, по сути, будет тем же HTML-шаблоном, только вместо, например «[header]» будет написано » «, что не затруднит работу дизайнера. Но в нем также будет возможность выводить более сложные программные структуры. Идея в том, чтобы код во втором файле (где HTML) был действительно минимален и четко выделен. Т.е. все крупные куски кода инкапсулируются в функции и объекты, которые создаются в первом файле (чистый ASP-скрипт). Второй файл (HTML) лишь запускает эти функции и методы объектов. В этом плане JavaScript дает несомненные преимущества. Не пожалейте часа-двух, и изучите разные способы создания объектов в JavaScript — это позволит вам создавать удивительно красивые по своей простоте и логике архитектурные конструкции.

Общая схема разделения ASP/HTML
file1.asp	file2.htm.asp
Business Logic Level: Чтение/Обработка данных. Создание объектов (например объекта objExample), которые будет использовать Файл #2 (file2.htm.asp).	. .
Presentation Level:
Finalization Level: Закрытие DB-connections, etc.

Отметим также, что в случае перехода на JSP, такой HTML-шаблон можно совсем не менять.
Сформулируем основные принципы вышеописанного подхода:

ASP-страница состоит из 2х файлов
1й файл содержит чистый серверный скрипт, и в нужном месте включает 2й файл, (например через SSI)
1й файл не посылает информацию клиенту
1й файл не содержит команд HTML
1й файл инкапсулирует весь код в функции и/или методы объектов, которые затем могут быть вызваны из 2-го файла
2й файл содержит полную HTML-страницу, от до
2й файл содержит минимально возможный ASP-код. любой код бизнес-логики сокрыт в методах и/или функциях первого файла, и вызывается нужный метод или функция
1й и 2й файлы не содержат команд Response.Write() (по причинам, описанным ниже)
1й файл имеет расширение .asp, т.к. это чистый ASP-файл
2-му файлу можно дать расширение .htm.asp, чтобы подчеркнуть, что это все-таки HTML по содержанию. Имя 2-го файла может быть то же что у 1-го, или с каким нибудь префиксом, для удобства поиска. Например: shopinfo.asp и _t_shopinfo.htm.asp .

К побочным эффектам подобного разделения можно отнести достаточно простую возможность поддержки генерации не-HTML страниц. Например — WAP или XML. Для этого надо только написать другой файл шаблона (файл #2). Файл с серверным скриптом (#1) останется тем же.

Теперь остановимся еще на двух часто встречающихся деталях.

2.3 Чего желательно избегать: Response.Write(); HTML-форма и ее ASP-обработчик в одном файле

Response.Write() — проклятие для дизайнера

Мы можем записать команду генерации динамического HTML в ASP двумя способами:

Работают они, с внутренней точки зрения, одинаково. Однако они записываются с несколько различным синтаксисом. Сравните два варианта записи:

Первый вариант еще выглядит как HTML и доступен для осмысления дизайнером-непрограммистом. Второй вариант, из-за обилия кавычек, конкатенаций и бэкслешей, обычно осмыслению не поддается никак. Более того, при достижении определенного уровня сложности, его не могут осмыслить даже авторы через неделю после написания. Поэтому — не стоит использовать Response.Write(. ), если это не критично.

HTML-форма и ее ASP-обработчик в одном файле

Очень хочется развенчать совершенно кошмарный пример, который обычно приводят в туториалах по ASP. Это — объединение HTML-формы и обрабатывающего ее кода в одной ASP-странице. Поначалу это смотрится круто, и кажется что снижение количества файлов проекта дает прекрасный упрощающий эффект. Поверьте — карма человека, придумавшего этот пример из туториала, запятнана навсегда. А ведь все могло быть так просто — форма в обычном HTML-файле, а обработчик — в ASP. И дизайнер и программист были бы счастливы. Если бы не этот пример из туториала.

3. Выносим SQL из ASP (простой вариант уровня бизнес-логики)

3.1 Независимость ASP кода от источника данных, снятие нагрузки с IIS, упрощение ASP кода.

Мы уже рассмотрели, как вынести HTML в отдельный файл и отдать его дизайнеру. Но остался еще один кандидат на то, чтобы убрать его из ASP. Это — SQL. Он усложняет ASP-код, жестко связывает его с конкретным сервером базы данных, загружает IIS излишними вычислениями, снижает возможность масштабирования. Проще говоря — он превращает 3-х уровневое приложение в 2-х уровневое (клиент-сервер).
Рассмотрим архитектуру 3-х уровневого web-приложения, применительно к IIS, ASP и COM

Где на данной схеме расположить ASP c ADODB? Поскольку используется прямая запись SQL и однозначное обращение к конкретной базе данных, то можно утверждать, что ASP обращается непосредственно к 3rd tier, а ADODB является сервисом доступа к данным, и принадлежит 3rd tier. В 3-х уровневой архитектуре прямая связь 1st tier c 3rd tier недопустима. Говоря об SQL, можно утверждать, что он однозначно связывает код с выбранным типом сервера базы данных (будь то Oracle, MSSQL или что либо еще). То, что можно писать только на ANSI SQL, который будет работать везде, скорее всего миф. В любом случае это очень сложно реализовать.
Посмотрим, что можно предложить.

3.2 Формированию уровня бизнес-логики

Объекты 2nd tier принято разделять на две группы — представляющие клиента и его действия (Session Beans в EJB), и представляющие сущности источника данных (Entity Beans в EJB). Cущности источника данных (в частности — БД) выявляются и формулируются на фазе планирования / разработки логической структуры проекта. К сожалению во многих проектах эти фазы отсутствуют как класс и правит тенденция к стихийному развитию структуры БД. Если вам достался подобный проект, то придется заново тщательно проработать структуру базы данных, выявлять основные сущности и распределить все таблицы к конкретным сущностям.
Объекты, представляющие клиента на 2nd tier, реализуют возможные действия клиента. Эти действия осуществляются только через объекты — сущности (и не через прямой доступ к DB). Поскольку хардкодить все, даже самые незначительные, операции в компилируемых объектах возьмется далеко не любая компания, можно предложить писать эти объекты на ASP в страницах, не содержащих HTML (см. главу о вынесении HTML из ASP). Тогда получается такое изменение схемы распределенной архитектуры для IIS/ASP/COM:

Мы можем выделить ASP-код, представляющий клиента, исключительно с бизнес-логикой, без HTML-форматирования и взаимодействия с пользователем. Как и в ситуации с хранимыми процедурами, такой отход от правила может быть, иногда, оправдан. Требования к нему просты: код бизнес-логики нужно организовать в независимую, от остального 1st tier, структуру объектов, которая не занимается делами 1st tier (т.е. никак не взаимодействует с пользователем напрямую). Этот код лучше хранить в отдельных файлах. А в обычном коде 1st tier использовать одинаковый интерфейс, способ создания и удаления таких встроенных ASP-объектов и настоящих 2nd tier объектов. В этом помогут, описанные ранее, Project ASP API и ObjectFactory. Тогда не возникнет «размазывания» кода бизнес-логики по интерфейсу пользователя, а, при необходимости, его легко можно будет вынести в настоящий 2nd tier объект.

Объекты, представляющие сущности на 2nd tier, реализуют следующие услуги:

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

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

3.3 Перемещаем SQL из ASP-файлов в SQL-шаблоны

Одним из главных достоинств ASP является его скриптовость. Т.е. файл и исходным кодом является одновременно и исполняемым файлом. Без необходимости компиляции, связывания и т.д. Выигрыш в скорости у компилируемых объектов обычно бывает менее важен, чем простота скриптов на фазе поддержки проекта. Ничто не сравнится с ощущением молниеносного всевластия над ошибками в приложении, когда можно что-либо подправить в непосредственно работающем сайте прямо по время презентации, зайдя на сервер по FTP (что, конечно же, мы делать не будем, т.к. нарушим структуру версионного контроля).
И, если слишком многое хардкодить в компилируемых объектах 2nd tier, то скриптовость ASP мы утратим. Здесь уместно предложить разумный компромисс. Сложные операции клиента мы согласимся хардкодить в объекты 2nd tier. А вот со всеми SELECT и с единичными INSERT,UPDATE,DELETE (не требующих участия в сложных транзакциях) поступим проще. Вынесем их во внешние файлы, называемые SQL-шаблонами. С ними будет работать один унифицированный объект 2nd tier.
SQL-шаблоны могут иметь любую структуру — XML, INI, etc. Они, теоретически, могут храниться как угодно, и не обязательно в файлах. Главный принцип в том, что каждому SQL-выражению задается сущность, тип (SELECT, UPDATE, INSERT, DELETE) и присваивается имя. И основной код 1st tier обращается к уникальному SQL по комбинации: сущность+тип+имя шаблона. Затем передаются входящие параметры и (в случае SELECT) получаются исходящие. Т.е., основной код 1st tier и клиентских Session-объектов с SQL больше никак не связан.
По сути SQL-шаблоны — это очень простой способ реализовать все объекты сущностей (Entity Beans) быстро и унифицированно.

3.4 Пример структуры SQL-шаблонов

Рассмотрим один из вариантов организации структуры SQL-шаблонов в виде каталогов и файлов.

Допустим, корневой каталог структуры называется просто «entities» («сущности»).
В этом каталоге находятся подкаталоги, соответствующие сущностям базы данных. На рисунке их четыре: Agent, Customer, Goods, Shop. (имена сущностей принято записывать в единственном числе).
В каждом каталоге сущности находятся 4 подкаталога, соответствующих типам DML SQL-выражений: SELECT, UPDATE, INSERT, DELETE.
В каталогах DML-типов находятся сами SQL-шаблоны. Это просто файлы, у которых имя соответствует назначению SQL-шаблона, а расширение, например, определяет тип DB сервера под который они написаны. (т.е. можно иметь несколько одинаковых SQL-шаблонов оптимизированных под разные типы SQL-серверов: Oracle, MSSQL, MySQL, etc.).

Дополнительно, в корневом каталоге «entities» может находиться общий конфигурационный файл доступа к DB. А в каталогах сущностей — опциональные конфигурационные файлы доступа к DB для каждой сущности. Таким образом, мы можем обеспечить инфраструктуру для хранения различных сущностей на различных DB-серверах.

Приведем пример файла SQL-шаблона в *.INI-подобном формате (исключительно для простоты, т.к. XML-формат файла в данном случае гораздо удобнее). Это шаблон сущности Customer, типа SELECT, который производит выборку имен и фамилий всех клиентов, зарегистрировавшихся в промежутке между двумя заданными датами

[Parameters]
name=AllBetweenDates
type=select
entity=Customer
INnames=dtAfter,dtBefore
INtypes=d,d
OUTnames=sFirstName,sLastName
OUTtypes=s,s

[SQL]
select FIRST_NAME, LAST_NAME
from CUSTOMER
where REGISTER_DATE = ::dtAfter
order by LAST_NAME, FIRST_NAME

В секции параметров шаблона мы видим 3 параметра(name,type,entity), ответственных за позиционирование шаблона (в случае, если файл попадет не в нужный каталог, эту ошибку легко будет обнаружить).
Затем идут имена и типы входных параметров(INnames, INtypes). Входные параметры доступны в SQL выражении через синтаксис «::»+ . Типы задаются символами. Например, дата/время — d, строка — s, целое число — i, и т.д.
Затем идут имена и типы выходных параметров — атрибутов(OUTnames, OUTtypes).

И, наконец, в секции [SQL] записано само SQL выражение. Его результат доступен 1st tier по именам, записанным в OUTnames.

Приведенный вариант структуры SQL-шаблонов не обеспечивает автоматического механизма для гарантированного обеспечения соответствия одинаковых имен параметров/атрибутов во всех шаблонах одной сущности. Это можно решать административным путем (введением корпоративных конвенций на именование параметров/атрибутов, в зависимости, например, от названия колонки таблицы).
Но на практике, это не слишком большая проблема.

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

3.5 Пример API для использования SQL-шаблонов

Работу с SQL-шаблонами будет осуществлять специально написанный унифицированный объект 2nd tier. А в ASP стандартная библиотека Project ASP API будет предоставлять удобную оболочку (адаптер) для этого объекта. Пусть этот адаптер называется EntityManager. Упрощенно, он должен предоставлять все те же 4 DML функции: SELECT, UPDATE, INSERT, DELETE. Часто предлагается использовать другие названия, чтобы подчеркнуть, что это уже не SQL, а абстрактная сущность уровня бизнес-логики. «SELECT» называют, например, «Get», «UPDATE» -> «Amend», «INSERT» -> «New» или «Create», «DELETE» -> «Remove». Ограничения, также, накладывает используемый язык программирования. Например, в JScript «delete» является зарезервированным словом и его нельзя использовать как имя.
«SELECT» можно разделить на 2 метода. Один возвращает единичную строку выборки. А второй возвращает объект-итератор, через который можно получить многострочную выборку. В JScript и PerlScript достаточно просто реализуется динамическое создание нового типа объекта и его возврат как результат метода. В обоих случаях «SELECT»-методов, атрибуты возвращаемого объекта будут соответствовать OUT-переменным SQL-шаблона. А, в случае многострочной выборки, объект будет дополнительно содержать стандартные, для итератора, методы next() и eof(). Никто не запрещает также предложить другие удобные в работе методы.

Вот пример списка методов класса EntityManager:

selectOne(entity_name, template_name, arg1, arg2, . argN)	Этот метод получает имя сущности, имя шаблона и список входных параметров шаблона. Как результат, возвращается объект, содержащий выходные параметры шаблона в виде своих атрибутов. В JavaScript это реализуется при помощи функции eval(): например так: s = «this.sFirstName='»+sFirstName+»‘;\n»; s += «this.sLastName=. . obj = eval(«new function() < "+s+" >«); return obj; Все эти механизмы скрывает адаптер EntityManager. Он взаимодействует с 2nd tier объектом, который может передавать сразу все полученные атрибуты в виде пригодной для eval() строки. Таким образом будет экономится время на вызовы 2nd tier (все атрибуты будут получены одним вызовом) и на формирование JScript-объекта.
selectSet(entity_name, template_name, arg1, arg2, . argN)	Этот метод возвращает объект-итератор, атрибуты которого аналогичны описанным для selectOne(), а методы стандартны для итераторов: next(), eof(), и close()
selectAttr(entity_name, template_name, arg1, arg2, . argN)	Возвращает значение первого выходного параметра шаблона (для простейших SELECT-выражений, выбирающих 1 значение)
exists(entity_name, template_name, arg1, arg2, . argN)	Возвращает TRUE/FALSE при наличии/отсутствии результирующих строк у SQL-шаблона типа SELECT
update(entity_name, template_name, arg1, arg2, . argN)	Реализует DML-команду UPDATE
insert(entity_name, template_name, arg1, arg2, . argN)	Реализует DML-команду INSERT
remove(entity_name, template_name, arg1, arg2, . argN)	Реализует DML-команду DELETE
close()	деструктор объекта EntityManager

Вышеописанные методы имеют переменное число аргументов, что совсем не является проблемой для Perl, а в JavaScript массив аргументов метода объекта (внутри этого метода) получается через запись this.имя_метода.arguments;
Очень часто более сложную бизнес-логику для операции с сущностями абстрактно можно свести к одной из 4х вышеупомянутых DML команд — SELECT, INSERT, UPDATE, DELETE. И так же нужно передать входные и получить выходные параметры. А это означает, что мы можем использовать одинаковую форму записи вызовов к SQL-шаблонам и к сложным операциям бизнес-логики 2nd tier. Корректную переадресацию вызовов инкапсулирует EntityManager, действуя в зависимости от имени шаблона. Например, вызов SQL-шаблона сущности Shop, типа INSERT, c именем «NewShop», может переадресовываться сложному объекту 2nd tier, создающему новый экземпляр сущности Shop и выполняющий соответствующие действия. Основной ASP-код не будет никак от этого зависеть, т.к. форма вызова остается унифицированной.
Приведенный пример достаточно прост. В нем отсутствуют, в частности, средства управления транзакциями и т.п. Однако даже описанным API (который разрабатывается достаточно быстро) можно решать вполне широкий круг задач ASP проектов.

4.Пример разделения монолитной ASP-страницы

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

Монолитный ASP-файл: showcustomers.asp	Разделенные файлы:
objADOConn = Server.CreateObject(«ADODB.Connection»); objADOConn.Open(«dsn=DSN_DBSAMPLE;»);	showcustomers.asp

	HTML-шаблон: _t_showcustomers.htm.asp
	SQL-шаблон (INI format): /entities/Customer/select/ AllBetweenDates.ora8

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

Послесловие

Не привязываемся к Microsoft, не привязываемся к языку скриптов, не привязываемся к
стандартным ASP-объектам, не привязываемся к MTS. (о стремлении к абсолютной свободе)

Смысл этой статьи сводится к тому что проекту, при желании, можно придать довольно большую степень свободы. Даже без особых дополнительных затрат. Свободу от аппаратной/программной платформы, web-технологии, источника данных, инфраструктуры 2nd tier, от проблем с web-мастерами не разбирающимися в программировании и с бездарными в web-дизайне программистами (к коим относит себя автор статьи). Свободу от прихотей Microsoft, Sun, Oracle, Borland, Allaire, BEA и т.д. , которые привнесли в нашу жизнь все эти занимательные технологии и часто приятно, и не очень, удивляют нас своими выходками.
В 80-х годах SQL дал программистам относительную свободу от конкретной реализации сервера реляционной БД. В 90-х появился, например, J2EE, претендующий на предоставление свободы от конкретной реализации сервера приложений. Но почему бы не быть свободыми и от SQL, и от J2EE, даже строя проект на этих технологиях?

Разработка сложных Web-приложений на примере Microsoft Active Server Pages

Проблема 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 с точки зрения пользователя (как источника прибыли), в условиях ограниченных ресурсов на разработку (временных, финансовых, кадровых и т.д.). Предлагаемая иерархия такова:

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

Это спорная схема. Если первейшая задача — продемонстрировать что-то несведущим инвесторам, что пункты 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 можно отнести то, что он прост для использования VisualBasic-программистами. Если объекты 2nd tier пишутся как COM-объекты на VisualBasic, это может служить оправданием использования VBScript. Т.к. образуется некий «корпоративный стандарт». Язык Basic, сам по себе, является прекрасным языком для обучения программированию, на котором выросло не одно поколение программистов. Однако, непосредственно VBScript, не способствует появлению хорошего стиля программирования и потому стимулирует крах проектов средней и большой сложности. Наверное, худшим ограничением является отсутствие возможности объектно-ориентированного программирования, что очень критично для крупных проектов. Если, все-таки, решено использовать VBScript, следует уделить тщательное внимание аккуратности при написании кода, комментариям, отступам, понятным названиям процедур, функции и переменных, хорошему документированию. Это важно при любом программировании, но для VBScript это актуально вдвойне. Не следует также пользоваться независимостью от регистра языка VBScript.

Одним из новаторских изобретений фирмы 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.

Появившись как язык для написания 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, со всеми преимуществами корпоративных стандартов.

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

Объектно-ориентированное программирование

Нет

Да

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.Java );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(), мы получим гарантированное закрытие всех объектов, даже если мы забыли закрыть их в основном коде. Для объектов работы с базой данных это особенно критично.

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Способы организации активных web-серверов

ISAPI

Если Web- сервер создан на базе Microsoft Internet Information Server , вместо программ CGI можно использовать приложения ISAPI , реализованные в виде библиотек динамической загрузки DLL , что позволяет повысить производительность и масштабируемость . Приложения ISAPI условно делятся на расширения ISAPI и фильтры ISAPI .

Расширения ISAPI

Расширения ISAPI выполняют те же функции, что и программы CGI : обычно они применяются для обработки клиентских запросов и возвращения ответа в формате HTML.

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

Для повышения производительности в некоторых Web-серверах (в частности, Microsoft Internet Information Server) используется другой способ создания расширений. Расширение создается как библиотека динамической загрузки DLL с использованием программного интерфейса ISAPI ( Internet Server API).

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

Программирование приложений ISAPI представляет собой более сложную задачу, нежели создание программ CGI . Поскольку такие приложения всегда работают в мультизадачном режиме, необходимо обеспечить синхронизацию доступа к критичным ресурсам. Ошибки в приложениях ISAPI могут привести к аварийной остановке сервера Web, а вот при использовании программ CGI это маловероятно.

ISAPI -расширения явно указываются в URL-адресе, отправляемом на IIS-сервер: Например: http://localhost/sayhelloisapi/sayhelloisapi.dll

ISAPI -расширение можно вызывать с параметрами, которые позволят одному компоненту выполнять разные задачи.

Сервер IIS версии 4.0 и старше позволяет загружать программы ISAPI в отдельное адресное пространство . Эта возможность, замедляющая работу сервера, обычно используется для отладки новых программ. Аварийное завершение программы ISAPI , загруженной в отдельное адресное пространство не приводит к полной остановке Web-сервера.

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

Однако приложения ISAPI приходится отлаживать намного тщательнее, чем программы CGI . Так как приложение ISAPI работает в адресном пространстве Web-сервера, ошибка в приложении ISAPI способна вызвать аварийное завершение работы Web-сервера.

Фильтры ISAPI

Фильтры ISAPI , так же как и расширения ISAPI , реализованы в виде библиотек динамической загрузки DLL и способны контролировать весь поток данных между браузером и Web-сервером на уровне протокола HTTP.

ISAPI -фильтры никогда не вызываются явно — IIS-сервер обращается к ним в ответ на определенные события в процессе выполнения запроса:

на завершение обработки сервером предоставленных клиентом заголовков;
на завершение сервером процедуры аутентификации клиента;
на сопоставление сервером логического URL-адреса физическому;
до начала пересылки «сырых» данных от клиента на сервер;

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

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

ISAPI -расширения часто создаются с использованием ISAPI -классов библиотеки MFC (Microsoft Foundation Class Library ). Это значительно упрощает разработку ISAPI -расширений.

Активные страницы ASP

Active Server Pages ( ASP ) — это серверная среда для разработки и выполнения динамических интерактивных веб-приложений .

Технология ASP предполагает интенсивное использование серверных сценариев и объектов СОМ для создания активных Web-серверов.

Языки программирования, используются для создания больших и сложных программных комплексов. Языки написания сценариев используются для создания программ ограниченных возможностей, называемых сценариями, которые выполняют функции web-узла на web-сервере или в браузере. В отличие от сложных языков программирования, языки написания сценариев интерпретируются: инструкции последовательно выполняются промежуточной программой, называемой интерпретатором команд . Хотя интерпретация уменьшает эффективность выполнения, языки написания сценариев просты для изучения и обеспечивают большие возможности. Сценарии могут быть встроены в HTML -страницы для форматирования содержимого или могут реализовывать компоненты COM , заключающие в себе бизнес-логику.

Файл Active Server Pages ( ASP ) представляет собой текстовый файл с расширением «. asp «. Этот файл может содержать текстовые данные, тэги языка HTML и серверные сценарии.

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

Когда пользователь обращается к странице ASP , Web- сервер вызывает веб-сервер расширение ASP для обработки указанного в запросе файла, которое интерпретирует расположенный в ней сценарий . При этом анализируются параметры, переданные этой странице. Далее страница модифицируется (или создается заново), а затем отправляется обратно пользователю.

В ASP отсутствует ориентация на конкретный язык программирования , поэтому знакомства с любым языком сценариев ( VBScript , JScript или PERL) будет достаточно для того, чтобы работать с Active Server Pages. Более того, на страницах ASP допускается использование любого языка сценариев, для которого был установлен COM -совместимый обработчик сценариев. Обработчик сценариев — это программа , которая обрабатывает команды, записанные на определенном языке. В состав ASP входят обработчики сценариев VBScript и JScript , но имеется дополнительная возможность установки обработчиков для языков PERL, REXX и Python , которые могут быть получены от независимых разработчиков. Обработчик сценариев представляет собой расширение ISAPI , которое физически является динамически подключаемой библиотекой ASP.DLL . ASP.DLL просматривает файлы .asp на предмет наличия тэгов, обозначающих внедренный код для выполнения на сервере. ASP.DLL передает код сценария в Windows Script Host (WSH). WSH выполняет этот код и возвращает ответ файлу ASP.DLL , который, в свою очередь , передает IIS результат выполнения сценария и содержимое самого файла ASP . IIS возвращает ответ программному обеспечению, от которого поступил запрос .

Средствами технологии ASP можно создавать интерактивные Web-страницы, не используя расширения CGI или ISAPI , что позволяет в ряде случаев полностью избежать или максимально сократить программирование на C++ или Perl. Активные страницы ASP выполняют обработку данных, введенных пользователями при помощи форм, обращаясь при необходимости к базам данных или другим активным объектам .

Пользователь не может каким-либо образом получить содержимое страницы ASP , так как Web- сервер отправляет ему не саму страницу, а результат ее интерпретации. Таким образом, логика работы страницы скрыта от пользователей.

ASP поддерживает технологию работы со сценариями Windows Script Components. Она позволяет поместить все сценарные процедуры, выполняющие бизнес-логику, в COM -компоненты. Эти компоненты допускают повторное использование, и могут работать как в web-приложениях, так и в других программах, построенных по технологии COM .

ASP поддерживает новую служебную программу шифрования сценариев, поставляемую с MicrosoftVisual Basic Scripting Edition ( VBScript ) и Microsoft® JScript 5.0. Имеется возможность шифровать как клиентские, так и серверные сценарии, в результате чего тексты сценариев будут отображаться бессмысленной последовательностью ASCII-символов. Зашифрованные сценарии расшифровываются обработчиком сценариев во время их выполнения, поэтому нет необходимости в использовании отдельной программы расшифровки. Несмотря на то, что это не является полностью безопасным решением, технология не позволяет большинству обычных пользователей скопировать или просмотреть сценарий .

Серверный сценарий , встроенный в страницу ASP , способен обращаться к базам данных через вызов методов интерфейса ActiveX Data Objects ( ADO ) — простую и понятную процедуру. Если возникнет необходимость реализовать собственную бизнес-логику, имеется возможность создания новых объектов СОМ или использования объектов СОМ сторонних разработчиков.

Образовательный блог — всё для учебы

1) Общие сведения об ASP
ASP (Active Server Pages) – это технология программирования, позволяющая создавать на Web-сервере (с IIS, 1997 г.) динамические интерактивные Web-страницы. ASP представляет собой файлы с расширением *.Asp, содержащие смесь кода HTML, кода сценариев на языке VBScript или JavaScript, средств доступа к БД (ADO), управления внешними COM-объектами и внутренних объектов ASP. Эта технология впервые была реализована в Web-сервере IIS фирмы Microsoft и фактически является интерпретируемым вариантом ISAPI-расширения сервера.

2) Встроенные объекты
ASP включает семь встроенных (не требующих создания и инициализации) объектов, используемых для пересылки HTML-страниц и данных браузеру, извлечения данных, обмена данными с сервером и т.д. среди них:
• Response – пересылает данные клиенту
• Request – обрабатывает данные, поступающие с запросом от клиента.
• Server – обеспечивает взаимодействие с сервером.
• Application – кэширует данные о приложении.
• Session – кэширует данные о браузере.
• ObjectContext – запускает транзакции и управляет их выполнением.
• ASPError – поддерживает работу с ошибками.

3) Особенности ASP
Помимо встроенных, в комплект ASP входит ряд устанавливаемых объектов, часть из которых бывает полезна, а часть незаменима. Так COM объект Dictionary незаменимый.

В отличие от CGI, ASP-сценарий выполняется как внутренний процесс сервера, кроме того, он многопоточен и оптимизирован для работы с большим количеством пользователей. ASP-сценарий начинает выполняться после того, как браузер запросит файл с расширением *.Asp с Web-сервера. Web-сервер посылает вызов встроенному в IIS ASP-механизму обработки (..\System\InetSrv\Asp.Dll), который считывает сценарий и выполняет все встретившиеся команды. В результате генерируется HTML-страница, которая посылается браузеру.

Для того, чтобы с помощью ASP сделать что-либо серьезное на Web-сервере, необходимо создать COM-объекты и использовать их службы (методы). Компоненты ASP Должны использовать модель потоков STA – каждый объект выполняется в контексте собственного потока и защищен от конкурирующих потоков.

4) Доступ к встроенным объектам
Для доступа от создаваемых COM-объектов ко встроенным необходимо использовать интерфейсы:
a) С помощью функции GetObjectContext получить указатель на интерфейс IObjectContext;
b) С помощью указателя следует получить указатель на интерфейс IGetContextProperties;
c) Вызвав метод GetProperties() и передав ему имя встроенного объекта, например, Request или Response, и вариантную переменную, можно получить через нее указатель на IDispatch интерфейс запрашиваемого объекта;
d) Далее можно вызывать методы встроенного объекта.

5) Недостатки ASP
• Программы ASP не компилируются, а интерпретируются. Следовательно, они исполняются медленнее компилируемых.
• ASP не имеет развитых средств определения типов. Все переменные имеют тип Variant (16 байт). Это удобно, но не способствует повышению скорости работы.
• Внешние файлы приходится включать (include) при каждом обращении.
• ASP трактует все объектные (object) переменные как объекты с поздним связыванием. При каждом обращении к свойству или методу запрашиваются все данные об объекте, что увеличивает время отклика.

6) Пример реализации ASP
— Необходимые настройки и установки
На сервере необходимо установить IIS (каталог WEB5), ADO, ODBC (System DSN – SLS), InterBase (FireBird). В качестве источника данных воспользуемся БД Sales.Gdb.

— Структура программы доступа к БД

HTML-заголовок:

Демонстрация ASP

Подключение к БД

Подключение к БД:

HTML-подвал:

Цикл считывания данных:

Fields.Count-1 %>

— Работа с программой
Для запуска программы следует в браузере набрать: http://localhost/web5/sales/php

7) ASP клоны и аналоги
• Chili!Soft
Chili!Soft, продукт одноименной компании, — достаточно гибкий клон ASP, способный работать на разнообразном оборудовании, операционных системах и Web-серверах. Считается, что Chili!Soft и ASP совместимы на 90%.

• Java Server Pages
Java Server Pages (JSP) – технология, напоминающая ASP, но в которой используется только язык Java в сочетании с HTML, для поддержки динамического формирования страниц на любой платформе с поддержкой Java. Аналогом COM-объектов являются объекты JavaBeans.

• Apache::ASP
Apache::ASP на основе PerlScript от Apache Perl International Project работает на множестве операционных систем, но только с Web-сервером Apache.

• PHP
Похожими возможностями обладает язык с открытой лицензией PHP. Правда технология PHP базируется на классических библиотеках объектных модулей, а не на использовании модели компонентного объекта COM и элементов управления ActiveX.

Asp active server pages

Этот текст предназначен для тех, кто никогда не имел дела с ASP и вообще смутно себе представляет возможности программирования на стороне сервера. Я ставил себе задачу создать у читателя общее представление о предмете. Отдельные неточности при этом менее важны — пожалуйста, громко не ругайтесь.

Общие сведения

ASP (Active Server Pages) – это мощная технология от Microsoft, позволяющая легко разрабатывать приложения для WWW. ASP работает на платформе Windows NT и IIS (Internet Information Server), начиная с версии 3, хотя вроде есть реализации на других платформах. ASP – это не язык программирования, это внутренняя технология, позволяющая подключать программы к Web-страницам. Основа успеха ASP – простой скриптовый язык (Visual Basic Script или Java Script) и возможность использования внешних COM-компонент.

Как это все происходит?

Вы пишете программу и складываете в файл на сервере. Браузер клиента запрашивает файл. Файл сначала интерпретируется сервером, на выходе производится HTML-код. Этот HTML посылается клиенту. Файлы с программами имеют расширение .asp. Файлы asp – это обычные текстовые файлы, содержащие исходные тексты программ. Файлы делаются с помощью любого текстового редактора. Каталог, в котором размещены файлы asp должен иметь права на выполнение, так как сервер исполняет эти файлы, когда браузер их запрашивает. Собственно программы пишутся на любом скриптовом языке, который установлен в системе. По умолчанию поддерживаются VBScript и JavaScript. Можно доустановить другие (например, Perl). Если ничего специально не указывать используется VBScript. В дальнейшем будем ссылаться только на него. Программные фрагменты заключаются в скобки . Можно ставить открывающую скобку в начале файла, закрывающую – в конце, все что между ними – программа на Visual Basic’е.

Какие средства есть для программирования?

Web – нормальная среда программирования, если правильно понять, что есть что. В VBScript есть все нормальные конструкции структурного программирования (if, while, case, etc). Есть переменные (описывать не обязательно, тип явно не задается). Поддерживаются объекты. Работа с ними обычная – Object.Property, Object.Method. Есть ряд встроенных объектов (Request, Response, Session, Server, Connection, Recordset). Можно доустанавливать другие компоненты (скачивать, покупать, программировать), например для работы с электронной почтой.

Вывод

Понятия «экран», куда можно выводить данные нет. Все, что надо показать пользователю, выбрасывается в выходной поток на языке HTML. Браузер пользователя интерпретирует этот HTML. Для упрощения вывода существует объект Response . Вывод осуществляется с помощью метода Write .

Так производится запись во внутренний буфер объекта Response. Когда скрипт заканчивает работу, весь буфер выдается клиенту. Надо заметить, что клиент получает «чистый» HTML, таким образом программы на ASP не зависят от клиентского ПО, что очень важно. Если внутри выводимой строки нужно использовать кавычку, кавычка удваивается. Другие методы и свойства Response позволяют управлять выводом. Так Response.Buffer регулирует, получает ли клиент данные по мере из записи в Response, или все сразу по завершении исполнения страницы. Метод Response.Redirect перенаправляет браузер на другую страницу. Чтобы им пользоваться, нельзя до него на странице использовать Response.Write.

Программа на ASP не может явно спросить пользователя о чем-то. Она получает данные из других страниц, либо через URL. Передаваемые параметры помещаются во входной поток и доступны через объект Request . Чтобы передать переменную var в программу test.asp , надо написать:

Чтобы из программы получить значение этой переменной, надо написать:

Несколько переменных разделяется знаком &:

Кроме того, чтобы задавать параметры в URL, можно воспользоваться формами HTML. В вызывающей странице пишем так:

Так это выглядит:

При этом пользователь увидит форму из одного поля ввода (var1), в нем будет значение по умолчанию «default». Второе поле (var2) будет невидимо и будет передавать всегда фиксированное значение «var2value». Кнопка «Submit Form» завершает заполнение формы и передает все переменные на test.asp (action). Если method=»get», переменные передаются через URL (test.asp?var1=default&var2=var2value). Если method=»post», передаются вместе с запросом так, что внешне передача переменных не заметна. В вызываемой программе безразлично, какой метод изпользовался (почти). Если у вас нет специальных аргументов за метод GET, используйте метод POST.

Формы

Формы HTML используются для организации диалога с пользователем. Поддерживаются стандартные элементы управления. Все многообразие задается немногими тэгами:

INPUT (с параметром TYPE=)
SELECT
TEXTAREA

Описание – в документации по HTML.

Взаимосвязь между отдельными страницами

Обычно сервер WWW не хранит состояние приложения, т.е. все запросы взаимонезависимы, и нет стандартного способа понять, что несколько запросов пришли от одного и того же пользователя. Но это очень нужно для разработки полноценных приложений и является одной из главных проблем разработки Web-приложений.

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

ASP, используя cookies, предоставляет программисту более простое средство — объект Session (сессия). Сессия стартует, когда новый пользователь обращается к любому asp-файлу приложения. Сессия заканчивается при отсутствии активности пользователя в течение 20 минут, либо по явной команде. Специальный объект Session хранит состояние сессии. Туда можно записывать переменные, которые доступны из любой страницы в этой сессии. Записать данные в этот объект можно просто:

Считать потом еще проще:

Сессия, таким образом, – это еще один метод передачи данных между страницами. Одна страница пишет данные в сессию, другая – берет потом оттуда.

Наряду с объектом Session существует объект Application . Если сессия создается для каждого нового пользователя, до Application существует в единственном экземпляре, и может использоваться всеми страницами приложения.

Управление приложением

Программисту предоставляется возможность реагировать на 4 события: старт/стоп приложения и старт/стоп каждой сессии. Для реализации этих событий предназначен файл global.asa , который должен располагаться в корневом каталоге приложения. Вот его примерный скелет:

Нужно «просто» вписать Ваш код на соответствующее место. Нужно заметить, что отлаживать код для global.asa довольно непросто, так как он выполняется при очень специфических обстоятельствах (к примеру при старте или остановке сервера).

Использование внешних компонент

Если на сервере установлены дополнительные компоненты, их можно использовать из ASP. Стандартные объекты (например из библиотек ADO (Connection и Recordset) и Scripting (Dictionary, FileSystemObject)) доступны всегда. Установка новой компоненты обычно состоит в копировании dll-файла в каталог на сервере и ее регистрации с помощью программы regsvr32.exe. [В COM+ используется своя процедура инсталляции объектов, это однако не влияет на использования объектов.]

Создать экземпляр объекта можно так:

Class.Object указываются в документации на компоненту. В переменной var запоминается ссылка на созданный экземпляр объекта. Когда объект не нужен, ссылку нужно обнулить с помощью команды:

Пожалуйста всегда обнуляйте все ссылки на объекты, когда они больше не нужны. Теоретически это должно происходить автоматически при завершении процедуры/страницы, однако в стандартной сборке мусора есть определенные «проблемы».

В остальном использование компоненты зависит от самой этой компоненты.

Работа с базами данных

Из ASP можно легко и просто работать с любыми базами данных. Это делается через две промежуточные технологии: ODBC и ADO.

ODBC позволяет организовать доступ к любым базам данных через унифицированный интерфейс с помощью языка SQL. Специфика конкретных СУБД учитывается при помощи специальных драйверов БД. Такие драйверы существуют для всевозможных СУБД (в частности SQL Server, Oracle, Access, FoxPro). Поддержка ODBC обеспечивается на уровне операционной системы Windows (NT). Настройка – через Control Panel/ODBC. Базовым понятием является источник данных или data source. Источник данных – это совокупность сведений о базе данных, включая ее драйвер, имя компьютера и файла, параметры. Чтобы пользоваться базой надо создать источник данных для нее. Важно, чтобы источник данных был «системным», в отличии от «пользовательского». После этого надо лишь знать имя источника данных. [В настоящее время ODBC отступает перед натиском технологии OLE DB. На практике это однако практически ничего не изменяет. Вместо имени источника данных нужно использовать Connection String, в которой указывается имя ODBC-драйвера и все его параметры.]

ADO – это совокупность объектов, доступных из ASP, позволяющих обращаться к источнику данных ODBC [или OLE DB]. Фактически нужны лишь 2 объекта – Connection , представляющий соединение с базой данных и Recordset , представляющий набор записей, полученный от источника. Сначала необходимо открыть соединение, потом к нему привязать Recordset, потом, пользуясь методами Recordset’а, обрабатывать данные. Вот пример:

Если команда SQL не возвращает данных, recordset не нужен, надо пользоваться методом Conn. Execute (SQL_COMMAND).

Если Вы хотите вызывать хранимые процедуры сервера БД с параметрами, нужно воспользоваться объектом Command , который в свою очеред содержит объекты Parameter .

Методики программирования, советы

Описание переменных

VBScript — очень нетребовательный к программисту язык. Так он не требует описывать переменные и не содержит явных типов данных. Все переменные принадлежат одному типу Variant . Из-за отсутствия описаний могут произойти очень трудно обнаруживаемые ошибки. Одна опечатка может стоить полдня поисков.

Однако, есть возможность явно потребовать описания переменных. Для этого первой строкой в ASP-файле нужно написать Option Explicit . После этого обращение к переменной, которая не была объявлена с помощью Dim , вызывает ошибку с указанием номера строки.

Кстати, где расположены описания Dim в процедуре — совершенно не важно. Они могут стоять как до использования переменной, так и после, и даже в цикле. Видимо они отрабатываются препроцессором. Явно задать тип переменной с помощью Dim Var as Typ , как в Visual Basic, все равно нельзя.

Чередование ASP/HTML

Если нужно выдать большой кусок HTML, можно не пользоваться Response.Write. Если в asp-файле встречается кусок текста вне скобок , он трактуется просто как HTML, который надо вывести. Пример:

Обработка ошибок

Для отслеживания ошибок используется специальный объект Err . Он устанавливается в ненулевое значение, если предыдущая команда породила ошибку. Ее можно проверять с помощью If, и таким образом реагировать на ошибки. Чтобы из-за ошибки не прерывалось выполнение программы, в начале нужно включить команду

Включение других файлов

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

Важно: все includes в тексте отрабатываются до исполнения файла. Т.е. даже если include стоит внутри if, то сначала будут включены все includes во всех ветках, и только потом, во время исполнения, будет принятно решение, какую ветку выполнять. Т.е. следующий код не дает условного включения файлов:

Обработка форм

Если надо что-то спросить у пользователя и на основании этого что-то сделать, в простейшем случае создается два файла: один с формой, второй – с ее обработчиком. Обработчик выполняет все действия. Пример:

Рекурсивная обработка форм

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

Переменные HTTP

Запрос от браузера, кроме запрашиваемой страницы несет еще некоторые данные. Эти данные, например, IP-адрес клиента, доступны через специальные переменные объекта Request. IP-адрес – Request(«REMOTE_ADDR»). Другие — см.документацию (ASPSamp\Samples\srvvar.asp).

Переадресация

Очень легко написать на ASP скрипт, который будет производить некоторые расчеты, и в зависимости от результатов переадресовывать браузер на разные URL (например, подставлять нужный баннер). Делается это так:

Только надо следить, чтобы до выполнения команды redirect ничего не было записано в Response (даже коментарии HTML).

Электронная почта

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

Но это приводит к тому, что при отправке формы делается попытка на клиентской машине запустить почтовую программу и создать новое сообщение с данными формы. Если это не получается (почтовая программа не настроена, пользователь не отправил почту, и т.д.) — письмо и не будет отправлено. Гораздо надежнее работает серверное решение.

Для этого существуют внешние компоненты, есть и бесплатные. Например, компонента Jmail от Dimac. Все, что для нее нужно – это адрес SMTP-сервера. Вот пример ее использования:

ASP — Руководство по Active Server Pages

Перед вами — руководство по Active Server Pages. В данном разделе представлены подробные сведения по созданию страниц ASP и разработке веб-приложений. Здесь также описаны особые методы событий и интерфейсные средства для создания компонентов, доступ к которым обеспечивается расширениями ASP и ISAPI. В настоящем разделе можно найти необходимые указания по сохранению данных пользовательских настроек IIS и работе с ними через встроенные объекты. Наконец, в руководство включена библиотека сценариев и примеров программ, где наглядно представлены различные возможности взаимодействия с IIS.

Лекция 1. Что такое ASP.NET. Инсталляция и тестовый проект.

Введение

Microsoft .NET Framework — это платформа для создания, развертывания и запуска Web-сервисов и приложений. Она предоставляет высокопроизводительную, основанную на стандартах, многоязыковую среду, которая позволяет интегрировать существующие приложения с приложениями и сервисами следующего поколения, а также решать задачи развертывания и использования интернет-приложений. .NET Framework состоит из трех основных частей — общеязыковой среды выполнения (common language runtime), иерархического множества унифицированных библиотек классов и компонентной версии ASP, называемую ASP.NET.

ASP.NET – это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты. Вы также можете использовать сервисы, предоставляемые другими сайтами, прозрачно для пользователей вашего сайта. В общем, возможности ASP.NET ограничены только вашим воображением.

Давайте обсудим, что такое динамические страницы HTML и чем они отличаются от статических. Статическая страница содержит код на языке гипертекстовой разметки HTML. Когда автор страницы пишет ее, он определяет, как будет выглядеть страница для всех пользователей страницы. Содержание страницы будет всегда одинаковым независимо от того, кто и когда решит ее просмотреть. Языка HTML вполне достаточно для отображения информации, которая редко изменяется и не зависит от того, кто ее просматривает. Страница HTML — простой ASCII-текст, следовательно, клиент может работать в любой операционной системе.

Совершенно понятно, что если сформировать web-страницу, описав ее структуру средствами HTML, она будет совершенно статична в смысле содержимого. То есть при просмотре в браузере она будет нести в себе точно ту же информацию, что была в нее записана в момент создания, и переданные пользователем данные не могут быть использованы для модификации содержимого отображаемых ему страниц: он сможет увидеть только то, что предварительно было записано в конечный набор файлов.

Но что, если мы хотим отобразить на странице текущий курс евро или прогноз погоды? Если мы написали страницу HTML вчера, сегодня она уже устареет. Следовательно, мы должны уметь создавать динамические страницы. Динамическое наполнение страницы – это информация, содержание которой определяется тем, кому она предназначена, и которая отличается от просмотра к просмотру. Оно позволяет обеспечить двусторонний обмен информацией – от клиента к серверу и обратно.

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

Большинство страниц на ранних стадиях развития интернета были статическими. Последние 10 лет растет количество динамических страниц. И это понятно, пользователи интернет хотят не только читать готовую информацию, а быть активными действующими лицами. Например, они заказывают товары в интернет-магазине, пишут дневники, участвуют в конкурсах. Информационные порталы обновляют новости каждую минуту. Динамические страницы могут подстраиваться под конкретного пользователя, а также реагировать на его действия в браузере. Каким же образом? Для этого придумано множество технологий. Например, того, чтобы идентифицировать пользователя и сохранить его настройки для данного сайта, применяются файлы-cookies.

Существуют языки, способные динамически изменять содержимое веб-страницы. С одной стороны, это языки скриптов, выполняющиеся непосредственно у клиента. Примеры скриптовых языков — JavaScript и VBScript. Скрипты на этих языках встроены в код HTML, который сервер посылает браузеру. Сценарии, выполняемые на стороне клиента, выделяются тегами и . Браузер интерпретирует этот код и показывает пользователю результат. Сам код можно просмотреть через View Source браузера. Естественно, эти программы не могут быть большими. Например, если нужно выполнить поиск в базе данных, мы не может отправить пользователю все ее содержимое. Но скрипты могут проверить правильность запроса, введенного в форму, тогда не придется перезагружать сервер обработкой неправильных запросов. Некоторые программисты создают на JavaScript анимационные эффекты. Одна студентка intuit.ru желала найти скрипт, который бы отправлял SMS-сообщения. Увы, это невозможно. Выполняемых на стороне клиента сценариев недостаточно для создания полноценных динамических страниц. Даже если на странице используется JavaScript, анимированные картинки .gif, она называется статической.

Динамическая веб-странице должна быть создана «на лету» программой, исполняющейся на интернет-сервере. Широко применяются механизм шлюзов CGI(Common Gateway Interface). Вначале пользователь получает статическую страницу с формой. Вам известно, что в теге FORM существует атрибут ACTION. Именно он задает адрес (URL) исполняемого приложения. На сервере находятся исполняемые файлы программ, написанных, например на C/С++ или Дельфи, которые по протоколу HTTP принимают данные из входного потока или из переменных окружения и записывают в стандартный выходной поток готовую страницу.

Пользователю в ответ на запрос посылается HTML код, который был специально сгенерирован для него. Это может быть, например, результат поиска в поисковой системе. CGI -скрипты могут быть написаны на интерпретируемом языке (Perl) или даже скрипте командной строки. Входной и выходной потоки переназначаются. На вход интернет-сервер принимает данные, введенные пользователем. После обработки полученных данных, пользователю возвращается результирующая страница. При исполнении cgi-программа загружается в память сервера, а при завершении – удаляется. Когда 100 клиентов одновременно обращаются к серверу, в памяти создаются 100 процессов, для размещения кода каждого из которых нужна память. Это отрицательно сказывается на масштабируемости. Напомним, что масштабируемость — это возможность плавного роста времени ответа программной системы на запрос с ростом числа одновременно работающих пользователей.

Для решения это проблемы Microsoft была предложена альтернатива – ISAPI(Internet Server Application Programming Interface)-расширения и фильтры. Вместо исполняемых файлов используются DLL – библиотеки. Код DLL находится в памяти все время и для каждого запроса создает не процессы, а нити исполнения. Все нити используют один и тот же программный код. ISAPI –приложение выполняется в процессе IIS-сервера. Это позволяет повысить производительность и масштабируемость.

ISAPI-расширения можно создавать в Visual Studio C++ 6.0, пользуясь мастером.

У ISAPI тоже есть недостатки, относящиеся к разработке. Если мы меняем исходный код dll, мы должны его откомпилировать и поместить в исполняемую директорию сервера. Но так как предыдущий вариант dll находится в памяти, необходимо остановить сервер, чтобы получить доступ на изменение файла. В это время клиенты не смогут получить в сервера ни один документ, и, конечно, будут не удовлетворены.

Скриптовые языки, исполняющиеся на стороне сервера – php и asp. Технология asp была разработана Microsoft в 90-х годах.

Выполнение кода asp поддерживается ISAPI-расширением сервера. В диалоге конфигурации сервера IIS определяются способы обработки файлов с различными расширениями. Для обработки URL-адреса с расширением в установках сервера определен файл asp.dll. Файлы asp отправляются к нему на обработку. На вход поступает asp, а на выходе имеем поток HTML-кода.

Пример файла asp:

Тег сигнализирует asp, что в нем находится код, который он должен обрабатывать на сервере. Выполняется скрипт на языке, который указан в директиве Language. Оператор Response.Write записывает текст в выходной поток сервера, таким образом, он становится частью HTML-страницы, отправленной пользователю.

Технология asp была ограничена по своим возможностям. Он использовал скриптовые языки, которые имеют меньше возможностей, чем полнофункциональные языки программирования. Код asp был встроен в HTML в виде специальных тегов, что создавало путаницу. Кусочки asp были разбросаны по нему, как изюм в булке. Но HTML код обычно создают дизайнеры, которые умеют «делать красиво», а asp – программисты, которые заставляют все это работать. В ASP.NET вы можете держать код asp и HTML в разных файлах.

Скриптовые языки не поддерживают строгую типизацию. Что это значит? Вы можете не описывать переменную до ее использования и можете присваивать ей значения разных типов. Это удобно, но создает почву для ошибок. Например, у вас есть переменная x1, и вы присваиваете ей значение 1, но вы сделали опечатку и по ошибке написали x2=1. Будет создана новая переменная x2, а значение x1 не изменится. В языке со строгой типизацией компилятор заметит, что переменная x2 не описывалась, и выдаст ошибку.

В 2000 году на конференции разработчиков в качестве части новой технологии .NET Microsoft представила ASP+. С выходом .NET Framework 1.0 она стала называться ASP.NET.

ASP.NET — это не продолжение ASP. Это концептуально новая технология Microsoft, созданная в рамках идеологии .NET. В ASP.NET заложено все, для того, чтобы сделать весь цикл разработки веб-приложения более быстрым, а поддержку более простой. ASP.NET основана на объектно-ориентированной технологии, но сохранила модель разработки asp: вы создаете программу и помещаете ее в директорию, выделенную сервером, и она будет работать. В ASP.NET появилось много новых функций, а существовавшие в asp значительно усовершенствованы.

В ASP.NET используются компилируемые языки. Во время компиляции проверяется синтаксическая корректность исходного текста. Скомпилированный в промежуточный язык код выполняется быстрее, и он будет таким же независимо от языка, который мы используем. Компилируемые языки поддерживают строгую типизацию.

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

Платформа .NET Framework предоставляет приложениям среду выполнения, сама непосредственно взаимодействуя с операционной системой. Выше лежит интерфейс ASP.NET приложений, на котором в свою очередь базируются веб-формы (ASP.NET страницы) и веб-сервисы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки. CLR обеспечивает единый набор сервисов для всех языков.

ASP.NET использует технологию доступа к данным ADO.NET, которая обеспечивает единый интерфейс для доступа к базам данных SQL Server и файлам XML. Кроме того, усиленная модель безопасности позволяет обеспечивать защиту клиента и сервера от несанкционированного доступа.

В 2004 году появилась версия ASP.NET 2.0(бета-версия, окончательный выход – конец 2005-начало 2006). Как утверждается, эта версия позволяет сократить объем кодирования на 70%. Новые возможности версии 2.0 – например, использование шаблонов дизайна страниц(Master Page), упрощенная локализация Web-приложений, более 50 новых серверных элементов управления. Цели, которые преследовали разработчики новой версии – повысить скорость разработки сайтов, масштабируемость, легкость поддержки и администрирования сайтов, скорость работы сервера. Появилась панель остнастки MMC (консоль управления Microsoft), предоставляющая графический интерфейс для управления настройками ASP.NET. Изменять настройки проекта теперь можно и через web-интерфейс. ASP.NET 2.0 поддерживает работу на 64-битных процессорах. Сервис персонализации (personalization) предоставляет готовое решение для хранения персональных данных, непосредственно характеризующих пользователя сайта, так называемого профиля пользователя (Profile).

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

Предыдущие версии Visual Studio для проектов ASP.NET требовали наличия на машине разработчика сервера IIS. Теперь сервер встроен в среду разработки.

ASP.NET 2.0 и Visual Studio 2005 предоставляют инструменты для легкого построения локализируемых сайтов, которые определяют предпочитаемый язык пользователя и посылают ему страницы на его языке.

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

В ASP.NET 2.0 встроена технология автоматического обновления кэширования баз данных. Данные, полученные из базы, хранятся на сервере и он не обращается к базе для обработки повторного запроса. При изменении базы данных кэш обновляет свое содержимое.

ASP.NET — это технология, а не язык, и позволяет программировать на разных языках – С#, Visual Basic, J#. В платформе .NET все языки равны, но некоторые равнее(Дж. Оруэлл). Вот таким языком и является С#, потому что он был специально создан для этой платформы. Программирование C# позволяет в полной мере использовать концепции, методы и паттерны объектно-ориентированной разработки. Язык Visual Basic 8.0 наделен почти теми же возможностями. Чтобы научиться ASP.NET, вам нужно знать основы HTML, а знание asp не обязательно. Оно может даже помешать, так как придется менять образ мышления. Также для понимания многих желательно знать CSS и JavaScript.

Процесс инсталляции

ASP .NET 2.0 можно установить на компьютерах с ОС Windows 2000 с Service Pack 4, Windows XP с Service Pack 2 и более поздними версиями Windows. Готовые сайты предпочтительно устанавливать на Windows Server 2003.

Для разработки приложения можно использовать любую среду разработки или даже текстовый редактор, при условии, что у вас есть доступ к IIS. Если же вы хотите воспользоваться всей мощью Microsoft .NET Framework и ASP.NET и при этом, затратить как можно меньше усилий, то нужно воспользоваться средой разработки, специально разработанной для программирования ASP.NET 2.0.

Если вы приобретете Visual Studio .NET 2005, то для работы достаточно будет только его. .NET Framework содержится на дисках. В его состав входит Visual Web Developer, который позволяет создавать профессиональные веб-приложения, а также desktop-приложения на разных языках программирования. Продукты Microsoft выпускаются на DVD, но есть набор из двух CD от «Мегасофт». Visual Studio .NET 2005 требует около 2 Гигабайт дискового пространства. При этом инсталлируется ASP.NET 2.0, среда разработки, SQL Server Express, встроенный веб-сервер, Crystal Reports со специальными элементами управления для ASP.NET 2.0.
Бесплатно распространяемое программное обеспечение.

Visual Web Developer 2005 Express Edition – свободно распространяемая среда предназначенный для новичков и студентов, доступная по адресу http://msdn.microsoft.com/vstudio/express/vwd/. Список отличий VWD от Visual Studio.NET 2005 невелик и для начинающих несущественен, он приведен здесь: http://msdn.microsoft.com/vstudio/products/compare/default.aspx

Инсталлятор VWD имеет объем 2,8 Мб, но в процессе инсталляции он загрузит еще 40 Мб и 80 Мб, если захотите установить документацию. При этом также будет установлен .NET Framework с ASP.NET 2.0.

Системные требования – процессор с минимальной скоростью 600 МГц, 128 МБ памяти и 1.3 ГБ дискового пространства. После инсталляции нужно будет зарегистрировать свою установку, это совершенно бесплатно.

В качестве среды разработки вы можете выбрать WebMatrix. Эта программа совмещает в себе редактор и http-сервер. Ее можно загрузить на http://www.asp.net/WebMatrix.

У WebMatrix инсталлятор размером всего 1.2 Мб, но у него меньше возможностей, чем у VWD. Но, в общем, эти среды разработки похожи. У WebMatrix есть неприятная особенность – она дает запрос на сохранение во время закрытия файлов, которые не редактировались. VWD Express позволяет одним нажатием кнопки открыть Web-интерфейс конфигурирования проекта. В VWD работает технология IntelliSense, которая автоматически предлагает возможные в данном месте элементы кода.

Если вы решили работать с WebMatrix, вы должны установить на своей машине .NET Framework 2.0 и ASP.NET 2.0.

Если у вас операционная система Windows Server 2003, то .NET Framework уже предустановлен. Вы можете проверить, есть ли вас директория %WINSDIR%Microsoft.NETFramework. Если нет, вы можете ее загрузить на сайте Microsoft. Последние версии находятся по адресу http://msdn.microsoft.com/netframework/downloads/updates

На данный момент это .NET Framework 2.0, но к моменту, когда вы будете читать эту лекцию, могут появиться более новые версии. Вы можете скачать новую версию, даже если у вас уже есть другая. Они будут существовать на компьютере одновременно в поддиректориях %WINSDIR%Microsoft.NETFramework, с именем, соответствующим номеру версии. Можно сказать, что каждая версия представляет собой сборку. Система версий поддерживается для всех приложений, созданных с использованием .NET Framework.

Там вы увидите ссылки на .NET Framework для разных архитектур компьютера.

При желании загрузите .NET Framework Version 2.0 SDK, которая содержит наряду с .NET Framework Version 2.0 SDK документацию и примеры, которые могут оказаться полезными.

По адресу http://asp.net/default.aspx можно найти много полезных для разработчиков программных продуктов, примеров кода и статей.

IIS(Internet Information Server) находится на инсталляционном диске Windows 2000/XP, но предустановлен только на серверах. Его можно установить, зайдя в Control Panel->Add or Remove Programs->Add/Remove Windows Components. Компьютер попросит вас вставить инсталляционный диск.

IIS может понадобиться, если вам нужен полноценный сервер для работы в интернет, а не просто на своем компьютере или в локальной сети или вы решили набирать текст в обычном редакторе. Для работы на своем компьютере во все эти среды разработки встроен сервер Cassini, который первоначально появился как часть WebMatrix. Символ WebMatrix – планета Сатурн, а Кассини — известный исследователь Сатурна. Предыдущие версии Visual Studio требовали наличия IIS, но теперь Cassini встроен и в Visual Studio 2005, что позволяет работать даже в Windows XP Home Edition.

Примеры будут даваться как для WebMatrix, так и Visual Studio. Некоторые примеры требуют VWD Express или Visual Studio.
Сообщества разработчиков.

Через меню помощи Visual Web Developer Express можно зайти на сайты форума по ASP.NET. А вот адреса сайтов на русском языке:

* http://www.aspnetmania.com
* http://www.gotdotnet.ru/
* http://www.sql.ru/
* http://dotsite.ru/
* http://www.rsdn.ru/

Вы можете завести пробный хостинг на http://europe.webmatrixhosting.net/russia/default.aspx.

Первый проект

Вначале решите, в какой директории будете создавать страницы. Все файлы, находящиеся в одной директории, считаются единым проектом.Запустите выбранную вами среду разработки. Выберите пункт меню File-New-Website. Появится диалоговое окно. Назначьте в нем имя проекта и выберите язык программирования С#.

По умолчанию проект создается в файловой системе. По желанию его можно создать на HTTP или FTP-сервере. Из файловой системы проект всегда можно скопировать на сервер нажатием одной кнопки в заголовке Solution Explorer.

В проекте будет создана страница default.aspx. Выберите ее, и появится окно редактирования с закладками Design и Source. Не меняя ничего, щелкните на кнопке со стрелкой, чтобы просмотреть страницу в браузере. Появится окно, котором спрашивается, нужно ли добавить в файл web.config возможность отладки. Нажмите OK. На панели задач должен появиться значок веб-сервера. Откроется браузер, показывающий страницу по адресу http://localhost:номерпорта/Website1/default.aspx. localhost обозначает сервер, работающий на вашем компьютере. Встроенный сервер Cassini сам назначает себе номер порта – для каждого проекта он разный. Сервер IIS обычно работает через порт 80(или 8080, если тот занят), и для него номер порта указывать не нужно. При этом ваша страница будет скомпилирована.

Пока что страница в бразере пустая.

Но исходный код этой страницы не пустой. Программа сгенерировала код для вас.

Active Server Pages

Active Server Pages

3.0 (no further versions planned)

Тип
Последняя версия

Active Server Pages

ASP (англ. Active Server Pages — «активные серверные страницы») — технология, предложенная компанией Microsoft в 1996 году для создания Web-приложений. Эта технология основана на внедрении в обыкновенные веб-страницы специальных элементов управления, допускающих программное управление.

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

Для реализации приложений ASP используются языки сценариев (VBScript или JScript). Также допускается применение COM-компонентов.

Технология ASP разработана для операционных систем из семейства Windows NT и функционирует под управлением веб-сервера Microsoft IIS.

Технология ASP получила своё развитие в виде ASP.NET — технологии создания веб-приложений, основанной уже на платформе Microsoft .NET.

Содержание

Синтаксис [ править ]

Страница на ASP — это обычная страница HTML, со вставками, обозначенными ограничителями и %> :

То что находится внутри ограничителей — это текст программы, интерпретируемый при запросе страницы. VBScript является языком по умолчанию, хотя возможно использование и JScript [источник не указан 2893 дня] (или любого другого языка, если установлен соответствующий интерпретатор):

Версии [ править ]

ASP в своём развитии прошёл через несколько версий:

ASP 1.0 (распространяется с IIS 3.0) в декабре 1996 года.
ASP 2.0 (распространяется с IIS 4.0) в сентябре 1997 года.
ASP 3.0 (распространяется с IIS 5.0) в ноябре 2000 года.

Apache::ASP [ править ]

Apache::ASP (англ.) предоставляет функциональность ASP на основе веб-сервера Apache, со скриптами на основе Perl.

ASP в Sambar Server [ править ]

Сервер Sambar Server имеет собственную реализацию ASP, которая использует язык CScript в качестве языка программных вставок. [1]

Примерные аналоги [ править ]

mod_php и mod_perl

Достоинства и недостатки [ править ]

Возможно, этот раздел содержит оригинальное исследование.

Язык VBScript, обычно используемый в ASP, имеет менее удобный синтаксис чем другие языки, например язык PHP. JScript лишен этого недостатка, но имеет другой, более серьёзный — неприятную обработку типов данных OLE Automation, что приводит к скрытым, трудным в обнаружении ошибкам.

Однако ASP может использовать очень хороший набор классов для работы с SQL базами данных — ADO, который примерно аналогичен Perl DBI и куда лучше, чем вызовы mysql_xxx в PHP.

Производительность интерпретатора VBScript значительно выше, чем PHP.

Кроме того, ASP поддерживает объекты Session и Application, с которыми в PHP/Apache традиционно есть огромные сложности, связанные с архитектурой процессов Apache 1.x (а она восходит к нелюбви к потокам в мире UNIX и использованию fork() вместо них везде, где возможно).

Тем не менее, объект Session ныне считается с трудом удовлетворяющим требованиям безопасности, и зачастую вместо него все его содержимое помещают в один огромный cookie, и передают туда-обратно между клиентом и сервером. Такое легко реализуемо в PHP, этим пользуются, например, phpBB и его коммерческий дериватив vBulletin