Технология CORBA (Назначение CORBA. Общие положения по применению системы «CORBA»)

Содержание:

Введение

Ядро CORBA брокер (посредник) объектных запросов (ORB). Это что-то вроде магистрали для объектов. Основная задача ORB оказывать посреднические услуги при обмене запросами между объектами. Хотя ORB "обитает" в среде клиент -сервер, объекты, с которыми он работает, выполняют функции либо клиентов, либо серверов, в зависимости от обстоятельств. Если объект принимает и обрабатывает запрос, то он играет роль сервера. Если он отправляет запрос, то выступает в роли клиента. Основная задача ORB прием и отправка запросов, а также передача результатов, в том числе перехват каждого запроса одного объекта другому; определение местонахождения объекта, который, предположительно, обработает запрос; запуск соответствующего метода принимающего объекта; при необходимости передача параметров и передача результатов объекту, инициировавшему запрос. Поскольку ORB обрабатывает запросы "прозрачно", неважно, от какого объекта локального или удаленного поступил запрос. При обработке этих запросов для ORB не имеет значения ни язык программирования, ни операционная система или платформа. Механизм, обеспечивающий "прозрачность" обработки запросов, называется языком определения интерфейса (Interface Definition Language, IDL). Этот язык применяется для объявления границ и интерфейсов объекта. Во многом подобно независимому арбитру, IDL нейтрален и не зависит от объектов и ORB, тем не менее он связывает поставщиков служб распределенных объектов с их клиентами. Всякому, кто знаком с DCOM, наверное, известно, что в модели DCOM используется IDL. Но IDL DCOM несовместим с CORBA и работает иначе, чем IDL CORBA. В CORBA предусматривается множественное наследование, а ее IDL-средствам наследование необходимо для инкапсуляции объектов. Это существенно облегчает многократное использование блоков программ. В DCOM механизм множественного наследования не реализован. Поэтому вы должны подготовить и объединить все интерфейсы, прежде чем к ним обратится клиент. Язык IDL хорош тем, что позволяет кратко описать API, сохранив при этом свободу определить методы на любом языке программирования, который обеспечивает связывание с CORBA. К таким языкам относятся Ада, Кобол, Си, Си++, Smalltalk и Java. У некоторых поставщиков имеются собственные средства согласования с CORBA для Visual Basic и Фортрана. Как известно любому человеку, имевшему дело с объектно-ориентированным программированием, для составления запроса необходимы сведения об интерфейсе принимающего объекта, а объекты должны быть разработаны так, чтобы они могли получать информацию об интерфейсах тех объектов, с которыми они будут взаимодействовать. Но, пытаясь применить этот подход для распределенной между гетерогенными объектами обработки, вы столкнетесь с множеством проблем. Для подлинной независимости IDL в CORBA используется репозиторий (хранилище) интерфейсов, предназначенный для хранения сигнатур методов, принадлежащих объектам, с тем чтобы эти сигнатуры можно было динамически извлекать и обновлять во время исполнения программы. Благодаря этому все объекты в корпоративной системе могут получить информацию об интерфейсах других объектов, методах, принадлежащих этим интерфейсам, и параметрах, необходимых для обращения к ним.

Целью данной курсовой работы является определение назначения CORBA, изучение технологий CORBA и ее объектно-ориентированных компонентов.

1. Назначение CORBA. Общие положения по применению системы «CORBA»

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

Спецификация CORBA предписывает объединение программного кода в объект, который должен содержать информацию о функциональности кода и интерфейсах доступа. Готовые объекты могут вызываться из других программ (или объектов спецификации CORBA), расположенных в сети.

Спецификация CORBA использует язык описания интерфейсов (OMG IDL) для определения интерфейсов взаимодействия объектов с внешним миром, она описывает правила отображения из IDL в язык, используемый разработчиком CORBA-объекта.

Стандартизованы отображения для Ада, Си, C++, Lisp, Smalltalk, Java, Кобол, ObjectPascal, ПЛ/1 и Python.

Также существуют нестандартные отображения на языки Perl, Visual Basic, Ruby и Tcl, реализованные средствами ORB, написанными для этих языков.

1.1 Объекты по значению

Помимо удалённых объектов в CORBA 3.0 определено понятие объект по значению. Код методов таких объектов по умолчанию выполняется локально. Если объект по значению был получен с удалённой стороны, то необходимый код должен либо быть заранее известен обеим сторонам, либо быть динамически загружен. Чтобы это было возможно, запись, определяющая такой объект, содержит поле Code Base — список URL, откуда может быть загружен код. У объекта по значению могут также быть и удалённые методы, поля, которые передаются вместе с самим объектом. Поля, в свою очередь также могут быть такими объектами, формируя таким образом списки, деревья или произвольные графы. Объекты по значению могут иметь иерархию классов, включая абстрактные и множественное наследование.

1.2 Компонентная модель CORBA (CCM)

Компонентная модель CORBA (CCM) — недавнее дополнение к семейству определений CORBA.

CCM была введена начиная с CORBA 3.0 и описывает стандартный каркас приложения для компонент CORBA. CCM построено под сильным влиянием Enterprise Java Beans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через чётко определённые именованные интерфейсы, порты. Модель CCM предоставляет контейнер компонентов, в котором могут поставляться программные компоненты. Контейнер предоставляет набор служб, которые может использовать компонент. Эти службы включают (но не ограничены) службу уведомления, авторизации, персистентности и управления транзакциями. Это наиболее часто используемые распределённым приложением службы. Перенося реализацию этих сервисов от необходимости реализации самим приложением в функциональность контейнера приложения, можно значительно снизить сложность реализации собственно компонентов.

Одной из наиболее распространенных программных систем ЗИ является «Кобра», предназначенная для защиты конфиденциальной информации при обработке и хранении в однопользовательском и многопользовательском режимах эксплуатации ПК. Основными ее потребительскими свойствами являются: качественный уровень ЗИ; высокое быстродействие; технологичность. К основным функциям «Кобры» относятся: идентификация и аутентификация пользователя; парольный вход; накопление, хранение и обработка информации в преобразованном (шифрованном) виде; «прозрачная» ЗИ на уровне логического устройства ПК, логического диска, каталогов и шаблонов файлов; управление доступом; мандатный контроль доступа; регистрация и учет событий; объединение пользователей в группы с общими файлами; защита файлов пользователей на чтение, запись, удаление, переименование, изменение, создание с тем же именем; запрещение запуска программ с дискет; контроль целостности ПО; работа пользователя в привычной среде; индивидуальная и групповая настройка; сигнализация об эталонном изменении целостности ПК; обеспечение полноты функций ЗИ при работе с широким спектром прикладного ПО от пользовательских оболочек до интегральных сред. «Кобра» является многоуровневой системой ЗИ. Защита от загрузки через НГМД в обход «Кобры» путем динамического преобразования информации и специальной технологии взаимодействия модулей защиты. Идентификация и аутентификация путем одностороннего преобразования и хранения только контрольных значений, а не паролей, а также путем использования основных и дополнительных паролей и входе при раздельном вводе независимыми субъектами двух разных паролей. Обеспечение ПРД путем санкционирования доступа, детализацией разграничения доступа к шаблонам файлов и ресурсам ПК, а также блокировкой клавиатуры и экрана. Периодический КЦ системы «Кобра» автоматически (в период загрузки и окончания работы ПК), и вручную (во время процесса работы ПК), а также регистрация действий администраторов и пользователей и самостоятельное восстановление рабочей среды. Специальные преобразования информации в «прозрачную» для легальных пользователей. Кратко рассмотрим подсистемы системы «Кобра». Подсистема обеспечения санкционированного доступа обеспечивает ЗИ на уровне логических дисков. Каждому законному пользователю ЭВМ устанавливаются индивидуальные полномочия по доступу к логическим дискам: запрет доступа, только чтение, полный доступ, суперзащита (гарантия конфиденциальности информации при похищении дискет, жестких дисков, или даже самого ПК). Устанавливаются каждому законному пользователю полномочия доступа к последовательным и параллельным портам ПК по принципу: есть доступ, нет доступа. «Кобра» реализует мандатный принцип контроля полномочий доступа (возможность считать объект, осуществлять запись в объект и осуществлять коррекцию) применительно ко всем объектам при явном и скрытом доступе со стороны любого из пользователей. Для реализации этого принципа сопоставляются классификационные метки каждого пользователя системы и каждого объекта (логических устройств), отражающих их место в соответствующей иерархии. Посредством этих меток пользователям и объектам назначаются классификационные уровни (категории конфиденциальности). При вводе новых данных в систему запрашиваются от санкционированного пользователя классификационные метки этих данных. При санкционированном занесении в список пользователей нового пользователя ему назначаются, в зависимости от уровня доступа, классификационные метки. Подсистема закрытия позволяет закрыть доступ к ресурсам ПК через системную дискету. При этом «Кобра» выдает пользователю специальную системную дискету, с которой, при необходимости, можно загрузиться. Любая другая дискета будет игнорироваться. Подсистема обеспечения целостности рабочей среды ПК осуществляет анализ и фиксацию состояния рабочей среды ПК, которая в дальнейшем принимается как эталонная, контролируется и поддерживается. Подсистема фиксирует: обнаружение несанкционированных изменений в рабочей среде ПК со стороны лиц, получивших доступ к ней; обнаружение несанкционированных изменений, вызванных вредоносными программами; обнаружение искажений в программах и ключевой информации, возникших в результате машинных сбоев или износа магнитного носителя. Подсистема контролирует состояние оперативной памяти ПК, содержание главной корневой записи диска и загрузочного сектора, состояние файлов конфигурирования, автозапуска, файлов с системными и прикладными программами и данными, а также, контролирует действия вирусов (как известных, так и новых). Кроме того, подсистема предоставляет возможность автоматического восстановления основных компонентов рабочей среды ПК, а в случае невозможности автоматического восстановления автоматически сигнализирует об этом пользователю, выдавая данные о поврежденных частях рабочей среды ПК для проведения ручного восстановления. Подсистема регистрации и учета работы предназначена для: регистрации изменений ПРД; регистрация длительности сеанса работа каждого пользователя ПК; регистрация нарушений пользователем инструкций по работе с системой «Кобра»; накопление сведений о работе каждого пользователя на ПК за отчетный период; выдачи по запросу справки о работе за текущий период, в том числе: имя, дата регистрации, общее время нарушений правил работы с «Коброй». Подсистема файлового закрытия информации осуществляет закрытие информации в файлах, в группах файлов, в каталогах, в группах каталогов (с подкаталогами) и логических разделах дисков или дискет. Подсистема представляет собой автоматизированное рабочее место (администратора, оператора компьютерной сети, оператора базы данных или пользователя компьютера, нуждающегося в надежном закрытии своей информации). Подсистема детального разграничения доступа к шаблонам файлов предназначена для разграничения доступа к файлам данных и программ, находящихся на одной ПК. Разграничение производится на уровне каталогов и отдельных файлов, позволяя разграничивать отдельно по чтению записи, удалению, переименованию файлов или каталогов, запуску на выполнение. Подсистема разграничения доступа к ресурсам ПК предназначена для разграничения доступа к функциональным клавишам, файлам, каталогам, командной строке DOS. Подсистема затираний обеспечивает физическое удаление стираемой на магнитных носителях информации. Подсистема регистрации предназначена для контроля действий пользователя с целью выявления некорректных или преднамеренных действий пользователей или вредоносных программ. Подсистема блокировки клавиатуры и монитора предназначена для блокировки работы клавиатуры и монитора при отсутствии ввода информации с клавиатуры. Подсистема создания дополнительных логических дисков предназначена для создания необходимого количество дисков, без предварительного удаления информации с них. Подсистема окончания работы позволяет выполнить проверку целостности рабочей среды с целью обнаружения и исправления действий вирусов, последствий ошибочных действий пользователей и других действий, изменивших рабочую среду при завершении работы ПК. Средства преобразования информации предназначены для преобразования информации в нечитаемый вид с целью возможности ее хранения на внешних магнитных носителях.
 

1.3 Общий протокол межброкерного взаимодействия (GIOP)

GIOP (GeneralInter-ORB Protocol) — абстрактный протокол в стандарте CORBA, обеспечивающий интероперабельность брокеров. Стандарты, связанные с протоколом выпускает Object Management Group (OMG). Архитектура GIOP включает несколько конкретных протоколов:

Internet Inter ORBP protocol (IIOP) (Межброкерный протокол для Интернет) — протокол для организации взаимодействия между различными брокерами, опубликованный консорциумом OMG. IIOP используется GIOP в среде интернет, и обеспечивает отображение сообщений между GIOP и слоем TCP/IP.

SSL InterORBProtocol (SSLIOP) — IIOP поверх SSL, поддерживаются шифрование и аутентификация.

Hyper Text Inter ORB Protocol (HTIOP) — IIOP поверх HTTP.

Corba Loc (англ. Corba Location) — является строковой ссылкой на объект технологии CORBA, подобной URL. Borland Enterprise Server, Visi Broker Ed. — CORBA 2.6-совместимый коммерческий ORB от Borland, поддерживает Java и C++.

• MICO — свободный (LGPL) ORB с поддержкой C++.
• omni ORB — свободный (LGPL) ORB для C++ и Python.
• ORBit2 — свободный (LGPL) ORB для C, C++ и Python.
• Jac ORB — свободный (LGPL) ORB, написан на Java.
• TAO — The ACE ORB, открытый ORB для C++.
• Orbacus — коммерческий ORB для C++, Java от IONA Technologies.

CORBA (CommonObjectRequestBrokerArchitecture) – Общая Архитектура Брокера Объектных Запросов - это стандарт, набор спецификаций для промежуточного программного обеспечения (ППО, middleware) объектного типа. Задача ППО, как известно, заключается в связывании программных приложений для обмена данными.

CORBA программирование распределенных систем Уильям Р. Станек Подготовка прикладных программ, объекты которых составлены на разных языках и взаимодействуют между собой на самых разных ОС и платформах.

Взрывообразный рост Интернета и Web стал причиной появления технологий, в корне меняющих существующие способы применения компьютеров. Наиболее серьезные изменения происходят в объектно-ориентированной технологии, которой провидцы отводят новую роль в системах распределенной обработки. Вместо традиционных вычислительных сетей архитектуры клиентсервер новая эра распределенной обработки влечет за собой переход к системам масштаба предприятия с объектами, которые распределены между множеством компьютеров, способных обмениваться информацией независимо от операционной системы, платформы или языка программирования. Еще удивительнее то, что эти распределенные объекты могут быть компонентами либо одной программы, либо десятков программ, образующих систему, предназначенную для предприятия.

Назовем технологии, позволяющие осуществлять распределенную обработку в гетерогенных системах: это архитектура брокера общих объектных запросов (CommonObjectRequestBrokerArchitecture, CORBA) и протокол InternetInter-ORB Protocol (IIOP). CORBA полностью определяет архитектуру, необходимую для обмена информацией между распределенными объектами. К числу ее спецификаций относятся IIOP и множество других технологий. IIOP самый важный компонент CORBA, потому что его основная функция организация взаимодействия распределенных объектов в гетерогенной среде. Вместе CORBA и IIOP характеризуют многообразие средств промежуточного уровня, которые станут стимулом для пересмотра подходов к созданию прикладных программ в сетевых средах разработчиками всего мира.

CORBA не исключительный варианты решения, обеспечивающего распределенную обработку. Существует и конкурирующая архитектура, разработанная корпорацией Microsoft, объектная модель распределенной обработки (DistributedComputingObjectModel, DCOM), в основном представленная брокером объектных запросов (ObjectRequestBroker, ORB), который входит в состав Windows NT 4.0 и будет включен в следующую редакцию Windows[10].

CORBA детище консорциума ObjectManagementGroup (OMG), в составе которого более 700 компаний из самых различных отраслей промышленности. Цель этой организации состоит в том, чтобы определять базовые структуры для разработки приложений с использованием объектно-ориентированных методов. OMG выпускает спецификации, позволяющие стандартизировать обработку распределенных объектов, а не прикладные программы, и такая ориентация на разработку идей, а не программ принесла группе большой успех.Самый удачный результат деятельности OMG впервые реализованная в 1991 г. CORBA. CORBA описывает стандартную архитектуру для обмена информацией между распределенными объектами, благодаря которой компоненты прикладных программ могут связываться друг с другом, независимо от их местоположения в вычислительной сети. Более того, поскольку CORBA определяет стандартный интерфейс между объектами, операционная система, в которой работает объект, и язык, на котором он составлен, не имеют значения. Если объект удовлетворяет требованиям CORBA, он способен обмениваться информацией с другими распределенными объектами.Появившийся в декабре 1994 г. как составная часть спецификации CORBA 2.0 протокол IIOP еще одна удача OMG. До того как был подготовлен протокол IIOP, спецификация CORBA определяла способ взаимодействия только для распределенных объектов, созданных одним производителем. При подготовке объектов приходилось рассчитывать лишь на конкретную реализацию архитектуры. Благодаря IIOP вторая спецификация CORBA стала окончательным решением для взаимодействия объектов, которое не привязано ни к какой конкретной платформе или реализации.

С применением CORBA вы создадите системы масштаба предприятия (корпоративные системы), в которых объекты распределены по вычислительной сети. В корпоративных системах основные объекты для обслуживания файлов, необходимые прикладной программе, могут храниться на сервере Windows NT. Эти объекты вы составите, например, на языке Си++. На большом компьютере можно разместить первичные функции ядра системы скажем, используя объекты, запрограммированные на языке Кобол. Любой настольный компьютер, работающий под управлением Windows 95, пригоден для хранения внешних интерфейсов, использующих объекты, созданные средствами VisualBasic. И все эти объекты могут обмениваться информацией, а посредником при передаче запросов служит CORBA[8].

Фирмы Netscape Communications Corp. и SunMicrosystems избрали CORBA и IIOP в качестве основы для следующего поколения своих программ. Sun применяет CORBA и IIOP для реализации гетерогенных вызовов удаленных процедур в языке программирования Java 1.1, причем без этих технологий в копоративных сетях не было бы платформы Java (JavaPlatform). Более того, в API EnterpriseJavaBeans будут применяться CORBA и IIOP, чтобы обеспечить возможность создания масштабируемых прикладных программ для деловой сферы (бизнес-приложения) с многократно используемыми серверными компонентами.Дляогранизации вызовов удаленных процедур в языке Java пригодна и технология DCOM. Необходимые для этого специальные программные процедуры имеются в Visual J++. Но модель DCOM рассчитана только на платформы Windows NT 4.0 и Windows 95 (с помощью расширений InternetExplorer), т. е. DCOM не годится для обмена информацией с другими операционными системами. Microsoft сообщает, что в будущем технология DCOM будет перенесена на другие платформы.По протоколу IIOP осуществляется взаимодействие открытой сетевой среды (OpenNetworkEnvironment, ONE) фирмы Netscape с корпоративными системами. Кроме того, с помощью IIOP программисты могут подключать программы, подготовленные на языках Java, JavaScript и Си или Си++, к системам масштаба предприятия.

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

2. Технология CORBA

2.1 Объединение компонентов

Как технология, которая обеспечивает базовые структуры для взаимодействия разнородных объектов, CORBA достигла замечательных успехов, и это при том, что она представляет собой только часть еще более крупной архитектуры управления объектами (ObjectManagementArchitecture, OMA), состоящей из следующих компонентов:

