КОРОЛЕВ Владимир Сергеевич

Некоторые аспекты построения интегрированных систем безопасности.
Архитектура автоматизированных систем

Источник: журнал "Специальная Техника" № 4 2007 год
 

Рано или поздно должностные лица, отвечающие за безопасность вверенного объекта, оказываются перед проблемой выбора автоматизированной системы охраны. И совершенно не важно, происходит ли это на этапе проектирования или в процессе эксплуатации. Хорошо если при этом есть ведомственные рекомендации, хоть как-то ограничивающие и сужающие пространство поиска. А если нет? При таком обилии рекламных предложений, красивых интерфейсов и обещаний золотых гор. Какими критериями руководствоваться? А если учесть, что бюджет всегда ограничен, как получить максимальное качество при минимальных затратах?

Сравнение различных автоматизированных систем охраны объектов, подавляющее большинство которых гордо именуются интегрированными системами безопасности (ИСБ), задача действительно сложная. И дело здесь вот в чем. Например, никому и в голову не придет сравнивать между собой симпатичный садовый домик с серой пятиэтажкой или современной высоткой. И уж тем более задавать вопрос − что лучше? А вот в области автоматизированных систем обеспечения безопасности объектов такая ситуация встречается достаточно часто. Потому что за красивой оболочкой, набором «наукоемких» фраз порой очень сложно разглядеть, а что же система «игрек» представляет собой на самом деле и какова ее предпочтительная область применения.

Процесс разработки и построения автоматизированной системы очень похож на строительство здания − строительство и того, и другого представляет собой сложный, трудоемкий процесс, зачастую с малопредсказуемым результатом (бюджет, сроки, отступления от проекта и т.д.). И если рассматривать автоматизированную систему как единство закономерно расположенных и взаимосвязанных частей, решающих общую задачу, то ответ на вопрос, какой она будет по окончании разработки, и какие будет иметь потребительские свойства, в первую очередь будет определяться ее архитектурой. Потому что именно архитектура описывает компоненты системы и их взаимосвязи, определяет принципы развития, совершенствования и поддержки, определяет класс объектов, на которых ее применение будет наиболее эффективным. Продолжая аналогию со строительством, можно сказать, что архитектура жилого дома, спроектированного для Египта или Саудовской Аравии, вряд ли будет пригодна для Сибири.

К сожалению, такая актуальная тема, как построение интегрированных систем безопасности объектов в настоящее время еще достаточно слабо освещена. Да и вообще, в этой области много «белых» пятен: вопросы стандартизации, терминологии, классификации технических средств, архитектуры систем − все это требует самого пристального внимания и тщательного анализа. Цель данной статьи − рассмотреть некоторые вопросы, связанные с архитектурой автоматизированных систем охраны объектов.

Результат поиска по словосочетанию «интегрированная система безопасности» совершенно не удивил. Понятно, почему одна поисковая машина сразу же выдала около тысячи ссылок, а вторая и того больше. Сегодня все, что представляет собой компьютер, к которому подключено какое-либо сигнализационное устройство и телекамера, называется ИСБ.

Учитывая сложность предмета обсуждения необходимо все-таки более строгое определение. Интегрированная система безопасности − это совокупность организационных и технических мероприятий, позволяющих на базе универсального программного обеспечения и программно-аппаратных средств осуществить автоматизированное получение, гарантированную доставку и отображение информации при обнаружении в контролируемых точках потенциально опасных ситуаций в целях принятия своевременных мер по их предупреждению и пресечению [1]. Основой ИСБ является автоматизированная система (АС), объединяющая в единое целое средства охраны периметра, управления доступом, телевизионного наблюдения и т.п., то есть все то, что необходимо для обеспечения безопасной эксплуатации объекта. Поэтому, в данном случае, при обсуждении вопросов архитектуры речь пойдет исключительно об автоматизированных системах и особенностях их построения.

Следующим шагом необходимо выбрать тип объектов, на которых АС проявляют весь свой потенциал. Имеет смысл рассматривать автоматизированные системы, позиционируемые как предназначенные для крупных, важных и особо важных объектов. Потому что именно на таких объектах в полной мере требуется реализовывать заявленную функциональность и максимально проявляются возможности систем, их сильные и слабые стороны.

