15
переговоров, переписки, соглашений и прочее. Это очень удобный инструмент
для быстрой и качественной работы с огромными массивами информации о
клиентах. Эффективное управление клиентами способствует реализации
маркетинговой стратегии предприятия на рынке и позволяет получить
конкурентные преимущества за счет более быстрой реакции на изменения
спроса потребителя. На основе этих знаний разрабатываются новые концепции
продвижения товаров или услуг и таким способом предприятие достигает
поставленных целей и улучшает свой финансовый показатель.
БД складских запасов содержит информацию о текущих складских
запасах, наличия там товаров, зарезервированной продукции. Менеджеры
всегда могут видеть наличие и количество товаров на складе. С помощью базы
данных складских запасов ответственные сотрудники могут следить за
выполнением плана закупок нужных товаров.
БД реестра товаров представляет собой полный перечень товарного
ассортимента имеющегося в организации.
БД продаж сохраняет для конкретного менеджера данные о текущих
объемах продаж и планах продаж. Информация, содержащаяся в базе данных
продаж позволяет составлять планы по различным показателям (доход с
продаж по менеджерам, отделам, продуктам и др.). По истории продаж групп
товаров можно выстроить стратегию продаж, которая позволяет определять
проблемные зоны в циклах продаж.
База данных отчетной информации служит для хранения информации о
деятельности предприятия, данных сравнительного анализа и прогнозы продаж
для конкретного пользователя. База данных отчетной информации
обеспечивает широкие возможности автоматизации документооборота на
торговом предприятии, в систему можно ввести шаблоны любых документов,
которые используются в торговой организации, при этом исчезает
необходимость ручного составления нового документа при возникновении
события.
16
БД ключей содержит информацию каждого пользователя об открытых и
закрытых ключах, а также по соответствующих документах, которые
инициируют проведение транзакций.
Вся информация в БД сохраняется в виде реляционных таблиц,
содержание которых, способ формирования, целостность и права доступа
формируются в соответствии с положениями теории баз данных [7, 8].
Разработана структура информационного и программного обеспечения
СУБПТП позволяет реализовать широкий спектр функциональных
возможностей системы
управления и обеспечивает автоматизацию бизнес процессов
подразделений компании (маркетинг, продажи,
сервис и др.) в рамках единого информационного поля,
а также оперативный информационный обмен между подразделениями и
сотрудниками предприятия.
1.2 Обзор существующих готовых решений
Отдел закупок компании принимает активное участие в проведении
тендерных конкурсов. Сама процедура проведения тендера является довольно
сложной и основывается на действующих нормативных законах и актах.
Правильная и точная подготовка тендерной документации позволяет надеяться
на успешное проведение тендерных закупок. Процедура проведения тендера
регламентируется соответствующими нормативными документами. Регламент
содержит описание все ключевых точек процесса проведения тендера, а также
описание механизма принятия финальных основных решений по ходу
проведения тендера.
Для улучшения бизнес-процессов компании по проведению тендеров
предлагается проектирование, разработка и внедрение автоматизированной
информационной системы для проведения и архивации тендеров. Данная
информационная система будет иметь удобную систему поиска, которая дает
возможность компании определять тендеры, наиболее выигрышные для
17
компании. Система даст возможность просматривать статистику по
проведённым тендерам, что дает возможность строить стратегию работы отдела
закупок.
Внедрение информационных систем проведения и архивации тендеров на
предприятии повышает уровень зрелости процесса закупок и не требует
глобальных изменений в структуру работы процессов.
Информационные системы, которые сейчас используются для
автоматизации процессов проведения закупок, имеют ряд недостатков,
связанных с их громоздкостью и направленностью на работу с закупщиком, а
не поставщиком в процессе закупок. При проведении тендеров необходимо
указывать конкретные площадки, рассматривать обеспечение безопасности
проведения тендеров, проводить блокирование доступа посторонних к
процессу проведения мероприятий, определять сроки проведения тендеров и
сроки и условия выполнения обязательств по тендерным закупкам. На
сегодняшний день можно отметить следующие сайты, которые автоматизируют
процедуры по проведению электронных тендеров:
«Единая информационная система в сфере закупок»
(http://zakupki.gov.ru/);
«Автоматизированная система торгов «Сбербанк-АСТ»
(http://www.sberbank-ast.ru/);
«Электронная торговая площадка ТЭК Торг» (http://rn.tektorg.ru/);
«В2В «Центр электронных торгов» (https://www.b2b-center.ru/).
Сайт «Автоматизированная система торгов «Сбербанк-АСТ» состоит из
комплекса, в состав которого входят 22 мощных дублирующих сервера. Все
сервера объединены в центр обработки данных. Для поддержки работы
серверов используется серверная операционная системы (ОС) Microsoft
Windows, для поддержки работы базы данных сайта используется СУБД
Microsoft SQL Server. Аппаратное и программное обеспечение дает
возможность ежедневно проводить тендеры, без сбоев и с запасом по нагрузке.
18
Вся нагрузка распределяется между серверами комплекса, которые динамично
распределяют задания между собой.
Для защиты от сайта от внешних распределенных DDoS-атак используется
специальные программные средства от компании «Лаборатория Касперского».
Договор с этой компанией позволяет испытывать на комплексе новые средства
по защите и борьбе с атаками.
Для работы с сервисом, необходимо наличие компьютера с установленной
ОС Microsoft Windows и браузером Internet Explorer лишь определенных версий
в связи с применением криптографической защиты, работающей в конкретном
браузере. Это относится к взаимодействию с документами, подписываемыми в
электронном виде электронной цифровой подписью.
Основными преимуществами данного сервиса является его безотказность,
защищенность и наличие круглосуточной технической поддержка. Но очень
часто при проведении тендерных закупок предприятие вынуждено решать
довольно конкретный круг задач, которые не заложены в функционале
универсальных программ. При настройке универсальных систем под нужды
конкретного предприятия могут возникнуть сложности. Поэтому было принято
решение о разработке собственной информационной системы для проведения и
архивации тендеров.
1.3. Характеристика средств разработки информационных систем
проведения и архивации тендеров
Для реализации информационной системы выбрана трехуровневая
архитектура (рис.1.1).
Трехуровневая архитектура относится к типу архитектуры
информационных систем (или приложений), то есть к способу разделения
приложения к тому, что пользователь видит и использует (так называемый
уровень представления), и о том, что происходит в фоновом режиме на сервер
(область приложений и данных).
Архитектурные слои:
19
Уровень представления (Presentation tier) - часть приложения, которая
видна пользователю; он позволяет вводить требования и представление
результатов. Он зависит от платформы (например, веб-приложений,
приложений Windows, приложений Android и т.д.). Поэтому он может быть
различным для разных устройств или платформ.
Уровень приложения (Application tier) - средний уровень модели
(промежуточное ПО), он обеспечивает расчеты и операции, выполняемые
между вводом-выводом и данными. Также известен как сервер приложений.
Уровень данных (Data tier) - самый низкий уровень модели, он
обеспечивает все операции с данными, то есть системой управления базами
данных и базовыми операциями базы данных для функционального хранения,
выбора, агрегации, обработки, целостности и аудита данных.
Рисунок 1.1 – Трехуровневая архитектура
Преимущество такой архитектуры заключается в том, что она отделяет
отдельные слои, чтобы они не были взаимозависимыми.
Предшественником трехуровневой архитектуры является двухуровневая
архитектура (клиент-сервер).
20
Использование трехуровневой архитектуры на практике: трехуровневая
архитектура используется большим количеством приложений, работающих с
данными. Таким образом, большинство современных корпоративных
приложений, некоторые портальные решения и веб-сайты. В настоящее время
существует трех- или многослойная архитектура, и она используется для
создания более надежных решений. Его преимуществом является более гибкое
распределение выходных данных между пользовательским устройством и
сервером. Кроме того, слой презентации может работать и на недорогом
оборудовании.
Для реализации веб-сервисов можно воспользоваться одной из
технологий SOAP или REST [9-11]. Проведем краткий обзор SOAP и REST.
SOAP - это протокол, который был разработан до REST. Основная идея
разработки SOAP заключалась в том, чтобы программы, созданные на разных
платформах и языках программирования, могли легко обмениваться данными.
REST - был специально разработан для работы с такими компонентами,
как мультимедия, файлы и даже объекты на определенном аппаратном
устройстве. Любой веб-сервис, определенный на принципах REST, можно
назвать веб-службой RestFul [12, 13]. Служба Restful будет использовать
обычные HTTP-команды GET, POST, PUT и DELETE для работы с требуемыми
компонентами.
Одна из наиболее дискуссионных тем - когда следует использовать REST
или когда использовать SOAP при разработке веб-сервисов.
Ниже приведены некоторые ключевые факторы, определяющие, когда
каждая технология должна использоваться для веб-служб.
Службы REST следует использовать в следующих случаях:
Ограниченные ресурсы и пропускная способность. Поскольку сообщения
SOAP более тяжелые по содержанию и потребляют гораздо большую
пропускную способность, REST следует использовать в случаях, когда
ограничение пропускной способности сети является ограничением.
21
Statelessness - если нет необходимости поддерживать состояние
информации от одного запроса к другому, тогда следует использовать REST.
Если нужен информационный поток, в котором некоторая информация из
одного запроса должна перетекать в другую, то SOAP больше подходит для
этой цели. Мы можем взять пример любого онлайн-сайта для покупки. Эти
сайты обычно требуют, чтобы пользователь сначала добавлял элементы,
которые необходимо приобрести в корзину. Все элементы корзины затем
переводятся на страницу оплаты для завершения покупки. Это пример
приложения, которому нужна функция сохранения состояния. Состояние
элементов корзины необходимо перенести на страницу оплаты для дальнейшей
обработки.
Кэширование - если есть необходимость кэшировать много запросов, то
REST - идеальное решение. Иногда клиенты могли запросить один и тот же
ресурс несколько раз. Это может увеличить количество запросов, отправленных
на сервер. При реализации кэша наиболее часто используемые результаты
запросов могут храниться в промежуточном местоположении. Поэтому, когда
клиент запрашивает ресурс, он сначала проверяет кеш. Если ресурсы
существуют, то они не будут поступать на сервер. Таким образом, кэширование
может помочь в минимизации количества поездок, совершаемых на веб-
сервере.
Простота кодирования - Кодирование REST Службы и последующая
реализация намного проще, чем SOAP. Так что если для веб-сервисов требуется
быстрое решение, то REST - это лучший выбор.
SOAP следует использовать в следующих случаях:
Асинхронная обработка и последующий вызов - если есть требование о
том, чтобы клиент нуждался в гарантированном уровне надежности и
безопасности, тогда новый стандарт SOAP для SOAP 1.2 предоставляет
множество дополнительных функций, особенно когда речь идет о
безопасности.
22
Формальные средства коммуникации - если у клиента и сервера есть
соглашение об обменном формате, тогда SOAP 1.2 дает жесткие спецификации
для этого типа взаимодействия. Примером является сайт онлайн-покупки, в
котором пользователи добавляют элементы в корзину до того, как платеж будет
выполнен. Предположим, у нас есть веб-сервис, выполняющий окончательный
платеж. Существует твердое соглашение о том, что веб-служба будет
принимать только имя элемента корзины, цену за единицу и количество. Если
такой сценарий существует, тогда всегда лучше использовать протокол SOAP.
Операции с учетом состояния - если у приложения есть требование о том,
что состояние должно поддерживаться от одного запроса к другому, тогда
стандарт SOAP 1.2 предоставляет структуру WS * для поддержки таких
требований
Проблемы SOAP и REST API [14]. API известен как интерфейс
прикладного программирования и предлагается как клиентом, так и сервером.
В мире клиентов это предлагается браузером, тогда как в мире серверов именно
это обеспечивает веб-сервис, который может быть SOAP или REST.
Проблемы с SOAP API
WSDL-файл. Одной из ключевых проблем SOAP API является сам
документ WSDL. Документ WSDL - это то, что сообщает клиенту обо всех
операциях, которые могут выполняться веб-службой. Документ WSDL будет
содержать всю информацию, такую как типы данных, используемые в
сообщениях SOAP, и то, что все операции доступны через веб-службу.
WSDL-файл является жестким контрактом между клиентом и сервером, и
одно изменение может оказать большое влияние на все клиентские
приложения. Другой ключевой проблемой является размер сообщений SOAP,
которые передаются от клиента к серверу. Из-за больших сообщений
использование SOAP в местах, где пропускная способность является
ограничением, может быть большой проблемой.
Проблемы с API REST.
23
Отсутствие безопасности - REST не навязывает какую-либо безопасность,
такую как SOAP. Вот почему REST очень подходит для общедоступных URL-
адресов, но когда дело доходит до конфиденциальных данных, передаваемых
между клиентом и сервером, REST является худшим механизмом, который
будет использоваться для веб-служб.
Отсутствие состояния - для большинства веб-приложений требуется
механизм с сохранением состояния. Например, если у вас есть сайт покупки, у
которого есть механизм наличия корзины покупок, необходимо знать
количество товаров в корзине до фактической покупки. К сожалению, бремя
поддержания этого состояния лежит на клиенте, который просто делает
клиентское приложение более тяжелым и сложным в обслуживании.
Разница между SOAP и другими методами удаленного доступа
Методы удаленного доступа, такие как RPC (удаленные вызовы
процедур), были широко распространены до того, как появились SOAP и REST.
Различные методы удаленного доступа, которые были доступны, упомянуты
ниже.
DCOM - это модель распределенных компонентных объектов, которая
является запатентованной технологией Microsoft для клиентов для доступа к
удаленным компонентам. Самая большая проблема с этим механизмом
заключалась в том, что для клиентского приложения освобождались ресурсы,
когда это больше не требовалось.
Во-вторых, когда клиент отправлял запрос, то он должен был убедиться,
что запрос был упакован или маршалирован правильно, чтобы веб-служба
могла понять отправленный запрос. Другая проблема заключалась в том, что
если клиентское приложение было основано на Java-приложении, которое
должно было работать с DCOM (Microsoft Technology), дополнительное
кодирование необходимо для обеспечения того, чтобы приложения, созданные
на других языках программирования, могли работать с веб-службами на базе
DCOM.
24
Java RMI - известный как Java Remote Method Invocation, это была
реализация Java описывающая то, как удаленные объекты могут быть вызваны
с помощью удаленных вызовов процедур. Самым большим ограничением этой
технологии было то, что Java RMI можно было запускать только на
виртуальной машине Java. Это означало, что вызывающее приложение также
должно быть запущено на платформе Java, чтобы использовать Java RMI.
CORBA - это архитектура брокера общих запросов. Эта система была
создана для обеспечения того, чтобы приложения, созданные на различных
платформах, могли общаться друг с другом. CORBA базировалась на объектно-
ориентированной архитектуре, но вызывающее приложение не было основано
на этой архитектуре. Основным недостатком этого метода было то, что его
пришлось разрабатывать на отдельном языке, называемом языком определения
интерфейса, и он просто представил дополнительный язык, который должен
был быть освоен разработчиками для использования системы CORBA.
Основные различия между SOAP и этими методами заключаются в
следующем
Работа через HTTP. Все методы RPC имеют одно большое ограничение, и
они не работают в соответствии с протоколом HTTP. Поскольку все
приложения в Интернете должны были работать по этому протоколу, это было
основным препятствием для клиентов, которым приходилось обращаться к
этим веб-службам в стиле RPC.
Работа с нестандартными портами. Поскольку веб-службы стиля RPC не
работали в соответствии с протоколом HTTP, для них должны быть открыты
отдельные порты, чтобы клиенты могли получить доступ к функциям этих веб-
служб.
Одним из ключевых различий между SOAP и REST является то, что
SOAP - это протокол, а REST - архитектурный шаблон.
Другие ключевые различия между протоколом SOAP и REST
заключаются в том, что запросы, отправляемые через REST, как правило,