CORBA ORB оперирует запросами между объектами; Службы (сервисы) CORBA определяют служебные функции системного уровня, предназначенные для управления объектами и обеспечения их работы; Средства CORBA определяют функциональные возможности и интерфейсы на уровне прикладной программы; Объекты прикладных программ собственно объекты.Как мы уже упоминали, брокер объектных запросов управляет обменом запросами между объектами. Но как все остальные кусочки этой мозаики складываются воедино? Давайте рассмотрим службы, средства и объекты CORBA.

2.2 Службы объектов CORBA

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

Имеется 16 объектных служб, в том числе:

CollectionProperties

Сoncurrency Сontrol

Query Eventnotification

NshipsExternalizationSecurity

LicensingStartup

LifecycleTime

NamingTrader

PersistenceTransactions

Реальные объекты, образующие ядро совместимой с CORBA прикладной программы, называются бизнес-объектами. Бизнес-объект это способ описания понятий, не зависящих от прикладной программы, типа покупатель, заказ или платеж. Для подготовки прикладной программы вам будет необходим набор бизнес-объектов.В отличие от объектов системного уровня, которые выполняют такие задачи, как поддержание устойчивости, бизнес-объекты имеют дело с процессами, характерными для реального делового мира. Хотя типичный бизнес-объект несет ответственность только за одну задачу (например, обработку предварительных заказов, работу с покупателями или складом), наборы бизнес-объектов можно применять для управления всем бизнес-процессом, таким, как продажа билетов и обработка предварительных заказов на авиарейсы. Поскольку бизнес-объекты поставляются в готовом к работе виде, разработчик может, объединив их, составить прикладную программу, соответствующую требованиям заказчика.Для управления сложной прикладной программой с распределенными бизнес-объектами у последних есть информация только о том, какие сервисные функции выполняют другие объекты, но не о том, как эти функции реализуются на самом деле. Благодаря бизнес-объектам мы избавлены от сложностей реализации внутренней обработки, поскольку можем сконцентрировать внимание на интерфейсах.

Компонент это набор бизнес-объектов, которые осуществляют обработку, инкапсулируют данные и обеспечивают необходимые интерфейсы пользователя. Для взаимодействия объектов в рамках компонента используется ORB. Кроме того, с помощью ORB объекты обмениваются информацией о себе, в результате объекты "узнают" о существовании других объектов во время исполнения программы. Таким образом, в компоненте имеется все необходимое для вывода на экран представления объекта и взаимодействия с ним. Типичный бизнес-компонент мог бы применяться, скажем, для вывода на экран распределения мест на 11-часовом рейсе до Лос-Анджелеса, а другой для регистрации сведений о бронировании мест на этот рейс.Возможности компонентов можно расширить за счет добавления служебных функций системного уровня. Функция Persistence пригодится, чтобы поддерживать состояние объектов в рамках компонента.

Поскольку эти сервисные функции встроены в CORBA, их можно применять для создания "интеллектуальных" (smart) компонентов, при этом нет необходимости программировать их с нуля. Хотя и в DCOM имеется реестр компонентов и справочная служба, там нет способа поддерживать состояние объектов DCOM в перерыве между соединениями. Из-за этого недостатка DCOM уступает CORBA.На уровне прикладной программы, где устанавливаются границы инфраструктуры компонентов, базовые структуры программ определяют способы реализации совместной деятельности независимых компонентов. Благодаря четко определенным границам все компоненты вместе функционируют как единый комплекс, так что создается впечатление единства прикладной программы. Именно такое единство позволяет прикладным программам, использующим распределенные в гетерогенных средах объекты, "прозрачно" сопрягаться друг с другом. "Прозрачная" интеграция означает, что пользователи воспринимают прикладную программу как единое целое, а не как сложный набор разобщенных модулей.Инфраструктуру компонента одной прикладной программы можно расширить до инфраструктуры компонента нескольких программ. В этом случае CORBA несет ответственность за обмен информацией между множеством различных прикладных программ в рамках корпоративной системы. Для несовместимых с CORBA программ, например доставшихся в наследство приложений, можно создать оболочки (wrappers), которые придают им подобие объектов CORBA. Оболочка выполняет роль интерфейса, необходимого для доступа к конкретным функциям старой программы.Если вы с помощью CORBA интегрировали унаследованные программы с процессами клиента и сервера, у вас есть все составляющие многоуровневой модели клиентсервер. Один уровень это визуальные объекты, например интерфейсы, размещаемые на клиентских ПК. Другой уровень объекты сервера, предусматривающие бизнес-функции. Еще один уровень составляют унаследованные прикладные программы, например СУБД на большой ЭВМ.

Чтобы показать, почему CORBA ORB так хороши для ППО архитектуры клиент сервер, мы приводим следующий «краткий» список замечательных свойств, присущих всем ORB:

Статические и динамические вызовы методов. CORBA ORB позволяет статически определять вызовы ваших методов во время компиляции или находить их динамически во время выполнения. Таким образом, вам предоставляется выбор: строгий контроль типов на стадии компиляции или максимальная гибкость при отложенном (на этапе выполнения) связывании.

Связывание с языком высокого уровня. CORBA ORB позволяет вызывать методы серверного объекта с помощью выбранного Вами языка высокого уровня. При этом не имеет значения на каком языке написаны серверные объекты. CORBA отделяет интерфейс от его реализации и предоставляет независимые от языка типы данных, что дает возможность вызывать объекты из любого языка и для любой операционной системы. Наоборот, другие типы промежуточного программного обеспечения обычно предоставляют низко-уров-невые API-библиотеки для определенного языка . Кроме того, они не отделяют реализацию от спецификации и, как следствие, API тесно связан с реализацией, что делает интерфейс очень чувствительным к изменениям.

2.3 Объект CORBA и жизненный цикл серванта

POA обеспечивает сильное разделение между сроками службы объектов CORBA и сроками службы серванта. Следующие термины относятся к циклу жизни объекта CORBA:

• Активация (activation) - запуск существующего объекта CORBA, чтобы позволить ему принимать запросы.
• Дезактивация (deactivation) - завершение работы активного объекта CORBA.

Следующие термины относятся к циклу жизни серванта:

• Воплощение (incarnation) - соединение серванта с объектом CORBA
• Уничтожение (еtherealization) - разрушение ассоциации между сервантом и объектом CORBA

Во время своей жизни объект CORBA может быть воплощен более чем одним сервантом. В то же самое время, отдельный сервант, с другой стороны, может воплощать более одного объекта.Технология CORBA носит существенно более общий и универсальный характер, чем COM, что заложено в ее фундаменте. Опережение разработки спецификаций (по сравнению с реализациями) позволяет добиться более связной, целостной и гармоничной системы. С другой стороны, при разработке реального проекта нужно предварительно убедиться, что высококачественная реализация того или иного сервиса CORBA уже доступна (источниками проблем могут служить, например, PersistenceService и SecurityService).В настоящий момент CORBA не имеет своей собственной компонентной модели; работа над ней началась в 1998 г. и еще не завершена. Это главный серьезный недостаток. Правда, он несколько компенсируется наличием основанной на CORBA компонентной моделью Enterprise

JavaBeans, так что программисты на Java находятся в привилегированном положении. Все остальное, что присутствует в COM, имеется и в CORBA, и даже более того - за исключением универсальной технологии доступа к БД. Опять-таки, Java-программисты имеют преимущество и здесь - за счет наличия общей для Java технологии доступа к данным JDBC.Под “стандартом” применительно к CORBA понимается то, что официально утверждено консорциумом OMG. Надо сказать, что это очень высокий уровень “легитимности”, так как авторитет OMG в компьютерном мире чрезвычайно высок. В настоящий момент стандартизовано отображение языка IDL на 6 языков программирования - Ada, C, C++, Cobol, Java и Smalltalk. Существуют также отображения на Pascal (точнее, Delphi), Perl, Python и еще десяток языков.Наиболее используемыми языками в настоящий момент являются Java (вследствие прекрасного взаимодействия Java-технологий, особенно JDBC, RMI, JNDI и EJB, с CORBA), и C++ - как самый эффективный, мощный и распространенный язык компьютерной индустрии. CORBA обеспечивает даже несколько более высокий уровень за счет базировании технологии исключительно на языке описания IDL с последующим отображением таких спецификаций на конкретный язык программирования, а также некоторых возможностей, например, автоматического (т.е. прозрачного для программиста) распространения контекста транзакций.CORBA в настоящее время не имеет своей компонентной модели. Пусть это не имеет практического значения для Java-программистов, но в общем случае эта та область, где OMG (и фирмам-производителям программного обеспечения) еще предстоит серьезно поработать.CORBA имеет очень развитую сервисную часть; например, только для поиска серверных объектов по различным критериям можно использовать 4 различных сервиса CORBA. Кроме того, OMG стремится к максимальной стандартизации вспомогательных возможностей CORBA. CORBA предоставляет разработчикам существенно большие возможности, чем COM, в области сервисов и вспомогательных средств. С другой стороны, COM-программисты обычно не испытывают какого-либо дискомфорта из-за их недостатка. Вследствие ограниченности области применения COM объективно нет необходимости в создании таких же развитых и универсальных средств, как это совершенно необходимо для CORBA.Понятие “объекта” в CORBA принципиально отличается от своего COM-аналога. Объект CORBA не является переменной языка программирования и в общем случае время его существования не связано со временем работы серверных или клиентских приложений. СORBA-объект не занимает никаких ресурсов компьютера - оперативной памяти, сетевых ресурсов и т.п.

Эти ресурсы занимает только так называемый “сервант” (servant), который является “инкарнацией” одного или нескольких CORBA-объектов. Именно сервант является переменной языка программирования. Пока не существует сервант, сопоставленный с конкретным объектом CORBA, этот объект не может обслуживать вызовы клиентов, но, тем не менее, он существует. Результатом создания объекта (при этом совершенно не обязательно при этом создается и сопоставляется с этим объектом соответствующий сервант!) является так называемая “объектная ссылка” CORBA. Объектная ссылка сопоставлена с этим, и только с этим объектом, и это сопоставление остается корректным в течение всего срока существования CORBA-объекта (может быть, в течение нескольких лет). Объектная ссылка CORBA правильно интерпретируется ORB’ами от любого производителя программного обеспечения. После уничтожения CORBA-объекта все объектные ссылки на него навсегда теряют смысл. С помощью объектной ссылки клиент вызывает методы объекта, при этом инкарнациями этого объекта могут быть различные серванты (не более одного одновременно), которые физически могут находиться даже на различных компьютерах.CORBA является существенно более открытой, универсальной и гибкой системой, чем COM. И COM, и CORBA способны тесно и эффективно взаимодействовать со стандартными средствами обеспечения безопасности.

Несмотря на внешнюю похожесть, что вызвано общностью решаемых задач, между COM и CORBA, пожалуй, больше различий, чем сходства. В большинстве случаев либо нецелесообразно использовать CORBA (для небольших и простых проектов под Windows просто по причине относительно высоких затрат на приобретение программного обеспечения, лицензий и пр.), либо практически невозможно использовать COM (для сложных, масштабируемых, высоконадежных проектов или просто при работе в гетерогенных средах, а не только в Windows). Windows-приложения, ориентированные на взаимодействие с MicrosoftOffice, всегда будут использовать COM; проекты с использованием Java и любых Java-технологий (кроме Microsoft J++), как говорится, “сам бог велел” строить на основе CORBA. Во многих случаях выбор технологии диктует выбор той или иной части проекта: если вы планируете работать, например, с ORACLE 8i, то, безусловно, гораздо лучше ориентироваться на CORBA. Область, где эти технологии реально конкурируют, на мой взгляд, очень невелика.

2.4 Защита в среде MS-DOS

Защиту от НСД к ПК при оставлении без завершения сеанса работы в среде MS-DOS можно реализовать с помощью утилиты Diskreet, входящей в состав пакета Norton Utility 7-й или 8-й версий, так: подключить драйвер Diskreet.sys (включить в файл Config.sys строку DEVICE=d:\path\ DISKREET.SYS, где d и path – соответственно логический привод и путь файла Diskreet.sys); перезагрузить ОС; запустить утилиту Diskreet.exe; нажатием клавиши F10 войти в меню, выбрать пункт Options и ввести команду Driver; раскрыть список «Hot key» с помощью комбинации клавиш и выбрать комбинацию клавиш для блокирования клавиатуры, мыши и экрана; установить нажатием клавиши пробела флажок Keyboard/Screen Lock и нажать Ok; используя команду Master Password из пункта меню Options, ввести главный пароль и выйти из утилиты. Так можно будет блокировать экран, клавиатуру и мышь, нажав установленную комбинацию клавиш. Для разблокирования следует ввести главный пароль и нажать клавишу . Данный пароль необходимо будет вводить и после выдачи команды Driver в меню Options из среды утилиты Diskreet. Для изменения главного пароля следует запустить утилиту Diskreet, ввести команду Master Password из пункта меню Options и далее определить новый пароль, введя предварительно старый. При забывании главного пароля единственным выходом из данного положения является удаление файла Diskreet.ini. Когда данный файл отсутствует, считается, что главный пароль не установлен.

2.5 Защита в средах Windows. Классификация компьютерных вирусов. Антивирусы-полифаги

Для установки параметров ЗИ от НСД к ПК при его оставлении без завершения сеанса работы в среде Windows 3.XX необходимо: двойным щелчком мыши запустить в Windows программу «Панель управления» и далее «Оформление»; выбрать любой хранитель экрана в группе элементов «Хранитель экрана», обеспечивающий защиту паролем, например Marquee, Flying Windows или Starfiefd Simulation; в поле «Задержка» установить время бездействия пользователя, по истечении которого будет активизироваться хранитель экрана; нажать кнопку «Параметры», установить флажок «Защита паролем» и определить пароль; нажать «Ok» и закрыть «Панель управления». По истечении установленного времени бездействия пользователя будет активизирован хранитель экрана, который не позволит вернуться в систему без ввода пароля. Изменение пароля осуществляется аналогично. Для установки параметров ЗИ от НСД к ПК при его оставлении без завершения сеанса работы для ОС Windows 95/98/NT необходимо: активизировать «Панель управления» и далее «Экран»; активизировать лист «Заставка» и выбрать понравившийся хранитель экрана; установить в поле «Интервал» время бездействия пользователя, по истечении которого будет активизироваться хранитель экрана; установить флажок «Пароль»; определить пароль с помощью кнопки «Сменить»; нажать «Ok» и закрыть «Панель управления». По истечении установленного времени бездействия пользователя будет активизирован хранитель экрана, который не позволит вернуться в систему без ввода пароля. Изменение пароля осуществляется аналогично.

Компьютерные вирусы классифицируются в соответствии со следующими признаками:

1) среда обитания: файловые вирусы; загрузочные вирусы, заражающие компоненты системной области, используемые при загрузке ОС; файлово-загрузочные вирусы.

2) способ заражения среды обитания;

3) способ активизации: резидентные и нерезидентные вирусы;

4) способ проявления (деструктивные действия или вызываемые эффекты): влияние на работу ПК; искажение программных файлов, файлов с данными; форматирование диска или его части; замена информации на диске или его части; искажение BR или MBR диска; разрушение связности файлов путем искажения FAT; искажение данных в CMOS-памяти;

5) способ маскировки: немаскирующиеся, самошифрующиеся и стелс-вирусы.

