Создание системы электронной коммерции

 

Создание системы электронной коммерции

1 Корпоративные компоненты

На рисунке 1 показана общая схема взаимодействия компонентов. В этой работе будет подробно рассмотрен каждый тип компонентов, а в конце главы будет рассмотрен процесс построения, размещения и запуска приложения.

Рисунок 1 - Приложение Duke's Bank

На рисунке 2 более детально изображены связи между клиентами, корпоративными компонентами и таблицами базы данных. Вы видите, что конечные пользователи (Web-клиенты и клиенты J2EE-приложения) обращаются только к сессионным компонентам. На уровне корпоративных компонентов сессионные компоненты являются клиентами компонентов управления данными. На уровне сервера компоненты управления данными обращаются к таблицам базы данных, в которой сохраняются их состояния.

Рисунок 2 - Корпоративные компоненты приложения Duke's Bank

2 Сессионные компоненты

Приложение Duke's Bank имеет три сессионных компонента: AccountControllerEJB, CustomerControllerEJB и TxControllerEJB. (Tx обозначает бизнес-транзакцию, например перевод денег.) Эти сессионные компоненты обеспечивают клиентский взгляд на бизнес-логику приложения. Скрытыми от клиента являются процедуры на стороне сервера, реализующие бизнес-логику, доступ к базе данных, управление отношениями и выполнение проверки ошибок.

2.1 AccountControllerEJB

Бизнес-методы сессионного компонента AccountControllerEJB выполняют задачи, попадающие в следующие категории: создание и удаление компонентов управления данными, управление связями счет-пользователь и получение информации о счете.

Следующие методы создают и удаляют компоненты управления данными:

-createAccount;

-removeAccount.

Эти методы сессионного компонента AccountControllerEJB вызывают методы create и remove компонента управления данными AccountEJB. Методы createAccount и removeAccount генерируют исключительную ситуацию для указания неправильных аргументов метода. Метод createAccount генерирует IllegalAccountTypeException, если тип аргумента не Checking, Saving, Credit или Money Market. Метод createAccount также проверяет, что указанный пользователь существует, при помощи вызова метода findByPrimaryKey компонента управления данными CustomerEJB. Если результат этой проверки равен false, метод createAccount генерирует CustomerNotFoundException.

Следующие методы управляют отношениями счет-пользователь:

-addCustomerToAccount;

-removeCustomerFromAccount.

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

В приложении Duke's Bank методы addCustomerToAccount и removeCustomerFromAccount сессионного компонента AccountControllerEJB управляют отношением счет-пользователь. Метод addCustomerToAccount, например, начинает работу с проверки существования пользователя. Для создания отношения метод addCustomerToAccount вставляет строку в таблицу customer_account_xref базы данных. В этой таблице перекрестных ссылок каждая строка содержит customerId и accountId связанных сущностей. Для удаления отношения метод removeCustomerFromAccount удаляет строку из таблицы customer_account_xref базы данных. Если клиент вызывает метод removeAccount, удаляются все строки с указанным accountId из таблицы customer_account_xref.

Следущие методы получают информацию о счете:

-getAccountsOfCustomer;

-getDetails.

Сессионный компонент AccountControllerEJB имеет два метода get. Метод getAccountsOfCustomer возвращает все счета указанного пользователя при помощи вызова метода findByCustomer компонента управления данными AccountEJB. Вместо реализации метода get для каждой переменной экземпляра, AccountControllerEJB имеет метод getDetails, возвращающий объект (AccountDetails), который объединяет в себе полное состояние компонента AccountEJB. Поскольку он может вызвать один метод для извлечения полного состояния, клиент избегает издержек, связанных с несколькими удаленными вызовами.

.2 CustomerControllerEJB

Поскольку существует компонент AccountControllerEJB, управляющий отношением пользователь-счет, из этих двух сессионных компонентов CustomerControllerEJB является более простым. Клиент создает компонент управления данными CustomerEJB, вызывая метод createCustomer сессионного компонента CustomerControllerEJB. Для удаления пользователя клиент вызывает метод removeCustomer, который не только вызывает метод remove компонента CustomerEJB, но также удаляет из таблицы customer_account_xref все строки, идентифицирующие пользователя.

Сессионный компонент CustomerControllerEJB имеет два метода, возвращающих несколько пользователей: getCustomersOfAccount и getCustomersOfLastName. Эти методы вызывают соответствующие методы поиска - findByAccountId и findByLastName - компонента CustomerEJB.

2.3 TxControllerEJB

Сессионный компонент TxControllerEJB обрабатывает банковские транзакции. В дополнение к своим методам get (getTxsOfAccount и getDetails) компонент TxControllerEJB имеет несколько методов, которые изменяют балансы банковских счетов:

-withdraw;

-deposit;

makeCharge;

makePayment;

transferFunds.

Эти методы обращаются к компоненту управления данными AccountEJB для проверки типа счета и установки нового баланса. Методы withdraw и deposit предназначены для не кредитных счетов, в то время как методы makeCharge и makePayment предназначены для кредитных счетов. Если аргумент type метода не соответствует счету, эти методы генерируют IllegalAccountTypeException. Если операция расходования денег может привести к негативному балансу, метод withdraw генерирует InsufficientFundsException. Если сумма обязательства превышает величину кредитной линии для счета, метод makeCharge генерирует InsufficientCreditException.

Метод transferFunds также проверяет тип счета и новый баланс; если необходимо, он генерирует те же самые исключительные ситуации, что и методы withdraw и makeCharge. Метод transferFunds вычитает из баланса одного экземпляра AccountEJB и добавляет такое же количество к другому экземпляру. Поскольку оба этих шага должны завершиться, метод transferFunds имеет атрибут транзакции Required. Если какой-либо из шагов заканчивается неудачно, происходит откат всей операции, и балансы остаются неизмененными.

3 Компоненты управления данными

Для каждого бизнес-субъекта, представленного в нашем простом банке, приложение Duke's Bank имеет соответствующий компонент управления данными:

-AccountEJB;

-CustomerEJB;

TxEJB.

Целью этих компонентов является обеспечение объектного представления следующих таблиц базы данных: account, customer и tx. Для каждого столбца в таблице соответствующий компонент управления данными имеет переменную экземпляра. Поскольку они используют управляемую компонентом персистенцию, компоненты управления данными содержат SQL-операторы, обращающиеся к базе данных. Например, метод create компонента управления данными CustomerEJB вызывает SQL-команду INSERT.

В отличие от сессионных компонентов компоненты управления данными не проверяют параметры методов (за исключением параметра с первичным ключом в ejbCreate). Во время фазы проектирования мы решили, что сессионные компоненты должны проверять параметры и генерировать исключительные ситуации, такие как CustomerNotInAccountException и IllegalAccountTypeException. Следовательно, если какое-либо другое приложение собиралось бы использовать эти компоненты управления данными, его сессионные компоненты должны были бы тоже проверять параметры методов.

4 Вспомогательные классы

Файлы EJB JAR включают несколько вспомогательных классов, используемых корпоративными компонентами. В таблице 1 кратко описываются вспомогательные классы.

Таблица 1 Вспомогательные классы для корпоративных компонентов приложения

Имя классаОписаниеAccountsDetailОбъединяет в себе состояние экземпляра AccountEJB. Возвращается методами getDetails компонентов AccountControllerEJB и AccountEJB.CodedNamesОпределяет строки, являющиеся логическими именами в вызовах метода lookup. (Например: java:comp/env/ejb/account). Класс EJBGetter ссылается на эти строки.CustomerDetailsОбъединяет в себе состояние экземпляра CustomerEJB. Возвращается методами getDetails компонентов CustomerControllerEJB и CustomerEJB.DBHelperОбеспечивает методы, которые генерируют следующие первичные ключи (например, getNextAccountId).DebugИмеет простые методы для вывода отладочных сообщений корпоративного компонента. Эти сообщения появляются на стандартном устройстве вывода J2EE-сервера, если он был запущен с ключом -verbose.DomainUtilСодержит проверочные методы: getAccountTypes, checkAccountType и isCreditAccount.EJBGetterИмеет методы, определяющие (путем вызова lookup) и возвращающие домашние интерфейсы (например, getAccountControllerHome).TxDetailsОбъединяет в себе состояние экземпляра TxEJB. Возвращается методами getDetails компонентов TxControllerEJB и TxEJB.

5 Таблицы базы данных

