Файл: Технология CORВA (Различие технологий распределенных объектов).pdf

Прямой наследницей Windows 2000 явилась вышедшая в 2002 году операционная система Windows XP (eXPerience - опыт) , также созданная на основе технологии NT. Система стала более простой, надежной, безопасной и быстрой.

В Windows XP используется привычный интерфейс Windows, но более простой и «интеллектуальный». Удалены лишние элементы пользовательского интерфейса, а стандартные элементы стали интуитивно понятными. Упрощен механизм поиска информации, ставший при этом более эффективным. Обеспечивается поддержка многих национальных языков. Благодаря использованию новых программ-мастеров, упрощена настройка системы для подключения новых устройств, сетевых соединений и т.д. Имеются эффективные, встроенные в систему инструменты для работы в Интернете, которые ускоряют навигацию и поиск информации в WWW, позволяют передавать мгновенные текстовые сообщения, общаться в режиме реального времени посредством передачи звука и видео.

Поддерживаются устройства нового поколения: компьютеры с возможностью управления питанием, шины AGP, USB и IEEE 1394, DVD-диски, адаптеры ATM, кабельные модемы и т.д. Имеется встроенная сетевая поддержка для подключения к системам Windows NT Server, Novel NetWare и Unix.

В Windows XP появилось множество средств для индивидуальных домашних пользователей, в том числе поддержка профессиональной работы с цифровым мультимедиа -цифровыми изображениями, музыкой, видео, DVD-файлами, а также многие другие возможности.

В настоящее время последней разработкой компании Microsoft является ОС Windows 7. Корпорация Microsoft планировала разработку операционной системы Blackcomb, которая была переименована в Vienna, а затем стала известна как Windows 7, с 2000 года. Blackcomb должна была заменить Windows XP, но стала преемницей Vista. В октябре 2008 года Windows 7 стало официальным названием ОС. Ожидалось, что финальная версия Windows 7 выйдет во второй половине 2009 года, однако позже Microsoft назвала в качестве срока начало 2010 года. В конце октября 2008 Microsoft продемонстрировала Windows 7. Позднее вышли бета-версия и релиз-кандидат ОС. Окончательная версия системы появилась 22 июля. Windows 7, в том числе и российская версия, появилась в магазинах 22 октября 2009 года.

CORBA и DCOM поддерживают как статические, так и динамические вызовы объектов. COM реализует динамический вызов, немного отличающийся от DII / DSI в CORBA (см. Ниже) или JavaReflection. Обычно компилятор MIDL создает прокси-сервер и код-заглушку, зарегистрированные в системном реестре Windows. Интерфейс IDispatch используется динамически для вызова методов на интерфейсе на основе маршалинга, управляемого библиотекой. Вместо использования отдельной DLL-прокси / заглушки, которая содержит информацию, специфичную для интерфейса, общий маршалер может выполнять маршалинг, читая информацию о библиотеке типов [Grimes97].

Объекты CORBA могут быть вызваны интерфейсом динамического вызова (DII на рисунке 2), который позволяет клиенту напрямую обращаться к базовым механизмам запросов, предоставляемым ORB. Приложение использует DII для динамического запроса запросов к объектам, не требуя привязки к конкретному интерфейсу IDL. В отличие от окон IDL (которые разрешают только запросы в стиле RPC), DII также позволяет клиентам делать блокировку отложенной синхронной (отдельной операции отправки и получения) и односторонние (только для отправки) звонки. Однако информация об объекте должна находиться в Репозитории информации (см. Рис. 2). Динамический скелетный интерфейс (DSI на рисунке 2) является аналогом сервера на стороне клиента DII. ORB может доставлять запросы к реализации объекта. Реализация объекта не имеет знаний о типе объекта, который он реализует во время компиляции. Клиент, делающий запрос, понятия не имеет, использует ли реализация специфичные для типа IDL-скелеты или использует динамические скелеты.

Любой объект Java наследует объект java.lang.Object, который содержит информацию о типе. Отражение и интроспекция могут использоваться для запроса информации о типе объекта. API Reflection API (в версии 1.2 спецификации языка Java), однако, не интегрирован с Java / RMI [Emmerich00].

3.1. Передача параметров

Три технологии поддерживают параметры, проходящие по значению по ссылке. Интерфейсы COM и CORBA передаются в качестве ссылок, интерфейсы Java должны реализовывать интерфейс java.rmi.Remote для передачи по ссылке, все остальные объекты и параметры передаются по значению. Параметры, которые являются объектами Java, должны реализовывать интерфейс Serializable для передачи по значению.

Параметры COM могут быть указаны в IDL либо для передачи по значению, либо по ссылке. Параметры CORBA, которые не указаны как интерфейсы CORBA, включая сложные типы данных, передаются по значению. Причина этого в том, что CORBA не определяет классы в IDL (объекты CORBA могут быть реализованы практически на любом языке, включая языки, которые не являются объектно-ориентированными). Объект по значению (OBV) является совершенно новым расширением стандарта CORBA. OBV означает, что объект CORBA, помимо передачи по ссылке, также может передаваться по значению по сети. Эта функция синергетична с отображением Java-to-IDL [Welsh01]. Но в отличие от Java, это только состояние, которое может быть передано, это из-за возможного другого языка на другом конце.

3.2. Сбор мусора

И DCOM, и Java пытаются выполнить сборку мусора для удаленных серверных объектов. CORBA не пытается выполнять сборку мусора общего назначения, но некоторые продукты CORBA включают в себя собственные услуги по сбору мусора. Объект COM-сервера отслеживает клиентов, используя подсчет ссылок, как описано в 2.2. Когда клиенты не ссылаются на экземпляр COM-объекта, он удаляет себя. Метод DCOM для сбора мусора (механизм pinging) подвергся критике из-за увеличения сетевого трафика. Объекты Java имеют встроенный подсчет ссылок, где отдельный процесс в JVM, сборщик мусора выпускает экземпляры, когда ни один другой объект не имеет ссылок на объект.

Поддержка оборудования

DCOM в основном поддерживается на платформе Windows, но он пытался обеспечить COM на других аппаратных платформах, не будучи очень успешным (например, SOLARIS); CORBA и Java / RMI поддерживаются практически на всех аппаратных платформах.

Основным преимуществом промежуточного программного обеспечения Java является то, что одна и та же версия приложения может с небольшими изменениями работать на любой платформе с совместимой JVM.

Сетевые протоколы Сетевой протокол DCOM сильно привязан к RPC, сетевые протоколы CORBA и Java / RMI не являются [Chung]. Была предоставлена ​​спецификация CORBA GIOP (GeneralInter-ORB Protocol) для обеспечения взаимодействия между ORB, работающими на разных сетевых протоколах. IIOP - это интернет-специализация GIOP, обеспечивающая транспорт через безопасные уровни сокетов через TCP / IP. Все CORBA 2-совместимые ORB могут использовать альтернативные протоколы, если они также обеспечивают IIOP [Welsh01]. Сетевые протоколы для трех стандартов не являются основными протоколами для Интернета. DCOM и IIOP обычно не работают поверх брандмауэров, где HTTP является единственным используемым протоколом. Тем не менее, Java ORB можно загрузить в виде апплета (ORBlet), упрощающего распространение. Java ORB могут также смешиваться и сопоставляться без перекомпиляции, если установлен JVM.

Безопасность Модель безопасности DCOM в Windows NT основана главным образом на безопасности NT LAN Manager, в то время как CORBA определила собственную службу безопасности для проверки подлинности клиентов. Модель безопасности Windows NT является специфичной для Windows и не соответствует другим стандартам безопасности, таким как Kerberos. Это вызывает осложнения для безопасности компонентов DCOM, если используются другие протоколы безопасности или LAN, напримерNovellNetWare. DCOM ожидает, что пользователь будет аутентифицирован и авторизирован как пользователь в домене Windows NT для контроля доступа к компонентам. Если NovellNetWare заботится об аутентификации пользователя и авторизации на стороне клиента, а пользователь не определен как пользователь Windows NT, это вызывает проблемы с авторизацией на сервере DCOM. Тем не менее, можно избежать этих проблем, не используя встроенную защиту сервера DCOM, с возможными последствиями, которые могут иметь вредоносное использование. Еще одна проблема с безопасностью Windows NT - это масштабируемость и отсутствие поддержки делегирования. В Windows 2000 реализована модель безопасности Kerberos, которая более масштабируема и поддерживает делегирование и взаимную аутентификацию между сервером и клиентом. CORBA обеспечивает безопасность на двух уровнях, где уровень 1 включает аутентификацию пользователя, авторизацию, шифрование данных и целостность. Уровень 1 позволяет приложениям, не поддающимся безопасности, относиться к безопасному домену. Уровень 2 обеспечивает более сильную модель безопасности, где приложения защищены от безопасности. Java / RMI использует встроенные механизмы безопасности Java. Для повышения уровня безопасности можно использовать отдельный менеджер безопасности (java.rmi.RMISecurityManager), например, используя SecureSocketLayer (SSL). Менеджер безопасности не является обязательным, но позволяет клиентам RMI обрабатывать сериализованные объекты, где у клиента нет соответствующих файлов классов в локальном пути класса. Компонентные модели

С конвергенцией моделей компонентов EJB и CCM на самом деле это только две конкурирующие модели компонентов, Microsoft и другие. Хотя EJB и CCM полностью объектно-ориентированы, COM + / MTS основаны на компонентах. Все они предоставляют такие услуги, как транзакции, безопасность, параллелизм и многопоточность. Масштабируемость хорошо поддерживается всеми моделями через продукты сервера приложений.

И EJB, и CCM предоставляют XML-дескрипторы для маркировки компонентов с информацией о упаковке и развертывании. Кроме того, CCM предоставляет дескрипторы сборки, чтобы показать, как компоненты CORBA должны быть связаны между собой. Библиотеки данных и библиотеки типов используются в Windows NT для развертывания компонентов DCOM. В Windows 2000 сценарии развертывания автоматически создаются для конкретного сервера при установке компонента DCOM. Эти сценарии развертывания могут быть установлены вручную или загружены (если клиент является интернет-браузером).

Большинство продуктов серверов приложений, поставляемых сегодня, включают поддержку всех трех компонентных моделей, даже если основная архитектура часто строится поверх архитектуры CORBA. Компоненты DCOM обычно расширяются мостом CORBA при установке на сервере приложений.

Наибольшее различие между составными моделями заключается в понятии идентичности объекта и жизненного цикла, когда COM обычно не неявно обрабатывает состояние вместе с идентификатором объекта. Состояние должно быть загружено отдельно после создания COM-объекта. Время жизни объекта COM ограничено временем жизни его клиентов и, в конечном счете, временем жизни процесса, в котором он существует [Rosen98]. COM-объект в MTS может за свою жизненную нагрузку и хранить несколько различных идентифицируемых состояний и использоваться несколькими клиентами. Клиентские программы обычно отвечают за явное управление состояниями и его ассоциациями с объектами COM. Клиентские программы для объектов CCM (CORBA) и EJB не имеют понятия состояния с отдельным идентификатором, кроме объекта, который его инкапсулирует.

Заключение

Распределенные объекты и модели компонентов, сравниваемые в этом эссе, весьма схожи по отношению к архитектуре и поддерживаемым функциям. Это также вывод большинства опубликованных статей, которые сравнивали технологии последних лет (например, [Chung] [GR00] [MCP98] [Raj] [Payton] [Welsh01] [Rosen98]). Наиболее значительным различием в архитектуре является понятие идентичности объекта и жизненного цикла.

Преимущество CORBA заключается в объектно-ориентированной, более современной и оснащенной более широкими возможностями, чем COM. Технология CORBA имела большой недостаток: она слишком низкоуровневая и сложная, и поэтому ее трудно освоить, требуя очень опытных разработчиков [Welsh01]. Поэтому объекты CORBA трудно использовать повторно. CCM - отличный шаг в направлении определения и группировки объектов CORBA для более высоких абстракций как компонентов. Еще одним преимуществом CORBA является то, что разработчики могут выбирать практически любой язык, аппаратную платформу, сетевой протокол и технологию персистентности, а также использовать CORBA.

Платформа Java и промежуточное ПО для объектов являются очень хорошим выбором для интеграции приложений и поддерживаются практически всеми серверами приложений, интеграционными брокерами, мониторами транзакций, серверами XML, продуктами интеграции B2B / корпоративных приложений и механизмами перевода данных [GR00]. CORBA дополняет Java в интеграции приложений и унаследованных систем, написанных на других языках, чем Java.

Технологии Microsoft, такие как DCOM, COM + / MTS, являются очень хорошим выбором для организаций, которые в основном используют технологии Windows для запуска критически важных приложений. Самый большой недостаток технологий Microsoft - ограничение (текущее?) Для платформы Windows.

Совместимость между различными объектными моделями была проблемой, поскольку война промежуточного программного обеспечения началась в середине 1990-х годов. Внедрение Java как языка Интернета еще больше вызвало проблему взаимодействия, тем более, что большинство приложений были написаны в других технологиях. С тех пор Java выросла с языка программирования до полной платформы разработки приложений и поддерживается большинством систем интеграции приложений. Стандарт Java (J2EE) был расширен для обеспечения реализации ORB (Java-IIOP) в дополнение к RMI в качестве опции распределенной технологии. Архитектуры Java и CORBA достаточно схожи, чтобы взаимодействовать легко, в то время как COM относительно несовместим с этими двумя. OMG определила мост CORBA-COM для решения проблем совместимости этих двух моделей распределенных объектов (см. [Rosen98] для подробного описания совместимости COM-CORBA).

XML (eXtensibleMark-upLanguage) и SOAP вместе с серверами приложений показали большую перспективу для взаимодействия между различными объектными моделями. Microsoft и OMG, а также многие другие поставщики приняли XML. XML является истинным независимым от платформы стандартом и может использоваться любым типом приложения или объектной модели на любой аппаратной платформе. XML-файлы являются ASCII-файлами и могут транспортироваться по HTTP-протоколу, избегая проблем с, например, брандмауэрами. Недостатком XML является определение согласованных метамоделей между поставщиками и потребителями XML-сообщений. Кроме того, XML достаточно пространственный, с возможными очень большими издержками описательной информации. Тем не менее, можно использовать переводчики стилей-листов как XSLT, чтобы перевести данный XML-файл из XML-модели в другую XML-модель. SOAP удовлетворяет необходимость обмена структурированными данными через Интернет независимо от базовых платформ. SOAP в отличие от CORBA не предлагает никаких услуг или инструментов управления. Аргумент брандмауэра в пользу SOAP может быть сомнительным, если SOAP выполняет вызовы RPC через брандмауэры. Это подрывает режим безопасности, поскольку брандмауэр считает, что это просто безопасный веб-трафик, который проходит через него. Microsoft .NET обещает реализовать как XML, так и SOAP, что дает возможность приложениям Windows легко взаимодействовать с приложениями, отличными от Windows. Серверы приложений представляют собой конвергенцию нескольких технологий, включая модели объектов и компонентов, распределенную обработку приложений и мониторы транзакций объектов. Серверы приложений, такие как транзакции, безопасность, настойчивость, потоки, службы именования и службы каталогов, а также функции распределенной обработки. Серверы чаще всего поддерживают все EJB, CORBA и COM, обеспечивая интероперабельность между компонентами. Интегрированные средства среды разработки (IDE) поддерживают разработчиков для создания и использования фреймворков и различных архитектур, часто основанных на шаблонах. Эволюция поддержки инструмента для разработки распределенных систем может помочь избежать значительной части сложного программирования распределенных компонентов. Сервер приложений и интегрированные среды разработки вместе, скорее всего, позволят разработать компоненты, которые используют распределенную технологию, которая наилучшим образом разрешит требования к распределенному приложению. Также возможно поддерживать интерфейсы от любой из распределенных технологий, основанных на типе клиентов, запрашивающих услуги от компонента (ов).