При повседневной работе пользователь может обнаружить вирус обычно только по его симптомам: увеличение числа файлов на диске; появление на экране сообщения «I File(s) copied» («Скопирован один файл»), хотя вы не выдавали команду COPY; уменьшение объема свободной оперативной памяти; изменение даты и времени создания файла; увеличение размера программного файла; появление на диске зарегистрированных дефектных кластеров; ненормальная работа программы; замедление работы программы; загорание лампочки дисковода в то время, когда к диску не должны происходить обращения; заметное возрастание времени доступа к жесткому диску; сбои в работе ОС, в частности ее зависание; невозможность загрузки ОС; разрушение файловой структуры (исчезновение файлов, искажение каталогов). Файловые вирусы либо различными способами внедряются в выполняемые файлы (наиболее распространенный тип вирусов), либо создают файлы-двойники (вирусы-компаньоны), либо используют особенности организации файловой системы (link-вирусы). Загрузочные вирусы записывают себя либо в загрузочный сектор диска (boot-сектор), либо в сектор, содержащий системный загрузчик винчестера (Master Boot Record), либо меняют указатель на активный boot-сектор. Макровирусы заражают файлы-документы и электронные таблицы нескольких популярных редакторов. Сетевые вирусы используют для своего распространения протоколы или команды компьютерных сетей и электронной почты. Существует большое количество сочетаний, например файлово-загрузочные вирусы, заражающие как файлы, так и загрузочные сектора дисков. Такие вирусы, как правило, имеют довольно сложный алгоритм работы, часто применяют оригинальные методы проникновения в систему, используют "стелc-" и полиморфик-технологии. Другой пример – сетевой макровирус, который не только заражает редактируемые документы, но и рассылает свои копии по электронной почте. Заражаемая ОС (объекты которой подвержены заражению) является вторым уровнем деления вирусов на классы. Каждый файловый или сетевой вирус заражает файлы какой-либо одной или нескольких ОС – DOS, Windows, Win95/NT, OS/2 и т.д. Макровирусы заражают файлы форматов Word, Excel, Office 97. Загрузочные вирусы также ориентированы на конкретные форматы расположения системных данных в загрузочных секторах дисков. Среди особенностей алгоритма работы вирусов выделяют резидентность; использование «стелс»-алгоритмов; самошифрование и полиморфичность; использование нестандартных приемов. Резидентный вирус при инфицировании ПК оставляет в оперативной памяти свою резидентную часть, которая затем перехватывает обращения ОС к объектам заражения и внедряется в них. Резидентные вирусы находятся в памяти и являются активными вплоть до выключения ПК или перезагрузки ОС. Нерезидентные вирусы не заражают память ПК и сохраняют активность ограниченное время. Некоторые вирусы оставляют в оперативной памяти небольшие резидентные программы, которые не распространяют вирус. Такие вирусы считаются нерезидентными. Резидентными можно считать макровирусы как присутствующие в памяти ПК в течение всего времени работы зараженного редактора. Роль ОС берет на себя редактор, а понятие «перезагрузка ОС» трактуется как выход из редактора. В многозадачных ОС время «жизни» резидентного DOS-вируса также может быть ограничено моментом закрытия зараженного DOS-окна, а активность загрузочных вирусов в некоторых ОС ограничивается моментом инсталляции дисковых драйверов ОС. Использование "стелc''-алгоритмов позволяет вирусам полностью или частично скрыть себя в системе. Наиболее распространенным "стелс"-алгоритмом является перехват запросов ОС на чтение-запись зараженных объектов, затем "стелс"-вирусы либо временно лечат их, либо подставляют вместо себя незараженные участки информации. В случае макровирусов наиболее популярный способ – запрет вызовов меню просмотра макросов. Один из первых файловых "стелс"-вирусов – вирус Frodo, первый загрузочный "стелс"-вирус – Brain. Самошифрование и полиморфичность используются практически всеми типами вирусов для максимального усложнения процедуры обнаружения вируса. Полиморфик-вирусы (polymorphic) трудно обнаруживаются, не имеют сигнатур, т.е. не содержат ни одного постоянного участка кода. Два образца одного и того же полиморфик-вируса обычно не имеют ни одного совпадения. Это достигается шифрованием основного тела вируса и модификациями программы-расшифровщика. Нестандартные приемы часто используются в вирусах для того, чтобы глубже спрятаться в ядре ОС (вирус «ЗАРАЗА»), защитить от обнаружения свою резидентную копию (вирусы TPVO, Trout2), затруднить лечение от вируса (например, помещают свою копию в Flash-BIOS) и т.д. По деструктивным возможностям вирусы можно разделить на: безвредные, никак не влияющие на работу ПК (кроме уменьшения свободной памяти на диске в результате распространения); неопасные, влияние которых ограничивается уменьшением свободной памяти на диске и графическими, звуковыми и прочими эффектами; опасные вирусы, которые могут привести к серьезным сбоям в работе ПК; очень опасные, которые могут вызвать потерю программ, данных, информации в системных областях памяти и даже, как гласит одна из непроверенных компьютерных легенд, способствовать быстрому износу движущихся частей механизмов – вводить в резонанс и разрушать головки некоторых типов винчестеров. Даже если в алгоритме вируса не найдено ветвей, наносящих ущерб, этот вирус нельзя с полной уверенностью назвать безвредным, так как он может вызвать непредсказуемые и порой катастрофические последствия. Ведь вирус, как и всякая программа, имеет ошибки, в результате которых могут быть испорчены как файлы, так и секторы дисков (например, вполне безобидный на первый взгляд вирус DenZuk довольно корректно работает с 360-килобайтовыми дискетами, но может уничтожить информацию на дискетах большего объема). До сих пор попадаются вирусы, определяющие СОМ или ЕХЕ не по внутреннему формату файла, а по расширению. При несовпадении формата и расширения имени файл после заражения оказывается неработоспособным. Возможно также «заклинивание» резидентного вируса и системы при использовании новых версий DOS, при работе в Windows или с другими мощными программными системами. И так далее. Файловые вирусы при своем размножении тем или иным способом используют файловую систему какой-либо (или каких-либо) ОС. Они могут внедряться практически во все исполняемые файлы всех популярных ОС. Известны вирусы, поражающие все типы выполняемых объектов стандартной DOS: файлы с компонентами DOS, командные файлы (ВАТ), загружаемые драйверы (SYS- и BIN-файлы, в том числе специальные файлы IO.SYS и MSDOS.SYS) и выполняемые двоичные файлы (ЕХЕ, СОМ). Существуют вирусы, поражающие исполняемые файлы других ОС – Windows З.х, Windows 95/NT, OS/2, Macintosh, Unix, включая VxD-драйверы Windows З.х и Windows 95. Возможна запись вируса и в файлы данных, но это случается либо в результате ошибки в вирусе, либо при проявлении его агрессивных свойств. Макровирусы также записывают свой код в файлы данных – документы или электронные таблицы, однако эти вирусы настолько специфичны, что вынесены в отдельную группу. По способу заражения файлов вирусы делятся на overwriting, паразитические (parasitic), компаньон-вирусы (companion), link-вирусы, вирусы-черви и вирусы, заражающие объектные модули (OBJ), библиотеки компиляторов (LIB) и исходные тексты программ (в расчете на компиляцию этих программ). Overwriting-вирусы используют наиболее простой метод заражения: записывают свой код вместо кода заражаемого файла, уничтожая его содержимое. Файл перестает работать и не восстанавливается. Такие вирусы очень быстро обнаруживают себя, так как ОС и приложения довольно быстро перестают работать. Практически не известно ни одного случая обнаружения подобного типа вируса «в живом виде». Разновидностью являются вирусы, записывающиеся вместо DOS-заголовка NewEXE-файлов. Основная часть файла при этом остается без изменений и продолжает нормально работать в соответствующей ОС, однако DOS-заголовок оказывается испорченным. Parasitic-вирусы при распространении своих копий обязательно изменяют содержимое файлов, оставляя сами файлы при этом полностью или частично работоспособными. Основными типами таких вирусов являются вирусы, записывающиеся в начало (prepending), конец (appending) и середину файлов (inserting). Внедрение в середину происходит различными методами: переносом части файла в конец или внедрением в заведомо неиспользуемые данные файла (cavity-вирусы). Внедрение вируса в начало файла возможно двумя способами. Первый способ (рис. 5.1, а) заключается в том, что вирус переписывает начало заражаемого файла в его конец, а сам копируется на освободившееся место. При втором способе (рис. 5.1, б) вирус создает в оперативной памяти свою копию, дописывает к ней заражаемый файл и сохраняет полученную конкатенацию на диск. Некоторые вирусы при этом дописывают в конец файла блок дополнительной информации (например, вирус Jerusalem по этому блоку отличает зараженные файлы от незараженных). Рис. 5.1. Внедрение вируса в начало файла: а-первым; б-вторым способом Внедрение в начало файла применяется обычно при заражении ВАТ- и СОМ-файлов DOS. Известно несколько вирусов, записывающих себя в начало ЕХЕ-файлов DOS, Windows. При этом вирусы, чтобы сохранить работоспособность программы, либо лечат зараженный файл, повторно запускают его, ждут окончания его работы и снова записываются в его начало (иногда используется временный файл, в который записывается обезвреженный файл), либо восстанавливают код программы в памяти ПК и настраивают необходимые адреса в ее теле (т.е. дублируют работу ОС). Внедрение вируса в конец файла является наиболее распространенным способом внедрения вируса в файл (рис. 5.2). Вирус изменяет начало файла таким образом, что первыми выполняемыми командами являются команды вируса. В DOS СОМ-файле это достигается обычно изменением его первых трех (или более) байтов на коды инструкции JMP Loc_Virus (или в более общем случае – на коды программы, передающей управление на тело вируса). DOS ЕХЕ-файл переводится в формат СОМ-файла и затем заражается как СОМ-файл либо модифицируется заголовок файла. В заголовке DOS ЕХЕ-файла изменяются значения стартового адреса (CS:IP) и длины выполняемого модуля (файла), реже – регистры-указатели на стек (SS:SP), контрольная сумма файла и т.д. В выполняемых файлах Windows и OS/2 (NewEXE – NE, РЕ, LE, LX) изменяются поля в NewEXE-заголовке. Структура этого заголовка значительно сложнее заголовка DOS ЕХЕ-файлов, поэтому изменению подлежит большее число полей – значение стартового адреса, количество секций в файле, характеристики секций и т.д. Дополнительно к этому длины файлов перед заражением могут увеличиваться до значения, кратного параграфу (16 байт) в DOS или секции в Windows и OS/2 (размер секции зависит от параметров заголовка ЕХЕ-файла). Рис. 5.2. Внедрение вируса в конец файла Вирусы, внедряющиеся в DOS SYS-файлы, приписывают свои коды к телу файла и модифицируют адреса программ стратегии (Strategy) и прерывания (Interrupt) заражаемого драйвера (или адрес только одной из программ). При инициализации зараженного драйвера (рис. 5.3) вирус перехватывает соответствующий запрос ОС, передает его драйверу, ждет ответа, корректирует его и остается в одном блоке в памяти вместе с драйвером. Вирус может быть чрезвычайно опасным и живучим, так как внедряется в оперативную память при загрузке DOS раньше любой антивирусной программы, если она тоже не является драйвером. Рис. 5.3. Зараженный системный драйвер Некоторые вирусы заражают системные драйверы по-другому: модифицируется заголовок так, что DOS рассматривает инфицированный файл как цепочку из двух (или более) драйверов (рис. 5.4). Рис. 5.4. Зараженный системный драйвер в виде цепочки драйверов Аналогично вирус может записать свои коды в начало драйвера, а если в файле содержится несколько драйверов, то и в середину файла. Внедрение вируса в середину файла имеет несколько возможностей. Наиболее простая – перенос части файла в конец или раздвижка и запись кода вируса в освободившееся место. Отдельные вирусы сжимают переносимый блок так, что длина файла не изменяется (например, Mutant). Cavity-вирус записывается в заведомо неиспользуемые области файла: незадействованные области таблицы настройки адресов DOS ЕХЕ-файла (см. BootExe) или заголовок NewEXE-файла (Wm95.Murkry), область стека файла COMMAND.СОМ (Lehigh) или область текстовых сообщений популярных компиляторов (NMSG). Некоторые вирусы заражают только те файлы, которые содержат блоки, заполненные каким-либо постоянным байтом, при этом вирус записывает свой код вместо такого блока. Кроме того, копирование вируса в середину файла может произойти в результате ошибки вируса, в этом случае файл может быть необратимо испорчен. Вирусы без точки входа (ЕРО-вирусы – Entry Point Obscuring viruses) – довольно незначительная группа вирусов, к которым относятся вирусы, не записывающие команд передачи управления в заголовок СОМ-файлов (JMP) и не изменяющие адрес точки старта в заголовке ЕХЕ-файлов. Такие вирусы записывают команду перехода на свой код в какое-либо место в середину файла и получают управление не непосредственно при запуске зараженного файла, а при вызове процедуры, содержащей код передачи управления на тело вируса. Выполняться эта процедура может крайне редко (например, при выводе сообщения о какой-либо специфической ошибке). Вирус может долгие годы «спать» и выскочить на свободу только при некоторых условиях. Перед записью в середину файла команды перехода на свой код вирусу необходимо выбрать «правильный» адрес в файле – иначе зараженный файл может оказаться испорченным. Известны несколько способов определения таких адресов. Первый способ – поиск в файле последовательности стандартного кода (стандартные заголовки процедур) Си/Паскаль с записью вместо них своего кода (вирусы Lucretia, Zhengxi). Второй способ – загрузка файла в память, трассировка или дизассемблирование и в зависимости от различных условий выбор команды (или команд), вместо которой записывается код перехода на тело вируса (CNTV, Midlnfector, NexivDer). Третий способ применяется только резидентными вирусами – при запуске файла они контролируют какое-либо прерывание (чаще – INT 21h). При вызове заражаемым файлом этого прерывания вирус записывает свой код вместо команды вызова прерывания (например Avatar.Positron, Markiz). Сompanion-вирусы не изменяют заражаемых файлов. Для заражаемого файла создается файл-двойник, причем при запуске зараженного файла управление получает именно этот двойник, т.е. вирус. Наиболее распространены компаньон-вирусы, использующие особенность DOS первым выполнять СОМ-файл, если в одном каталоге присутствуют два файла с одним и тем же именем, но различными расширениями имени – СОМ и ЕХЕ. Такие вирусы создают для ЕХЕ-файлов файлы-спутники, имеющие то же самое имя, но с расширением СОМ, например, для файла XCOPY.EXE создается файл XCOPY.COM. Вирус записывается в СОМ-файл и никак не изменяет ЕХЕ-файл. При запуске такого файла DOS первым обнаружит и выполнит СОМ-файл, т.е. вирус, который затем запустит и ЕХЕ-файл. Некоторые вирусы используют не только вариант СОМ-ЕХЕ, но также и ВАТ-СОМ-ЕХЕ. Вторую группу составляют вирусы, которые при заражении переименовывают файл, запоминают его (для последующего запуска файла-хозяина) и записывают свой код на диск под именем заражаемого файла. Например, файл XCOPY.EXE переименовывается в XCOPY.EXD, а вирус записывается под именем XCOPY.EXE. При запуске управление получает код вируса, который затем запускает оригинальный XCOPY, хранящийся под именем XCOPY.EXD. Данный метод работает, наверное, во всех ОС – подобного типа вирусы были обнаружены не только в DOS, но и в Windows, и OS/2. В третью группу входят Path-companion-вирусы, которые «играют» на особенностях DOS PATH. Они либо записывают свой код под именем заражаемого файла, но «выше» на один уровень PATH (DOS, таким образом, первым обнаружит и запустит файл-вирус), либо переносят файл-жертву выше на один подкаталог и т.д. Link-вирусы, как и компаньон-вирусы, не изменяют физического содержимого файлов, однако при запуске зараженного файла заставляют ОС выполнить свой код. Это достигается модификацией необходимых полей файловой системы. Известен единственный тип link-вирусов – семейство Dir_II. Они записывают свое тело в последний кластер логического диска. Вирусы корректируют лишь номер первого кластера файла, расположенный в соответствующем секторе каталога. Новый начальный кластер файла указывает на кластер, содержащий тело вируса. При заражении файлов их длина и содержимое кластеров с этими файлами не изменяются, а на все зараженные файлы на одном логическом диске будет приходиться только одна копия вируса. До заражения данные каталога хранят адрес первого кластера файла (рис. 5.5). Рис. 5.5. Каталог до заражения После заражения данные каталога указывают на вирус, т.е. при запуске файла управление получает вирус (рис. 5.6). Рис. 5.6. Каталог после заражения Файловые черви (worms) являются в некотором смысле разновидностью компаньон-вирусов, но при этом никоим образом не связывают свое присутствие с каким-либо выполняемым файлом. При размножении они копируют свой код в какие-либо каталоги в надежде, что эти копии будут когда-либо запущены. Иногда эти вирусы дают своим копиям «специальные» имена, чтобы подтолкнуть пользователя на запуск, например INSTALL.EXE или WINSTART.BAT. Существуют вирусы-черви, использующие довольно необычные приемы, например, записывающие свои копии в архивы (ARJ, ZIP и пр.). К таким вирусам относятся «ArjVirus» и «Winstart». Некоторые вирусы записывают команду запуска зараженного файла в ВАТ-файлы (например, «Worm.Info»). Не следует путать файловые вирусы-черви с сетевыми червями. Первые используют только файловые функции какой-либо ОС, вторые же при своем размножении пользуются сетевыми протоколами. OBJ-, LIB-вирусы и вирусы в исходных текстах заражают библиотеки компиляторов, объектные модули и исходные тексты программ, достаточно экзотичны и практически не распространены. Всего их около десятка. Вирусы, заражающие OBJ- и LIB-файлы, записывают в них свой код в формате объектного модуля или библиотеки. Зараженный файл не является выполняемым и не способен на распространение вируса в своем текущем состоянии. Носителем «живого» вируса становится СОМ- или ЕХЕ-файл, получаемый в процессе компоновки зараженного OBJ/LIB-файла с другими объектными модулями и библиотеками. Вирус распространяется в два этапа: на первом заражаются OBJ/LIB-файлы, на втором (компоновка) получается работоспособный вирус. Заражение исходных текстов программ логически продолжает предыдущий метод размножения. Вирус добавляет к исходным текстам свой исходный код (в этом случае он должен содержать его) или свой шестнадцатеричный дамп (что технически легче). Зараженный файл способен на дальнейшее распространение вируса только после компиляции и компоновки (например SrcVir, Urphin).