Таблица базы данных приложения Duke's Bank может быть классифицирована в соответствии со своим назначением: представление бизнес-сущностей и хранение следующего первичного ключа.

5.1 Таблицы, представляющие бизнес-сущности

На рисунке 3 показаны отношения между таблицами базы данных. Таблицы customer и account имеют отношения многие ко многим: пользователь может иметь несколько банковских счетов, и каждый счет может принадлежать более чем одному пользователю. Эти отношения реализуются при помощи таблицы перекрестных ссылок с именем customer_account_xref. Таблицы account и tx имеют отношения один ко многим: банковский счет может иметь много транзакций, но каждая транзакция относится только к одному счету.

Рисунок 3 Таблицы базы данных приложения Duke's Bank

Рисунок 3 использует несколько аббревиатур. PK обозначает первичный ключ - значение, уникально идентифицирующее строку в таблице. FK обозначает внешний ключ, являющийся первичным ключом связанной таблицы. Tx является сокращением для транзакции, такой как пополнение или расходование денежных средств.

.2 Таблицы, содержащие следующий первичный ключ

Эти таблицы имеют следующие имена:

-next_account_id;

-next_customer_id;

next_tx_id.

Каждая из этих таблиц имеет один столбец с именем id. Значение id представляет собой следующий первичный ключ, передаваемый в метод create компонента управления данными. Например, перед созданием нового компонента управления данными AccountsEJB сессионный компонент AccountControllerEJB должен получить уникальный ключ путем вызова метода getNextAccountId класса DBHelper. Метод getNextAccountId читает id из таблицы next_account_id, инкрементирует значение id в таблице и возвращает id.

6 Защита корпоративных компонентов

В платформе J2EE вы можете защитить корпоративный компонент, указав роли безопасности, которые могут обращаться к его методам (см. раздел Безопасность на уровне EJB). В приложении Duke's Bank определены две роли (BankCustomer и BankAdmin), поскольку корпоративными компонентами определяются две категории операций.

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

Доступ к этим функциям ограничивается для определенной роли путем установки разрешений метода для выбранных методов корпоративных компонентов CustomerControllerEJB, AccountControllerEJB и TxControllerEJB. Например, разрешая доступ к методу createAccount в компоненте AccountControllerEJB только пользователям, имеющим роль BankAdmin, вы запретите пользователям, имеющим роль BankCustomer или любую другую роль, создавать банковские счета. Чтобы просмотреть установленные разрешения метода в deploytool, найдите корпоративные компоненты CustomerControllerEJB, AccountControllerEJB и TxControllerEJB в древовидном списке. Для каждого компонента выберите закладку Security и просмотрите разрешения метода.

7 Классы и их отношения

Клиент J2EE-приложения делится на три класса: bankAdmin, EventHandle и DataModel: отношения между классами показаны на рисунке 4.

Рисунок 4 - Отношения между классами

создает начальный пользовательский интерфейс, создает объект EventHandle и обеспечивает методы объектов EventHandle и DataModel для вызова обновления пользовательского интерфейса. перехватывает нажатия кнопок пользователем, выполняет действие в зависимости от нажатой кнопки, создает объект DataModel, вызывает методы объекта DataModel для записи данных и чтения их из базы данных, а также вызывает методы в объекте BankAdmin для обновления пользовательского интерфейса после завершения действий.

Класс DataModel извлекает данные из интерфейса пользователя, выполняет проверки данных, записывает проверенные данные и читает сохраненные данные из базы данных, вызывает методы объекта BankAdmin в зависимости от успешности операций чтения или записи в базу данных.

8 Web-клиент

В приложении Duke's Bank Web-клиент используется пользователями для доступа к информации о счете и выполнения операций над счетами. В таблице 2 приведен список функций, поддерживаемых клиентом, URL, используемые для доступа к функциям, и компоненты, реализующие функции. На рисунке 5 показан экран истории счета.

Таблица 2 Web-клиент

ФункцияПсевдонимы URLJSP-страницы Компоненты JavaBeans Домашняя страница/mainmain.jspВход или выход из приложения/logon /logonError /logofflogon.jsp logonError.jsp logoff.jspВывести счет/accountListaccountList.jspВывести историю счета/accountHistaccountHist.jspAccountHistoryBeanДвижение средств на счетах/transferFunds /transferAcktransferFunds.jsp transferAck.jspTransferBeanСнять или внести средства/atm /atmAckatm.jsp atmAck.jspATMBeanОбработка ошибок/errorerror.jsp

