Программные продукты и системы

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

Очевидным способом построения распределенной системы является подход, при котором для связи взаимодействующих компонентов вырабатывается некий специальный формат данных, а, возможно, даже и протокол связи, и на обеих сторонах создаются программы, умеющие этот формат обрабатывать. При таком способе взаимодействия компонентов системы говорят о жестком (сильном) связывании (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-службами прикладного транспортного протокола 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.