Антивирусы-полифаги – наиболее распространенные средства по борьбе с вредоносными программами. Исторически они появились первыми и до сих пор удерживают несомненное лидерство в этой области. В основе работы полифагов стоит простой принцип – поиск в программах и документах знакомых участков вирусного кода (сигнатур вирусов). Сигнатура – это запись о вирусе, позволяющая однозначно идентифицировать присутствие вирусного кода в программе или документе, чаще всего участок вирусного кода или его контрольная сумма (дайджест). Первоначально антивирусы-полифаги осуществляли последовательный просмотр файлов на предмет нахождения вирусов. Если сигнатура вируса была обнаружена, то производилась процедура удаления вирусного кода. Прежде проверки файлов программа-фаг всегда проверяет оперативную память. Если там оказывается вирус, то происходит его деактивация. Это вызвано тем, что зачастую вирусы заражают программы, запускающиеся или открывающиеся в момент активной стадии вируса (это связано со стремлением экономить на усилиях по поиску объектов заражения). Таким образом, если вирус останется активным в памяти, то тотальная проверка всех исполняемых файлов приведет к тотальному заражению системы. В настоящее время вирусы значительно усложнились. Например, появились «stealth-вирусы». В основе их работы лежит использование ОС при обращении к периферийным устройствам (в том числе и к жестким дискам) механизма прерываний. При возникновении прерывания управление передается обработчику прерываний. Эта программа отвечает за ввод/вывод информации в/из периферийного устройства. Кроме того, прерывания делятся на уровни взаимодействия с периферией (в нашем случае – с жесткими и гибкими дисками). Есть уровень ОС (в среде MS DOS – прерывание 25h), есть уровень базовой системы ввода/вывода (уровень BIOS – прерывание 13h). Программисты могут работать и напрямую, обращаясь к портам ввода/вывода устройств, но это весьма трудно. Столь многоуровневая система сделана, прежде всего, с целью сохранения переносимости приложений. Именно благодаря такой системе, скажем, оказалось возможным осуществлять запуск DOS-приложений в многозадачных средах типа MS Windows или IBM OS/2. Но изначально скрыта и уязвимость: управляя обработчиком прерываний, можно управлять потоком информации от периферийного устройства к пользователю. Stealth-вирусы, в частности, используют механизм перехвата управления при возникновении прерывания. Заменяя оригинальный обработчик прерывания своим кодом, stealth-вирусы контролируют чтение данных с диска. Если с диска читается зараженная программа, вирус «выкусывает» собственный код (обычно происходит подмена номера читаемого сектора диска). В итоге пользователь получает для чтения «чистый» код. До тех пор, пока вектор обработчика прерываний изменен вирусным кодом, сам вирус активен в памяти ПК, обнаружить его простым чтением диска средствами ОС невозможно. Схожий механизм маскировки используется загрузочными вирусами. В целях борьбы со stealth-вирусами рекомендуется осуществлять альтернативную загрузку системы с гибкого диска и только после этого проводить поиск и удаление вирусов. В настоящее время загрузка с гибкого диска может оказаться проблематичной (для случая с Win32 – антивирусными приложениями запустить их не удастся). Антивирусы-полифаги максимально эффективны только против уже известных вирусов, чьи сигнатуры и методы поведения знакомы разработчикам. Тогда вирус обязательно будет обнаружен и удален из памяти ПК, а потом из всех проверяемых файлов. Если же вирус неизвестен, то он может противостоять попыткам его обнаружения и лечения. Поэтому главное при пользовании любым полифагом – чаще обновлять версии программы и вирусные базы. Особняком стоят эвристические анализаторы. Существует большое количество вирусов, алгоритм которых практически скопирован с алгоритма других вирусов. Как правило, их создают непрофессиональные программисты. Для борьбы с такими «копиями» были придуманы эвристические анализаторы. С их помощью антивирус способен находить аналоги известных вирусов, сообщая, что, похоже, завелся вирус. Надежность эвристического анализатора не 100%, но все же больше 50%, Вирусы, которые не распознаются антивирусными анализаторами, способны написать только наиболее опытные и квалифицированные программисты. Эвристическим анализатором кода называется набор подпрограмм, анализирующих код исполняемых файлов, памяти или загрузочных секторов для обнаружения в нем разных типов вирусов. Основной частью анализатора является эмулятор кода. Он работает в режиме просмотра, не выполняя код, а выявляя в нем всевозможные события, т.е. совокупность кода или вызов определенной функции ОС, направленные на преобразование системных данных, работу с файлами, или обнаруживая часто используемые вирусные конструкции. Грубо говоря, эмулятор просматривает код программы и выявляет те действия, которые эта программа совершает. Если действия укладываются в какую-то определенную схему, то делается вывод о наличии в программе вирусного кода. Конечно, вероятность пропуска и ложного срабатывания весьма высока. Однако, правильно используя механизм эвристики, пользователь может самостоятельно прийти к верным выводам. Например, если антивирус выдает сообщение о подозрении на вирус для единичного файла, то вероятность ложного срабатывания весьма высока. Если же такое повторяется на многих файлах (а до этого антивирус ничего подозрительного в этих файлах не обнаруживал), то можно почти уверенно говорить о заражении. Наиболее мощным эвристическим анализатором в настоящее время обладает антивирус Dr.Web. Использование эвристического анализатора позволяет также бороться с вирус-генераторами и полиморфными вирусами. Метод сигнатуры в этом случае вообще неэффективен. Вирус-генераторы – это специализированный набор библиотек, который позволяет пользователю легко сконструировать собственный вирус. К написанной программе подключаются библиотеки генератора, вставляются в нужных местах вызовы внешних процедур – и вот элементарный вирус превратился в достаточно сложный продукт. Сигнатура вируса будет каждый раз другая, поэтому отследить вирус оказывается возможным только по характерным вызовам внешних процедур – а это уже работа эвристического анализатора. Полиморфный вирус имеет еще более сложную структуру. Тело вируса видоизменяется от заражения к заражению, сохраняя функциональное наполнение. В простейшем случае – если разбросать в теле вируса случайным образом ничего не исполняющие, пустые операторы, то тело вирусного кода претерпит значительные изменения, а алгоритм останется прежним. В этом случае на помощь также приходит эвристический анализатор.

2.6 Программы-ревизоры

Программы-ревизоры относятся к самым надежным средствам защиты от вирусов. Они запоминают исходное состояние программ, каталогов и системных областей диска до заражения, а затем периодически или по желанию пользователя сравнивают текущее состояние с исходным. Обнаруженные изменения выводятся на экран монитора. Как правило, сравнение состояний производят сразу после загрузки ОС. При сравнении проверяются длина файла, код циклического контроля (контрольная сумма файла), дата и время модификации, другие параметры. Программы-ревизоры имеют достаточно развитые алгоритмы, обнаруживают стелс-вирусы и могут даже очистить изменения версии проверяемой программы от изменений, внесенных вирусом. К числу программ-ревизоров относится широко распространенная в России программа Adinf. Антивирусные программы-ревизоры позволяют обнаружить вирус. Чаще всего этим дело и заканчивается. Существует блок лечения Cure Module для Adinf, но он позволяет лечить лишь файлы, не зараженные на момент создания базы данных программы. Однако обнаружить вирус на ПК (или даже подозрение на него) антивирусы-ревизоры могут с большой степенью надежности. Оптимальна связка полифаг-ревизор. Ревизор служит для обнаружения факта заражения, тогда в дело пускается полифаг. Если же ему не удалось уничтожить вирус, то можно обратиться к разработчику антивирусных средств – скорее всего, попал новый, неизвестный разработчикам вирус. Основу работы ревизоров составляет контроль за изменениями, характерными для работы вирусных программ. В них содержится информация: о контрольных суммах неизменяемых файлов, содержимом системных областей, адресах обработчиков прерываний, размере доступной оперативной памяти и т.п. Остальная работа состоит в сравнении текущего состояния диска с сохраненным, поэтому крайне важно создавать контрольные таблицы не на зараженной машине. Итак, перейдем к стадиям работы программы-ревизора.

Контроль оперативной памяти включает процедуры обнаружения следов активных загрузочных и stealth-вирусов в памяти ПК. Если такие алгоритмы найдены, выдается предупреждение. Обычно сначала программа ищет знакомые вирусы, далее проверяет, изменился ли обработчик Int13h. Если да, то с вероятностью 90 % ПК инфицирован загрузочным вирусом (эти вирусы вынуждены перехватывать данное прерывание, чтобы после своей активизации передать управление «нормальному» загрузочному сектору и ОС загрузилась без сбоев). Ревизор выдает предупреждение об этом и сообщает адрес в памяти нового обработчика Int13h. Информация о местонахождении обработчика необходима программистам и системным администраторам, а рядовому пользователю следует обратить внимание на предупреждение. Даже если ревизор устанавливается на зараженный ПК и реальный адрес обработчика маскируется вирусом, в 85 % случаев ревизору удается обнаружить истинный адрес обработчика в BIOS и работать, используя его. Если не удалось получить реальный адрес обработчика, то выдается предупреждение. Истинный адрес достигается путем пошагового просмотра тела вируса (по алгоритму своей работы загрузочный вирус вынужден, в конце концов, передавать управление оригинальному обработчику). Некоторые вирусы блокируют трассировку прерываний: при попытке трассировать их коды они приводят ОС к «зависанию», перезагружают ПК и т.д. Поэтому, если при трассировке прерываний ПК ведет себя «странно», то не исключено, что оперативная память поражена вирусом. Важен и размер свободной оперативной памяти. Обычно ревизор запускается самым первым, до загрузки каких-либо программ. Если же размер оперативной памяти уменьшился – это верный признак присутствия в ОЗУ еще какой-то программы, скорее всего, вируса.

Контроль системных областей предназначен для обнаружения вирусов, которые используют для своей активации механизм загрузки. Первой с диска загружается загрузочная запись (boot record), которая содержит в себе мини-программу, управляющую дальнейшей загрузкой. Для жесткого диска первой производится загрузка главной загрузочной записи (Master-BootRecord или MBR). Если система поражена загрузочным вирусом, то именно ему передается управление при попытке загрузиться с пораженного диска. В этом опасность вируса – если поражен жесткий диск, то управление вирусу будет передаваться при каждом включении ПК. Загрузочные вирусы в чистом виде передаются исключительно через дискеты, и заражение осуществляется при попытке загрузиться с пораженной дискеты. Со временем использование дискет вообще и загрузочных дискет, в частности, сократилось до минимума. Однако способ захвата управления столь удобен, что очень распространены вирусы, которые могут поражать как файлы, так и загрузочные сектора. Попав на «чистый» ПК, такие вирусы первым делом поражают MBR. Однако методы обнаружения именно загрузочных вирусов крайне эффективны и приближаются к 100 % надежности. Рассмотрим обнаружение такого вируса «вручную». Произведем загрузку с чистой дискеты (при этом прерывание 13h гарантировано не будет перехвачено загрузочным вирусом) и рассмотрим сектор 0/0/1 винчестера (это физический адрес сектора MBR). Если винчестер разделен (при помощи fdisk) на логические диски, то код занимает приблизительно половину сектора и начинается с байтов FAh33hCOh (вместо 33h иногда может быть 2Bh). Заканчиваться код должен текстовыми строками типа «Missing operating system». В конце сектора размещаются внешне разрозненные байты таблицы разделов. Нужно обратить внимание на размещение активного раздела в таблице разделов. Если ОС расположена на диске С, а активны 2-й, 3-й или 4-й разделы, то вирус мог изменить точку старта, сам разместившись в начале другого логического диска (заодно нужно посмотреть и там). Но также это может говорить о наличии нескольких ОС и какого-либо boot-менеджера, обеспечивающего выборочную загрузку. Проверяем всю нулевую дорожку. Если она чистая, то есть секторы содержат только байт-заполнитель, все в порядке. Наличие мусора, копий сектора 0/0/1 и прочего может говорить о присутствии загрузочного вируса. Впрочем, антивирусы при лечении загрузочных вирусов лишь «обезглавливают» противника (восстанавливают исходное значение сектора 0/0/1). Проверяем boot-сектор MS-DOS, он обычно расположен в секторе 0/1/1. Его внешний вид для сравнения можно найти на любом «чистом» ПК. Примерно так же действуют программы-ревизоры. Их особенность в том, что они не могут судить об изначальной «чистоте» оперативной памяти, поэтому чтение MBR происходит тремя различными способами: (bios) – прямым обращением в BIOS; (i13h) – чтением через BIOS-прерывание Intl3h; (i25h) – чтением средствами ОС (прерывание Int25h). Если считанная информация не совпадает, налицо действие stealth-алгоритмов. Для большей надежности производится чтение MBR через IDE-порты жесткого диска. До сих пор еще не встречались вирусы, маскирующиеся от ревизора с такой функцией. Аналогично проверяется и простой (не главный) загрузочный сектор. Обычно за счет того, что ревизор сохраняет резервную копию системных областей, восстановление повреждений от загрузочного вируса с согласия пользователя сводится к записи системных областей заново.

Контроль неизменяемых файлов завершает проверку и направлен на обнаружение файловых вирусов. Для всех файлов, которые активно используются и не должны изменяться (обычно это программы типа win.com и т.п.), создаются контрольные таблицы со значениями контрольных сумм и размеров файлов. Затем информация с дисков сравнивается с эталонной в таблицах. Если информация не совпадает, то весьма вероятно заражение файловым вирусом. Самый явный признак – изменение размера или содержимого файла без изменения даты создания файла. Очень важно выявить неизменяемые файлы. При настройке ревизора данные о них заносятся в таблицы, содержащие список имен файлов и каталогов, подлежащих контролю ревизором. Каждая строка таблицы содержит одно имя или маску. Рекомендуется внести в разряд «неизменяемых» те исполняемые файлы, путь к которым указан в переменной PATH. Они чаще всего становятся жертвой файловых вирусов. После проверки всех файлов ревизоры часто сохраняют копии дополнительных областей памяти, которые могут быть испорчены вирусами. Это FLASH- и CMOS-память. Они также изменяются редко, и их изменения могут быть подозрительны. В «связке» ревизор-полифаг первый отслеживает активность вируса на диске, а второй служит для проверки новых файлов, а также удаления известных вирусов. Программы-фильтры, или «сторожа», представляют собой небольшие резидентные программы, предназначенные для обнаружения подозрительных действий, характерных для вирусов: попытки коррекции СОМ-, ЕХЕ-файлов; изменение атрибутов файла; прямая запись на диск по абсолютному адресу; запись в загрузочные сектора диска; загрузка резидентной программы. При попытке произвести такое действие «сторож» посылает сообщение и предлагает запретить или разрешить его. Программы-фильтры весьма полезны, так как способны обнаружить вирус на самой ранней стадии существования до размножения. Однако они не «лечат» файлы и диски. Для уничтожения вирусов требуется применить другие программы, например фаги. К недостаткам программ-сторожей можно отнести их «назойливость» (например, они постоянно выдают предупреждение о любой попытке копирования исполняемого файла), а также возможные конфликты с другим ПО. Примером программы-фильтра является Vsafe, входящая в пакет утилит MS DOS. Вакцины, или иммунизаторы, – это резидентные программы, предотвращающие заражение. Имеют ограниченное применение, их применяют при отсутствии «лечащих» программ-докторов и только от известных вирусов. Вакцина модифицирует программу или диск так, чтобы это не отражалось на их работе, а вирус будет воспринимать их зараженными и поэтому не внедрится. Рассмотрим некоторые из антивирусных программ. Программа-полифаг Aidstest Aidstest

