На правах рекламы:
ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Авторитетность издания

ВАК - К1
RSCI, ядро РИНЦ

Добавить в закладки

Следующий номер на сайте

2
Ожидается:
17 Июня 2024

Целесообразность применения web-служб в распределенных автоматизированных системах военного назначения

Статья опубликована в выпуске журнала № 2 за 2005 год.
Аннотация:
Abstract:
Автор: Кеменов А.Ф. () -
Ключевое слово:
Ключевое слово:
Количество просмотров: 14447
Версия для печати
Выпуск в формате PDF (1.97Мб)

Размер шрифта:       Шрифт:

В современных распределенных автоматизированных системах военного назначения (АС ВН), как правило, должно обеспечиваться взаимодействие как между внутренними функциональными подсистемами, так и с внешними системами – в рамках единого информационного пространства Министерства обороны РФ.

Очевидным способом построения распределенной системы является подход, при котором для связи взаимодействующих компонентов вырабатывается некий специальный формат данных, а, возможно, даже и протокол связи, и на обеих сторонах создаются программы, умеющие этот формат обрабатывать. При таком способе взаимодействия компонентов системы говорят о жестком (сильном) связывании (tight coupling). Совершенствование протоколов взаимодействия и форматов данных в такой системе в процессе развития информационных технологий требует больших финансовых и временных затрат. Тем не менее, именно таким образом связаны подсистемы большинства современных распределенных АС ВН.

В дополнение к традиционному подходу при построении современных распределенных АС ВН возможно использовать архитектуру, между компонентами которой осуществляется так называемая слабая связность (loose coupling). Слабая связность предполагает, в частности, что компонентам системы не обязательно знать, как устроены взаимодействующие с ними подсистемы, а для расширения взаимодействия нет необходимости в определении новых форматов данных и в расширении специальных протоколов связи. Эта архитектура основана на использовании так называемых web-служб [1,2].

Самый простой вариант взаимодействия с внешними системами может быть достигнут при реализации в каждой из взаимодействующих систем стандартной электронной почты по протоколу SMTP (Simple mail transfer protocol) и использование стандартных форматов сообщений. Использование документов в форматах MS Office, ставших стандартом де-факто в офисном документообороте, не следует принимать за основу. Более подходящим для этой цели является использование сообщений в формате XML (eXtensible markup language). Текстовый XML-документ имеет одинаковое представление на любой платформе, может хранить любые данные и легко передаваться по сетям передачи данных. Обмен XML-сообщениями положен и в основу web-служб.

Для определения особенностей web-служб рассмотрим их в сравнении с другими технологиями построения распределенных систем [2]. Наиболее известными из таких технологий являются CORBA и DCOM.

CORBA (Common object request broker architecture) – это технология создания распределенных систем в соответствии со спецификациями, предлагаемыми консорциумом OMG (Object management group). Спецификация CORBA 1.1 была представлена в 1991 году и стала первой серьезной технологией построения распределенных систем, предлагающей реальную независимость от инфраструктуры, сетевых протоколов, операционных систем и языков программирования. В основе CORBA лежат три понятия:

-    язык описания интерфейсов OMG IDL (Interface definition language), с помощью которого описываются интерфейсы всех объектов, участвующих во взаимодействии;

-    брокер объектных запросов ORB (Object request broker), являющийся посредником, промежуточным звеном системы и скрывающий в себе всю сложную логику взаимодействия клиентского приложения с серверными объектами;

-    протокол IIOP (Internet inter-ORB protocol), обеспечивающий транспортную поддержку для запросов клиента и ответов сервера, а также взаимодействия между ORB.

К сожалению, на практике ORB от различных производителей оказались несовместимыми (или не полностью совместимыми), что не позволило строить на основе CORBA распределенные системы, действительно не зависимые от платформы и поставщика программного обеспечения для промежуточного слоя.

DCOM (Distributed common object model) – технология создания распределенных систем, разработанная фирмой Microsoft на основе модели COM. Как известно, COM использует двоичную структуру объектов, что в некотором смысле является ее достоинством, позволяя использовать для работы различные языки программирования (С++, Visual Basic, Visual J++ и др.). С другой стороны, такая архитектура определяет и главный недостаток COM/DCOM: каждый компонент распределенного DCOM-приложения должен обязательно выполняться под управлением операционной системы Windows. Хотя Microsoft неоднократно декларировала, что DCOM будет перенесена на другие платформы, эти обещания так и не были выполнены.

Следует заметить, что, кроме CORBA и DCOM, существовали и существуют другие модели для удаленных вызовов в распределенных системах. Однако все они, обладая теми или иными ограничениями, не смогли завоевать популярности у разработчиков распределенных систем. Скажем, технология RMI (Remote method invocation) поддерживает вызов методов удаленных объектов, но только в том случае, когда и клиентская, и серверная части являются Java-приложениями. В этом качестве она с успехом используется, например, для вызова методов EJB-объектов в распределенных J2EE-приложениях (наряду с протоколом IIOP и некоторыми сервисами CORBA).

