Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:JAVA. Серверные приложения
.pdf
Часть 1. Электронная коммерция 81
Уровень данных — на этом уровне содержатся данные в базах данных, внешних файловых системах и других носителях. Уровень данных
может находиться в любом месте и обычно доступ к нему осуществляется непосредственно через средний уровень.
Обычно первый уровень — это Web-браузер, такой, как Internet Explorer, или Netscape Navigator, или любой другой. Второй, или средний,
уровень традиционно включает Web-сервер (http-сервер), а также может включать сервер приложений (Application Server), например WEBSphere Application Server. Последующие звенья или уровни могут включать в себя внешние источники данных, такие, как корпоративные базы
данных, транзакционные серверы и т. д., такие, как СУБД DB2 или CISC.
После выбора сценария и распределения ролей устанавливается топология выполнения приложения.
Приложение, использующие топологию 1, является отправной точкой создания любого e-commerсe приложения. В значительной мере
развитию данной топологии способствовала хорошо продуманная топология выполнения приложения. В топологии выполнения приложения
указываются различные группы компонентов, сгруппированных для решения различных задач по определенному принципу.
Используя графические формы, проектировщик описывает взаимодействие компонентов системы на физическом уровне. Каждая топология выполнения может содержать несколько различных компонентов
физической сущности, но одинаковых по логической. Это касается базы
данных, кластеризации Application-серверов и т. д.
Узел Application Server физически может располагаться как на одной
машине с одним DNS, так и на нескольких компьютерах. Application Server имеет встроенный Web-сервер, предназначенный для обработки httpзапросов клиента. Данные, содержащиеся на этом уровне, предназначены
для описания бизнес-логики и UI-логики. В данном узле описываются
следующие ресурсы: HTML-страницы, изображения, мультимедиакомпоненты, скачиваемые клиентом. Далее располагаются JSP-страницы,
приложения и апплеты, передаваемые клиенту по мере надобности.
Затем описывается узел DNS, предназначенный для физической ассоциации системы с сетевым адресом. Здесь описываются все URL,
принадлежащие данному сетевому адресу.
Пользовательский узел содержит описание клиента. Клиентом могут
являться различные устройства. Появившиеся с развитием сотовых
технологий, обычно это представляет ручные компьютеры и сотовые телефоны, на один уровень выше стоят Web-браузеры, Java-клиенты.
Основной этап разработки e-commerce приложений пока затрагивает
только первый уровень, но недалек день использования передовых Java-технологий для нулевого уровня, все пока зависит только от разработчиков аппаратного обеспечения и принятия единых стандартов передачи и отображения данных. Отсутствие таковых ставит разработчика
перед сложной задачей реализации единого приложения, имеющего
возможность работать с разными клиентами разных уровней.
Узел, обеспечивающий секретность и идентификацию клиентских
транзакций.
82 Часть 1. Электронная коммерция
На данном узле содержатся компоненты, отвечающие за безопасность данных, используя различные способы сертификации организации доступа к хранилищам.
Узел хранилища данных предназначен для хранения постоянных данных, используемых клиентом, в данном случае не только системных, но и
бизнес-данных. Основным занятием этого узла, кроме непосредственного
хранения, является определение видов доступа к ресурсам базы данных.
В отличие от узла безопасности, узел внешней безопасности отвечает за организацию доступа из внешних источников. Это первый уровень
идентификации пользователя. В этом узле описываются используемые
протоколы firewalls. Традиционно firewalls используются как внешние
барьеры, обеспечивающие безопасный доступ к узлу DNS.
Диспетчер запросов предназначен для организации оптимального трафика, используется при кластеризации и в распределенных системах.
Узел внешнего кэша содержит часто используемые данные.
Узел перенаправления запроса необходим в случае сбоя системы целиком. Используются различные методы перенаправления запроса, от
простого HTML «извинения» до незаметного для пользовательского запроса перенаправления в дублирующую систему.
Все эти узлы в терминологии Java представляют собой пакеты классов. Большая часть проблем уже решена в самом Application Server и
используемой базе данных. За проектировщиком остается выбор необходимых компонентов.
На логическом уровне выполнения эта топология должна обеспечивать
синхронное взаимодействие всех компонентов в момент взаимодействия с
клиентом и асинхронную обработку совместно используемых ресурсов.
Среднестатистический сценарий покупки в Web-магазине выглядит
следующим образом:
1. Запрос поступает из Web-браузера клиента, покупатель взаимодействует с продавцом при помощи коммерческого сайта продавца. На
данном этапе клиент регистрируется в системе, и данные о регистрации
сервер заносит в базу. Далее сервер осуществляет проверку вновь зарегистрированного пользователя и производит либо операцию дальнейшей регистрации, либо отказ пользователю в регистрации. Без регистрации у пользователя есть возможность работать в ограниченном режиме. Благодаря идентификационным параметрам, паролю, логину,
присвоенному значению ID, а также части системной информации (номер порта, используемый протокол передачи, mail) и т. д., о пользователе получают первичную информацию. Благодаря первичной информации можно выяснить, сколько раз посещал данный клиент Web-магазин
и чем больше всего интересовался или не интересовался.
2. После регистрации пользователь перенаправляется сервером на
исходные страницы, сгенерированные в статические данные и динамические запросы. Проходя первый этап регистрации пользователя в системе и получения первичной информации, клиент вступает в стадию
оформления заказа, на сервере ведется работа по генерации предложений, основанная на первичной информации и бизнес-данных.
3. Осуществляется выбор понравившегося товара. Сервер сохраняет
данные о пользовательской сессии в базе данных и генерирует cookies
Часть 1. Электронная коммерция 83
для отправки клиенту. Подробнее о cookies можно узнать из главы, описывающей создание servlet.
4. После окончательного выбора товара или, наоборот, отказа от товара сервер пересылает заказ, даже в отсутствие такового, в бизнес-базу данных для дальнейшей обработки. Зачем обрабатывать заказ, от которого отказались? Для того, чтобы в дальнейшем пользователь получил именно то, что искал.
5. Сервер, используя одну из возможных технологий JMS, JTS или
EJB, перенаправляет заказ на соответствующий уровень обработки, на
сервер службы доставки, на склад и т.д.
На этом клиентская часть заканчивается, дальше наступает время
работы только сервера.
Работа сервера связана в основном с обновлением бизнес-данных и
данных о клиенте.
О сервере как об основном звене будущего приложения необходимо
упомянуть отдельно.
Первая задача стоит за выбором программных продуктов используемых сервером. Проблемой большинства проектировщиков остается полное незнание используемых программных продуктов. Архитектор системы знает только о функциональных возможностях, не вдаваясь в детали. После быстрого ознакомления архитектор приступает
непосредственно к проектированию, основываясь на знании старых версий или интуиции. А потом получается так, что прекрасно работавшее
приложение на одой платформе вдруг начинает вести себя очень странно на другой подобной платформе.
Создавать независимое приложение или строго ориентированное на
одну платформу — это решение остается за проектировщиком. Тем более разговор можно вести только о действительно подобных системах.
Сравнивать Windows-системы с UNIX-клонами бесполезно, для каждой
используются свои собственные решения.
Первый выбор, стоящий перед архитектором, — это выбор платформы, на которой будет работать e-commerсe приложение. Выбор платформы основывается на следующих критериях:
— Доступность как самой платформы, так и специалистов по обслуживанию этой платформы.
— Необходимо учитывать специальные требования заказчика по использованию платформы.
— Web-клиенты должны получить доступ к ресурсам, размещенным
на данной платформе.
Как самую распространенную можно рассмотреть ситуацию с использованием операционной системы Windows NT, соответствующих программных продуктов фирмы IBM.
В самом простом случае необходимо использование двух копий операционной системы, используется трехуровневая Web-архитектура.
Первая копия размещается на сервере данных, другая на сервере, впоследствии превращенного в Web-сервер.
Выбор операционной системы и базы данных — главная, но не основная задача. Для прекрасной работы e-commerсe приложения требуется
прекрасная работа всех компонентов системы. Говоря о выборе програм-
84 Часть 1. Электронная коммерция
много обеспечения, нельзя не упомянуть о выборе виртуальной машины
Java. Например, для платформ Windows версия JVM 1.1.7 фирмы IBM
оказалась значительно быстрее родной машины компании SUN версии
1.2. А на платформах самой IBM говорить о сравнении просто бесполезно. Также не бесполезно будет узнать, каким JIT-компилятором оснащен Web-сервер, реализующий созданное приложение. Другим важным
компонентом является EJB-контейнер, если в приложении предполагается использовать EJB. Java является потоковым языком, и большинство серверных компонентов многопоточные, использование многопроцессорных систем значительно ускоряет работу JVM. Некоторые операционные системы предоставляют свои потоки для использования JVM.
На сервере данных используется СУБД DB2 компании IBM. Практически кроме СУБД на данном сервере можно разместить дополнительные компоненты, обеспечивающие дублирование, копирование, кэширование и прочие операции обработки данных. На основном сервере, базирующемся на другой копии Windows NT, используются WEBSphere
Application Server, IBM http-сервер, IBM JDK и диспетчер запросов
Network Dispatcher, IBM SecureWay Firewall. При использовании прокси-сервера, последние два продукта можно перенести на отдельную
машину. Использование одноуровневой архитектуры в данном случае не
оправданно, даже если используется многопроцессорная система, слишком много операций производится по системной шине для базы данных и
слишком медлительны встроенные компоненты. Вообще очень удивительная ситуация складывается с взаимодействием программного «железного» обеспечения. Заказчик, не жалеющий денег на дизайн, начинает «мяться» при необходимости использовать более совершенное железо.
Говоря о быстродействии базы данных, подразумевается правильно
составленный запрос, в то время как использование flash-диска увеличивает производительность всей системы в целом, скорость особенно актуальна в Web-приложениях, работающих с мультимедиаданными. И каким
бы оригинальным ни был запрос, обеспечить доступ со скоростью 500 Мб
в секунду на стандартном оборудовании у запроса вряд ли получится,
тем более что память в последнее время не так уж дорога. Именно использование flash-дисков, а не громадного количества ram оправданно при
использовании Windows NT как основной операционной системы. Алгоритм работы с памятью у Windows NT достаточно своеобразен — информация сбрасывается в файл подкачки, что влечет за собой увеличение
тактов процессора для каждой операции чтения /записи.
Самым медленным программным компонентом можно назвать базу
данных. Большое количество SQL запросов, часто используемые данные
о продуктах и клиентах, разные блокировки значительно снижают производительность всей базы данных. А такие тяжеловесные компоненты,
как мультимедиа, загружают всю систему целиком. Выбор базы данных
не столько необходим, сколько важен. По отношению к остальным базам
данных DB2 фирмы IBM изначально создавалась как база данных для
клиент-серверных приложений. Прекрасная способность к кластеризации добавляет еще один полюс использования DB2 в качестве источника
данных на Web-серверах. DB2 обеспечивает работу различных таблиц
одной базы данных на различных физических машинах, а что еще надо
Часть 1. Электронная коммерция 85
Web-приложению? Специальные расширители (extenders), поставляемые в версии 6.1 и выше, облегчают обработку больших объемов данных.
Одной из рекомендаций по повышению производительно всей системы в целом является использование трехуровневой топологии.
Все это длинная история, предваряющая разговор об используемой
Web-архитектуре.
Одноуровневая архитектура не требует детального рассмотрения,
поскольку используется в основном создателями приложения.
Двухуровневая архитектура.
Один Web-сервер, один сервер данных. Обычно оба сервера находятся в одном сегменте сети. С точки зрения «железа» два компьютера, соединенных локальной сетью. Трехуровневая архитектура определяет
дополнительные компоненты, используются при создании больших сайтов. В отличие от двухуровневой архитектуры, несколько Web-серверов
обслуживают один сервер данных, сеть может несколько сегментов. Выбор данной архитектуры обычно íå ограничивается технологией
WINTEL, а используется более мощное «железо» и программное обеспечение, такое, как AS/400 фирмы IBM.
Вообще о производительности системы в целом относительно e-commerсe приложения можно судить по специальному параметру.
Отношение количества запросов к количеству проведенных транзакций, прекрасный параметр, указывающий пробелы в созданном приложении. В повседневной жизни это отношение лежит в пределах 95\5,
что считается хорошим показателем. Все остальное требует детального
рассмотрения.
Желательно весь мыслительный процесс начать именно до начала
набора программистов, реализующих грандиозные планы системного
архитектора. Если же с архитектором совсем плохо и не последнюю
роль играет меркантильный интерес, то лучше сразу приобрести готовое решение. Позже можно представлять заказчику данное решение
как сделанное собственными руками, но чуть переработанное ребятами
из IBM, у вас с ними дружеские отношения.
Сводя воедино все вышесказанное, можно обрисовать картину создания типичного e-commerсe приложения. От выбора Web-архитектуры
до конечного создания приложения проект проходит несколько этапов:
1. Дизайн основного Web-приложения. Когда приложение представляет собой просто один файл, говорить о построении компонентов бессмысленно. Нормальное приложение использует большое количество
разнородных сервисов и рабочих модулей. Приложение содержит методы, описывающие взаимодействие между клиентом и сервером, часть
методов предназначена для решения системных задач, другая часть
бизнес-методы. На данном этапе описываются все компоненты системы.
Описывается, какие клиенты будут использовать данное приложение,
какие сервисы будут обслуживать запросы клиентов на сервере, какие
ресурсы будут затребованы для выполнения запросов клиентов.
2. Построение компонентов приложения. Проектирование основной
структуры e-commerсe распределяет роли между ресурсами. Используют классическую систему MVC. Компоненты, описанные на первом этапе, теперь распределяются по ролям.
86 Часть 1. Электронная коммерция
3. Описание структуры приложения. Описание рабочей логики приложения, бизнес-методы. Рабочая логика приложения содержит методы, описывающие отношение компонентов. Коммерческая сторона приложения состоит из описания бизнес-данных и методов по работе с указанными данными.
4. Определение роли контроллера. Описываются приложения, выполняющие роль контроллера. В большинстве случае именно servlet выполняет данную роль. Контроллер описывает реакцию системы на действия
пользователя.
5. Описание UI и отображаемые данные. Существует два типа данных, отображаемых в стандартной HTML-странице. Размещение графических компонентов и внешний вид данных, а также определение типа
данных описываются на данном этапе.
6. Создание системных управляющих компонентов пользовательской
сессией. На данном этапе проектируются элементы управления httpсессией при помощи различных данных клиентской сессии, cookie и т. д.
7. Безопасность системы. Описывает различные способы обеспечения
секретности выполняемых действий, аутентификация, регистрация пользователя, сертификация и прочие операции обеспечения безопасности. Авторизация и аутентификация (идентификация) пользователя,
два основных метода обеспечения безопасности.
8. Используемые модели e-commerсe приложения. В зависимости от
решения e-commerсe приложение может строиться на различных отношениях между клиентом и поставщиком. На заключительном этапе моделируются различные бизнес-ситуации и то, как система реагирует на
различные сценарии действий клиента.
Вся созданная система представляется в виде Web-компонентов,
большая часть которых скрыта от клиента. На рис. 1.11 изображена
стандартная модель сайта торговой площадки.
•
Welcome — основная страница, встречающая пользователя;
•
Catalog — страница, содержащая перечень товаров и услуг;
•
Logon — страница для подключения уже существующего пользователя;
•
Register — регистрация нового пользователя;
•
Address book — пользовательская адресная книга;
•
Search — организация поиска;
•
Interest list — дополнительные ссылки и предложения по добавлению продуктов в пользовательскую корзину;
•
Order status — страница, возвращаемая пользователю. Подтверждает транзакцию;
•
Customer service — сервис для пользователя.
Первая страница является, с одной стороны, визитной карточкой
компании, с другой — главным входом в «сокровищницу». На данной
странице практически отсутствует бизнес-логика, и клиент получает
доступ к другим ресурсам, используя обычные ссылки (якоря). Но благодаря этой странице можно получить первичную информацию как о
самом клиенте, так и о некоторых системных ресурсах клиента. В дальнейшем данная информация может помочь избавиться от ненужного
дублирования опроса клиента по поводу используемых ресурсов.
Часть 1. Электронная коммерция 87
Рис. 1.11. Структура Web-приложения
По логике распространенных приложений следующая страница
предлагает пользователю зарегистрироваться. Здесь включается первое
обращение к базе данных. Клиентский запрос поступает на servlet, проводящий проверку самостоятельно либо при помощи EJB. В результате
servlet либо самостоятельно, либо используя JSP извещает посетителя
о результатах проверки.
В зависимости от данных первичной регистрации, если клиент впервые попал на сайт, ему предлагают пройти процесс регистрации. Если
он уже зарегистрированный пользователь, то автоматически переходит
на основную страницу — каталог. Каталог содержит информацию о
продуктах, продаваемых компанией. Доступ к каталогу можно обеспечить непосредственно из EJB, но, придерживаясь политики MVC, опять
же запрос перенаправляется в servlet, будет это один и тот же или разные servlet, все зависит от проектировщика. Посмотрев и убедившись,
посетитель выбирает продукт, используя interest list. На данной странице реализован механизм хранения некоторого множества объектов. Надеемся, что посетитель купит не один продукт. Здесь обязательно следует использовать пару servlet — EJB, поскольку клиент вызывает частичное обновление данных. Поиск можно организовывать либо с
помощью JSP, либо с помощью servlet. Работа других страниц полностью зависит о логики приложения.
Для представления всех страниц и определяется роль e-commerсe
приложения. Существует множество различных решений, основанных
на разных технологиях. В дальнейшем будет рассмотрено использование Java-объектов для создания e-commerсe приложения. В этом обзоре опущены конкретные реализации алгоритмов поиска, схемы таблиц
базы данных, методы табличных отображений данных в презентационной графике.
ЧАСТЬ 2 JAVA SERVER PAGE
Распространение HTML в Web-приложениях полностью выработало
ресурс статических тегов, применяемых для формирования и передачи
документа через Интернет. Генерируемые HTML-страницы, формируемые в момент клиентского запроса и содержащие динамические данные, полностью заменили статические элементы разметки, предоставляемые HTML. Множество компаний предложили свои решения по
оживлению HTML-страниц. Свободно распространяемый PHP, Cold Fusion фирмы Allaire, и ASP компании Microsoft — вот далеко не полный
список технологий, предлагающих создание динамического контекста в
Web-страницах. Наиболее распространенной технологией, в силу специфики маркетинговых решений, можно назвать Active Server Page
(ASP) — технологию динамических страниц, основанную на языке программирования Visual Basic компании Microsoft. Но данная технология
имеет один большой недостаток или огромный плюс по сравнению с
другими (мнение самой компании Microsoft) — ASP работает только на
платформах самого создателя т. е. в операционной системе Windows и
Web-сервере Интернет Information Server (IIS).
Рождение платформонезависимого языка Java привело компанию
SUN к решению создания своего представления HTML-страниц. Скрещивание Java и HTML в одном приложении способствовало созданию
серверной технологии генерации динамических страниц.
Java Server Page (JSP) — серверная технология, позволяющая встраивать и использовать Java-код в статических Web-страницах, с исполнением кода в момент обращения к данной странице. Одной из отличительных особенностей JSP является возможность совмещения на одной
странице бизнес-логики приложения и графических элементов пользовательского интерфейса. JSP могут создавать как программисты, так и
Web-дизайнеры. На данном этапе Java превращается из компилируемого языка в скриптовый, это превращение позволяет создавать динамические страницы без создания приложений и использования апплетов. Как
и все Java-решения, JSP допускает использование других Java-объектов, таких, как приложения, апплеты, сервлеты, бобы (JavaBean) и EJB.
Как и обычная Web-страница, JSP представляет собой набор специфических тегов плюс дополнительные синтаксические конструкции,
определяемые встроенным скриптовым языком. Самыми распространенными скриптовыми языками для использования в Web-страницах
по-прежнему остаются JavaScript и VBScript. Основная их черта в том,
что они выполняются на клиентской стороне без какой-либо компиля-
Часть 2 Java Server Page 89
ции со стороны программиста, создавшего данную страницу. Хотя уже
существуют версии JavaScript для исполнения на серверной части, до
сих пор JavaScript использовался на стороне клиентского приложения.
И хотя в названии JavaScript присутствует слово Java, практически ничего общего с данным языком программирования JavaScript не имеет,
являясь в большей степени независимым языком программирования.
В JSP скриптовым языком является Java. JSP является серверным
ресурсом. Для обработки встроенных конструкций требуется специальный обработчик — jsp-engine. Данный обработчик поставляется сторонними поставщиками или является неотъемлемой частью Web-сервера
или сервера приложений. Web Shpere Application Server (WAS), компании IBM имеет встроенный обработчик JSP-страниц, поддерживающий
все существующие версии JSP, 0.91 и выше.
Поскольку JSP является расширением Java, то одной из причин использования JSP являются платформонезависимость Java виртуальных
машин. Другая причина — поддержка широко распространенного языка
программирования Java и использование HTML-тегов в Web-приложениях. Основная особенность JSP — возможность легко встраивать JavaBeans и исполняемый Java-код в JSP.
JSP теги встраиваются в обычный HTML-файл. Совместное использование стандартных HTML-тегов, скриптов и тегов JSP позволяет решить проблему создания действительно динамических страниц.
Возможность использования Java в JSP позволяет выбирать наиболее
мощное и быстрое решение, а количество библиотек Java API делает эту
возможность просто уникальной. Также плюсом можно считать способы
оптимизации Java-кода, также применимые и для оптимизации JSP.
Существует несколько основных версий JSP. Первая имела номер
0.91 и была реализована в ранних версиях WEBSphere Apllication Server
и SUN JavaWebServer. На настоящий момент основной версией считается 1.1, к тому же компания IBM, как, впрочем, и другие поставщики программного обеспечения, предлагает собственные теги расширения JSP
для существующих версии 0.91 и версии 1.1 На настоящий момент все
последние версии продуктов IBM семейства Web Sphere и VisualAge for
Java, начиная с 3.02, поддерживают JSP всех стандартных версий.
JSP распространяется в виде специального расширения поставляемым компанией SUN в дополнительном наборе пакетов для приложений
уровня предприятия — Enterprise Extension, платформа J2EE.
Основным источником информации по использованию JSP и появлению новых версий можно найти на официальном сайте компании SUN:
http://www.java.sun.com/products/jsp/index.html, новые спецификации
на JSP можно получить по адресу: http://www.java.sun.com/products/jsp/index.html
Глава 7. Основные Java-классы по созданию и обработке JSP
Классы по работе JSP можно формально разделить на несколько типов. Первые нужны для организации работы JSP в среде сервера, другие отвечают за трансляцию, и, наконец, последние предназначены для
создания JSP-элементов — тегов.
90 Часть 2 Java Server Page
Основные классы, необходимые для работы с JSP, помещены в jarархив, поставляемый либо отдельно для каждого сервера, либо в расширенной спецификации Java2 Enterprise Edition (J2EE). В пакете javax.servlet.jsp, являющемся частью набора API J2EE, имеются четыре
абстрактных класса, т. е. классов с не полностью описанными методами,
и два интерфейса, при помощи которых можно получить информацию
об исполняемой системе JSP. Для версии JSP 1.1 существует дополнительный пакет javax.servlet.tegext. по созданию и работе с пользовательским тегами. Сам транслятор страниц является обычным Java-приложением, находится в пакете com.sun jsp.copmiles или пакете, распространяемом вместе с Application Server, на котором выполняется
генерация страниц. Для трансляции созданного кода сервер вызывает
нужный класс jsp-транслятора, но при очень большой необходимости
можно вручную транслировать созданную JSP-страницу. Для этого
можно воспользоваться командной строкой: c:\>java com.sun.jsp.compiler.Main myJSPFile.jsp.
Ê сожалению, нельзя, просто указав â системной переменой
CLASSPATH необходимые классы, получить исполняемые JSP-страницы, для каждого сервера, будь то Web-сервер или Application Server,
необходимо произвести определенные настройки работы JSP –engine и
Java Virtual Machine (JVM). Для получения более точной информации
можно обратиться к документации на поставляемый сервер. Например,
WEBSphere Application Server фирмы IBM поставляется с уже оптимально настроенным jsp-engine и нет большой необходимости в настройке сервера для работы с JSP. В WEBSphere Application Server
существуют свои компиляторы для каждой версии JSP. Для работы с
версией 0.91 необходимо установить jar-архивы в системной переменной CLASSPATH: ibmwebas.jar,servlet.jar, а для применения версии
JSP 1.0 необходимо заменить файл ibmwebas.jar на новый архив
jsp10.jar. После этого можно воспользоваться транслятором JSP, разработанным фирмой IBM.
Для исполнения и компиляции созданного JSP-файла можно воспользоваться командной строкой: X:\>java com.ibm.servlet.jsp.http.pagecompile.jsp.tsx.batch.JspBatch myJSPFile.jsp для первых версий или для
версии JSP 1.0: X:\> java com.sun.jsp.runtime.JspServlet myJSPFile.jsp
В обоих случаях JSP-компилятор является Java-классом, поэтому и
вызывается при посредничестве JVM (первый аргумент командной
строки).
В большинстве случаев разработчику не потребуется самостоятельно
транслировать код исходной JSP-страницы. Поскольку специфика работы JSP несколько отличается от работы привычного приложения, необходимость вручную вызывать JSP-транслятор, отпадает за ненадобностью.
Если посмотреть на JSP-файл с точки зрения создателя Web-приложения, то можно увидеть текстовой файл, содержащий стандартный
HTML-теги, Java-код и теги самой JSP-страницы. Именование файла
не имеет большого значения, в отличие от «pure Java» приложений, но
расширение обязательно должно иметь трехбуквенное значение — JSP,
определяющие, что данный файл является JSP-страницей.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]