CC BY
293
УДК 004.4(043) 681.513.2
АНАЛИЗ АРХИТЕКТУРЫ РАЗВЕРТЫВАНИЯ РЬМ СИСТЕМ В.В. Сафронов, В.Ф. Барабанов, С.Л. Кенин
В статье приведен обобщенный анализ, архитектур развертывания РЬМ систем
Ключевые слова: PLM, архитектура, SOA, клиент
Системы, сопрягаемые с PLM решениями различных производителей (Siemens, Dassault Systemes, PTC, Aras Corporation, Oracle, SAP, Lotsia) ориентированы на классическую архитектуру развертывания данных системы.
Современные инструменты управления бизнес-процессами позволяют обойтись без ручной разработки и тестирования. Так, с помощью методов моделирования можно проверять корректность исполнения бизнес-логики, представленной в диаграммах, а затем автоматически получать описания этих диаграмм на XML-языках управления бизнес-процессами. Данный подход позволяет упростить вызов Web-сервисов из любого местоположения и их выполнение на основе бизнес-правил.
Сервис ориентированная архитектура (SOA) инициирует использование
альтернативных технологий и подходов для построения приложений посредством связывания сервисов, а не посредством написания нового программного кода. В этом случае, при надлежащем проектировании, применение сообщений позволяет компаниям своевременно реагировать на изменение рыночных условий - "настраивать" процесс обмена сообщениями, а не разрабатывать новые приложения [1].
В частном случае SOA определяет вызов Web-сервисов с помощью средств и языков управления бизнес-процессами. SOA - это термин, применяющийся для описания исполняемых компонентов - таких как Web-сервисы вызываемые другими программами, выступающими в качестве клиентов или потребителей этих сервисов. Эти сервисы могут быть полностью современными - или даже устаревшими - прикладными
Сафронов Виталий Владимирович - ВГТУ, аспирант e-mail: safronov.vitaliy@mail.ru
Барабанов Владимир Федорович - ВГТУ, д-р техн. наук, профессор, e-mail: bvf@list.ru Кенин Сергей Леонидович - ВГТУ, соискатель, e-mail: sergey.kenin@siemens.com
программами, которые активизируются на уровне черного ящика.
В самом общем виде 80А предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (рис. 1.). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.
Реестр сервисов
Рис. 1. Общая схема SOA
Для использования сервиса необходимо следовать соглашению об интерфейсе обращения к сервису - интерфейс должен не зависеть от платформы [2]. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна быть платформонезависимой. Поэтому, как правило, сообщения являются XML-документами, которые соответствуют определенной XML-схеме.
Открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компаниях. Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP [3]. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен
использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.
Web-сервисы являются эффективным инструментом интеграции, в том числе для взаимодействия процессов, выполняемых в различных программных системах. Особое место среди различных спецификаций, предназначенных для описания систем и приложений на уровне бизнес-процессов, занимает язык BPEL4WS [5].
Стратегические преимущества
применения SOA:
— сокращение времени реализации проектов (времени выхода на рынок);
— повышение производительности;
— быстрая и недорогая интеграция приложений и B2B.
Тактические преимущества
использования SOA:
— простота разработки и внедрения приложений;
— использование текущих инвестиций;
— уменьшение риска, связанного с внедрением проектов в области автоматизации услуг и процессов;
— возможность непрерывного улучшения предоставляемых услуг;
— сокращение числа обращений к технической поддержке;
— повышение показателя возврата инвестиций (ROI).
Как и реализация большинства серверных архитектур, SOA PLM ориентирована на использование стандартного HTTP/S протокола связи, для пересылки XML документов между сервером и пользователем. Это способствует открытости, гибкости и расширяемости системы.
Наиболее часто внедряемая
четырехуровневая логическая SOA модель (рис. 2.), содержит следующие компоненты:
— Клиент-приложений: большинство
клиент-приложений, включая приложения, разработанные производителем PLM и его партнерами, являются частью одной из клиентских библиотек PLM. Специально разработанные сборки с использованием WSDL подхода обычно не используют клиентских библиотек или CDM.
— Сервер веб-приложений: в PLM
используются серверы веб-приложений для отображения конечных точек сервиса SOA (используется для всех типов клиентов). Запросы REST-стиля (стандартный HTTP
POST) и SOAP-стиля поддерживаются компонентами PLM, выполняемыми на серверах приложений в соответствии с промышленными стандартами (Microsoft IIS). Основные компоненты SOA, работающие на сервисах приложений осуществляют преобразование запроса в общепринятый формат, адресуемый в логический сервер PLM, находящийся на уровне предприятия. Вебприложения используют существующие приложения и серверы напрямую или через ESB (Enterprise Service Bus - сервисная шина предприятия). Клиентами, как внутренними, так и внешними, могут быть пользователи или абоненты.
— Промышленный уровень (уровень предприятия): логический сервер PLM вместе с серверными компонентами пакета находится на уровне предприятия.
— Уровень ресурсов: уровень ресурсов хранит базу данных PLM. Ни один SOA компонент не является частью уровня ресурсов.
Рис. 2. Четырехуровневая логическая SOA модель
SOA сервисы PLM полностью поддерживаются всеми стандартными четырехуровневыми построениями
архитектуры. SOA сервисы также
поддерживают двухуровневую структуру (рис. 3.). База данных и хранилища файлов остаются на централизованном уровне ресурсов. Обычно, эта конфигурация использует протоколы связи CORBA/IIOP/JDBC больше чем HTTP/S и игнорирует веб-уровень PLM. При создании клиента необходимо использовать один из поддерживаемых языков связи основанный на WSDL [4].
Рис. 3. Двухуровневая логическая SOA модель
Двухуровневая архитектура клиент-сервер разделяет информационную систему на два уровня: представления и хранения данных.
Первый уровень - клиентские компьютеры с прикладными программами, с помощью которых пользователи обращаются по сети к базе данных. Второй уровень - сервер с размещенной на нем базой данных.
Для предотвращения несогласованности различных элементов архитектуры, обработку данных выполняют на одной из двух физических частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент). Данные подходы имеют недостатки. Так использование толстого клиента перегружает сеть, поскольку передаются необработанные, избыточные данные. Помимо этого, усложняется поддержка системы и ее изменение, это связанно с тем, что замена алгоритма вычислений или исправление ошибки требует полной замены всех интерфейсных программ, во избежание несогласованности и потери данных. Применение для обработки информации сервера, вызывает проблему описания встроенных процедур и их отладки. Язык описания встроенных процедур обычно является декларативным и, не допускает пошаговой отладки. Также, систему обработки информации с сервера невозможно перенести на другую платформу.
Большинство современных средств быстрой разработки приложений (RAD), работающих с различными базами данных, реализуют первую стратегию, т. е. "толстый" клиент обеспечивает интерфейс с сервером базы данных, через встроенный SQL. Такой вариант реализации системы имеет ещё один существенный недостаток низкий уровень безопасности. Кроме того, данную систему почти невозможно перенести на Web-уровень, так как для доступа к серверу базы данных используется специализированное клиентское ПО.
Недостатки двухуровневой архитектуры клиент-сервер.
1. "Толстый" клиент:
— сложность администрирования;
— усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;
— усложняется распределение
полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;
— перегружается сеть вследствие передачи по ней необработанных данных;
— слабая защита данных.
2."Тонкий" клиент:
— сложность реализации, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и отсутствуют кроссплатформенные средства отладки;
— производительность программ,
написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках;
— программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
— такие программы полностью непереносимы на другие системы и платформы.
Логическая архитектура двухуровневой модели PLM системы имеет следующий вид (рис. 4.):
— уровень клиента - серверный процесс запускается на стороне клиента;
— уровень ресурсов - включает в себя сервер БД, тома и файловые сервисы.
Рис. 4. Логическая архитектура двухуровневой модели РЬМ системы
Физическая архитектура двухуровневой модели имеет вид (рис. 5.): сервер БД; сервер лицензий; сервер данных; файловый сервер.
Сервер СУБД
Рис. 5. Физическая архитектура двухуровневой модели РЬМ системы
Четырехуровневый клиент - фактически такой же клиент, как и двухуровневый, только вместо непосредственных обращений к службам баз данных и файловым, обращается в серверу приложений (в частности на WebLogic), который обращается к БД и файловым томам, а клиент на базе браузера обращается к веб серверу, а он в свою очередь к серверу приложений. При этом страничка входа - в зоне ответственности веб сервера, а обработка отправленных данных - сервер приложений.
В идеале все процедуры такой модели реализуются так, чтобы изолировать транзакции от специфики механизма СУБД. Теоретически, при этом для переноса приложения, разработанного для работы с механизмом СУБД Microsoft Jet, достаточно всего лишь изменить программные компоненты уровня интерфейса внешнего доступа.
Такие архитектуры более эффективно распределяют модули обработки данных, которые выполняются на одном или нескольких выделенных серверах. В четырехуровневой архитектуре "тонкий" клиент не перегружен функциями обработки данных, а выполняет основную роль системы представления информации, поступающей с сервера приложений. Такой интерфейс реализуется с помощью стандартных средств Web-технологии - браузера, CGI и Java. Это уменьшает объем данных, передаваемых между клиентом и сервером приложений, что позволяет подключать клиентские
компьютеры используя медленные линии. Четырехуровневая архитектура клиент-сервер позволяет корректно распределять полномочия пользователей, так как они получают права доступа не к самой базе данных, а к определенным функциям сервера приложений.
Многоуровневые клиент-серверные
системы достаточно легко переносятся на Web-уровень - для этого достаточно заменить клиентскую часть специализированным браузером, а сервер приложений расширить Web-сервером и программами вызова процедур сервера. Для разработки этих программ используется как Common Gateway Interface (CGI), так и технология Java.
Четырехуровневая модель подразделяется на следующие уровни (рис. 6.):
— уровень клиента - позволяет поддерживать три типа клиентов: Rich Client, Thin Client, Web Client; содержит клиентские приложения, предоставляет пользовательский 72
интерфейс, содержит защищённый файловый кэш;
- уровень WEB - серверные java-приложения 12ЕЕ; направляет клиентские запросы к бизнес-логике, предоставляет клиентам статическое содержимое;
- корпоративный уровень - управляет серверными процессами (С++) для работы с БД; содержит бизнес-логику, применяет правила безопасности, предоставляет клиентам динамическое содержимое;
- уровень ресурсов - заключает в себя сервера БД, томов, файловые сервера; хранит постоянные метаданные (таблицы).
Рис. 6. Логическая архитектура четырехуровневой модели РЬМ системы
Физическая архитектура
четырехуровневой модели включает в себя (рис. 7.): сервер БД; сервер лицензий; сервер данных; файловый сервер; сервер приложений.
Сервер СУБД
Рис. 7. Физическая архитектура четырехуровневой модели РЬМ системы
В данной модели на машине клиента работает только java - Rich Client:
- TC Rich Client 4-го уровня и тонкий клиенты;
- WEB сервер приложений J2EE;
- корпоративный сервер TC;
- сервер БД (Oracle или MsSQL).
Уровень WEB (рис. 8.) обеспечивает связь
между серверными процессами доступа к БД и клиентами. Сервер J2EE обеспечивает связь с пулом процессов tcserver при помощи технологии corba. Также он связан с WEB сервером, через который осуществляется связь с клиентскими приложениями.
приложении данными с данных. МТ управления
Рис. 8. Уровень WEB четырехуровневой модели PLM системы
Особенностью многоуровневых
архитектур является использование
менеджеров транзакций (МТ), которые позволяют одному серверу одновременно обмениваться несколькими серверами баз используется для
распределенными разнородными операциями и согласования действий различных компонентов информационной системы.
Менеджер транзакций - это программа или комплекс программ, с помощью которых можно согласовать работу различных компонентов информационной системы. Логически MT делится на несколько частей:
— коммуникационный менеджер
(Communication Manager) контролирует обмен
Воронежский государственный технический университет
ANALYSIS OF ARCHITECTURE DEPLOYMENT OF PLM
сообщениями между компонентами информационной системы;
— менеджер авторизации (Authorisation Manager) обеспечивает аутентификацию пользователей и проверку их прав доступа;
— менеджер транзакций (Transaction Manager) управляет распределенными операциями;
— менеджер ведения журнальных записей (Log Manager) следит за восстановлением и откатом распределенных операций;
— менеджер блокировок (Lock Manager) обеспечивает правильный доступ к совместно используемым данным.
Таким образом, многоуровневая архитектура клиент-сервер позволяет существенно упростить распределенные вычисления, делая их не только более
надежными, но и более доступными. Использование таких средств, как Java, упрощает связь сервера приложений с клиентами, а менеджеры транзакций обеспечивают согласованную работу сервера приложений с базами данных. В результате, разработчиками PLM решений заложены предпосылки создания сложных
распределенных информационных систем, эффективно использующих преимущества
современных технологий.
Литература
1. Ли К. Основы САПР (CAD/CAM/CAE) / Ли К. СПб.: Питер, 1996. 559 с.
2. Д.Левин, В.Малюх, Д.Ушаков Энциклопедия PLM / Д.Левин, В.Малюх, Д.Ушаков; Издательский дом «Азия», 2008 г. - 448 с.
3. В. Малюх Введение в современные САПР / В. Малюх; Изд-во ДМК Пресс, 2010 г. - 192 с.
4. Д. Ушаков Введение в математические основы САПР / Д. Ушаков; Изд-во Ледас, 2006 г. - 180 с.
5. А. Буланов, О. Шевченко, С. Гусаров Wildfire 3.0. Первые шаги / А. Буланов, О. Шевченко, С. Гусаров; Изд-во Поматур, 2008 г. - 240 с.
V.V. Safronov, V.F. Barabanov, S.L. Kenin
The paper presents a generalized analysis, architectures, deployment of PLM systems Key words: PLM, architecture, SOA, client