В упомянутых выше технологиях легко можно выделить некоторые общие черты. В частности, каждая из них предлагала некий транспортный протокол для обмена данными между компонентами (IIOP в CORBA, RPC в DCOM), формат для передачи значений по этому протоколу (CDR, NDR), а также способ адресации серверных объектов (IOR, OBJREF). Относительные неудачи технологий во многом были вызваны сложностью и несовместимостью указанных стандартов и форматов.

Технология web-служб предполагает, что для взаимодействия распределенных систем используются распространенные коммуникационные протоколы (HTTP, SMTP), универсальный язык разметки XML, а в качестве ссылки на серверные объекты используется URI (Unified resource identifier). Обмен информацией осуществляется с помощью простого протокола доступа к объектам (Simple object access protocol, SOAP). Каждая служба описывает собственные возможности на языке WSDL (Web services description language – язык описания web-служб). Теоретически любая прикладная программа, которой требуется определенная услуга, может с помощью средств UDDI (Universal description, discovery and integration) найти соответствующую службу, по ассоциированному документу на языке WSDL определить ее функциональные возможности и немедленно обратиться к ее средствам. Все обмены являются текстовыми и не зависят от платформы. Для сравнения в таблице приведены  стандарты, используемые web-службами, CORBA и DCOM.

Характеристика

web-службы

CORBA

DCOM

Транспортный протокол

HTTP, SMTP

IIOP

RPC

Формат сообщения

SOAP (XML)

CDR

NDR

Способ адресации

URI

IOR

OBJREF

Для условий построения АС ВН особое значение приобретает возможность использования web-службами прикладного транспортного протокола SMTP (или иного асинхронного протокола обмена сообщениями). Дело в том, что значительное количество унаследованных защищенных каналов передачи данных не позволяют использовать протокол TCP/IP, но могут обеспечить асинхронную передачу сообщений. Создание на границах этих каналов соответствующих шлюзов позволит использовать их для взаимодействия посредством web-служб.

Защита информации при использовании web-служб может быть произведена на основе спецификации Web services security: SOAP message security 1.0 [3], одобренной организацией OASIS (Organization for the advancement of structured information standards) в апреле 2004 г. Эта спецификация позволяет реализовать в протоколе SOAP методы защиты целостности сообщений и сохранения их конфиденциальности, а также определяет особенности обмена информацией, касающейся защиты данных.

Стандарт web services security обеспечивает возможность присоединения к сообщению одного из нескольких типов защитных маркеров. Маркер безопасности отправителя содержится в элементе SOAP-сообщения и состоит из ряда заявок. Отправитель заявки на некоторое конкретное имя и на определенный объем полномочий одновременно предоставляет средства для проверки правомочности этих притязаний. В большинстве случаев маркеры заверяются цифровыми подписями XML signature. Их аутентичность может проверяется несколькими способами, в частности с помощью сертификата X.509. В результате проверки сертификата подтверждается подлинность имени субъекта и его полномочий, а наличие цифровой подписи XML signature свидетельствует о том, что содержание сообщения не было изменено. В случае необходимости часть сообщения или все его содержимое могут быть зашифрованы в соответствии со стандартом XML encryption.

Реализация элементарных web-служб на основе существующих web-технологий достаточно проста и может быть выполнена как с помощью традиционных средств разработки типа Delphi/Kylix, содержащих компоненты для формирования SOAP-сообщений, так и с помощью специализированных средств типа Java или PHP. Особенно эффективно web-службы реализуются на платформе Apache tomcat, являющейся эталонной средой для исполнения Java-сервлетов [3].

Для использования в АС ВН средства реализации web-служб должны базироваться на отечественных защищенных технологиях (платформа МСВС). Публикация Sun microsystems исходного кода Java 5 (1.5) в конце 2004 г. позволяет рассчитывать на перенос технологии Java на платформу МСВС и реализацию web-служб средствами защищенного web-сервера. При удачной реализации защищенных web-служб на платформе МСВС эта технология может быть внедрена во многих АС ВН, требующих совместимых решений по взаимодействию.

Список литературы

1. Ньюкомер Э. Веб-сервисы для профессионалов. – СПб.: Питер, 2003.

2. Разумовский К. Введение в технологию web-служб. Ч. 1. // Компьютерные вести. - № 43. - 2002 (www.kv.by/index2002430601.htm).

3. Бекет Г. и др. Java: основы web-служб. - М.: Кудиц-Образ, 2004.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=539&lang=&lang=&like=1
Версия для печати
Выпуск в формате PDF (1.97Мб)
Статья опубликована в выпуске журнала № 2 за 2005 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: