Cравнение технологий: Microsoft .Net Framework и Java-CORBA

введение

В качестве введения необходимо определить что такое .Net и что такое CORBA и кто является разработчиком этих технологий. 
И .Net, и CORBA — современные программные технологии, которые могут быть использованы для создания крупных корпоративных систем. 
CORBA (Common Object Request Broker Architecture) — это набор открытых спецификаций интерфейсов, определяющий архитектуру технологии межпроцессного и платформонезависимого манипулирования объектами. Разработчиками данных интерфейсов являются OMG и X/Open. 
Реализовать технологию в соответствии со спецификациями может кто угодно. Созданные программные продукты, естественно, уже не являются открытыми, а становятся коммерческими программными продуктами, продаваемыми на рынке. 
.Net же сам по себе есть программный коммерческий продукт, ориентированный, в первую очередь, на практическое использование. По этой причине в .Net кроме собственно архитектуры манипулирования объектами присутствует еще и вся инфраструктура, обеспечивающая распределенную обработку объектов в реальном программном и аппаратном окружении. Разработчиком .Net Framework является фирма Microsoft. 

Одно из основных отличий CORBA и .Net заключается в подходе к разработке и развитию этих технологий. Условно можно назвать подход, принятый в CORBA, как "движение сверху", а подход .Net как "движение снизу". То есть, разработка и реализация в CORBA, в первую очередь, ведется от спецификаций OMG, которые хотя и основываются на практическом опыте разработчиков, но в своей основе, теоретические проекты интерфейсов, рассчитанные на практическую реализацию кем угодно.
В отличие от CORBA, .Net возникла эволюционным путем, т.е. путем проб и ошибок фирмы Microsoft, которая создавала свои продукты, продвигаясь мелкими шагами, отталкиваясь от опыта использования их миллионами пользователей. Конечно, это не обошлось без крови и слез данных пользователей, но зато есть гораздо большая уверенность, что этот путь не заведет в тупик. Возможно, в некоторых отношениях .Net выглядит более примитивной, но зато есть уверенность, что это реальная работающая технология. Эта примитивность может оказаться мнимой, так как CORBA — открытый стандарт и все ее внутренности предоставлены ко всеобщему обозрению, в .Net же внутренняя структура в основном скрыта, а то что находится снаружи действительно смотрится довольно просто. 

доступ к реляционным базам данных

.Net
Основой доступа к базам данных технологии .Net является библиотека ADO.NET. С ее помощью можно получить доступ к источникам данных, используя OLE DB-провайдеры, .Net-провайдеры или XML. С реляционными данными можно производить все необходимые операции (выборки, добавление, обновление, удаление и т.д.). 
В ADO.NET четко разделяется доступ к данным и различные операции с данными при помощи выделения различных функций в компоненты, которые могут использоваться по отдельности или совместно. Результаты выборок могут быть обработаны сразу либо могут быть помещены в ADO.NET DataSet. Результаты могут быть сконструированы из запросов к гетерогенным или распределенным базам данных. Причем DataSet является как-бы частью реляционной базы данных, состоящей из коллекции таблиц, содержащей все связи этих таблиц, первичные ключи, индексы и т.д.

Java-CORBA
Модель доступа к даным отличается от .Net тем, что вместо DataSet и других классов общего назначения, осуществляющих доступ к данным, создаются различные переходники к конкретным структурам реляционных и объектных баз данных. Например, создается класс, который представляет абсолютно конкретную таблицу или соединение таблиц базы данных. Из реализаций систем доступа к данным можно назвать службы доступа к объектно-реляционным базам данных на основе Oracle 8i. Но в этом случае, опять же, классы в программе и их экземпляры представляют совершенно конкретные объекты базы данных. 
CORBA для доступа как к реляционным, так и к объектным базам применяет подход, при котором разрабатываются классы (типы), отображающие структуру хранилища данных непосредственно. Далее, объекты этих классов представляют информацию из базы данных в "доступном" виде, например в виде пар имя-значение. Все усилия направлены на преодоление несоответствия структуры представления данных в базе данных и в приложении. 

доступ к объектам в других процессах, на разных компьютерах и сетях

.Net
Поддерживается два типа приложений, осуществляющих межпроцессное взаимодействие и удаленный вызов объектов: 
ASP.NET. Это инфраструктура, управляемая Internet Information Services (IIS). Поддерживаются базовые типы (классы). Приложения на основе технологии ASP хорошо известны разработчикам, использовавшим предыдущую версию библиотеки. 
.Net Remoting. Предоставляет ряд сервисов: активации объектов; контроль времени жизни объектов; коммуникационные каналы, ответственные за транспортировку сообщений между удаленными приложениями. Инфраструктура remoting — абстрактное описание процесса межпроцессных коммуникаций. Обеспечена полная прозрачность этого процесса. Поиск объектов, находящиеся вне домена приложения, производится при помощи URL. Это активационные URL, которые сами уникальны и представляют уникальные типы (объектов). Remoting разрабатывался с учетом обеспечения безопасности при передаче данных, предусмотрен ряд точек подключения дополнительных модулей для шифровки-расшифровки сообщений, а также другие стандартные и нестандартные механизмы обеспечения безопасности.
Remoting дает возможность взаимодействия объектов, находящихся в различных доменах приложений или процессах, с использованием различных транспортных протоколов, различных форматов сериализации, схем жизненного цикла объектов и способов создания объектов. К тому же, возможно вмешиваться в этот процесс на любой стадии (подключать дополнительные модули, изменять параметры и т.д.). Поддерживаются два стандартных канала передачи данных: TcpChannel и HttpChannel. Также, могут регистрироваться любые другие каналы. И по HTTP-, и по TCP-каналам сообщения могут транспортироваться как с применением протокола SOAP, так и в двоичном формате. Кроме того, можно подключать свои форматтеры сообщений для других форматов передачи данных. 

Java-CORBA
Цель создания CORBA заключается в обеспечении доступа к объектам в других процессах, на разных компьютерах и сетях. Полностью описать данную технологию здесь невозможно. Если кратко, то основной процесс, происходящий при функционировании CORBA — это вызов различных операций объектов. Анализируя отличия объектных идеологий .Net и CORBA можно сделать несколько неожиданный вывод, что в .Net в разных доменах распределены классы, а в CORBA — объекты. Например, большинство базовых классов библиотеки .Net — "nonremotable" объекты. Т.е. при создании объектов данных классов они не могут передаваться через границы процессов, как в виде ссылок, так и по значению. Это и понятно, так как базовые классы "существуют" в .Net Framework, а .Net Framework устанавливается на каждый компьютер, работающий с данной технологией. Поэтому нет необходимости делать эти классы "remotable" — они могут быть успешно созданы на каждом локальном компьютере. Другое дело, классы, специфичные для приложения. Такие классы скорее всего будут "remotable", их имплементация будет располагаться в модулях, находящихся на выбранных сетевых компьютерах, соответственно, ссылки на них будут производиться по URL. URL уникальны по своей природе, и классы, специфичные для приложения, также уникальны. В CORBA же способы поиска объектов более развиты. В CORBA по умолчанию предполагается, что объекты существуют постоянно, если есть ссылка (взятая из репозитория объектов, конфигурационного файла программы или даже просто жестко вбитая в программу), то предполагается, что есть и объект. На практике, конечно, используются различные механизмы активации-дезактивации, контроля времени жизни, персистирования объектов. Поиск объектов может производится:

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

Предложения в службе коммерции публикуют сервера, обслуживающие публикуемые объекты. Информация о свойствах объекта содержит список пар имя-значение. Значение может быть установлено, а может быть помечено как динамическое. Это означает, что вместо значения устанавливается адрес CallBack-функции. Динамические значения используются для часто изменяющихся свойств. Поиск в службе коммерции производится запросами, похожими на SQL Select c предложением Where. Можно задать диапазон требуемых свойств, объединеных логическими операциями. В ответ на такой запрос может быть получен набор ссылок на объекты. 
Могут применятся более простые способы, такие, как указание ссылки на объект в конфигурационном файле в виде строки, жесткое кодирование ссылки в программе и т.д.
Таким образом, .Net использует способ поиска объектов, подобный службе имен CORBA, роль службы имен выполняют DNS-серверы. Еще одно различие в том, что ссылка на объект .Net универсальная и уникальная в глобальном масштабе, а CORBA по первоначальному замыслу использует ссылки специфичные для определенного ORB. Можно сделать вывод, что поиск объектов .Net реализован примитивнее, чем в CORBA и обладает меньшими возможностями — нельзя получать наборы объектов по условиям поиска. Но, с другой стороны, преимуществом технологии .Net является то, что система поиска объектов интегрирована в глобальное сетевое окружение. 

доступ к Internet

.Net
Поддерживается многоуровневая, расширяемая и управляемая архитектура Internet services. Можно создавать подключаемые модули для новых Internet-протоколов или же использовать "управляемую" реализацию Windows socket interface для работы с сетью на уровне сокетов. 

Java-CORBA
Наблюдаемая картина подобна описанной для .Net при внешней непохожести. Также есть возможность создания приложений (серверов и клиентов), которые будут взаимодействовать через Internet либо при помощи протокола IIOP, либо применяя технологию туннелирования протокола HTTP или какой-либо еще из сетевых протоколов CORBA. Основной проблемой, в отличии от .Net, является преодаление файрволлов при использовании протоколов,подобных IIOP. При создании большинства существующих фпйрволлов не предполагалось существование протокола IIOP. Была разработана спецификация файрволлов CORBA. Производители брокеров объектных запросов предлагают Proxy, использующие протокол IIOP, например Wonderwall компании IONA Technologies, или поддержку туннелирования HTTP для маскирования IIOP сообщений, что позволяет последним незаметно преодолевать файрволлы, например, продукт Gatekeeper компании Inprise. 
Еще одной проблемой является так называемая Interoperability — необходимость преодоления границ доменов приложений при взаимодействии различных серверов и клиентов через Internet если они принадлежат к различным ORB. Чтобы преодолеть границы различных ORB, которые интерпретируют вызовы объектов (в частности, ссылки на объекты; объекты, передаваемые по значению и типы данных для разных ORB) по-разному из-за различий в языках программирования, на которых созданы клиенты и серверы, приходится создавать сложные алгоритмы трансформации этих вызовов. В отличие от CORBA в .Net применяется абсолютно единообразный механизм преодоления границ процессов, в том числе и границ доменов приложений. 

Active Directory

.Net
Пространство имен System.DirectoryServices — "управляемая" версия Active Directory Services Interfaces (ADSI). Соответственно, позволяет делать все то же самое — работать с иерархией объектов Active Directory, модифицировать свойства объектов и т.д. 

Java-CORBA
Аналогом Active Directory является служба коммерции и, отчасти, служба имен CORBA. В этой связи можно отметить разный подход, принятый в обсуждаемых технологиях к управлению распределенными сетевыми ресурсами. Так, CORBA предоставляет широкие возможности для создания сетевых ресурсов любого типа и, соответственно, продвинутые возможности поиска этих ресурсов. Microsoft же очертила круг наиболее подходящих кандидатов на роль таких ресурсов, (принтеры, каталоги, пользователи, компьютеры и т.д.) и создала всеобъемлющую систему управления именно ресурсами вышеописанного типа, которая по своим возможностям превосходит службы CORBA. Какое из решений лучше? Ответ на этот вопрос опять же можно получить анализируя разный, можно сказать, противоположный подход OMG и Microsoft к разработке спецификаций своих продуктов и их реализации. Абстрактный подход OMG вызывает меньшее доверие, так как вся история развития человеческого общества указывает на правило поступательного движения мелкими шагами методом проб и ошибок. 

создание расписаний выполнения процессов на сервере

.Net
Используя компонент Timer, можно создавать события, которые будут возбуждаться на сервере через определенные интервалы. 

Java-CORBA
Можно предположить, что такая же возможность имеется и в CORBA. Но для этого нужно создать очередной сервер приложений либо службу. 

разработка компонентов

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

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

интернационализация приложений

.Net
Поддерживается следующий 3-х стадийный процесс создания интернационализированных приложений:

• Глобализация. 
• Тестирование на возможность локализации 
• Локализация.

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

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

получение информации о типах во время выполнения приложений

.Net
Пространство имен Reflection поддерживает набор функций для работы с метаданными. В .Net сборки содержат модули, модули содержат типы, типы содержат члены. Reflection предоставляет объекты, которые инкапсулируют сборки, модули и типы. При помощи Reflection можно:

• определять и загружать сборки; загружать модули, которые записаны в манифесте сборки; узнавать местоположение типа из данной сборки и создавать его экземпляр;
• узнавать информацию о том, какая сборка содержит данный модуль и классы этого модуля. Также можно получать информацию о глобальных методах или других специфичных не глобальных методах, определенных в данном модуле;
• узнавать наименование, параметры, модификаторы доступа (public, private и т.д.), и детали реализации (abstract, virtual) конструктора. Далее, можно вызывать конструктор какого-либо типа (класса). То же самое можно проделывать с любым из методов;
• получать информацию об имени, модификаторах доступа (public, private и т.д.) деталях реализации (static и т.д.) какого-либо поля, читать или устанавливать значение поля. То же самое можно делать с событиями, свойствами, параметрами.

Java-CORBA
Определения интерфейсов объектов во время выполнения CORBA получает двумя способами: либо извлекая метаданные, которые находятся в статически линкованном Stub клиента, либо поиском интерфейсов в хранилище интерфейсов (Interface Repository). 
Интерфейсы в хранилище находятся в виде объектов. Основными свойствами объектов являются имя и идентификатор. Поиск интерфейсов может производиться по имени. Interface Repository используется для проверки типов сигнатур вызовов вне зависимости от вида службы управления интерфейсами (DII или же информация о типах из Stub), также, при проверке графа наследования интерфейсов, при создании мостов между различными ORB. В любом случае в конечном итоге описания интерфейсов представлены на языке IDL. При использовании DII генерируется запрос к объекту на выполнение какой-либо операции. Запрос содержит ссылку на объект, и информацию для вызова, такую как имя операции, параметры, возбуждаемые исключения, возвращаемые значения, контекст вызова. Метаданные для создания описания операции берутся из описания IDL, а значения параметров предоставляются вызывающим клиентом. 
Одним из основных различий представления метаданных в .Net и CORBA является способ хранения этих метаданных. В .Net метаданные хранятся абсолютно децентрализованно. В CORBA применяется сочетание децентрализованного и централизованного хранения метаданных. Метаданные .Net более всеобъемлющие, в то время как метаданные CORBA — это описания интерфейсов с некоторыми возможностями описания других структур и аттрибутов объектов. Динамическая генерация метаданных применяется как в .Net, так и в CORBA, но понимается по-разному. Обычное состояние метаданных в .Net в простом, элементарном случае — это статически влинкованные в сборку метаданные, которые используются при манипулировании объектами. В CORBA наоборот, обычен процесс генерации описаний IDL-интерфейсов во время выполнения программы. С одной стороны, методика управления метаданными CORBA кажется более гибкой, но это по-видимому, ошибочное впечатление, так как, во-первых, постоянная генерация метаданных, вероятно, будет снижать общую производительность (этот процесс подобен, например, постоянной конвертации каких-либо данных из одного формата в другой ), во вторых, в .Net, при необходимости, можно применять точно такую же методику. Но все дело в том, что необходимость-то возникает не так уж часто. Таким образом, по-видимому, на примере .Net мы видим просто более оптимизированную версию одного и того же процесса управления метаданными. Кроме того, в силу оптимизации в .Net предоставилась возможность реализовать более развитую модель метаданных, позволяющую описывать больше типов различных сущностей. Но, вероятно, к недостаткам модели метаданных .Net можно отнести сугубо децентрализованный способ их хранения. Не помешала бы и стандартная возможность централизованного хранения. Хотя намеки на это есть уже сейчас, например, Meta Data Services на платформе MS SQL Server. 

динамическая генерация выполняемых модулей

.Net
Классы пространства имен System.Reflection.Emit позволяют редактировать метаданные, создавать сборки, модули и типы во время выполнения. Reflection можно использовать для создания браузеров объектов, компиляторов, сериализации объектов и т.д. 

Java-CORBA
По-видимому, в CORBA такого понятия не существует. 

расширение метаданных

.Net
Для аннотации типов, полей, методов и свойств CLR позволяет добавлять описатели, подобные ключевым словам, которые называются атрибутами. Атрибуты сохраняются вместе с метаданными файлов .NET Framework и могут быть использованы для описания кода во время выполнения или же для изменения поведения приложения во время выполнения. Хотя в .NET Framework предопределен ряд основных атрибутов, можно добавлять определения новых атрибутов. Атрибуты также используются различными средами разработки, например дизайнерами компонентов, средами разработки приложений, подобными Delphi. 

Java-CORBA
По-видимому, в CORBA такого понятия не существует. 

генерация исходного кода на различных языках программирования во время проектирования

.Net
Можно считать, что специальным средством проектирования для платформы .Net является Microsoft Visio. С помощью Visio можно разработать и реализовать все виды диаграмм, предусмотренные стандартом OMG UML. Далее, по схемам генерируется исходный код на языках программирования, поддерживаемых CLR. Также, возможна генерация модели по исходному коду. Причем нужно учесть, что Visio интегрируется в Microsoft Office и Visual Studio .Net. 

Java-CORBA
Модели бизнесс-процессов создаются при помощи таких программных продуктов, как Rational Rose, Select, Forte, Dynasty, PowerTier компании Persistense Software и, между прочим, того же Microsoft Visio. Поддерживается кодогенерация на каком-либо языке программирования. 
В смысле создания моделей бизнесс-процессов подход технологий .Net и CORBA сходится на языке UML (детище OMG), подтверждая мысль о том, что мощь OMG проявляется в основном в области абстракции. 

генерация и компиляция исходного кода на различных языках программирования во время выполнения

.Net
При помощи .NET Framework SDK можно во время выполнения приложения генерировать исходный текст программы на нескольких языках программирования. Генерация производится по некой модели, созданной по определенным стандартам. Эта технология называется Code Document Object Model (CodeDOM). 
Структура модели (графа) исходного текста независима от языка программирования и содержит все элементы, характерные для большинства основных языков программирования. Модель исходного кода может быть создана программно, во время выполнения. Затем по ней может быть сгенерирован исходный код, который, в свою очередь, может быть скомпилирован, а затем полученная сборка может быть запущена. Например, CodeDOM используют: ASP.NET, для создания графов объектов, которые затем компилируются в сборки, которые, затем формируют HTML-страницы и элементы управления; пространства имен System.CodeDom и System.CodeDom.Compiler и т.д. Можно подключать дополнительные модули для любых языков программирования. 

Java-CORBA
По-видимому, в CORBA такого понятия не существует. 

группировка данных в коллекции

.Net
Поддерживаются коллекции со всеми стандартными свойствами и методами: энумераторами и т.д. 

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

обработка и возбуждение событий

.Net
События в .Net Framework представлены делегатами. Делегат — это класс, который может содержать ссылку на метод. В отличие от других классов, у делегата есть сигнатура и он может содержать ссылки только на те методы, которые соответствуют сигнатуре. Делегат эквивалентен указателю на type-safe function или callback. 

Java-CORBA
По-видимому, аналогией событий .Net являются асинхронные вызовы CORBA с применением callback-функций. Хотя есть спецификации и реализации так называемых "служб событий" CORBA, но это понятие скорее является аналогией системы обмена сообщениями Message Queue технологии .Net. 

обработка и возбуждение исключительных ситуаций

.Net
Все операции в .NET Framework в случае ошибки во время выполнения возбуждают исключительные ситуации. Обработка исключений CLR производится с использованием следующих принципов: 

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

Java-CORBA
Классический случай возникновения исключительной ситуации — ошибка на сервере при выполнении запроса клиента. Для этого в CORBA, как отмечалось выше, при формировании запроса к серверу в описании операции, производимой над серверным объектом, может указываеться [rises(except1,…exceptN)]. Это список пользовательских исключительных ситуаций. Далее, при получении в ответе исключительной ситуации, организуется ее обработка. Можно сделать вывод, что и .Net и CORBA обеспечивают сходную функциональность при обработке исключительных ситуаций. 

работа виртуальной машины на различных платформах

.Net
CLR поддерживает множество типов приложений. Для старта каждого приложения необходим runtime host. Runtime host загружает CLR в процесс, создает домены приложения внутри процесса, и загружает и выполняет пользовательский код в этих доменах приложений. Вместе с .NET Framework поставляется ряд runtime host’ов, в том числе: ASP.NET, Microsoft Internet Explorer, Shell executables. Также могут быть созданы дополнительные runtime host'ы, например, различные серверы приложений, специализирующиеся на осуществлении какой-либо бизнес-логики. Например, это может понадобиться при использовании ОС? отличной от Windows. Но в общем случае, особенно для Windows, достаточно стандартных runtime host. Так, для приложений с обычным Windows GUI достаточен Shell executable. 
Common Language Runtime (CLR) — виртуальная машина, выполняющая Microsoft Intermediate Language (MSIL). MSIL — промежуточный языко- и платформенно-независимый код, который получается при компиляции программ, написанных на языках, поддерживаемых технологией .Net. Microsoft планирует выпустить версии CLR для всех основных платформ и операционных систем. 

Java-CORBA
В CORBA нет как такого понятия, как "виртуальная машина", но архитектура CORBA по своей сути кроссплатформенная. Только кроссплатформенность достигается другими средствами, а именно тем, что для каждой платформы, операционной системы и языка могут быть созданы основные службы CORBA, в то время как архитектура системы останется неизменной. Но если посмотреть на такое решение более внимательно, то становится ясным, что это в общем то же самое, что и .Net, только система дробится на более мелкие блоки, которые не являются кроссплатформенными, а требуют адаптации под каждую конкретную ситуацию. Побочный эффект более мелкого дробления — требуется большее количество переходников между частями системы. Хорошие примеры этого недостатка — организация мостов между различными ORB или конвертация каждого определения операции, специфичного для реализации клиента или объекта на определенном языке программирования, в описание интерфейса на IDL. Из этого вытекает возможность ухудшения производительности системы, построенной на основе технологии CORBA. Но, вместе с тем, такой подход дает и некоторые преимущества, в частности, возможность более тонкой и гибкой настройки системы. Кроме того, существуют некие гибриды CORBA и Java технологий, которые позволяют использовать кроссплатформенную виртуальную машину Java. 

взаимодействие со сторонним кодом

.Net
.Net Framework может взаимодействовать с COM-приложениями, COM+ компонентами, внешними библиотеками типов, большинством сервисов операционной системы. Также, возможны вызовы .NET Framework из COM, COM+ приложений. Возникающие проблемы: несоответствие типов данных, сигнатур методов, механизмов обработки ошибок, которые различаются при выполнении управляемого и неуправляемого кодов. 

Java-CORBA
По сути, возможно взаимодействие с любым, как процедурным, так и объектно-ориентированным сторонним кодом. Но только возникает вопрос, чего это будет стоить? Можно дать быстрый ответ — нужно будет создать мириады самодельных переходников, которые будут тормозить весь процесс. Стандартно же реализовано взаимодействие только с COM. В этой связи можно заметить, что если основывать разработку корпоративной системы на CORBA, то неизбежно придется налаживать взаимодействие с COM- приложениями. Но, с другой стороны, COM — это устаревшая технология, которую Microsoft не собирается развивать. Таким образом, имея лишь одну легальную возможность соединить воедино разнородные системы мы заведомо будем опираться на устаревшую и, следовательно, постепенно теряющую поддержку фирмы-разработчика технологию. Это, по меньшей мере, не разумно. 

использование XML

.Net
Поддержка XML тесно интегрирована в .Net Framework. Форматы передачи пакетов данных удаленных вызовов, представление данных ADO DataSet и т.д. 

Java-CORBA
По состоянию на 2001 г. поддержка XML не была интегрирована в спецификацию CORBA. 

рисование и редактирование изображений

.Net
Частью .Net Framework является GDI+. Это улучшенный (по сравнению с GDI для ОС Windows), платформенно независимый, "управляемый" графический интерфейс. 

Java-CORBA
В силу гибкости архитектуры CORBA принципиально возможно использовать любой графический интерфейс. Например, можно передставить себе клиентское приложение использующее пользовательский интерфейс на основе какого-либо браузера Internet с формами на HTML и Java-апплетами. Или приложение, созданное с использованием Disigner 2000 Oracle. Или графический Windows-интерфейс, созданный с использованием Delphi. Основной недостаток данных решений — зависимость реализации от платформы. 

управление приложениями с использованием специализированных библиотек. выполнение мониторинга и управление операционной системой

.Net
В .Net интегрирована поддержка Windows Management Instrumentation (WMI), которая используется для управления операционной системой Microsoft Windows. 
Для мониторинга и управления системой используются компоненты: PerformanceCounter, EventLog, ServiceController, которые имеют смысл только в среде Windows. 

Java-CORBA
В CORBA реализованы различные службы концентраторов, управления пулом серверов и обнаружения сбоев и т.д. которые по своей архитектуре — кроссплатформенные. 
Таким образом, .Net предоставляет единые средста управления, но основанные на ОС Windows, в то время как CORBA предоставляет разнообразные, но плохо объединенные кроссплатформенные средства управления и конфигурирования. Что лучше? Ответ на этот вопрос зависит от решения другого вопроса — а нужна-ли кроссплатформенность в данном конкретном случае корпоративной системы? 

асинхронные вызовы и взаимодействие приложений при помощи сообщений

.Net
Возможно асинхронное программирование с использованием моделей:

• Callback.
• Poll Completed. 
• Begin Invoke, End Invoke. 
• Begin Invoke, Wait Handle, End Invoke.

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

Java-CORBA
В CORBA асинхронное программирование и взаимодействие при помощи сообщений практически не разделяется. Начиная с более примитивных способов асинхронных вызовов (CallBack) и кончая службами событий и групповым обменом сообщений, CORBA поддерживает практически те же возможности асинхроного программирования, что и .Net. 
Основным элементом службы событий является канал событий. Это объект, отвечающий за доставку событий (сообщений, запросов) всем заинтересованным в них клиентам. Каналы событий — те же объекты, поэтому их можно искать при помощи служб имен и коммерции и динамически подключать, когда это необходимо. Каналы можно конфигурировать, создавая объединение каналов или полное объединение каналов. Каналы могут сохранять сообщения в Persistent Storage. Более продвинутые решения строятся с использованием службы уведомления. В этом случае на каналы событий могут накладываться различные фильтры и условия, предусматриваться уведомление о доставке сообщения и т.д. 
Групповой обмен сообщениями — еще один способ обмена сообщениями, основанный на возможностях группового вещания протокола IP. Реализовано в программном продукте OrbixTalk. 
Можно сделать вывод, что реализации служб сообщений обладают достаточными возможностями как в .Net так и в CORBA. Но .Net не предоставляет платформеннонезависимую службу сообщений и это означает, что все преимущества этой службы .Net проявляются только при использовании ОС Windows. 

транзакции

.Net
CLR поддерживает два типа транзакций: автоматические и неавтоматические. Для того, чтобы транзакции начинались автоматически, необходимо чтобы классы были зарегистрированы в Windows 2000 Component Services. Неавтоматические транзакции поддерживают Microsoft ActiveX Data Objects (ADO), OLE DB, Open Database Connectivity (ODBC), Microsoft Message Queuing (MSMQ). 
Component Services поддерживают гораздо более мощную модель транзакций, чем применяется при реализации неавтоматических транзакций. Она содержит графы объектов, контексты транзакций и т.д. 
Термин "serviced component" не очень хорошо переводится на русский язык и введен в .Net Framework для обозначения компонентов, которые подготовлены для использования совместно с COM+. Вернее даже не совместно, а для интеграции с COM+. Таким образом, значительно увеличивается мощь технологии .Net в отношении управления группами объектов, путем включения их в хорошо структурированный и управляемый транзакционный процесс. Но данная технология, по-видимому, не платформеннонезависимая. 

Java-CORBA
Технология CORBA обладает высокоразвитой инфраструктурой транзакционных служб. OMG определил службу объектных транзакций OTS (Object Transaction Service) как играющую ключевую роль в распределенной обработке транзакций на основе CORBA. 
Мониторы обработки транзакций (TP-мониторы) обеспечивают основу для построения, выполнения и управления программным обеспечением систем обработки транзакций. TP-монитор — это набор инструментов и библиотек, которые используются для построения транзакционных приложений, среда, в которой эти приложения будут исполняться, а также набор инструментов для управления активной системой. TP-мониторы управляют ключевыми ресурсами, отвечают за отображение доступных служб, а также предлагают программные интерфейсы для системных ресурсов, например системы управления базами данных и коммуникационные системы. Обычно подобные TP-мониторы сильно интегрированы с операционной системой. Распределенные TP-мониторы поддерживают обработку транзакций в средах, в которых приложения и ресурсы распределены по нескольким узлам. В распределенных средах наиболее важными характеристиками TP-мониторов становится поддержка управления рабочим потоком, безопасности, сбалансированности нагрузки, администрирования и управления компонентами распределенной системы. 
Стандарт X/Open Reference Model for Distributed Transaction Processing (DTP) определяет стандартные интерфейсы взаимодействия компонетов TP-мониторов. Если модель X/Open DTP определяет процедурные интерфейсы, ограничивающие доступ на уровне процедур, то служба объектных транзакций OTS определяет распределенные, объектно-ориентированные интерфейсы для компонентов TP-систем. Коммерческие реализации TP-мониторов следуют этой тенденции, создавая мониторы транзакций объектов на основе технологии CORBA поверх существующей технологии TP-мониторов, основанной на модели X/Open DTP. Например, реализация OrbixOTS компании IONA Techologies базируется на программном продукте Encina компании Transarc, а промежуточное программное обеспечение M3 компании BEA Systems — на программном продукте TUXEDO. Спецификация CORBA OTS разрабатывалась таким образом, чтобы полностью совмещаться с моделью X/Open DTP, благодаря чему открытие технологии может выглядеть как процесс эволюции, а не как полная замена существующей технологии. Таким образом, реализации службы CORBA OTS позволяют использовать все преимущества существующей, проверенной технологии TP-мониторов в современной объектно-ориентированной среде CORBA. 
Таким образом, можно сделать вывод, что службы транзакций CORBA не уступают, а в некоторых смыслах даже превосходят поддержку транзакций технологией .Net. В частности, одним из больших преимуществ является кроссплатформенная поддержка транзакций. В отличие от CORBA COM+ по-видимому на настоящий момент существует только на платформе Windows, следовательно основываясь на технологии .Net невозможно создать распределенное кроссплатформенное приложение, полностью управляющее своими транзакциями. Такое приложение сможет осуществлять только кусочное управление транзакциями. Кроме того к этой же проблеме можно отнести выравнивание нагрузки и организацию пула объектов, так как эти задачи также выполняются на основе COM+. В CORBA службы выравнивания нагрузки и организации пулов объектов кроссплатформенные. 

сборка мусора

.Net
Производится автоматическая сборка мусора на уровне CLR. 

Java-CORBA
Сборка мусора не производится (за исключением Java). 

домены приложений и программные модули

.Net
Домены приложений — это единицы изоляции кода для CLR. Приложение может создать домен, сконфигурировать его, загрузить в него сборку, получить информацию из этой сборки и уничтожить домен, когда он станет не нужен. Основное преимущество создания отдельного домена приложения — это то, что можно установить изолированные параметры конфигурации для выполнения загруженного кода. Так, можно устанавливать параметры безопасности, различные каталоги, которые содержат сборки и конфигурационные файлы. 
Сборки — это строительные блоки .NET Framework, элементарные единицы, использующиеся при установке приложений, контроле их версии, повторном использовании, определении области активации объектов и определении уровня доступа. CLR получает из сборок информацию, необходимую для конструирования типов. Сборки — это коллекции типов и ресурсов, хранящихся в одном месте с целью совместного использования. Таким образом, они представляют собой логические единицы функциональности. Для CLR типы не существуют вне контекста сборок. Сборки могут состоять из одного или нескольких файлов. Простейший случай — когда сборки хранятся в одном каталоге и другие приложения не имеют доступа к этим сборкам. В таком случае, установка и удаление приложения сводится к копированию и удалению каталога, содержащего сборки. Но сборки также могут быть доступны и разделяться многими приложениями, в том числе и удаленными. В этом случае они должны иметь strong name и могут быть помещены в глобальный кэш сборок (GAC), который имеется на каждой машине с установленным .Net Framework. 

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

безопасность, защита и уровни доступа в приложениях

.Net
.Net Framework поддерживает два типа разграничения уровней доступа: разграничение уровня доступа к коду и роли. Оба типа основаны на инфраструктуре, предоставляемой CLR. Часть уровней доступа можно определить как "допуски". Их три типа: code access permission, identity permissions и role-based security permission. Code access permission используются для защиты ресурсов и операций от неавторизованного использования. Identity permissions используются для идентификации сборок. Role-based security permission основаны на установлении принадлежности пользователя определенной роли. 
Также в .Net Framework поддерживается type safety и security которые определяются во время JIT- компиляции. Выполнение условий type safety и security гарантирует то, что код приложения сможет получить доступ только к тем областям памяти, которые авторизованы для доступа. 
Security policy — это настраиваемый набор правил, которому следует CLR когда решает, что можно позволить делать выполняемому коду. 
Также поддерживается три вида principals, аутентификация и авторизация. 
Для обеспечения сетевой безопасности могут использоваться протоколы SSL, Kerberos, HTTPS, TCP/IP. 

Java-CORBA
На сегодня консорциумом OMG Разработаны четыре спецификации CORBA имеющие отношение к безопасности:

• Спецификация службы безопасности CORBA. Создана на основе существующих технологий безопасности, таких как служба безопасности DCE (Distributed Computing Environment), протокол Kerberos для аутентификации в распределенных системах, шифрование, разработанное в Массачусетском технологическом институте (MIT), а также общее средство доступа к службам безопасности, API общей службы безопасности (Generic Security Service API, GSS API). 
• Спецификация безопасного взаимодействия (протокол SecIOP CORBA).
• Спецификация интеграции CORBA ORB-SSL.
• Спецификация файрволлов CORBA.

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

сериализация объектов

.Net
Поддерживается двоичная и XML-сериализация. Двоичная сериализация используется при копировании, сохранении, передаче объектов по значению с сохранением точного соответствия типов. XML и SOAP — открытые стандарты, которые могут быть использованы в различных гетерогенных окружениях. Но в случае их использования для сериализации точное соответствие типов не сохраняется и сериализуются только общедоступные свойства и поля. 

Java-CORBA
Частичная сериализация производится при передаче объектов по значению, но передается только значение "состояния" объекта — это значение свойств объекта. Сам же объект создается на стороне клиента способом, характерным для языка программирования клиента с последующим присвоением его свойствам переданных значений. В этом процессе возникают проблемы несоответствия IDL-описания свойств и реальных свойств, характерных для языка (например, типов данных). Проблему силятся решить, но не всегда успешно. Такая же проблема возникает при сериализации объектов с сохранением их в каком-либо хранилище объектов (объектной базе данных и т.д.). .Net выгодно отличается в этом смысле от CORBA, так как объекты передаются в двоичном виде вне зависимости от языка — CLR понимает их всегда. 

работа с базовыми типами

.Net
На уровне CLR для базовых типов поддерживается конвертация, все виды форматирования, операции со строками и их разбор. Интерпретация не базовых типов целиком зависит от метаданных. 

Java-CORBA
Есть типы данных IDL, а есть типы данных, характерные для языка программирования. Следовательно, производится мэппинг-ремэппинг типов данных, не всегда успешный. Все стандартные операции с типами данных — в языках программирования клиентов и серверов. Следовательно, они, в общем случае, разные. 

ввод/вывод

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

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

Д.В. Лопаткин