Рисунок 5 - История счета

.1 Стратегии проектирования

Основной функцией JSP-страниц в приложении Duke's Bank является презентация. Стратегией для разработки пригодных для обслуживания JSP-страниц является минимизация количества сценариев, встроенных в страницу. Для того чтобы достичь этого, большинство задач динамической обработки переложены на корпоративные компоненты, пользовательские теги и компоненты JavaBeans.

В приложении Duke's Bank JSP-страницы используют корпоративные компоненты для обработки взаимодействий с базой данных. В приложении Duke's Bank компонент TransferBean играет такую же роль. Однако другие компоненты JavaBeans имеют намного большую функциональность. ATMBean вызывает методы корпоративного компонента и устанавливает строки подтверждения согласно вводу пользователя, а AccountHistoryBean обрабатывает данные, возвращаемые из корпоративных компонентов, для того чтобы представить для просмотра данные, запрошенные пользователем.клиент использует механизм шаблонов, реализованный пользовательскими тегами (рассмотрены в разделе Библиотека шаблонных тегов), для обеспечения единого внешнего вида всех JSP-страниц. Механизм шаблонов состоит из трех компонентов:

-template.jsp определяет структуру каждого экрана. Он использует тег insert для составления экранной формы из субкомпонентов;

-screendefinitions.jsp определяет субкомпоненты, используемые каждым экраном. Все экраны имеют один и тот же баннер, но различные заголовки и содержимое тела;

Dispatcher - сервлет, обрабатывающий запросы и перенаправляющий их в template.jsp.

Наконец, для выполнения управления передачей Web-клиент использует три логических тега (iterate, equal и notEqual) из библиотеки тегов Struts, рассмотренной в разделе Примеры JSP-страниц.

8.2 Цикл жизни Web-клиента

Инициализация компонентов клиента Ответственность за управление корпоративными компонентами, используемыми Web-клиентом, лежит на классе BeanManager. Он создает корпоративные компоненты пользователя, счета и контроллера транзакций, а также предоставляет методы для извлечения компонентов.