Основная задача, решаемая при охране объекта − это предупреждение и предотвращение проникновения нарушителей на объект, а также предотвращение несанкционированных действий как внешних, так и внутренних нарушителей в отношении инфраструктуры, имущества и персонала объекта. Таким образом, автоматизированную систему охраны объекта необходимо рассматривать как специализированное средство, инструментарий, помогающий службам безопасности, войсковым и военизированным подразделениям решать задачи по охране объектов.

Такой подход позволяет сформулировать критерии оценки потенциальных возможностей различных архитектурных решений при условии, что рассматриваемые системы имеют примерно одинаковую функциональность:

• надежность, как способность системы сохранять свою работоспособность при выходе из строя ее составных частей и обеспечивать гарантированную доставку сообщений в целях исключения потерь информации о существенных событиях;

• масштабируемость, как увеличение функциональных возможностей системы в процессе ее эксплуатации без останова работы.

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

Производители отечественных автоматизированных систем [2 − 9], отобранных по соображениям, приведенным выше, по крайней мере, в одном поразительно единодушны. Все предлагают сетевые распределенные системы, являющиеся, по сути, автоматизированными системами управления технологическим процессом. Все рассматриваемые варианты, с небольшими отличиями, построены по одной схеме: верхний уровень − принятие решений и отображение информации, средний уровень − преобразование протоколов и интерфейсов, нижний − уровень периферийных контроллеров, управляющих техническими средствами (рис. 1).

Верхний и нижний уровни рассматриваемых систем структурно и функционально практически одинаковы. Верхний уровень составляют различного рода автоматизированные рабочие места (АРМ), серверы баз данных и т.д., объединенные в локальную сеть на базе семейства протоколов TCP/IP. На нижнем уровне располагаются периферийные контроллеры, непосредственно взаимодействующие с техническими средствами. Взаимодействие со средним уровнем осуществляется, как правило, по RS485, хотя иногда используется RS232.

Наибольший интерес представляет архитектурное решение среднего уровня, являющегося ключевым, определяющим основные и наиболее важные особенности функционирования системы. Здесь уже нет единодушия и представленные варианты можно свести к трем следующим (рис. 2):

• централизованное управление на базе многофункционального контроллера или сервера (вариант а);

• децентрализованное управление на базе специализированного АРМ или сервера (вариант б);

• одноранговые системы без централизованного управления (вариант в)*.

*) Несмотря на то, что у каждого производителя своя собственная терминология, существа дела это не меняет.

Вариант построения системы, представленный на рис. 2а, встречается наиболее часто. Скорее всего, исторически сложилось так, что система «росла» из контроллера. По-видимому, сначала был разработан или приобретен некий многофункциональный прибор, и впоследствии, по мере роста потребностей заказчика и сложности решаемых задач, к нему добавлялось необходимое оборудование и программное обеспечение. В результате разработчик оказался заложником проблемы обеспечения совместимости «снизу – вверх», когда с выпуском каждой последующей версии внесение кардинальных изменений становилось все более и более затратным и проблематичным. В пользу этой гипотезы говорит то, что в качестве интерфейса связи с сервером, в большинстве случаев, используется RS-232, который вполне можно было использовать для начального конфигурирования контроллера и периодической передачи небольших блоков данных, но не более того.

Все, что может сломаться, когда-нибудь обязательно сломается. При всех достоинствах данное архитектурное решение не является самым эффективным с точки зрения обеспечения надежности. В этой схеме «узким» местом является контроллер, в котором сосредоточена вся бизнес-логика функционирования охраняемого объекта, и в случае выхода его из строя последствия могут быть весьма серьезными (если распределить бизнес-логику между сервером и контроллером, ситуация может быть еще хуже). Этот факт подразумевает наличие повышенных требований к программному обеспечению (ПО) собственно контроллера, повышенные требования к периферийным контроллерам и необходимость использования сложных схем резервирования.

Следующим по значимости «узким» местом этой схемы является сервер, который, скорее всего, хранит резервную копию базы данных (модель объекта) и предоставляет интерфейс для верхнего уровня. Сервер должен периодически опрашивать контроллер в целях получения информации об актуальном состоянии контролируемых точек и передачи ее «заинтересованным» узлам. К сожалению, в этом случае обеспечить функционирование в рамках событийной модели и режиме реального времени практически невозможно в силу ограничений, присущих RS-232.

Следует отметить, что система, построенная таким образом, совершенно не чувствительна к сбоям локальной сети и другого оборудования верхнего уровня. Даже если предположить, что будет нарушена работоспособность локальной сети, контроллер будет продолжать функционировать.

Существуют модификации этой схемы. Например, когда один сервер управляет несколькими контроллерами. Такое решение более эффективно по сравнению с рассмотренным выше, но тем не менее и здесь, как и в любой другой централизованной системе, весьма велика вероятность «падения» всей АС в целом.

Что касается масштабируемости систем, построенных на основе этого архитектурного решения, то здесь справедливы следующие замечания. Во-первых, при добавлении нового оборудования нижнего уровня необходимо будет вносить изменения в базу данных контроллера. В большинстве случаев это действие влечет за собой последующий рестарт контроллера, что, по сути, равносильно рестарту всей системы в целом. Однако на крупном действующем объекте такое событие связано с серьезными организационными трудностями. Во-вторых, избавиться от рестарта можно, реализовав некий вариант технологии «plug and play». Это однозначно приведет к усложнению ПО и соответственно увеличению количества ошибок и увеличению вероятности нестабильной работы контроллера. В-третьих, ситуация существенно облегчается в случае централизованного управления сервером несколькими контроллерами, т.к. при этом требуется рестарт только модифицированной части системы.

Архитектурное решение, реализованное по схеме, приведенной на рис. 2б, подразумевает наличие нескольких равноправных узлов, каждый из которых управляет своим набором оборудования нижнего уровня (периферийных котроллеров). При этом управляющим элементом может быть либо АРМ, либо выделенный сервер.

Стоит отметить, что существует схема, когда АРМ взаимодействует с многофункциональным контроллером, который, в свою очередь, управляет периферийными контроллерами. Эта схема является разновидностью решения рис. 2а и подробно рассмотрена выше.

Данное решение можно было бы отнести к категории одноранговых систем (рис. 2в). Однако схема с управляющим АРМ или сервером имеет свои принципиальные особенности и поэтому рассматривается как самостоятельный, достаточно часто встречающийся в реальной жизни, вариант построения АС.

Схема с сервером в качестве управляющего элемента какими-либо особыми преимуществами или недостатками не обладает. Минусами такого решения являются, во-первых, повышенная по сравнению с другими стоимость и, во-вторых, необходимость резервирования управляющего элемента. Причем основной вклад в стоимость будет давать не столько оборудование и прикладное ПО, сколько стоимость серверных операционных систем и СУБД плюс стоимость клиентских лицензий. Если представить, что в системе несколько таких управляющих узлов, и каждый из них работает на какое-то количество клиентов, то даже элементарный подсчет дает весьма приличную сумму. Необходимость резервирования будет определяться требованиями заказчика и способом построения нижнего уровня (степенью «интеллекта» периферийных контроллеров). В простейшем случае (такое решение применено в одной из систем) резервирование действительно необходимо и разработчик предлагает это в качестве опции.

Наиболее неудачным решением является вариант, когда в качестве управляющего элемента используется АРМ. В случае выхода из строя этого элемента охраняемый объект может оказаться в весьма сложной ситуации, например, останется без охраны часть периметра или перестанет функционировать набор точек доступа. Самое плохое в этом то, что и персонал в момент аварии останется без «глаз», т.к. и управление оборудованием, и отображение информации оператору «замкнуто» на один элемент. Единственный выход в данной ситуации − это «горячее» резервирование. Однако и этот шаг полностью не решает всех потенциальных проблем, которые присущи данной схеме.

Возможности масштабирования системы с архитектурой, приведенной на рис. 2б, значительно выше, чем у предыдущей схемы с централизованным управлением на базе контроллера. В идеальном случае при добавлении нового оборудования достаточно только экспортировать модифицированную базу данных на соответствующий АРМ или сервер. Эта схема позволяет достаточно просто реализовать программный рестарт, без останова функционирования и перезапуска управляющего элемента.

По сравнению с другими, одноранговые системы (рис. 2в) имеют более серьезные перспективы по своим возможностям. В таких схемах контроллер выступает в качестве равноправного сетевого узла, управляющего своей небольшой частью охраняемого объекта. Это решение позволяет достаточно гибко подойти к построению всей АС, распределив контроллеры так, чтобы минимизировать последствия выхода из строя каждой отдельной ветви. Однако этому решению, также как и другим, присущ типовой недостаток − отсутствие режима реального времени, обусловленный необходимостью «полинга» при организации взаимодействия с периферийными контроллерами. К сожалению, такая реализация не позволяет в полной мере использовать потенциальные возможности одноранговых систем.

С точки зрения масштабируемости, эта схема ничем не отличается от схемы рис. 2б, и здесь справедливы все сделанные выше замечания.

Рассматривая различные аспекты современного «контроллеростроения», можно однозначно утверждать, что в течение последнего десятилетия наблюдаются две устойчивые тенденции. Во-первых, в связи с бурным развитием микроэлектроники и микропроцессорной техники, а также уменьшением стоимости электронных компонентов возрастает уровень «интеллектуальности» контроллеров. Во-вторых, сопутствующее развитие информационных технологий «подстегивает» встраивание контроллеров в различные приборы и устройства, придавая им новые, недоступные прежде качественные характеристики и функциональность, сосредотачивая «интеллект» в месте его использования, т.е. именно там, где он действительно необходим. Ярчайший пример тому − новое поколение бытовой техники. Аналогичная картина наблюдается и на рынке охранных систем: средств управления доступом, технических средств охраны и т.д. Появились приборы, при использовании которых можно не только существенно улучшить тактико-технические характеристики систем, но и уменьшить их стоимость, например, за счет минимизации затрат на кабельную продукцию. Более того, современные контроллеры имеют возможность работать в локальной сети, выступая как равноправные самостоятельные узлы. Это дает основания полагать, что в скором времени и в области автоматизированных систем охраны появятся решения, в полной мере реализующие потенциал одноранговых систем. В качестве иллюстрации можно привести пример интенсивного развития рынка систем жизнеобеспечения и автоматизации зданий с началом использования технологий «полевая шина» (fieldbus). На концепциях «полевой шины», вышедшей из «недр» промышленности, базируются такие известные и широко используемые в этой области стандарты, как BACNet и LonWorks.

Опираясь только на опубликованные данные, невозможно составить обоснованное мнение об особенностях реализации программного обеспечения рассматриваемых систем. Поэтому, основываясь на вышеупомянутой методике и анализе современных тенденций в области информационных технологий, попытаемся сформулировать требования к архитектуре ПО с учетом особенностей данной предметной области. В качестве дополнительных критериев, кроме надежности и масштабируемости, необходимо рассматривать защищенность и интероперабельность как возможность встраивания в систему независимо разработанных программных модулей или подсистем [17].

Сегодня существует большое количество технологий построения распределенных автоматизированных систем как с процедурной, так и объектной парадигмой обеспечения взаимодействия составляющих элементов: RPC (remote procedure call), Java RMI (remote method invocation), CORBA (common object request broker architecture), DCOM (distributed component object model) и т.д. [10, 11] Наиболее перспективным на сегодняшний день считается архитектурное решение − SOA (service oriented architecture), особенно в сочетании с ESB (enterprise service bus) и EDA (event driven architecture), разработанное группой корпораций во главе с IBM и Microsoft [12 − 15].

Каждая из перечисленных технологий имеет свои плюсы и минусы, «нацеленность» на определенную область применения. Однако, несмотря на различия в реализации, перечисленные технологии имеют много общего, что позволяет определить общие тенденции и выбрать проверенные решения. Наиболее важными чертами, реализованными в той или иной мере во всех технологиях, являются:

• объектная (сервисная) парадигма доступа к данным, позволяющая абстрагироваться от физической природы объекта;

• унифицированный, абстрактный способ описания объектов;

• «хранилище» объектов, как способ получения ссылки на объект;

• взаимодействие посредством обмена сообщениями;

• независимый транспорт, синхронный или асинхронный способ взаимодействия;

• сервисная шина − слой программного обеспечения (middle ware), обеспечивающего унифицированный доступ к данным.

Основываясь на тенденциях развития информационных технологий и учитывая специфические требования к автоматизированным системам охраны объектов, можно сформулировать основные требования к архитектуре программного обеспечения:

• система должна строиться как гетерогенная распределенная система с определенными, фиксированными правилами доступа к данным;

• система должна строиться по иерархическому принципу с разграничением функциональности составляющих уровней;

• управляющий уровень должен быть полностью абстрагирован от физической природы используемых приборов и устройств, и оперировать только их логическими эквивалентами;

• взаимодействие управляющего уровня с техническими средствами должно осуществляться через «слой» программного обеспечения, предоставляющего интерфейс к конкретным физическим устройствам;

• элементы системы должны оперировать едиными сущностями и функционировать в рамках единой модели охраняемого объекта;

• элементы системы должны поддерживать «событийную» модель взаимодействия, информируя об изменении своего состояния;

• система должна обеспечивать заданное время реакции на произошедшее событие;

• информационный обмен должен осуществляться сообщениями посредством защищенного протокола с обязательной идентификацией абонента, гарантированной доставкой сообщения и автоматическим восстановлением связи.

Анализ различных способов построения автоматизированных систем позволяет сделать вывод, что в данном случае оптимальным и наиболее полно удовлетворяющим перечисленным требованиям является вариант системы, реализованной как одноранговая слабосвязанная распределенная система по классификации [10].

Под «слабосвязанностью» в данном случае понимается то, что каждый элемент (модуль) системы должен быть в известной мере независимым и самодостаточным, что позволит обеспечить работоспособность системы при выходе из строя любого элемента (с соответствующим уменьшением функциональности всей системы в целом). Другими словами, в системе не должно быть такого элемента (группы элементов), выход из строя которого привел бы к блокированию работы всей системы в целом.

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

От того, насколько эффективно решены вопросы обеспечения масштабируемости и интероперабельности, зависят эксплуатационные характеристики системы, потому что самое большое количество проблем начинает проявляться при добавлении нового, «неизвестного» системе оборудования или попытке встраивании подсистемы другого производителя.

Современные методы решения этих задач подразумевают использование различных технологий «позднего связывания» (late binding, method invocation) или динамического получения ссылки на программный объект, методы и свойства которого не известны на этапе проектирования. Однако все эти технологии в силу своей универсальности очень нетривиальны и сильно избыточны. В результате порождаются новые, дополнительные проблемы, решение которых требует привлечения высококвалифицированных программистов и сильно усложняет систему: в разработке, настройке и сопровождении.

Одна из особенностей рассматриваемой предметной области состоит в том, что она ограничена вполне определенным кругом задач, и здесь не требуется «всеобъемлющая» универсальность. Это создает серьезные предпосылки для оптимизации архитектуры. Для автоматизированных систем данного типа существует более простой и эффективный способ удовлетворения требований масштабируемости и интероперабельности − это обеспечение функционирования системы в рамках единой модели охраняемого объекта.

Описание оборудования, входящего в состав системы: технических средств охраны, средств управления доступом, телевизионных средств и т.д., как набора неких взаимосвязанных абстрактных объектов контроля (контролируемых точек) дает возможность стандартизировать, «узаконить» механизм доступа к данным. Такой подход позволяет при необходимости свободно менять внутренние структуры данных и алгоритмы функционирования без влияния на корректность работы всей системы в целом.

Обобщая сказанное, можно сформулировать требования к модели охраняемого объекта и составляющим ее компонентам:

• модель должна строиться из минимально необходимого набора компонентов − объектов контроля;

• каждый объект контроля должен иметь уникальный идентификатор;

• каждый объект контроля должен быть представлен в виде конечного автомата и иметь фиксированный набор состояний;

• каждый объект контроля должен генерировать системное сообщение при изменении своего состояния;

• модель объекта должна быть масштабируемой, т.е. допускать добавление и удаление объектов контроля в процессе эксплуатации.

Интегрированные системы безопасности, как уже отмечалось, по своему назначению являются автоматизированными системами управления технологическими процессами. Более того, в контуре управления данного технологического процесса основную, определяющую роль играет человек − оператор, принимающий решение. Система только предоставляет информацию о текущем состоянии объекта и при возникновении заранее заданных ситуаций управляет вспомогательным оборудованием: включает запись с телекамер, дополнительное освещение и т.п. Поэтому для системы важно лишь, произошло или нет срабатывание того или иного датчика, исправно ли функционирует то или иное устройство, чтобы вовремя проинформировать оператора о факте наступления некоторого события и предпринять необходимые действия. С точки зрения системы технологический процесс не только дискретен, но и характеризуется еще тем, что для каждого датчика или устройства (объекта контроля) имеется свой заданный, фиксированный набор состояний.

Технические средства, применяемые для охраны объектов, целесообразно сгруппировать в два больших класса, которые можно назвать точками контроля и точками доступа. Предлагаемое деление адекватно отражает суть происходящих процессов. Если не учитывать второстепенные детали, то реально в системе циркулируют два основных потока информации: поток данных управления доступом и поток контрольно-охранной информации. Таким образом, можно говорить о точках доступа и точках контроля как базовых компонентах математической модели. Однако для построения математической модели объекта или процесса необходимо задать еще взаимосвязи между составляющими элементами. Точки доступа и контроля являются лишь источниками сигналов, информирующих о наступлении некоего существенного события. Поэтому в качестве связующего элемента логично использовать объект «зона». Зона, являющаяся объектом контроля контейнерного типа, позволяет не только группировать точки, но и однозначно идентифицировать место возникновения события.

Дополнительным плюсом данного подхода к построению модели является то, что технические средства, сгруппированные таким образом, поддаются очень простой классификации [16], соответствующей парадигме объектно-ориентированного программирования.

Учитывая, что все перечисленные объекты контроля функционируют как конечные автоматы, можно утверждать, что этих элементов достаточно для построения математической модели охраняемого объекта, т.к., основываясь только на этих данных, можно однозначно вычислить состояние объекта в любой момент времени.

Ситуация такова, что инсталляторы и конечные заказчики уже больше не желают становиться «заложниками» производителя системы «икс» или «игрек». Реализация требований открытости и интероперабельности рано или поздно приведет к тому, что автоматизированные системы охраны будут представлять собой некое подобие SCADA, интегрирующие оборудование и подсистемы различных производителей. Более того, в некоторых случаях потребуется объединение и с системами жизнеобеспечения и автоматизации зданий. Хорошо это или плохо, это совсем другой вопрос. Существующие на сегодняшний день реализации нижнего уровня с использованием технологий «полевых шин» дают серьезные основания полагать, что именно так и будет.

Масштабность и сложность систем будет только возрастать. Построить открытую, надежную и защищенную систему можно только лишь в результате ее тщательного проектирования и поэтому вопросы архитектуры автоматизированных систем охраны становятся все более важными и актуальными.

Литература

1. Гооге И.Г. и др. Интегрированные системы безопасности /Мир безопасности, 2001 – №12.

2. www.bolid.ru

3. www.sigma-is.ru

4. www.algont.ru

5. www.bezopasnost.ru

6. www.eleron.ru

7. www.nikiret.ru

8. www.dedal.ru

9. www.itrium.ru

10. Э. Танненбаум, М. Ван Стеен. Распределенные системы. Принципы и парадигмы. /СПб.: Питер, 2003.

11. Д. Бэкон, Т. Харрис. Операционные системы. Параллельные и распределенные системы./СПб.: Питер, Киев: Издательская группа BHV, 2004.

12. Ньюкомер Э. Веб-сервисы.XML, WSDL, SOAP и UDDI. Для профессионалов./ СПб.: Питер, 2006.

13. Леонид Черняк. Поход за Чашей Грааля информационных технологий./Открытые системы, 2006 – №1(117).

14. Алексей Добровольский. Интеграция приложений: методы взаимодействия, топология, инструменты./Открытые системы, 2006 – №9(125).

15. Глеб Ладыженский. Интеграция приложений такая, какая она есть./Открытые системы, 2006 – №9(125).

16. Королев В.С. Классификация компонентов интегрированных систем безопасности./Специальная техника, 2007 – №1.

17. Сергей Кузнецов. Переносимость и интероперабельность информационных систем, и международные стандарты./www.citforum.ru

Статья опубликована на сайте: 23.05.2008