Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:JAVA. Серверные приложения
.pdf
Часть 1. Электронная коммерция 71
5.2. Проектирование топологии приложений
После окончательного выбора сценария e-commerсe необходимо
определить взаимоотношения между компонентами системы, клиентами, приложениями и данными. Выбор топологии взаимодействия влечет
за собой выбор управления системой. Топология приложения описывает
уровни приложения, фокусируется на логике и данных самого приложения. Взаимодействие между клиентом, данными и приложениями
проектируются в топологии приложений. Нельзя смешивать топологию
приложения e-commerсe с архитектурой Web-приложения. Топология
приложения описывается с помощью логических узлов, представляющих различные компоненты системы. Топология приложений показывает принципиальные уровни приложения, логику приложения и используемые данные. Здесь не отражается физическое разбиение компонентов по файлам, структуре базы данных и т. д. Топология приложения
работает с тремя уровнями представления информации:
обработчики деловой логики, логические представления контрол-
•
леров;
ключевые особенности топологии, описывает основные компоненты
•
приложения:
дополнительная информация, необходимая при проектировании e-
•
commerсe приложения.
Для e-commerсe приложений фирма IBM предложила несколько
различных типов топологий.
•
Топология 1.
Это самая распространенная топология Web-приложений.
•
Обычная система, в которой бизнес-логика размешена в базе данных в двухуровневой архитектуре Web-приложения. Такое решение имеет свои преимущества. Очень легко обслуживать данную
систему. Практически вся информация представлена клиенту в виде HTML-страниц. Бизнес-логика и данные работают в одном физическом пространстве. Использование единого физического пространства имеет свои недостатки в одних приложениях и достоинства в других приложениях. В будущем планируется интеграция
Web-приложений с системами управления предприятия. Благодаря первой топологии переход к другим типам топологий, уже использующих ERP-системы, такие, как Sun Francisco компании IBM,
будет достаточно прост без больших трудозатрат и капиталовложений.
•
Топология 2.
Очень похожа на начальную топологию, с разницей в том, что бизнес-логика находится на третьем уровне, а доступ к ней осуществляется через компоненты, находящиеся на втором уровне Web-приложения.
Это позволяет более гибко организовать доступ к бизнес-логике за счет
использования дублирующих элементов второго и третьего уровней.
В топологии 2 на третьем и на последующих уровнях, кроме базы данных могут располагаться ERP-системы или другие источники данных.
Организация доступа к различным источникам осуществляется на различных уровнях Web-приложения.
72 Часть 1. Электронная коммерция
Топология 3.
•
Предназначена для работы с «тонкими» клиентами, клиентами с минимальным набором программного обеспечения, такими, как
3270/5250/ASCII эмуляторами.
Топология 4.
•
Представляет специальных «тонких» клиентов, использующих системные ресурсы серверов.
Топология 5.
•
Предназначена для работы внутренних систем серверов. Описывает
взаимодействие разных серверов предприятия (многоуровневая Webархитектура) в ответ на запросы клиента.
Топология 6.
•
Похожа на вышеуказанную с одним отличием — приложение не использует механизм отслеживания запроса. Бизнес-запрос с одного
уровня разбивается на несколько частей, и каждая из вновь созданной
части посылается на обработку в другие уровни.
Топология 7.
•
Представляет дополнительную способность сервера сформировать
предварительный ответ на основе частичной информации из клиентского запроса, пока на основной запрос формируется ответ.
Топология 8.
•
Подобна седьмой топология, различие состоит в том, что клиентский
запрос посылается от различных машин.
5.3. Установка архитектуры выполнения
Как только была выбрана топология приложения, наступает черед
выбора топологии выполнения приложения. Здесь уже определяются
физические узлы, на которых основывается е-приложение. С помощью
узлов определяются все уровни Web-приложения.
•
Первый узел — интегрированный сервер, содержит данные, описывающие логику приложения, имеет монитор транзакций. Как
минимум интегрированный сервер используется на третьем уровне
Web-архитектуры как отправная точка для описания инфраструктуры приложения.
•
Следующий узел топологии — сервер приложений, включает в себя http-сервер по обработке http-запросов от клиентов. Web application server указывает, на каком Application Server сервере происходит обработка приложения.
•
Третий узел просто информационный, определяет специальное
имя Domain Name Service (DNS) — имя ресурса для использования в Интернете. Обычно этот узел локализует используемые ресурсы под одним именем. Очень важный узел, поскольку позволяет
не забыть об указании адресов расположения для распределенных
ресурсов.
•
Узел User предназначен для определения пользователя, имеющего
доступ к ресурсам сервера приложений по указанному DNS.
Часть 1. Электронная коммерция 73
Рис. 1.9. Основные логические узлы Web-приложения
За обеспечение безопасности отвечает еще один узел — безопас-
•
ности. Каждое приложение, особенно e-commerсe, должно обеспечиваться нормальным уровнем безопасности, узел безопасности
упоминается для организации доступа к ресурсам приложения.
Источником данных определяется узел сервер данных — описыва-
•
ет, какая и как база данных используется в создаваемом e-commerсe приложении. Данные, описанные в этом узле, являются в большей степени бизнес-данными, и их лучше не смешивать при
проектировании с системными данными.
Протокол внешней защиты описывается в узле firewall, предназ-
•
начен для описания протоколов, используемых для обеспечения
функции внешней защиты.
•
Дополнительные узлы обеспечивают более гибкое проектирование
e-commerсe приложения или в некоторых случаях являются требованием заказчика.
•
Узел диспетчеризации предназначен для кластерных и многоуровневых систем, обеспечивает равноценное распределение ресурсов
по обработке клиентских запросов. Совместно используемые ресурсы описываются с помощью узла Shared file system — совместно используемые файловые системы.
•
Последний узел самого приложения предназначен для указания
специфических свойств приложения, например, однопоточность в
одном из основных узлов.
На рис. 1.9 отражена вся физическая структура Web-приложения.
5.4. Выбор используемых программных продуктов
Для осуществления задуманного проекта выбираются конкретные
программные продукты и производители различных платформ. Колоссальное количество стандартов и технологий, с одной стороны, облегчает выбор компонентов, с другой — громадные проблемы ждут проектировщиков при совмещении существующих компонентов, создаваемых
приложений и будущих стандартов. Выбор программного обеспечения,
предназначен не только для выбора платформы выполнения e-commerсe приложения. Бизнес-аналитики частенько проектируют приложение
74 Часть 1. Электронная коммерция
независимо от используемых в дальнейшем программных продуктов.
Эта независимость от программных основ усложняет проект в несколько раз. Проектировщику кроме описания бизнес-правил приложения
приходится описывать дополнительные системные функции по управлению ресурсами, пользовательскими данными, обеспечению безопасности и т. д.
В большинстве случаев часть готовых решений уже поставляется в
программном обеспечении, используемом в e-commerсe приложении.
Кэширование данных, управление пользовательской сессией и обеспечение безопасности — практически все это уже имеется в Application
Server разных фирм. Поэтому выбор используемых программных продуктов выделен в отдельный этап проектирования. Важно не просто
выбрать операционную систему, Application Server и базу данных,
важно знать имеющиеся способности каждого используемого продукта,
а не опираться только на нужные в данный момент компоненты. Здесь
рождается ценовой вопрос, что дешевле: нанять специалиста по конкретному продукту или несколько программистов, способных «улучшить» систему. В любом Web-приложении существуют как минимум
два уровня безопасности. Первый обеспечивается самой операционной
системой и обычно не используется проектировщиками Web-приложений. Другой способ обеспечения безопасности, и не самый худший,
обеспечивается используемой базой данных, чаще всего опускается
при проектировании e-commerсe приложения. Хотя на настоящий момент любая операционная система и практически все базы данных
имеют достаточное количество модулей, обеспечивающих хороший
уровень безопасности. Но аналитики до сих пор предпочитают использовать для работы с данными несколько SQL-операторов (язык DML),
вкладывая всю информацию в BLOB, и развивать у программистов
любовь к массивам, хэш-таблицам, прочим множествам. Управление
всем созданным хозяйством ложится на плечи Application Server или
программистов, хотя в большинстве управление системным ресурсами
является основным механизмом любого сервера, с чем он прекрасно и
справляется.
Затем по оптимальному выбору для выбранного программного обеспечения компонуется «железное» обеспечение.
5.5. Обучение использованию приложений
Одним из основных этапов выделено обучение пользователей работе
с e-commerсe приложением. Вот здесь и вступает в силу описание пользовательского интерфейса и логики в одном лице. Стремление сделать
сайт красивым и «загруженным» различными добавочными компонентами сильно усложняет понимание пользователем работы приложения.
Во-первых, красота отвлекает, во-вторых, графический интерфейс здорово усложняет не только разработку, но и поддержку приложения. Втретьих, при создании приложения могут быть задействованы различные команды специалистов. При этом нет уверенности, что обе команды
понимают друг друга, а это значит, что каждая видит мир по-своему,
Часть 1. Электронная коммерция 75
кроме того, обе команды должны использовать одни инструменты или
по крайней мере одни стандарты, иначе неизбежны лишние нервы,
лишние строки кода, лишние затраты. Среди тысяч пользователей уже
отсутствует такое понятие, как BIOS. Конечные пользователи знают,
для того чтобы начать работать, надо просто опуститься в левый нижний угол экрана. Хотя еще существуют приверженцы командной строки, лучше все-таки обучать на повседневных примерах, чем на редких
представлениях. Обучение проводится быстрее, если пользователь уже
имеет какой-нибудь навык в данной области. Использование комбинации «быстрых клавиш» упрощает работу пользователя с приложением,
а в дальнейшем работа с приложением может принести даже удовлетворение. Во-вторых, не все бизнес-правила должны знать конечные пользователи, но, с другой стороны, пользователю необходимо правильно
выполнять именно свою пользовательскую роль. Опять же все это решается с помощью обучения. Совершенно неважно, как организовано
обучение — в виде всплывающей help-страницы или отдельной конференции на Гавайских островах. Важно иметь в виду данный этап проектирования e-commerсe приложения, ни одно приложение, тем более с
участием человеческого фактора, нельзя использовать без предварительного обучения. К сожалению, большинство крупных компаний частенько при выпуске новой версии программы забывают о привычках пользователей, которые сами и привили в первых версиях. Речь идет не
столько о затратах на обучение, сколько о создании интуитивно понятного интерфейса. Если пользователь привык выполнять операции
Ctrl+C и Ctrl+V, то незачем предоставлять ему другую комбинацию.
Так же говорить о пользовательском интерфейсе можно в зеркале
исполняемого кода. Приложение должно быть спроектировано так, чтобы у пользователя было минимальное количество выполняемых действий и только необходимая информация.
E-commerce приложение логически делится на две части: бизнес-логику и системные данные, необходимые для выполнения работы системы в целом. Существует несколько стилей реализации бизнес-логики,
это могут быть Enterprice JavaBean, приложения, использующие API
JDBC, организующие доступ к базе данных, файлы, находящиеся в сервере. Каждый из этих стилей имеет собственные модели обработки бизнес-логики.
5.6. Бизнес логика
Бизнес-логика, в широком смысле, является набором руководящих
принципов выполнения деловых правил, принятых на определенном
предприятии. Описание бизнес-логики, используемой на предприятии,
позволяет бизнес-аналитику сконцентрироваться непосредственно на
ключевых этапах проектирования будущего приложения. Анализируя
бизнес-логику, разработчик разбивает весь бизнес-процесс на несколько элементарных цепочек взаимодействия. Бизнес-объекты или элементы описывают весь бизнес-процесс как единую систему тесных взаимоотношений. Бизнес-аналитик решает деловые задачи, связанные тем,
76 Часть 1. Электронная коммерция
как бизнес-объекты взаимодействуют между собой. Указание специфических бизнес-правил описывает поведение и связи бизнес-объектов.
Вся структура, описывающая бизнес-процесс, бизнес-объекты и бизнессвязи, в общем случае называется бизнес-логикой.
Структуру и поведение бизнес-объекта можно определить из требований, предъявляемых для решения бизнес-задачи.
В конечном счете бизнес-логика предназначена для удовлетворения
клиентского запроса.
В реальности вопрос целостности данных часто бывает связан с
внутренними порядками в той или иной фирме. К примеру, в компаниях, занимающихся розничной продажей, часто встречаются следующие
деловые правила:
Каждый клиент имеет только один финансовый идентификатор,
•
счет.
Каждый финансовый счет предприятия имеет собственные иден-
•
тификаторы, описывающие владельца счета., например телефон
или адрес.
Клиенты должны иметь возможность создавать финансовые счета.
•
Клиенты должны иметь возможность изменять информацию о
•
себе.
Клиенты должны обновлять и заменять только информацию о са-
•
мих себе.
Информация о клиенте обязательно должна храниться, а не гене-
•
рироваться.
•
Для организации можно описать другие правила. Например, количество счетов, обрабатываемых по одному товару единовременно.
•
Ценовая ответственность при различных продажах определяет
конкретное лицо, ответственное за сумму, превышающую лимит.
Распределение обработки заказов и т. д.
•
Клиент имеет несколько ограничений. Во-первых, клиент не может
разместить заказ на сумму, превышающую лимит кредита или по
данному продукту, или по данному клиенту. Во-вторых, о сумме,
превышающую кредит, должно быть извещено ответственное лицо.
Ели клиент является постоянным, то используются дополнительные поощрения крупных заказов и т. д. и т. д.
Из вышесказанного можно сделать несколько очень важных выводов.
Минимум создается три бизнес-объекта: клиент, счет, ответственное
лицо за обработку клиентских счетов. Поведение каждого представленного бизнес-объекта описывается с помощью бизнес-методов. У каждого
бизнес-объекта описываются свойства. Взаимоотношения между представленными бизнес-объектами описываются конкретно для каждого
предприятия отдельно.
Бизнес-логика обеспечивает процесс создания бизнес-данных в пользовательской форме. HTML-страницы, представленные пользователю с
генерированным сервером, есть результат работы бизнес-логики. Бизнес-логика в Java-приложениях описывается через соответствующие
компоненты:
•
Java Servlets
Часть 1. Электронная коммерция 77
JavaBeans
•
Enterprise JavaBeans (EJB)
•
JDBC
•
CORBA
•
LDAP
•
К сожалению, в большинстве случаев обработкой деловой логики занимается бизнес-приложение, что влечет за собой определенные трудности реализации.
В приложениях труднее, чем, в СУБД, контролировать действие
•
нескольких запросов к одному ресурсу, одной таблице. Соблюдение
бизнес-правил значительно усложняется при количестве одновременных запросов.
Во-вторых, нестандартное решение, пусть и лучшее, допускаемое
•
некоторыми создателями приложений, может исказить данные по
собственному усмотрению. SQL стандартизирован, и проблем конструирования запросов не возникает.
В-третьих, при изменении бизнес-правил, необходимо отследить
•
все приложения, влияющие на изменение бизнес логики, в то время как SQL-запрос всегда найти и изменить значительно легче.
В больших компаниях бизнес правила спокойно пересекают границу в сотню правил. Приложения, контролирующие все бизнес-правила, будут слишком громоздким и чрезвычайно сложным.
В результате деловая логика должна адресовать широкий диапа-
•
зон потенциальных требований, которые включают обеспечение
транзакционную целостность прикладных компонентов, поддержание и быстроту вызовов к прикладным данным, поддержку координации бизнес-процессов и объединение новых прикладных компонентов с существующими компонентами.
Очень важно при создании Web-компонентов распределение ролей,
отводимых каждому компоненту. То, с чем лучше всего справляется база данных, должно выполняться в базе данных, серверные компоненты
должны нести только данные, необходимые клиенту, а вся системная
информация записывается в системные журналы.
5.7. Представление данных
Логика представления данных полностью зависит от бизнес-процесса. Взаимодействие между бизнес-логикой и представлением данных
осуществляется через контроллер (Model-View -Controller). В Application Server, использующих Java, роль контроллера могут выполнять servlet или JavaBean или связь через обращение JSP к servlet. Для представления (View) данных больше всего подходят JSP-страницы с их
уникальными возможностями.
По большей части представлением данных занимаются Web-дизайнеры, инструмент которых ограничен двумя языками HTML и javascript или vbscript. И обычно проектировщик просто полагается на креативность дизайнера и на данные, нуждающиеся в отображении, после
чего рождаются прекрасные сайты, лишенные какой-либо логики. Со-
78 Часть 1. Электронная коммерция
здание хорошего дизайна, как создание картины, требует творчества,
проблема в одном — настоящие художники работают только по вдохновению. Девочка, бегущая к прекрасному дому, может добежать до руин
(литературное отступление).
ПРИМЕР СОЗДАНИЯ E-COMMERСE ПРИЛОЖЕНИЯ ПО НАИБОЛЕЕ
РАСПРОСТРАНЕННОМУ СЦЕНАРИЮ В2С
Осуществление перевода части деятельности предприятий, в особенности обработка и хранение информации, создание интерактивного
взаимодействия с клиентами, партнерами, служащими представляется
возможным при использовании новых методов и технологии взаимодействия сетевых технологий. На рис. 1.10 представлено обычное Web-приложение.
Прежде чем e-commerсe приложение будет создано, необходимо
определить взаимодействие различных компонентов. Используя парадигму MVC, создание приложения выглядит следующим образом.
Модель представляет основные данные. Чаще всего под основными
данными подразумевается бизнес-логика приложения. Презентация
данных осуществляется через страницы JSP или HTML. Клиент обращается к JSP-странице и получает ответ в виде HTML-страницы, сгенерированной JSP. Если предполагается использовать немного информации, для предоставления данных предпочтительнее использовать
servlet.
JSP перенаправляет клиентский запрос в контроллер — Servlet, являющийся обработчиком http-запросов. Роль контроллера предназначена для организации взаимодействия между бизнес-логикой и отображаемыми данными. Проектирование бизнес-логики приложения — одна из
сложнейших задач. Узнать, что действительно важно, а чем надо пренебречь, является для разработчика первоочередной задачей. И если дело
касается только Web-магазина, описанного не более десятью бизнесправилами, то и бизнес-аналитик, и проектировщик могут быть одним
лицом. Если же количество бизнес-правил увеличивается, то вступает в
действие разделение труда между различными участниками создания
Рис. 1.10. Web-приложение в действии
Часть 1. Электронная коммерция 79
e-commerсe приложения. JavaBean-компоненты бывают видимыми и
невидимыми, т. е. несущими элементы пользовательского интерфейса
или без оных — EJB. В большинстве Web-приложений бобам отводится
роль модели.
Создание любого приложения B2C, независимо от среды выполнения,
начинается с проектирования взаимодействия между приложением и
клиентом. Первичная информация, чаще всего получаемая из системного уровня клиента, такая, как тип баузера, URL, номер порта и т. д., используется для идентификации клиента на первом этапе. Для того чтобы написать уже написанное, проектировщику неплохо было бы ознакомиться с существующими решениями, предлагаемыми различным
производителями программного обеспечения. Что касается использования Java, то существующее количество API, распространяемых как
фирмой SUN, так и другими производителями, таких, как IBM, в принципе может решить все проблемы получения первичной информации о
пользователе. Необъятное количество пакетов заставляет проектировщика идти на неправильные шаги, предполагая, что его программисты
быстрее справятся с созданием необходимых классов, чем проектировщик найдет нужный класс. Стандартные расширения к Java, называемые Java Enterprise Extension, описаны достаточно тщательно, тем более бесплатно распространяются. Поэтому лучше поинтересоваться чужими решениями на данный счет, а потом придумывать свои. Просто
слишком часто вместо описания бизнес-правил проектировщик описывает получение системных данных, затягивая в рутину не только себя,
но и подвластных ему программистов.
Самым распространенным сценарием e-commerсe приложения на
территории империи на настоящий момент является взаимодействие с
конечным покупателем, чаще всего частным лицом.
Далее будет рассмотрено более детальное создание приложения по
бизнес-сценарию B2C, точнее, одному из его подтипов User-to-Online
Buying. Использование этого сценария оправдано при создании нового
e-commerсe приложения, когда отсутствует необходимость обеспечивать доступ к корпоративным данным управления предприятием или
большим хранилищам информации, предназначенным для служебного
пользования. Все требуемые данные обрабатываются непосредственно
e-commerсe приложением, при этом не используются взаимодействия с
другими e-commerсe приложениями. Создаваемое приложение реализует все функции обработки данных. Обычно для этого сценария выберется трехуровневая структура Web-приложения и первая из топологии
приложений.
Топология 1 используется предприятиями или Интернет-компаниями,
которые уже имеют или только хотят открыть доступ к свои ресурсам.
При этом наблюдается тенденция минимального вложения в описание
бизнес-правил, практически они минимальны, и уделяется больше внимания наглядности предлагаемых ресурсов. Наибольшее количество времени отводится под проектирование пользовательского интерфейса. Свод
бизнес-правил в основном ограничивается описанием товара, подтверждением финансовой операции, подтверждением заказа выбранного товара, формированием дополнительных условий поддержки покупки. Топо-
80 Часть 1. Электронная коммерция
логия 1 имеет один скрытый от большинства разработчиков «подводный
камень», часто ограничивающий способности созданного приложения
при дальнейшем расширении функциональности. Очень многие поставщики решений для e-commerсe, используя топологию 1, смешивают в одном логическом компоненте бизнес-логику и логику презентации приложения. Смесь, образуемая в результате, прекрасно может работать и в
дальнейшем, но только для приложений, использующих топологию 1.
Первичные причины для использования топологии 1 — скорость
продвижения на рынок и стоимость. Цель состоит в том, чтобы получить торговое представительство с минимальными переделками серверных компонентов. Поскольку Web-технологии уже достаточно широко
распространены и стандартизированы, минимальные изменения, вносимые на готовый сайт, делают из обычного представительства в сети
торговое представительство.
Ключевые особенности данной топологии заключаются в доступности
и готовности, малой потребности ресурсов и очень большом распространении уже существующих корпоративных сайтов. Не предъявляется
больших требований к используемым программным продуктам, достаточная дешевизна используемых ресурсов.
Интерфейс e-commerce (online-buying) приложения полностью отвечает потребностям минимальных обращений к бизнес-правилам. Поскольку часть из них описывается совместно с логикой пользовательского
интерфейса, разрабатывая приложение с данной топологией, проектировщик описывает только точечные решения приложения. Используется парадигма «если что» — реакция на действия пользователя и «что
будет, если», т. е., обработка неправильной информации.
Сценарий B2C используется для организации продаж напрямую конечному потребителю, минуя все возможных посредников. Полагаясь на
эмпирические методики, для конечного потребителя создается интерфейс с колоссальным количеством компонентов, практически не используемых в дальнейшем системой. При всем огромном росте продаж через
Интернет, большая часть которых осуществляется между предприятиями, по другому сценарию, конечный потребитель любит ходить в магазины. Поэтому создание дополнительных, тяжеловесных компонентов
не всегда оправданно в использовании B2C сценария.
Разработчикам следует учитывать взаимодействие с уже существующими компонентами. Опять же при использовании трехуровневой
Web-архитектуры обязательно учитывать физическое расположение и
уровень доступа к данным. E-commerсe приложение создается с различными уровнями взаимодействия, а это накладывает свой отпечаток
на скорость выполнения приложения. Тем более что часть работ в приложении должна выполняться синхронно, другая асинхронно.
Приложение уровня предприятия, использующего сценарий B2C,
предполагает наличие нескольких различных уровней взаимодействия:
Уровень клиента — именно на данном уровне создается клиентский
запрос для обработки и получается ответ на данный запрос.
Уровень сервера — Web и/или сервер приложений, — обрабатывающий клиентский запрос и формирующий в удобной для клиента форме
ответ. Именно на данном уровне выполняется основная работа.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]