При создании экземпляра BeanManager извлекает домашний интерфейс для каждого компонента из вспомогательного класса EJBGetter и создает экземпляр при помощи вызова метода create домашнего интерфейса. Поскольку это функция уровня приложения, BeanManager сам создается и сохраняется при первой инициализации клиента объектом ContextListener (см. раздел Обработка событий цикла жизни сервлета) как контекст атрибута.class BeanManager {

private CustomerController custctl;

private AccountController acctctl;

private TxController txctl;

public BeanManager() {

if (custctl == null) {

try {

CustomerControllerHome home =

EJBGetter.getCustomerControllerHome();

custctl = home.create();

} catch (RemoteException ex) {

System.out.println("...");

} catch (CreateException ex) {

System.out.println();

} catch (NamingException ex) {

System.out.println();

}

}

public CustomerController getCustomerController() {

return custctl;

}

...

}

final class ContextListener

implements ServletContextListener {

private ServletContext context = null;

...

public void contextInitialized(ServletContextEvent event) {

this.context = event.getServletContext();

context.setAttribute("beanManager",

new BeanManager());

context.log("contextInitialized()");

}

...

}

Обработка запроса Все запросы для перечисленных в таблице 2 URL отображаются в Web-компонент dispatcher, который реализуется сервлетом Dispatcher:

class Dispatcher extends HttpServlet {

public void doPost(HttpServletRequest request,

HttpServletResponse response) {

...

String selectedScreen = request.getServletPath();

request.setAttribute("selectedScreen", selectedScreen);

BeanManager beanManager = getServletContext().getAttribute(

"beanManager");

...

if (selectedScreen.equals("/accountHist")) {

...

} else if (selectedScreen.equals("/transferAck")) {

String fromAccountId =

request.getParameter("fromAccountId");

String toAccountId =

request.getParameter("toAccountId");

if ( (fromAccountId == null) || (toAccountId == null)) {

request.setAttribute("selectedScreen", "/error");

request.setAttribute("errorMessage",

messages.getString("AccountError"));

} else {

TransferBean transferBean = new TransferBean();

request.setAttribute("transferBean",

transferBean);

transferBean.setMessages(messages);

transferBean.setFromAccountId(fromAccountId);

transferBean.setToAccountId(toAccountId);

transferBean.setBeanManager(beanManager);

try {

transferBean.setTransferAmount(new

BigDecimal(request.

getParameter("transferAmount")));

String errorMessage = transferBean.populate();

if (errorMessage != null) {

request.setAttribute("selectedScreen", "/error");

request.setAttribute("errorMessage",

errorMessage);

}

} catch (NumberFormatException e) {

request.setAttribute("selectedScreen", "/error");

request.setAttribute("errorMessage",

messages.getString("AmountError"));

}

}

...

try {

request.getRequestDispatcher("/template.jsp").

forward(request, response);

} catch(Exception e) {

}

}

}

Когда передается запрос, Dispatcher делает следующее:

1.Извлекает и сохраняет URL входящего запроса в атрибуте запроса selectedScreen. Это делается потому, что URL будет изменен, когда запрос перенаправится в шаблонную страницу приложения.

2.Создает компонент JavaBeans и сохраняет компонент как атрибут запроса.

.Разбирает и проверяет параметры запроса. Если параметр не верен, Dispatcher может сбросить псевдоним запроса в страницу ошибок. В противном случае он инициализирует компонент JavaBeans.

.Вызывает метод populate компонента JavaBeans. Этот метод извлекает данные из корпоративных компонентов и обрабатывает их в соответствии с выбором, указанным пользователем.

.Перенаправляет запрос в template.jsp.

Как упоминалось ранее, template.jsp генерирует ответ, включая ответы из субкомпонентов. Если запросом является GET, субкомпонент тела обычно извлекает данные из корпоративного компонента непосредственно; в противном случае он извлекает данные из компонента JavaBeans, инициализированного сервлетом Dispatcher.

На рисунке 6 изображено взаимодействие между этими компонентами.

Рисунок 6 - Взаимодействие Web-компонентов

9 Защита Web-ресурсов

корпоративный бизнес первичный ключ

В J2EE-платформе Web-ресурс защищается от анонимного доступа указанием того, какие роли безопасности могут обращаться к ресурсу. Эти указания называются ограничением безопасности. Web-контейнер гарантирует, что только определенные пользователи, выступающие в роли, указанной в ограничении безопасности, могут обратиться к ресурсу. Для того чтобы Web-контейнер заставил действовать ограничение безопасности, приложение должно установить средство, при помощи которого пользователи будут идентифицировать себя (как рассматривалось в разделе Аутентификация пользователей Web-ресурсов), а Web-контейнер должен поддерживать отображение роли на пользователя.

В Web-клиенте приложения Duke's Bank все перечисленные в таблице 18-2 URL ограничены ролью безопасности BankCustomer. Приложение требует от пользователя идентифицировать себя при помощи механизма регистрации, основанного на форме. Когда пользователь пытается получить доступ к URL Web-клиента, являясь не аутентифицированным, Web-контейнер отображает URL регистрации /logon, который отображается в JSP-страницу logon.jsp. Эта страница содержит форму, которая требует от пользователя ввода идентификатора и пароля. Web-контейнер извлекает эту информацию, отображает ее в роль безопасности и проверяет, соответствует ли эта роль установленной в ограничении безопасности. Обратите внимание, что для того, чтобы Web-контейнер проверял правильность аутентификационной информации и выполнял отображение, при размещении приложения необходимы следующие шаги:

1.Добавьте группу пользователей, ID и пароль в область контейнера по умолчанию (см. раздел J2EE-пользователи, области и группы).

2.Отобразите роль BankCustomer на пользователя или группу пользователя (см. раздел J2EE-пользователи, области и группы).

После аутентификации пользователя введенный пользователем идентификатор используется как ключ для идентификации счетов пользователя. Идентификатор извлекается из запроса следующим образом:

<% ArrayList accounts = .getAccountController().getAccountsOfCustomer(

request.getUserPrincipal().getName())

Создание системы электронной коммерции 1 Корпоративные компоненты На рисунке 1 показана об

Больше работ по теме: