Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:JAVA. Серверные приложения
.pdf
Часть 1. Электронная коммерция 51
Persistence (CMP), то управление доступом к базе данных полностью
ложится на «плечи» EJB-контейнера.
Бизнес-логика Web-приложений полностью сохраняется в базе данных. Entity bean имеет методы, работающие с бизнес-данными. Простая
бизнес-задача может опираться на несколько таблиц в базе данных, а
манипулирование строками этих таблиц с использованием EJB упрощает логику управления данными. В реальных системах EJB-контейнеры
взаимодействуют со следующими элементами:
клиентами, установившими связь с EJB. Это могут быть как Java-
•
клиенты, использующие RMI и Java-интерфейсы, так и CORBAклиенты, использующие IDL-версии интерфейсов;
базами данных, к которым обращаются компоненты. Как правило,
•
это Entity-компоненты как с CMP, так и с BMP;
конечными сервисами, в том числе CORBA-серверами (реализо-
•
ванными на Java, C++ и др., взаимодействующими с любым CORBA-совместимым ORB), другими EJB-серверами другими сервисами (ERP-системами, серверами приложений на мейнфреймах и
т. д.).
Как компоненты EJB, так и их контейнеры способны управлять
транзакциями. Технология EJB позволяет изменять информацию в нескольких базах данных в контексте одной транзакции. Данные могут
находиться не только в различных БД, но и на разных компьютерах в
сети. Технология EJB использует стиль управления транзакциями, который отличается от традиционного стиля (так называемое декларативное управление). Компонент EJB устанавливает свои атрибуты транзакции на стадии поставки. Эти атрибуты транзакции определяют, будет
ли управление транзакцией осуществляться контейнером, или это возьмет на себя сам компонент. При использовании традиционного стиля за
все аспекты управления транзакциями отвечает само приложение. Это
подразумевает выполнение следующих операций:
•
создание объекта «транзакция»;
•
явное начало транзакции;
•
передача и отслеживание контекста транзакции;
•
подтверждение транзакции после внесения всех изменений.
Это требует от разработчика приложения глубоких знаний, как
управлять транзакциями с начала и до конца — код такого приложения
достаточно сложен, труден для написания и может содержать ошибки.
При декларативном стиле управления транзакциями контейнер берет
на себя выполнение большинства, если не всех, необходимых операций.
Контейнер начинает и завершает транзакцию, а также поддерживает
контекст транзакции в течение ее существования. Это существенным
образом упрощает задачу разработчика, особенно для транзакций в
распределенных средах.
Архитектура EJB определена в спецификации, разработанной фирмой SUN Microsystems.
В реальном мире все серверные компоненты взаимодействуют между собой и очень редко представляют самостоятельные приложения.
Работая как часть большого Web-приложения, все серверные компоненты, будь то servlet, JSP или EJB-функционируют совместно. Вся мощь
52 Часть 1. Электронная коммерция
и максимальная производительность Web-приложения достигается при
использования Java как серверной технологии.
Основным условием успешного исполнения Web-приложения, как,
впрочем, и любых других приложений, состоящих из отдельных программ, кроме хорошо созданных составных элементов, является обеспечение взаимодействия между различными компонентами.
Серверные взаимоотношения Java-компонентов описываются несколькими различными способами. Каждый способ взаимодействия имеет свои достоинства и недостатки, проявляющиеся в определенном бизнес-сценарии. Серверные взаимоотношения строятся не просто на вызове соответствующих методов и совместном использовании ресурсов.
Здесь на поверхность выплывает такое важное понятие, очень часто
употребляемое в программировании, как область видимости объекта
(scope). Если говорить более простым языком, то под областью видимости объекта можно назвать границы использования объекта.
Хочется отдельно обратить внимание на данную характеристику
Web-приложения. Так как при проектировании приложения в целом
особое внимание уделяется разрабатываемым компонентам, чаще всего
управление синхронизацией и обеспечением доступа к совместно используемым ресурсам перекладывают на плечи дополнительных программных модулей, хотя половину из этих задач можно решить обычным
указанием области использования, видимости объекта. В принципе для
каждых приложений описываются свои собственные области видимости.
Но в большинстве Web-приложений можно выделить основные три области.
Самая первая и самая большая область видимости для каждого
объекта это конечно же само Web-приложение. Обычно эта область
носит название APPLICATION. Объект, описанный в данной области,
доступен любым программным компонентам самого главного приложения. Свойствам и атрибутами данного объекта может пользоваться
любой другой объект. Следовательно, уровень безопасности понижается, а количество используемых ресурсов увеличивается, так как к одному объекту может обращаться очень большое количество других.
На один уровень ниже стоит граница области называемой SESSION.
Как следует из самого названия session, объект доступен только во
время клиентской сессии. Сессия — это последовательность клиентских запросов и серверных ответов. Объект, видимый в этой области,
доступен только объектам, с которыми клиент работал в сессии. Теперь безопасность обеспечивается не только основным приложением,
но и сессией. На последнем уровне — уровне запроса REQUEST, находятся объекты, доступные только в момент поступления клиентского запроса. К объекту с областью видимости REQUEST может получить доступ только одна часть общего приложения, именно та, на которую поступил запрос.
В большинстве случаев каждое приложение описывает свои области
видимости, помогающие более точно настроить всю систему в целом и
порой решить некоторые задачи без дополнительного программирования.
Часть 1. Электронная коммерция 53
3.4. Работа с третьим уровнем Web-приложений основанным
на технологии Java
Каждое приложение в конечном счете работает с данными, находящимися на последнем уровне Web-архитектуры, Enterprise Information
System, консолидированный источник всех данных предприятия. Кроме
баз данных, данный уровень может содержать серверы транзакций, системы планирования и учета — ERP-системы или любую другую информацию. Предприятие само и при помощи клиентов работает с данными, находящимися на этом уровне.
Развитие e-commerсe привело к появлению новых типов работы с
корпоративными данными: предприятия хотят, чтобы информация стала доступна через Web-партнерам, поставщикам и покупателям. Появилась первоочередная задача — обеспечивать служащих своевременной информацией. Кроме того, стало необходимым управлять этой информацией, опять же используя Web.
Таблица 4
Основные EIS сервисы и Java API
Web сервис Используемый стандарт Используемое Java API
Электронная почта SMTP, POP3, IMAP4, IRC, NNTP, FTP Java Notes API, javax.mail
Средства групповой работы — Java Notes API
Базы данных ODBC, DRDA JDBC, SQLJ, EJB
Транзакции CORBA IIOP/OTS EJB, JTS
Сообщения BMQS, MQI JMS
В табл. 4, перечислены основные способы и наборы API, необходимые для работы back-end систем предприятий.
Все эти причины заставили предприятия перевести часть бизнеса в
электронную сферу, то бишь e-business. Основная проблема заключается в том, что ресурсы копились годами, большей частью не стандартизированы, имеют разную природу и располагаются в разных местах.
Еще одна проблема заключается в том, что при манипулировании данными необходимо представлять их в требуемом виде. Со всеми этим задачами прекрасно может справиться Java с ее колоссальным набором
всевозможных API.
Java-приложения для организации доступа к базам данных, таким
как, DB2, в основном широко используют распространенную технологию JDBC. JDBC уже устоявшийся, хорошо опробованный стандарт со
своими программными шаблонами.
Новое решение в данной области, но не новое в работе с базами данных — встроенные в код приложения SQL-операторы.
Относительно Java-приложений, данная технология называется
SQLJ. Почему Java используется для создания приложений, работающих с базами данных:
54 Часть 1. Электронная коммерция
Java работает в различных средах, также как SQL работает с раз-
•
личными базами данных.
Все базовые SQL типы современных баз данных имеют представ-
•
ления в Java.
SQLJ и JDBC открыты стандарты, позволяющие различным при-
•
ложениям, реализованным на Java, легко взаимодействовать с разнородными базами данных.
Java является платформонезависимыv языком, это гарантирует
•
работу с любой базой данных на любой платформе. JDBC и SQLJ
предназначены именно для работы в гетерогенных средах. Транслятор SQLJ, написанный на Java, полностью переносимом на различные платформы, при этом каждый производитель СУБД может
по собственному усмотрению расширять и дополнять SQLJ-транслятор по собственному усмотрению.
Чем воспользоваться JDBC или SQLJ для организации доступа к
СУБД — вопрос некорректный. Оба решения хороши, каждый для своих целей и равноценно используются при программировании Java-приложений, servlet и JSP, т. е. в Web-приложениях.
Основное отличие JDBC от SQLJ в том, что JDBC использует «динамический» доступ к базам данных, а SQLJ — только статические вызовы
SQL-операторов. В других областях они практически не различаются.
3.4.1. JDBC
Java Data Base Connectivity (JDBC) — набор API, используемый для
доступа к базам данных. Он является первой попыткой создания приложений, использующих Java-операторы, заменяющих стандартные
SQL-операторы.
JDBC представляет собой двухуровневый API для организации доступа к базам данных. Первый уровень (Low Level) описывает драйвера
для доступа к различным базам данных, следующий уровень (High Level) содержит объекты классов для выполнения SQL-запросов.
JDBC не поддерживает конструкцию SELECT.....INTO.
Использование JDBC API позволяет приложению получить доступ к
различным источникам информации, начиная с баз данных и заканчивая файловыми системами. JDBC позволяет:
•
осуществлять соединение и аутентификацию пользователя базы
данных;
•
управлять транзакциями;
•
выполнять SQL-операторы в базе данных;
•
выполнять хранимые процедуры;
•
инспектировать и модифицировать результаты запросов, выполненных SQL-оператором SELECT.
Платформа J2EE работает с двумя версиями — JDBC 2.0 Core API
(используемое на стандартной J2SE-платформе, java.sql), и JDBC 2.0
Extension API,javax.sql, имеющего дополнительные средства работы со
строками результирующих запросов.
Часть 1. Электронная коммерция 55
3.4.2. SQLJ
SQLJ использует упрощенный синтаксис для организации доступа
к базам данных. SQLJ предназначен для совместного применения
SQL-операторов и Java-кода в одном приложении. Одним из недостатков использования SQLJ является неоднородная смесь, образованная двумя различными языками — Java и SQL. Другим недостатком
является невозможность работы с динамическими SQL-операторами.
В случае SQLJ недостатки превращаются в достоинства, поскольку
нет необходимости создавать на Java-аналоги SQL-операторов. Встроенные SQL-операторы могут ссылаться на переменные, описанные на
языке Java. Java-переменными присваиваются значения SQL-запросов. Вышесказанное определяет способность работы программы как с
SQL-операторами, так и Java-переменными.
Для облегчения обработки сложных запросов из нескольких строк в
SQLJ включены специальные объекты — interator. Также имеется специальный объект — context, предназначенный для обращения к базе
данных, без повсеместного указания параметров соединения.
Использование SQLJ предназначено äëÿ создания статических
SQL-операторов. Скорость выполнения статических операторов значительно выше, чем динамических. Статические операторы используются
при заранее известных исполняемых SQL-операторах. Ряд действий,
выполнимых СУБД по обработке клиентского запроса, в статических
операторах производится на этапе трансляции SQLJ-программы. Тогда
во время исполнения программы у клиента отпадет необходимость в
реализации данных запросов.
3.5. Основные бизнес-сценарии, описываемые с помощью
Java-компонентов
Далее будут рассмотрены основные типы бизнес-сценариев и опущены вариации использования бизнес-сценариев. Основной упор также
будет сделан на использование Java и технологии Java при создании
приложений по перечисленным сценариям. Конкретное описание использование бизнес-сценария будет дано ниже.
3.5.1. Бизнес-сценарий User-to-Business, B2C
Как и другие бизнес-сценарии e-commerсe приложений, B2C содержит Java-компоненты для серверной и клиентских частей. Основными
технологиями B2C, основанными на Java, можно назвать следующие:
•
HTML- — сформированные клиентские запросы и ответы;
•
Java servlets and JavaServer Pages — серверные обработчики клиентских запросов и генераторы ответов;
•
XML-представление документа;
•
Connectors — соединения с существующими информационными
ресурсами предприятия;
•
JDBC — для организации доступа к базам данных;
•
дополнительные Java API.
56 Часть 1. Электронная коммерция
Рис. 1.6. Бизнес-сценарий B2C
Типичная работа сценария выглядит следующим образом. Заказчик, клиент, используя Web-браузер, инициализирует e-commerсe
транзакцию ñ каким-нибудь предприятием, например магазином.
В браузере клиента отражается состояние «товарных полок» магазина. Клиент, выбирая соответствующий товар из перечисленных в каталоге, делает выбор, помещая выбранный продукты в «корзину». Типичная жизненная ситуация. Оставим пока описание создания каталога и «корзины». Кроме выбора продуктов, клиент должен каким-либо
образом идентифицировать себя в e-магазине. Для осуществления
этой операции клиент заполняет входную форму или просто вводит
ключевое слово и пароль. После выбора товаров клиент оформляет
заказ, самая важная часть и при этом самая простая часть, чаще всего кнопка submit. Как в обычной жизни, основным условием выполнения данного сценария является наличие товара на полках магазина.
В данном случае должна существовать база данных с описаниями
предлагаемых товаров и хранения всех транзакций выполняемых
клиентом.
Используя парадигму MVC, данную модель можно описать следующим образом:
Servlet — осуществляет роль контроллера;
JSP — презентационная графика приложения;
Servlet и JSP, осуществляющие доступ к базе данных, исполняют
роль модели приложения. На рис. 1.6 изображена приблизительная схема данного сценария.
Доступ к информационным ресурсам осуществляется при посредничестве соединителей. В данном выше описании нарочно опущено использование EJB, поскольку бизнес-логика не столь сложна, как хотелось
бы, чтобы пользоваться преимуществам EJB. Хотя использование EJB
не возбраняется.
Часть 1. Электронная коммерция 57
3.5.2. Бизнес сценарии Business-to-Business, B2B
Когда две компании участвуют в одном бизнес-процессе, это называется красивым словом «сотрудничество». Сценарий B2B описывает
партнерские отношения двух компаний. В данном сценарии можно
опустить клиентский уровень и организовать соединение двух различных серверов в виде единого, будь то серверы баз данных или приложений, либо использовать другие способы единения информации, на
уровне ERP- или файловых систем. В данный момент это не столь
важно. Важно, как выглядит этот сценарий с точки зрения Java-разработчика.
Самый логичный и самый практичный способ реализации данного
бизнес-сценария заключается в использовании EJB совместно с JTS без
каких бы то ни было ухищрений.
Главной «изюминкой» в данном сценарии (рис. 1.7) является использование двух независимых EJB-контейнеров, представляющих различные серверы различных компаний. Так как каждый контейнер может
иметь различные источники данных, кроме рекомендуемых СУБД, то
EJB одного сервера одной компании могут очень легко достучаться до
данных на другом сервере, с другим хранилищем информации. Использование EJB-контейнеров освобождает от использования других серверных компонентов, servlet и JSP. Отказ от использования в приложении servlet и JSP влечет за собой отказ и от использования Web-сервера. Хорошо ýòî или плохо, можно решить только ïðè точном
проектировании будущего e-commerсe приложения. Отказ от Web-клиента повышает безопасность приложения, что является немаловажным
фактором при финансовом сотрудничестве двух предприятий. Используемый при такой архитектуре протокол RMI обеспечивает дополнительные уровни секретности и повышает производительность передачи
данных.
Рис. 1.7. Бизнес-сценарий B2B
58 Часть 1. Электронная коммерция
3.5.3. Бизнес-сценарий Business-to-Employers, B2E
Служащие компании, так же как и другие участники бизнес-процесса, нуждаются в информации. Основным отличием от других сценариев,
где участники процесса являются внешними по отношению друг к другу, служащие составляют саму компанию, а значит, используют и другие способы получения информации. Если же оставить бизнес-тонкости,
то основное отличие наблюдается в используемой архитектуре и типе
клиента.
Прекрасным примером использования сценария B2E можно назвать
управление персоналом, т. е. работа отдела кадров совместно с первым
отделом.
Здесь все предельно просто — кое-кто должен получить зарплату.
Но чтобы узнать ее размер, следует выяснить, сколько времени работник прокурил, сколько проговорил по телефону и сколько, в конце концов, проработал.
Теперь о реализации. Наверное, это правильно — не публиковать
списки служащих в Интернете c уровнем заработной платы, превышающим минимальный прожиточный уровень более чем на 25%. Поэтому,
скорее всего, информацией о служащих будет интересоваться отдел
кадров и первый отдел, а раз это отделы предприятия, то сразу и определяется тип клиента. А тип-то как раз может быть любой, — и Webклиент, и EJB-клиент, и просто приложение. И теперь все то, что описывалось для клиентов вообще, необходимо реализовать в целом приложении.
И если с клиентами пока все понятно, то серверный уровень можно
рассмотреть более тщательно. Весь смысл в том, что данные о служащем располагаются в совершенно разных источниках, будь то СУБД
либо какие другие. Финансовая информация о человеке хранится в бухгалтерии, а вот важная информация у полковника из первого отдела.
Вот тут и встает вопрос об организации серверного уровня приложения.
Использование JSP не оправдывает себя, поскольку JSP лишен транзакционных механизмов. Servlet хорош всем, за исключением того, что
придется все время следить за синхронизацией данных. Остается EJB.
На рис. 1.8 изображена приблизительная схема данного сценария.
Данный сценарий основывается на распределенных транзакциях. Отсутствие Web-звена говорит о возможности использования только
средств EJB-технологии для осуществления распределенных транзакций. Транзакции, в которых задействовано несколько баз данных, ис-
Рис. 1.8. Бизнес-сценарий B2E
Часть 1. Электронная коммерция 59
пользуют двухфазный процесс подтверждения транзакции. Процесс гарантирует, что транзакция корректно вносит изменения во все базы
данных, участвующие в ней. Если она не может изменить все базы данных, то не изменяется ни одна. Двухфазное подтверждение выполняется за два шага. Первый шаг называется фазой подготовки. Транзакция
опрашивает все участвующие базы данных, и они должны сигнализировать о том, что они готовы подтвердить изменения и завершить транзакцию. Второй шаг — шаг собственно внесения изменений — выполняется только в том случае, если все базы данных подтвердили свою готовность завершить транзакцию.
Если бы в компании использовались однородные базы данных, тогда
работа EJB-сервера сводилась бы к стандартному решению транзакций.
Но в данном случае именно разнородность СУБД определяет основополагающую роль использования EJB-технологии.
3.5.4. Бизнес-сценарий расширенный Business-to-Business, e-Marketplaces
Самый сложный по реализацииивтожевремя самый интересный — бизнес-сценарий единой виртуальной торговой площадки. Бизнес-сценарий e-Marketplaces включает в себя несколько основных, более простых бизнес-сценариев, за счет чего и усложняется его реализация.
В отличие от своих предшественников, где роли каждого участника
строго регламентированы, в данном сценарии каждая из участвующих
сторон может одновременно участвовать в торговом процессе сразу в
нескольких ипостасях — быть и продавцом, и покупателем или другим
промежуточным звеном торговой сессии. Это говорит о том, что кроме
таких распространенных участников стандартного бизнес-процесса, как
покупатель и продавец, в сценарии e-Marketplaces принимают участие
другие роли, как определенные самим приложением, так и специальными бизнес-правилами применяемыми на данной торговой площадке.
Для каждой специфической торговой площадки, для которой создано
e-commerce, по указанному сценарию можно все-таки описать основные
действия ролей покупателя и продавца, главное, что необходимо учитывать при создании этих ролей, их полная взаимозаменяемость в момент
проведения торговой сессии. Оба участника процесса используют свои
собственные механизмы проведения торговых транзакций.
Как и всякая торговая площадка, e-Marketplace, работает либо с одним типом товаров, например валютная биржа, работающая только с
электронным предоставлением денежного эквивалента, либо предоставляет более широкий спектр товаров и услуг. Опять же выбор количества и типов товаров накладывает свои отпечатки на создание всего приложения в целом.
Кроме всего вышеуказанного, каждый электронный рынок должен
описывать работу с предоставляемым продуктом на различных временных промежутках по-разному. Если опустить мелкие детали, присущие
каждой отдельной торговой площадке, то, как и на обычной бирже, существует несколько транзакционных механизмов осуществления акта
покупки или продажи. Товар можно покупать по реальной цене, вы-
60 Часть 1. Электронная коммерция
ставляемой продавцом, по цене, которая сложится в будущем, как
предполагает покупатель, и по контракту, т. е. по цене участников процесса купли-продажи, пришедших к единому мнению. Вообще лучше
посмотреть о торговых транзакциях осуществляемых на бирже, что-нибудь более соответствующее данной тематике.
Глава 4. Решения фирмы IBM для создания e-commerce
приложений
Поясним, почему выбор пал на IBM. По нескольким причинам, вопервых, легче идти за слонами, чем успевать за маленькой, хоть и агрессивной (читай преуспевающей) пумой. Слонами в данном контексте
именуются компании IBM и SUN. Во-вторых, кроме заявленных платформ, для которых существует реализации Java, Linux, Windows, Solaris, компания IBM поддерживает платформы собственной разработки.
А их не мало — от маленькой, но очень надежной OS/2 до AIX, одного
из клонов UNIX-систем. Еще до рождения e-commerсe как отрасли деятельности компания IBM предлагала свое бизнес-решение, в виде сервера бизнес-приложений AS400. В-третьих, грандиозное количество
программного обеспечения, созданное под платформы IBM как самой
компанией IBM, так и сторонними производителями. В-четвертых, 80%
программного обеспечения мирового финансового рынка — это продукция IBM. При этом парк больших машин IBM занимает 22% от общего
количества. Также необходимо учесть позицию таких продуктов, как
базы данных, — DB2 занимает одно из лидирующих мест в корпоративной нише баз данных на протяжении нескольких десятков лет. То, что
остальные только начали производить и внедрять на рынок, IBM уже
поставляет как вполне годный к употреблению продукт. Наконец, версия JVM, созданная IBM, значительно быстрее реализации SUN, а количество API не уступает распространяемых создателем Java.
Использование программных продуктов фирмы IBM дает возможность разработки полнофункционального Web-приложения всех возможных уровней.
Взаимная интеграция этих продуктов представляет прекрасную возможность разработки больших сетевых проектов.
Основные компоненты для разработки сетевых приложений, представляемые фирмой IBM:
•
HTTP Server — работает со статическими HTML-страницами браузера.
•
WebSphere Application Server — надстройка над HTTP Server, позволяющая работать с динамическими компонентами, servlets и JavaServer Pages (JSP). Управление этими элементами лежит полностью на WebShere Applicatin Server.
•
WebSphere Studio — инструмент для создания HTML и JSPs-файлов и генерации servlet.
•
VisualAge for Java — продукт для разработки и тестирования Java-приложений, applets, servlets, JavaBeans, и Enterprise JavaBe-
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]