Это программа-полифаг предыдущего поколения. Первая версия, способная обнаруживать один вирус, была выпущена в 1988 году. Вскоре программа стала признанным лидером на российском рынке антивирусных программ. Последняя версия Aidstest вышла осенью 1997 года, и больше эта программа не поддерживается. Все вирусы, входившие в вирусную базу Aidstest, сегодня включены в сканер нового поколения Doctor Web.

Antivirial Toolkit Pro 3.0

Один из лидеров российского рынка антивирусных программ, завоевал более 10 международных премий. На AVP выходит еженедельное обновление, в его базе более 30000 записей. Выпускается российской вирусной лабораторией Касперского с возможностью обновления через сеть. Относится к детекторам-докторам, имеет «эвристический анализ». Ассортимент продукции: AVP для рабочих станций – AVP Lite, AVP Silver, AVP Gold, AVP Platinum, AVP для OS/2, AVP для Linux, AVP для FreeBSD, AVP для BSDi UNIX, AVP Inspector, AVP для Office 2000, AVP Z.E.S. Linux; AVP для серверов – AVP для Windows NT Server, AVP для Novell NetWare З.хх и 4.xx, AVP для Novell NetWare 5 (с интеграцией в NWAdmin), AVP Daemon для Linux, AVP Daemon для FreeBSD, AVP Daemon для BSDi UNIX; AVP для почтовых систем – AVP для Microsoft Exchange Server; AVP для межсетевых экранов (firewall); AVP для Firewall (бета-версия); AVP для WEB серверов – AVP WEB Inspector. При запуске AVP загружает антивирусные базы, тестирует оперативную память на наличие резидентных вирусов и проверяет себя на заражение вирусом. После успешной загрузки в строке состояния появляется сообщение «Последнее обновление: <дата>, <количество> вирусов», где <дата> – дата последнего обновления, а <количество> – количество известных вирусов (данные о вирусах находятся в файлах с расширением .AVC). Главное окно программы содержит четыре пункта меню (файл, поиск вирусов, сервис, «?»), пять вкладок (область, объекты, действия, настройки, статистика, кнопку «Пуск» («Стоп» во время сканирования диска) и окно просмотра «Объект – Результат». При загрузке автоматически открывается вкладка «Область». Для начала сканирования нужно выбрать на закладке «Область» диски и/или каталоги для проверки и нажать кнопку «Пуск» (или пункт меню «Поиск вирусов Пуск»). Выбрать проверяемый диск и/или папки можно, щелкнув на нужном объекте два раза левой клавишей мыши. Чтобы быстрее выделить диски, нужно поставить соответствующие флажки «Локальные диски» и/или «Сетевые диски» и/или «Флоппи-дисководы». Чтобы выбрать папку для сканирования, нужно нажать клавишу «Выбрать папку», после чего появится стандартное диалоговое окно Windows, в котором нужно выбрать имя папки для добавления в область тестирования. Если нажать кнопку «Пуск» без выбора объекта для проверки, то AVP выдаст сообщение: «Не задана область сканирования. Пожалуйста, отметьте диски на закладке «Область»». Чтобы срочно остановить тестирование, нужно нажать кнопку «Стоп» или выбрать пункт меню «Поиск вирусов – Стоп». Вкладка «Объекты» задает список объектов, подлежащих сканированию, и типы файлов, которые будут тестироваться. На вкладке «Объекты» можно установить следующие флажки: «Память» – включить процедуру сканирования системной памяти (в том числе High Memory Area); «Сектора» – включить в процедуру сканирования проверку системных секторов; «Файлы» – включить в процедуру сканирования проверку файлов (в том числе файлов с атрибутами Hidden, System, ReadOnly); «Упакованные объекты» – включить Unpack Engine, распаковывающий для тестирования файлы; «Архивы» – включить Extract Engine, позволяющий проводить поиск вирусов в архивах. «Тип файлов» содержит четыре переключателя. «Программы по формату» – сканировать программы (файлы .com, .exe, .vxd, .dll и форматы Microsoft Office), проверяются все файлы, которые могут содержать код вируса. «Программы по расширению» – сканировать все файлы, имеющие расширение *.ВАТ, *.СОМ, *.ЕХЕ, *.OV*, *.SYS, *.BIN, *PRG. «Все файлы» – сканировать все файлы. «По маске» – сканировать по маске, заданной пользователем в строке ввода. Вкладка «Действия» позволяет задавать действия на случай обнаружения зараженных или подозрительных объектов во время тестирования. По желанию пользователя программа будет либо только информировать его о найденных вирусах, лечить зараженный объект, предварительно открыв его, либо лечить автоматически. Подозрительные объекты могут быть скопированы либо в указанную папку, либо в рабочую папку программы. Вкладка «Настройки» позволяет настраивать программу на различные режимы. «Предупреждения» – включает добавочный механизм проверки. «Анализатор кода» – включает механизм, способный обнаружить неизвестные вирусы в исследуемых объектах. «Избыточное сканирование» – включает механизм полного сканирования содержимого файла (рекомендуется включать, когда вирус не обнаружен, но в работе ПК наблюдаются странные явления – замедление работы, частые самопроизвольные перезагрузки и т.п.). В остальных случаях использовать данный режим не рекомендуется, так как появляется возможность ложного срабатывания при сканировании чистых файлов. Настройки позволяют пользователю показывать во время сканирования имя проверяемого объекта в столбце «Объект», в окне «Результат» напротив имени объекта будет появляться сообщение «в порядке», если объект чистый. Можно также установить подачу звукового сигнала при обнаружении вируса, что на практике очень полезно, так как процесс сканирования достаточно длителен и однообразен. Можно также следить за последовательностью сканирования (флажок «Слежение за отчетом») или записать файл отчета, указав имя результирующего файла (флажок «Файл отчета»). Поставив этот флажок, пользователь получает доступ к двум вспомогательным флажкам: «Добавить» – новый отчет будет дописываться строго в конец старого; «Ограничение размера» – ограничение размера файла отчета по желанию пользователя (по умолчанию – 500 килобайт). После окончания проверки указанных объектов автоматически активизируется вкладка «Статистика», содержащая результаты работы программы. Вкладка разделена на две части, содержащие информацию о числе проверенных объектов, файлов, папок и о количестве найденных вирусов, предупреждений, испорченных объектов и т.п. База сигнатур AVP одна из самых больших – более 30000 вирусов. Работа с программой не вызывает затруднений у неопытного пользователя, получить новую версию можно из Internet.

Заключение

Учитывая, что в стоящий за этой спецификацией консорциум входит более 700 компаний, CORBA нечто большее, чем повальное увлечение, охватившее рынок. CORBA превосходит традиционную трехуровневую модель клиент сервер благодаря тому, что это полностью масштабируемая и исключительно гибкая архитектура. Используя CORBA, вы с легкостью расширите сеть, состоящую из трех компьютеров до сети масштабов Интернета. CORBA обеспечивает базовую структуру, позволяющую соединять объекты, запрограммированные на разных языках, причем не имеет значения, для какой платформы или операционной системы эти объекты были созданы, если есть средства согласования с CORBA. Поскольку CORBA предназначена для гетерогенных платформ, в настоящее время у нее есть преимущества перед DCOM. Однако принимая во внимание мощь Microsoft, DCOM, несомненно, в ближайшем будущем станет силой, с которой придется считаться.

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

Список использованной литературы

1. К.В. Ахтырченко, В.В.Леонтьев, Распределенные объектные технологии в информационных системах // СУБД 1997.
2. ЭккерсонВ.В поисках лучшей архитектуры клиент-сервер // Сети. 1995.
3. Аншина М. Симфония CORBA. “Открытые системы” № 3 1998г.
4. Коржов В. Многоуровневые системы клиент-сервер. “Сети ” 1997г.
5. Роберт Дж. Оберг Технология COM+. Основыипрограммирование = Understanding and Programming COM+: A Practical Guide to Windows 2000 First Edition. -- М.:«Вильямс», 2000. -- С. 480. -- ISBN 0-13-023114-2
6. Соммервилл И. Инженерия программного обеспечения.
7. Драница А. Java против .NET. - "Компьютерра", #516.
8. Аниканов А.А. Визуализация векторных полей с использованием текстурной анимации // Изв. вузов. Сев.-Кав. регион. Естеств. науки. 2001. №4. С. 5-9.
9. Jobard B., Lefer W. The Motion Map: efficient computation of steady flow animation // IEEE Visualization '97. Phoenix, Arizona, USA. 1997. P. 323-328.

Приложения

Архитектура CORBA

Сравнение CORBA и DCOM