ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.10.2023
Просмотров: 107
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
1. Концепция сервисно-ориентированной архитектуры
2. Обзор публикаций. Определение глубины исследования проблемы
3. Анализ практического применения SOA в ИТ компании
3.1 Описание деятельности компании «ЗАО КРОК Инкорпорейтед»
3.2 Моделирование процесса, протекающего в смежных системах
JOIN будет выполняться гораздо дольше, чем запрос к какому-либо справочнику системы, получению из него идентификатора сущности и вызову веб-сервиса для получения данных из мастер-системы по этому ключу для вывода их на форму.
Для подтверждения этого был проведен эксперимент: в процессе Согласования было замерено открытие формы в системе К2 на шаге Формирование, в которую подтягиваются данные из смежных систем с помощью вызовов методов получения данных. Это время составило 3 секунды. Если бы в Компании была общая база данных для всех систем, то при заполнении карточки договора потребовалось бы объединение таблиц: Agreement (договор), SystemUser (пользователь системы), Organization (организация), Firm (фирма), Direction (направление), Process (процесс), Manufacturer (производитель), Activity (активность) и нескольких других, содержащих большое количество атрибутов и строк каждая, а также несколько промежуточных таблиц-маппингов, описывающих связи многие-ко-многим.
Тестовый SQL-запрос с 1 условием из 8 таблиц произвольной базы данных, где таблицы имеют следующее количество строк: 57414, 7848, 17253, 50971, 116269, 35939, 18224, 26510 строк (что по объему даже меньше, чем справочники систем) выполнялся 9 секунд. Таким образом, выполнение SQL-запроса к массивной базе происходит дольше, чем получение данных с помощью веб-сервисов из распределенных справочников. Поскольку данные преимущественно динамичные, в такой базе будет неизбежно происходить постоянно обновление данных, а также к ней будет поступать слишком много запросов за единицу времени, что также увеличит время выполнения запроса.
Распределенная архитектура позволяет распределять системы и справочники на разные серверы, что повышает быстродействие систем, страхует в случае отказа одного или нескольких серверов и не требует затрат на мощные серверы. Из этого следует, что SOA не только предоставляет гибкий инструмент для управления системами и их модулями и позволяет инкапсулировать бизнес-логику в виде веб-сервисов, но и увеличивает производительность за счет снижения времени обработки одного запроса. Также эта архитектура позволяет организовать данные компании наиболее эффективным образом, а именно разделить их по предметным областям и хранить в разных базах данных, используемых разными системами.
Точкой интеграции принято называть набор правил, механизмов и последовательности вызовов, используемых при интеграции двух или более систем.
Поскольку в процессе Согласования договора преимущественно участвуют ранее описанные системы 1С:ERP, К2 и Финансовый калькулятор, далее будет рассмотрена точка интеграции этих трех систем и перечислены веб-сервисы от каждой системы, опубликованные в реестре. Кроме того, будет представлен пример вызова одного из сервисов в формате XML, также представленного на интеграционной схеме. Описание систем, участвующих в интеграции представлено в Таблице 3.2.
Таблица 3.2. Точка интеграции по процессу Согласование договора
Далее будет рассмотрен один из веб-сервисов системы Финансовый калькулятор под названием Integration, и представлено описание одного из методов сервиса (CheckAgreement). Затем будет проанализирована датаграмма одного вызова этого сервиса и ответа смежной системы.
Веб-сервис Integration, поставляемый системой Финансовый калькулятор, предназначен для интеграции систем ФК и К2, ФК и 1С. Методы (операции веб-сервиса) включают:
CheckOutAgreementPlanData: метод для блокировки плановых данных договора в системе ФК, необходим для прекращения всем пользователям доступа к редактированию договора в момент работы с этим договором другого пользователя;
CheckInAgreementPlanData: метод для снятия блокировки с плановых данных договора при прекращении с ним пользовательской работы;
MarkAsOfficial: метод для пометки последней версии договора, как окончательной;
CreatePDAVersion: метод для перевода чернового варианта договора в официальный и включения этой версии в проект;
SetAgreementPlanDataProperties: метод для получения изменений по договору, произведенных в др. системах (напр., различные статусы утверждения);
GetPlanData: метод для получения плановых данных;
CheckAgreement: метод для проверки наличия договора в системе (напр., чтобы убедиться, что сущность просинхронизировалась успешно из учетной системы);
CheckConfirmDocumentDrafts: метод для проверки наличия черновиков в системе.
Рассмотрим подробнее метод CheckAgreement. Метод CheckAgreement вызывается при первоначальном создании карточки договора в 1С на шаге Формирование. При этом в случае отсутствия договора в ФК при вызове метода CheckAgreement система ФК запрашивает данные по договору из системы 1С посредством шины (с помощью метода GetAgreementData, метод из другого веб-сервиса, опубликованного системой 1С). На основании полученных данных в системе ФК создается договор, после чего передается ответная информация о наличии договора в К2 через шину (см. Приложение 4).
Согласно требованиям к производительности из ТЗ: время на обработку одного вызова при наличии договора в ФК - не более 1сек., при отсутствие договора в ФК - не более 2 секунд, не считая времени выполнения метода GetAgreementData.
Пример входящего на ФК вызова CheckAgreement в виде XML-датаграммы, в которой передается параметр-идентификатор договора приведен ниже. Записи взяты из журнала интеграционных логов системы ФК данные получены запросом к таблице интеграционных логов:
SELECT * FROM IntegrationLogEntry AS ile.[TimeStamp] < '2017-04-20 14:59:33.007' and ile.[TimeStamp] > '2017-04-20 14:50:33.007' AND(ile.[Content] AS NVARCHAR(MAX)) LIKE '%CheckAgreement%'BY ile.[TimeStamp] DESC
Время сделанного вызова 2017-04-20 14:52:31.667. Датаграмма входящего сообщения:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
SD17_02425
Ответный вызов, отправленный в 2017-04-20 14:52:31.700. В датаграмме передается статус запроса (StatusCode), означающий успешную вставку договора в систему ФК:
Для подтверждения этого был проведен эксперимент: в процессе Согласования было замерено открытие формы в системе К2 на шаге Формирование, в которую подтягиваются данные из смежных систем с помощью вызовов методов получения данных. Это время составило 3 секунды. Если бы в Компании была общая база данных для всех систем, то при заполнении карточки договора потребовалось бы объединение таблиц: Agreement (договор), SystemUser (пользователь системы), Organization (организация), Firm (фирма), Direction (направление), Process (процесс), Manufacturer (производитель), Activity (активность) и нескольких других, содержащих большое количество атрибутов и строк каждая, а также несколько промежуточных таблиц-маппингов, описывающих связи многие-ко-многим.
Тестовый SQL-запрос с 1 условием из 8 таблиц произвольной базы данных, где таблицы имеют следующее количество строк: 57414, 7848, 17253, 50971, 116269, 35939, 18224, 26510 строк (что по объему даже меньше, чем справочники систем) выполнялся 9 секунд. Таким образом, выполнение SQL-запроса к массивной базе происходит дольше, чем получение данных с помощью веб-сервисов из распределенных справочников. Поскольку данные преимущественно динамичные, в такой базе будет неизбежно происходить постоянно обновление данных, а также к ней будет поступать слишком много запросов за единицу времени, что также увеличит время выполнения запроса.
Распределенная архитектура позволяет распределять системы и справочники на разные серверы, что повышает быстродействие систем, страхует в случае отказа одного или нескольких серверов и не требует затрат на мощные серверы. Из этого следует, что SOA не только предоставляет гибкий инструмент для управления системами и их модулями и позволяет инкапсулировать бизнес-логику в виде веб-сервисов, но и увеличивает производительность за счет снижения времени обработки одного запроса. Также эта архитектура позволяет организовать данные компании наиболее эффективным образом, а именно разделить их по предметным областям и хранить в разных базах данных, используемых разными системами.
3.3 Анализ одной точки интеграции
Точкой интеграции принято называть набор правил, механизмов и последовательности вызовов, используемых при интеграции двух или более систем.
Поскольку в процессе Согласования договора преимущественно участвуют ранее описанные системы 1С:ERP, К2 и Финансовый калькулятор, далее будет рассмотрена точка интеграции этих трех систем и перечислены веб-сервисы от каждой системы, опубликованные в реестре. Кроме того, будет представлен пример вызова одного из сервисов в формате XML, также представленного на интеграционной схеме. Описание систем, участвующих в интеграции представлено в Таблице 3.2.
Таблица 3.2. Точка интеграции по процессу Согласование договора
| Система | Описание взаимодействия |
| 1С | Взаимодействие типа сервис-ESB-сервис (в старте 1С вызывает сервис ESB, а ESB вызывает сервис К2, в результирующем потоке К2 вызывает сервис ESB, а ESB вызывает сервис 1С). |
| Корпоративная сервисная шина (enterprise service bus - ESB) | Принимает вызовы сервисов других систем и с помощью своих собственных сервисов вызывает другие смежные системы. |
| Система К2 | Взаимодействие типа сервис-ESB-сервис (в старте 1С вызывает сервис ESB, а ESB вызывает сервис К2, в результирующем потоке К2 вызывает сервис ESB, а ESB вызывает сервис 1С). |
| Финансовый калькулятор (ФК) | Взаимодействие типа К2-ESB-ФК (в процессе К2 вызывает сервис ESB, а ESB вызывает сервис ФК, в результирующем потоке К2 вызывает сервис ESB, а ESB вызывает сервис ФК). Взаимодействие типа ФК-ESB-1С (в процессе ФК вызывает сервис ESB, а ESB вызывает сервис 1С, в результирующем потоке 1С вызывает сервис ESB, а ESB вызывает сервис ФК). |
Далее будет рассмотрен один из веб-сервисов системы Финансовый калькулятор под названием Integration, и представлено описание одного из методов сервиса (CheckAgreement). Затем будет проанализирована датаграмма одного вызова этого сервиса и ответа смежной системы.
Веб-сервис Integration, поставляемый системой Финансовый калькулятор, предназначен для интеграции систем ФК и К2, ФК и 1С. Методы (операции веб-сервиса) включают:
CheckOutAgreementPlanData: метод для блокировки плановых данных договора в системе ФК, необходим для прекращения всем пользователям доступа к редактированию договора в момент работы с этим договором другого пользователя;
CheckInAgreementPlanData: метод для снятия блокировки с плановых данных договора при прекращении с ним пользовательской работы;
MarkAsOfficial: метод для пометки последней версии договора, как окончательной;
CreatePDAVersion: метод для перевода чернового варианта договора в официальный и включения этой версии в проект;
SetAgreementPlanDataProperties: метод для получения изменений по договору, произведенных в др. системах (напр., различные статусы утверждения);
GetPlanData: метод для получения плановых данных;
CheckAgreement: метод для проверки наличия договора в системе (напр., чтобы убедиться, что сущность просинхронизировалась успешно из учетной системы);
CheckConfirmDocumentDrafts: метод для проверки наличия черновиков в системе.
Рассмотрим подробнее метод CheckAgreement. Метод CheckAgreement вызывается при первоначальном создании карточки договора в 1С на шаге Формирование. При этом в случае отсутствия договора в ФК при вызове метода CheckAgreement система ФК запрашивает данные по договору из системы 1С посредством шины (с помощью метода GetAgreementData, метод из другого веб-сервиса, опубликованного системой 1С). На основании полученных данных в системе ФК создается договор, после чего передается ответная информация о наличии договора в К2 через шину (см. Приложение 4).
Согласно требованиям к производительности из ТЗ: время на обработку одного вызова при наличии договора в ФК - не более 1сек., при отсутствие договора в ФК - не более 2 секунд, не считая времени выполнения метода GetAgreementData.
Пример входящего на ФК вызова CheckAgreement в виде XML-датаграммы, в которой передается параметр-идентификатор договора приведен ниже. Записи взяты из журнала интеграционных логов системы ФК данные получены запросом к таблице интеграционных логов:
SELECT * FROM IntegrationLogEntry AS ile.[TimeStamp] < '2017-04-20 14:59:33.007' and ile.[TimeStamp] > '2017-04-20 14:50:33.007' AND(ile.[Content] AS NVARCHAR(MAX)) LIKE '%CheckAgreement%'BY ile.[TimeStamp] DESC
Время сделанного вызова 2017-04-20 14:52:31.667. Датаграмма входящего сообщения:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
Ответный вызов, отправленный в 2017-04-20 14:52:31.700. В датаграмме передается статус запроса (StatusCode), означающий успешную вставку договора в систему ФК: