Содержание
Введение.
В качестве введения необходимо определить что такое .Net и что такое
CORBA и кто является разработчиком этих технологий.
И .Net и CORBA - современные программные технологии которые могут
быть использованы для создания крупных корпоративных систем. Но сразу же
нужно заметить, что сравнение этих технологий не вполне правомерно, как
станет ясно из последующего изложения. .Net это более широкое понятие,
чем CORBA.
CORBA (Common Object Request Broker Architecture) это набор открытых
спецификаций интерфейсов определяющий архитектуру технологии
межпроцессного и платформонезависимого манипулирования объектами.
Разработчиками данных интерфейсов являются OMG и X/Open.
Object Management Group, Inc. (OMG) - интернациональная
организация, основана в 1989 г., состоящая более чем из 800 членов:
поставщиков информационных систем, разработчиков программного
обеспечения и пользователей. OMG продвигает теорию и практику
объектно-ориентированной технологии в область практической разработки
программного обеспечения. Этот процесс включает в себя разработку
промышленных стандартов и спецификаций управления объектами с целью
создания общей базы для разработки программного обеспечения.
Первоочередными задачами являются: повторное использование,
переносимость и интероперабельность объектно-ориентированного
программного обеспечения в распределенных, гетерогенных средах.
Поддержка данных стандартов создает возможность разрабатывать
гетерогенные приложения, работающие на всех основных платформах и
операционных системах. Концептуальной инфраструктурой, на которой
базируются все спецификации OMG является Object Management Architecture
(OMA).
X/Open - независимая, всемирная, открытая организация,
поддерживаемая большинством крупнейших поставщиков информационных
систем, пользовательских организаций и софтверных компаний. X/Open
разрабатывает на основе существующих и создающихся стандартов
всеобъемлющее и интегрированное системное окружение - Common
Applications Environment (CAE). Компоненты CAE определены в стандартах
X/Open CAE. Основная цель CAE - создание пакетов программных интерфейсов
(API) которые могут применяться на практике с сохранением максимальной
переносимости на уровне исходных кодов программ. API также повышают
уровень взаимодействия приложений при помощи предоставления определений
и ссылок на протоколы и их профили. Вышеназванные спецификации тщательно
тестируются, выдержавшим тестирование присваевается X/Open trademark
(XPG brand), лицензированная X/Open.
Реализовать технологию в соответствии со спецификациями может кто
угодно. Созданные программные продукты, естественно, уже не являются
открытыми, а становятся коммерческими программными продуктами
продаваемыми на рынке программного обеспечения.
.Net же сам по себе есть программный коммерческий продукт,
ориентированный в первую очередь, на практическое использование. По этой
причине в .Net кроме собственно архитектуры манипулирования объектами
присутствует еще и вся инфраструктура, обеспечивающая распределенную
обработку объектов в реальном программном и аппаратном окружении.
Разработчиком .Net Framework является всем известная фирма Microsoft.
Одно из основных отличий CORBA и .Net заключается в подходе к
разработке и развитию этих технологий. Условно можно назвать подход,
принятый в CORBA, как "движение сверху", а подход .Net как "движение
снизу". То есть, разработка и реализация в CORBA в первую очередь,
ведется от спецификаций OMG, которые хотя и основываются на практическом
опыте разработчиков, но в своей основе, теоретические проекты
интерфейсов рассчитанные на практическую реализацию кем угодно.
Следовательно, удачность реализации проверяется уже после реализации
сравнением результатов работы на практике приложений, созданных с
применением продуктов различных фирм удовлетворяющим спецификациям OMG.
Поэтому очень трудно сориентироваться в множестве существующих
реализаций чтобы выбрать одну из них для практического применения с
гарантированным успехом. Это в особенности относится к реализациям
каких-либо новых, прогрессивных решений, которые еще не были опробованы
на практике, но применение которых назрело в силу необходимости исходя
из тенденций развития современных технологий, предоставляемых
конкурентами, например, Microsoft. Также, трудно сориентироваться в
документации, так как, трудно различить что есть только спецификация OMG
еще ни кем не реализованная, или только реализуемая, или находящаяся в
эксперементтальном использовании, а что есть реально работающий продукт.
Это минусы разработки "сверху".
В отличие от CORBA, .Net возникла эволюционным путем, т.е. путем проб
и ошибок фирмы Microsoft которая создавала свои продукты продвигаясь
мелкими шагами отталкиваясь от опыта использования их миллионами
пользователей. Конечно, это не обошлось без крови и слез данных
пользователей, но зато, есть гораздо большая уверенность, что путь фирмы
Microsoft не заведет в тупик. По крайней мере, не может быть больших
ошибок, то есть целиком тупиковых программых продуктов. Возможно, в
некоторых отношениях .Net выглядит более примитивной, но зато есть
уверенность, что это реальная работающая технология. Эта примитивность
бывает мнимой, так как CORBA - открытый стандарт и все ее внутренности
предоставлены ко всеобщему обозрению. В .Net же внутренняя структура в
основном скрыта, а то что находится снаружи часто смотрится довольно
просто.
Сравнение.
Доступ к реляционным базам данных.
.Net
Основой доступа к базам данных технологии .Net является библиотека
ADO.NET. С ее помощью можно получить доступ к источникам данных
используя OLE DB провайдеры, .Net провайдеры или XML. С реляционными
данными можно производить все необходимые операции (выборки, добавление,
обновление, удаление и т.д.).
В ADO.NET четко разделяется доступ к данным и различные операции с
данными при помощи выделения различных функций в компоненты которые
могут использоваться по отдельности или совместно. Результаты выборок
могут быть обработаны сразу, либо могут быть помещены в ADO.NET DataSet.
Результаты могут быть сконструированы из запросов к гетерогенным или
распределенным базам данных. Причем, DataSet является как-бы частью
реляционной базы данных, состоящей из коллекции таблиц, содержащей все
связи этих таблиц, первичные ключи, индексы и т.д. Для обработки
локальных данных или данных полученных из XML DataSet можно использовать
независимо от провайдера данных (источника данных).
ADO.NET поддерживает новую программную модель. Можно отметить
некоторые ключевые особенности модели, такие как: возможность работы с
кэшированными данными (disconnected data architecture), тесная
интеграция с XML (классы XML в .NET Framework и ADO.NET - части
архитектуры системы), единая модель представления данных с возможностью
комбинировать данные из различных и изменяющихся источников данных,
возможность оптимизации в ключевых точках доступа к данным конкретных
СУБД, многоуровневая архитектура приложений поддерживается библиотекой
классов. Объекты классов ADO.NET могут быть переданы как по ссылке, так
и по значению. Разработчики объектной модели ADO.Net обеспечили
совместимость с предыдущей версией библиотеки - ADO, поэтому
программистам не нужно переучиваться при переходе на новую версию.
Java-CORBA
Модель доступа к даным отличается от .Net тем, что вместо DataSet и
других классов общего назначения, осуществляющих доступ к данным,
создаются различные переходники к конкретным структурам реляционных и
объектных баз данных. Например, создается класс, который представляет
абсолютно конкретную таблицу или соединение таблиц базы данных. Из
реализаций систем доступа к данным можно назвать службы доступа к
объектно-реляционным базам данных на основе Oracle 8i. Но в этом случае
опять же, классы в программе и их экземпляры представляют совершенно
конкретные объекты базы данных.
CORBA для доступа как к реляционным так и к объектным базам применяет
подход при котором разрабатываются классы (типы) отображающие структуру
хранилища данных непосредственно. Далее, объекты этих классов
представляют информацию из базы данных в "доступном" виде, например в
виде пар имя-значение. Все усилия направлены на преодоление
несоответствия структуры представления данных в базе данных и в
приложении. В .Net эта проблема решается более опосредованно и только
для реляционных баз данных: Есть стандартные строительные блоки, которые
могут представлять данные из любой реляционной базы данных, которые
потом комбинируютя при создании уже более высокоуровневых классов,
представляющих бизнес-логику приложения. Что лучше? По-видимому на
практике лучше подход принятый технологией .Net, так как использование
стандартных компонентов позволяет быстрее создать коммерческие
программные продукты.
Доступ к объектам в других процессах, на разных компьютерах и сетях.
.Net
Поддерживается два типа приложений, осуществляющих межпроцессное
взаимодействие и удаленный вызов объектов:
- ASP.NET это инфраструктура, управляемая Internet Information
Services (IIS). Поддерживаются базовые типы (классы). Приложения на
основе технологии ASP хорошо известны разработчикам программного
обеспечения, использовавшим предыдущую версию библиотеки.
- .Net Remoting. Предоставляет ряд сервисов: активации объектов;
контроль времени жизни объектов; коммуникационные каналы,
ответственные за транспортировку сообщений между удаленными
приложениями. Форматтеры используются для кодирования и
декодирования сообщений перед тем как они будут посланы по
коммуникационным каналам. Приложения могут использовать двоичное
кодирование, если требования к производительности критичны или
XML-кодирование, если необходима переносимость между различными
операционными системами. Remoting разрабатывался с учетом
обеспечения безопасности при передаче данных, предусмотрен ряд точек
подключения дополнительных модулей для шифровки-расшифровки
сообщений, а также другие стандартные и нестандартные механизмы
обеспечения безопасности.
Инфраструктура remoting - абстрактное описание процесса межпроцессных
коммуникаций. Обеспечена полная прозрачность этого процесса. Поиск
объектов, находящиеся вне домена приложения производится при помощи URL.
Это активационные URL, которые сами уникальны и представляют уникальные
типы (объектов). При помощи активационных URL можно безошибочно вызывать
именно те типы объектов, которые необходимы для выполнения функций
приложения. Далее, объекты, которые могут быть переданы по значению или
скопированы, автоматически передаются между приложениями в различных
доменах приложениий или на различных компьютерах. Необходимо только
пометить слассы как serializable.
Реальная мощь remoting заключается в возможности взаимодействия
объектов находящихся в различных доменах приложений или процессах с
использованием различных транспортных протоколов, различных форматов
сериализации, схем жизненного цикла объектов и способов создания
объектов. К тому же, возможно вмешиваться в этот процесс на любой стадии
(подключать дополнительные модули, изменять параметры и т.д.).
Поддерживаются два стандартных канала передачи данных: TcpChannel и
HttpChannel. Также, могут регистрироваться любые другие каналы. И по
HTTP и по TCP каналам сообщения могут транспортироваться как с
применением протокола SOAP, так и в двоичном формате. Кроме того, можно
подключать свои форматтеры сообщений для других форматов передачи
данных. Выбор канала определяется такими факторами, как скорость
передачи данных, безопасность и некоторыми более мелкими техническими
деталями. Например, безопасность HTTP-канала обеспечивается протоколом
HTTPS, а безопасность TCP-канала протоколом TCP/IP. TCP-канал более
производительный, чем HTTP-канал и т.д.
Для того, чтобы объект определенного типа был доступен удаленно
необходимо предоставить системе удаленного доступа следующую информацию:
- Требуемый тип активации класса объекта (типа).
- Полное описание метаданных типа.
- Коммуникационный канал, который требуется зарегистрировать для
обработки запросов к типу.
- URL, уникально идентифицирующий объект данного типа. В случае
серверной активации это URI, который уникален для данного типа. В
случае клиентской активации это уникальный URL, который будет
присвоен экземпляру данного типа.
Remoting process
Basic Channel Sink Chain
Java-CORBA
Цель создания CORBA заключается в обеспечении доступа к объектам в
других процессах, на разных компьютерах и сетях. Полностью описать
данную технологию здесь невозможно. Если кратко, то основной процесс,
происходящий при функционировании CORBA это вызов различных операций
объектов. Анализируя отличия объектных идеологий .Net и CORBA можно
сделать несколько неожиданный вывод, что в .Net в разных доменах
распределены классы, а в CORBA - объекты. Например, большинство базовых
классов библиотеки .Net - "nonremotable" объекты. Т.е. при создании
объектов данных классов они не могут передаваться через границы
процессов, как в виде ссылок так и по значению. Это и понятно, так как
базовые классы "существуют" в .Net Framework, а .Net Framework
устанавливается на каждый компьютер, работающий с данной технологией.
Поэтому нет необходимости делать эти классы "remotable" - они могут быть
успешно созданы на каждом локальном компьютере. Другое дело, классы,
специфичные для приложения. Такие классы скорее всего будут "remotable",
их имплементация будет располагаться в модулях, находящихся на выбранных
сетевых компьютерах (при выборе компьютера - сервера должна учитываться
количество клиентов, частота создание и время жизни объектов и т.д.),
соответственно, ссылки на них будут производиться по URL. URL уникальны
по своей природе и классы, специфичные для приложения также уникальны.
URL - некий аналог суррогатного первичного ключа в реляционных базах
данных. Так производится поиск объектов в .Net. В CORBA же способы
поиска объектов более развиты. В CORBA, по-умолчанию, предполагается,
что объекты существуют постоянно, если есть ссылка (взятая из
репозитория объектов, конфигурационного файла программы или, даже,
просто жестко вбитая в программу), то предполагается, что есть и объект.
На практике, конечно, используются различные механизмы
активации-дезактивации, контроля времени жизни, персистирования
объектов. Поиск объектов может производиться:
- При помощи службы имен. Эта служба содержит древовидную базу
данных объектов. Запрос к службе содержит имя требуемого объекта. На
запрос возвращается ссылка на объект. Служба имен это сервис CORBA,
который указывается при загрузке соответствующего ORB. Отдельные
службы имен можно объединять с объединением их баз данных.
- При помощи службы коммерции. Служба коммерции это также сервис
указываемый при конфигурировании ORB. Содержит базу данных ссылок на
объекты с прицепленной к ним информацией о свойствах этих объектов,
что называется предложениями. Предложения в службе коммерции
публикуют сервера, обслуживающие публикуемые объекты. Информация о
свойствах объекта содержит список пар имя-значение. Значение может
быть установлено, а может быть помечено как динамическое. Это
означает, что вместо значения устанавливается адрес CallBack
функции. Динамические значения используются для часто изменяющихся
свойств. Поиск в службе коммерции производится запросами, похожими
на SQL Select c предложением Where. Можно задать диапазон требуемых
свойств объединеных логическими операциями. В ответ на такой запрос
может быть получен набор ссылок на объекты.
- Могут применятся более простые способы, такие как указание
ссылки на объект в конфигурационном файле в виде строки, жесткое
кодирование ссылки в программе и т.д.
Таким образом, .Net использует способ поиска объектов подобный службе
имен CORBA, роль службы имен выполняют DNS-сервера. Еще одно различие -
то, что ссылка на объект .Net универсальная и уникальная в глобальном
масштабе, а CORBA по первоначальному замыслу использует ссылки
специфичные для определенного ORB. Можно сделать вывод, что поиск
объектов .Net реализован примитивнее, чем в CORBA и обладает меньшими
возможностями - нельзя получать наборы объектов по условиям поиска. Но,
с другой стороны, преимуществом технологии .Net является то, что система
поиска объектов интегрирована в глобальное сетевое окружение.
Далее, можно кратко рассмотреть объектную модель CORBA определенную
OMG (Object Management Group). Необходимость краткого рассмотрения
объектной модели CORBA диктуется ее непревычностью для стандартного
пользователя Windows, каковыми мы все являемся.
Объектная модель содержит сущности, называемые объектами. Объект это
идентифицируемая, инкапсулированная сущность которая предоставляет одну
или несколько служб которые могут быть запрошены клиентом.
Клиенты взаимодействуют с объектами при помощи запросов. Запрос
содержит следующую информацию: запрашиваемая операция, объект, на
котором запрашивается операция, 0 или более параметров и, опционально,
контекст запроса. Параметры запроса определяются по позиции, могут быть
in, out и inout, а также запрос может иметь возвращаемое значение.
Ссылка на объект позволяет гарантированно находить объект в
определенном домене приложения (насчет интероперабельной ссылки IOR не
совсем ясно?). Структура ссылки зависит от домена приложения, а точнее,
даже от ORB который управляет взаимодействием с объектом на который
ссылка, а также от способа проецирования специфичной для языка
программирования ссылки на объект в ссылку на объект, специфичную для
ORB, управляющего данным объектом.
Используемые типы делятся на:
- Базовые типы (16-bit, 32-bit, 64-bit signed and unsigned
integer, Single-precision (32-bit), double-precision (64-bit),
double-extended , Fixed-point decimal numbers of up to 31
significant digits, Character, as defined in ISO Latin-1 (8859.1)
and other single- or multi-byte character sets, boolean и т.д.)
- Сконструированные типы. Это:
- Запись (структура) - упорядоченный набор пар имя-значение.
- Дискриминированное объединение.
- Последовательность - массив переменной длины базового типа,
длина массива может изменяться во время выполнения.
- Массив - может быть многомерный.
- Интерфейс - представляет собой набор операций, который
должен поддерживать объект.
- Значение - набор операций, который должен поддерживать
объект плюс состояние, которое выражается набором свойств.
Основная последовательность действий при вызове операций объектов:
- Обращение клиента к заглушке (IDL Stub), которая представляет
объект на стороне клиента.
- Конвертирование заглушкой формы вызова, характерной для языка
программирования на котором написан клиент в описание операции над
объектом на языке IDL.
- Формирование запроса, который содержит ссылку на объект,
описание операции и другую информацию.
- Передача запроса ORB, который далее переправляет запрос объекту,
находящемуся либо в том же домене приложения, либо в другом.
- Достигнув сервера, запрос преобразуется соответствующим
представителем (IDL Skeleton) на стороне сервера в форму вызова
процедуры или метода объекта, характерную для языка
программирования, на котором написан объект.
- Далее вызывается метод объекта и если есть возвращаемое значение
или происходит исключительная ситуация, то в обратном порядке эта
информация передается клиенту.
Кроме вышеперечисленных служб, объектная модель содержит:
- Адаптер объектов, который выполняет задачи
создания-активации-деактивации-уничтожения объектов, управления
временем жизни объектов, взаимодействует напрямую с ORB в случае
возникновения необходимости и т.д.
- Интерфейс ORB, который могут использовать объекты как на стороне
клиента, так и на стороне сервера при возникновении различных
системных задач (например, во время загрузки ORB и всего, что с ним
связано и т.д.)
- Dinamic Invocation Interface (DII). Используется в случаях,
когда описания операций на языке IDL создаются динамически во время
выполнения программы, а не влинковываются статически (как в случае
использования IDL Stub). Генерация описаний на IDL производится по
спецификациям языково-зависимых методов, предоставляемых клиентом.
- Dinamic Skeleton Interface (DSI) выполняет те же задачи, что и
DII, но на стороне сервера.
- Интерфейсы делятся на два типа Normal Call Interface и Up-Call
Interface. Соответственно, первые являются основными на стороне
клиента, вторые - на стороне сервера.
- Исполнители (Servant) - управляют отдельными объектами на
стороне сервера.
- Реестр интерфейсов (Interface Repository).
- Хранилище объектов (Implementation Repository).
Доступ к Internet.
.Net
Поддерживается многоуровневая, расширяемая и управляемая архитектура
Internet services. Можно создавать подключаемые модули для новых
Internet-протоколов или же использовать "управляемую" реализацию Windows
socket interface для работы с сетью на уровне сокетов.
Java-CORBA
Наблюдаемая картина подобна описанной для .Net при внешней
непохожести. Также есть возможность создания приложений (серверов и
клиентов), которые будут взаимодействовать через Internet либо при
помощи протокола IIOP, либо применяя технологию туннелирования протокола
HTTP или какой-либо еще из сетевых протоколов CORBA. Основной проблемой,
в отличии от .Net, является преодаление брандмауэров (Fierwall) при
использовании протоколов,подобных IIOP. При создании большинства
существующих брандмауэров не предполагалось существование протокола
IIOP. Была разработана спецификация брандмауэров CORBA. По состоянию на
2000 г. не существовало ни одной реализации брандмауэров CORBA.
Производители брокеров объектных запросов предлагают Proxy-брандмауэры,
использующие протокол IIOP, например Wonderwall компании IONA
Technologies, или поддержку туннелирования HTTP (поддерживются
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 к разработке спецификаций своих продуктов и их
реализации (по поводу различия методологий проектирования и реализаций
программных продуктов фирмы Microsoft и консорциума OMG см. "Введение").
Абстрактный подход OMG вызывает меньшее доверие, так как вся история
развития человеческого общества указывает на правило поступательного
движения мелкими шагами методом проб и ошибок.
Создание расписаний выполнения процессов на сервере
.Net
Используя компонент Timer можно создавать события которые будут
возбуждаться на сервере через определенные интервалы.
Java-CORBA
Можно предположить, что такая же возможность имеется и в CORBA. Но
для этого нужно создать очередной сервер приложений, либо службу.
Разработка компонентов
.Net
Введено понятие компонента, которое почти полностью подобно
Дельфийскому. Причем существуют, так же как и в Delphi, Control`s,
которые происходят от компонентов. Также, существуют контейнеры
компонентов и контролов. Отличие в том, что это - двоичный стандарт и
компоненты, созданные на одном из языков программирования платформы .Net
полностью совместимы с компонентами созданными на другом языке.
Например, можно создавать производные классы компонентов созданных на
разных языках программирования. Но, впрочем, это же можно сказать и о
любых объектах в .Net. Одно же из основных назначений компонентов -
поддержка сред разработки приложений.
Java-CORBA
Под компонентом CORBA понимается набор объектов, предоставляющих
более сложную службу, чем отдельный объект. При использовании службы,
предоставляемой компонентом, пользователь взаимодействует с различными
обектами, образующими этот компонент. Как правило, компонент содержит
много отдельных объектов, между которыми есть какие-то ассоциации,
например агрегаты объектов, объекты использующие другие объекты и т.д.
Значит, внутренняя структура компонента намного сложнее его внешнего
интерфейса, хотя, снаружи компонент выглядит как единый объект. Вводится
понятие входной точки компонента, это интерфейс какого-либо объекта,
входящего в состав компонента. Значит, компонент взаимодействует со
внешним миром через какой-либо свой объект.
Можно сделать вывод, что в CORBA нет какой-либо спецификации
компонента. CORBA не определяет структуру компонентов, а предоставляет
полную свободу для их реализации. Поэтому не предполагается и какая-либо
поддержка сред проектирования и программирования. Концепция компонентов
CORBA гораздо слабее реализации компонентов в .Net.
Интернационализация приложений
.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)]. Это список пользовательских исключительных
ситуаций. Далее, при получении в ответе (responce) исключительной
ситуации организуется ее обработка. Можно сделать вывод, что и .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.
Но, во-первых, виртуальная машина Java поддерживает только один язык
программирования - Java, что ограничивает возможности команды
разработчиков, так как не позволяет использовать опыт разработки и
наработки на других языках. Кроме того, возможности языка более
скромные. Во-вторых, есть проблеммы чисто юридического характера во
взаимоотношениях фирм Microsoft и Sun Microsystems. В результате
длительных судебных тяжб Microsoft заявила, что не будет поставлять
виртуальную машину Java в составе своих программных продуктов, в свою
очередь, Sun требует возмещения убытков в размере более миллиарда
долларов и просит суд вынести предварительное решение, согласно которому
Microsoft будет обязана поставлять текущую версию JRE в составе Windows
XP и MS Internet Explorer, прекратить распространение своей Java Virtual
Machine, а кроме того - и это, безусловно, более значимо, чем любые
маркетинговые счеты между гигантами, - раскрыть программные интерфейсы
приложений (APIs), необходимые для разработки программного обеспечения
под Windows, и извлечь из этой операционной системы все незаконно
встроенное в нее ПО - MSIE, IIS и, что немаловажно, платформу .Net.
Очевидно, что этот конфликт уже не может закончиться бесследно в
кратчайшее время. А значит, тех разработчиков, которые решаться
создавать новые системы на основе виртуальной машины Java ожидают, по
меньшей мере, всякие проблемы несовместимости при разработке приложений
под Windows, а, может быть, и более крупные потрясения. Необходимо
учитывать, что львиная доля оффисных компьютеров работает под
управлением ОС Windows и пользователи привыкли ко всем службам этой ОС,
а также к оффисному программному обеспечению, созданному фирмой
Microsoft. И, более того, все рабочие процессы, форматы хранилищ данных
и т.д. большинства пользователей персональных компьютеров основаны на ОС
Windows. Можно смело предполагать, что массового перехода на другую ОС в
глобальном масштабе в ближайшее время не предполагается. По крайней
мере, работа под Windows в течение 5-ти ближайших лет обеспечена. А за
пять лет нормальная корпоративная система может устареть 2-а раза. Таким
образом, Java можно скинуть со счета и более не рассматривать. Остается
только CORBA.
Взаимодействие со сторонним кодом.
.Net
.Net Framework может взаимодействовать с COM приложениями, COM+
компонентами, внешними библиотеками типов, большинством сервисов
операционной системы. Также, возможны вызовы .NET Framework из COM, COM+
приложений. Возникающие проблемы: несоответствие типов данных, сигнатур
методов, механизмов обработки ошибок, которые различаются при выполнении
управляемого и неуправляемого кодов.
В случае взаимодействия .Net и COM возникает проблема подобная
обсуждаемой в подразделе, посвященном Java-CORBA (см. ниже). Но эта
проблема гораздо "мягче" по нескольким причинам:
- Взаимодействие придется налаживать не часто, так как в основном
все можно сделать с применением .Net.
- Если и придется налаживать взаимодействие, то это гораздо легче
сделать между двумя родственными продуктами COM-.Net, чем между
COM-Java_CORBA.
Java-CORBA
По сути, возможно взаимодействие с любым, как процедурным, так и
объектно-ориентированным сторонним кодом. Но только возникает вопрос,
чего это будет стоить? Можно дать быстрый ответ - нужно будет создать
мириады самодельных переходников, которые будут тормозить весь процесс.
Стандартно же реализовано взаимодействие только с COM. В этой связи
можно заметить, что если основывать разработку корпоративной системы на
CORBA, то неизбежно придется налаживать взаимодействие с
COM-приложениями. Как говорилось выше - пользователей Windows -
большинство. Основная технология для межпроцессного взаимодействия,
применяемая в Windows - COM. Следовательно, неизбежна интеграция
существующих пользователей Windows в корпоративную систему на основе
CORBA сопряженная с налаживанием взаимодействия с различными
COM-службами Windows и 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.
Основной недостаток данных решений - зависимость реализации от
платформы. Кроме того, в случае применения Java возникают серьезные
проблемы, о которых говорилось в подразделе "Работа виртуальной машины
на различных платформах".
Управление приложениями с использованием специализированных
библиотек (WMI и т.д.). Выполнение мониторинга и управление операционной
системой.
.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. При помощи этого компонента
можно выполнять запросы, содержащиеся в сообщениях, которые были
отложены, например по причине того, что был отключен мобильный компьютер
или устройство или сервер был слишком загружен и не мог обработать
запросы. MessageQueue - развитая служба обмена сообщениями, которая
интегрируется с COM+ и, следовательно, запросы на вызовы удаленных
процедур могут быть включены в долговременные распределенные транзакции.
Также, служба взаимодействует со многими основными сервисами ОС Windows.
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 OTS можно назвать:
- Cоздание транзакционных объектов.
- Распределенные транзакции с участием объектов служб OTS
реляционных СУБД Oracle, Sybase, Informix, MQSeries,
объектно-ориентированных СУБД Versant и Object Design, инструментов
для доступа к базам данных RogueWave и Persistence Software.
- Прикладные и системные транзакции.
- Имитация вложенных транзакций.
- Транзакции управляемые клиентом и транзакции управляемые
сервером.
- Долгоживущие транзакции и сеансы пользователей в двухзвенной и
трехзвенной средах.
Таким образом, можно сделать вывод, что службы транзакций 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, аутентификация и
авторизация.
В состав .Net Framework включено пространство имен Criptography.
Для обеспечения сетевой безопасности могут использоваться протоколы
SSL, Kerberos, HTTPS, TCP/IP.
Java-CORBA
На сегодня консорциумом OMG Разработаны четыре спецификации CORBA
имеющие отношение к безопасности:
- Спецификация службы безопасности CORBA. Создана на основе
существующих технологий безопасности, таких как служба безопасности
DCE (Distributed Computing Environment), протокол Kerberos для
аутентификации в распределенных системах, шифрование, разработанное
в Массачусетском технологическом институте (MTI), а также общее
средство доступа к службам безопасности, прикладной интерфейс API
общей службы безопасности (Generic Security Service API - GSS API).
- Спецификация безопасного взаимодействия (протокол SecIOP CORBA).
- Спецификация интеграции CORBA ORB-SSL.
- Спецификация брандмауэров CORBA.
Как отмечалось выше (см. "Доступ к Internet"), реализация спецификации
брандмауэров CORBA вызывает затруднения, поэтому наиболее реален в среде
CORBA протокол SSL. Можно сделать вывод, что и .Net и CORBA могут
обеспечить необходимый минимальный уровень безопасности имея вместе с
тем некоторые изъяны в реализации подобных служб.
Сериализация объектов
.Net
Поддерживается двоичная и XML-сериализация. Двоичная сериализация
используется при копировании, сохранении, передаче объектов по значению
с сохранением точного соответтвия типов. XML и SOAP - открытые стандарты
которые могут быть использованы в различных гетерогенных окружениях. Но
в случае их использования для сериализации точное соответствие типов не
сохраняется и сериализуются только общедоступные свойства и поля.
Java-CORBA
Частичная сериализация производится при передаче объектов по
значению, но передается только значение "состояния" объекта - это
значение свойств объекта. Сам же объект создается на стороне клиента
способом, характерным для языка программирования клиента с последующим
присвоением его свойствам переданных значений. В этом процессе возникают
проблемы несоответствия IDL-описания свойств и реальных свойств,
характерных для языка (например, типов данных). Проблему силятся решить,
но не всегда успешно. Такая же проблема возникает при сериализации
объектов с сохранением их в каком-либо хранилище объектов (объектной
базе данных и т.д.). .Net выгодно отличается в этом смысле от CORBA, так
как объекты передаются в двоичном виде вне зависимости от языка - CLR
понимает их всегда.
Потоки
.Net
Для создания "управляемых" потоков используется класс Thread.
Управляемые потоки задуманы как платформонезависимые.
Java-CORBA
Работа с базовыми типами
.Net
На уровне CLR для базовых типов поддерживается конвертация, все виды
форматирования, операции со строками и их разбор. Интерпретация не
базовых типов целиком зависит от метаданных.
Java-CORBA
Есть типы данных IDL, а есть типы данных, характерные для языка
программирования. Следовательно, производится мэппинг-ремэппинг типов
данных, не всегда успешный. Все стандартные операции с типами данных - в
языках программирования клиентов и серверов. Следовательно, они в общем
случае - разные.
Ввод/вывод
.Net
На уровне CLR поддерживается базовый файловый ввод/вывод, все
основные виды потоков, события от файловой системы, а также, новая
технология - изолированное хранилище, которое применяется в
платформнонезависимых приложениях для изоляции и структурирования
доступа различных локальных и удаленных пользователей, сборок и доменов
приложений к устройствам долговременного хранения информации.
Java-CORBA
Спецификаций CORBA описывающих стандартный ввод/вывод не существует.
Эти задачи выполняются средствами операционной системы, на которой
реализованы серверы и клиенты. Следовательно, о кроссплатформенности
можно говорить только на уровне общей архитектуры CORBA. Но это слишком
дорогая цена для тех, кто захочет ее реализовать, так как все придется
делать практически с нуля. Кроме того, и единообразия работы с
вводом/выводом также нет, так как различные языки программирования
делают это по-разному. Также нужно учесть, что фирма Microsoft в
настоящий момент разрабатывает новую, объектную файловую систему,
которую собирается интегрировать в Windows .Net с соответствующей
поддержкой со стороны .Net Framework. Можно сделать вывод, что данная
область не покрывается CORBA и все преимущества на стороне .Net.
Заключение.
Итак, после рассмотрения ряда ключевых особенностей двух технологий
можно собрать все "+" и "-" воедино и, далее, сделать соответствующие
выводы в отношении конкретной ситуации наиболее часто наблюдаемой в
конкретной организации.
Технология .Net Framework:
- Созданная эволюционным путем, представляет собой не слишком
дорогой коммерческий программный продукт "готовый к использованию".
- Содержит все основные службы и средства для разработки
корпоративной системы на основе ОС Windows. Путем интеграции с
другими программными продуктами фирмы Microsoft возможно осуществить
сквозной процесс
анализа-проектирования-разработки-внедрения-обслуживания
корпоративной системы. В частности, процесс анализа-проектирования с
помощью Microsoft Visio может плавно переходить через кодогенерацию
в процесс разработки при помощи Microsoft Visual Studio .Net, далее
в процессе программирования может участвовать команда разработчиков
пользующаяся средством групповой разработки от Microsoft - Visual
Source Safe, далее готовые программы оформляются в виде
инсталляционных модулей при помощи Microsoft Installer, далее
программный продукт обслуживается с использованием Active Directory
Services Interfaces (ADSI). Правда, вышеописанная схема очень
неполная, так как нет возможности перечислить все продукты
Microsoft, которые могут быть использованы в процессе жизненного
цикла корпоративной системы. В случае кроссплатформенной разработки
ситуация не столь радужная. Хотя, CLR в ближайшее время и будет
работать на всех основных ОС (Особенно это касается ОС семейства
UNIX в силу их открытости. Этим пользуется Microsoft при создании
своей виртуальной машины на таких ОС.), но, например, службы
транзакций, обмена сообщениями, выравнивания нагрузки в настоящий
момент не кроссплатформенные. Поэтому, может быть, для
взаимодействия с другими ОС придется использовать системы других
производителей программного обеспечения (например, технологию Jini
от Sun Microsystems с использованием интеграционной платформы Orbix
E2A Web Services Integration Platform компании IONA).
Но более правильным решением в случае кроссплатформенной разработки
на основе .Net будет использование технологии Microsoft Enterprise
Application Integration (EAI).
Фирмой Microsoft создан ряд программных продуктов реализующих полный
набор логических служб EAI. Технология EAI это не программный продукт, а
комплекс архитектурных решений, основанный на существующих программных
продуктах Microsoft центральную роль в котором играет Microsoft BizTalk®
Server. Решения EAI основаны на следующих программных продуктах:
- BizTalk Server. Это сервер интеграции приложений,
поддерживающий сложные распределенные, гетерогенные бизнесс
процессы. BizTalk Server содержит ядро системы сообщений, которое
представляет собой среду интеграции построенную с применением
технологии "orchestration". Смысл этого термина можно объяснить как
возможность графического описания бизнесс процессов в виде диаграмм
потоков данных и последующей привязкой этих диаграмм к выполняемым
компонентам. Технология оркестровки - мощное средство управления
долгоживущими транзакциями и сложными процедурами.
- Host Integration Server. Это всеобъемлющий набор
транзакционных gateways, служб и коннекторов которые позволяют
интегрировать платформу Microsoft Windows® с другими платформами,
такими как CICS, IMS, AS/400, UNIX. Он содержит такие возможности,
как мэппинг паролей, поддержку XA транзакций, доступ к приложениям
CICS и virtual private networking (VPN) для Internet-приложений.
- SQL Server. Это мощная реляционная СУБД которая также
поддерживает ряд возможностей интеграции данных, таких, как:
репликация баз данных, трансформация и импорт данных при помощи Data
Transformation Services (DTS), выполнение запросов к гетерогенным
источникам данных.
- Windows core services. В ядро ОС Windows входит ряд
служб, которые могут быть инкорпорированы в сценарии EAI. Это:
- XML Web services. Фундаментальный строительный блок для
разработки распределенных вычислений. Открытые стандарты,
концентрация на соединениях, кооперации пользователей и
приложений создает окружение в котором XML Web services
становятся платформой для интеграции приложений. Приложения
могут создаваться с использованием множества XML Web служб от
различных поставщиков вне зависимости от того, где они находятся
и как они реализованы.
- Microsoft Data Access Components (MDAC). Это ключевая
технология воплощающая стратегию универсального доступа к данным
фирмы Microsoft. Включает в себя:
- Microsoft ActiveX ® Data Objects (ADO).
- OLE DB.
- Open Database Connectivity (ODBC).
- MDAC также сопровождается компонентами доступа к данным
Host Integration Server 2000, которые позволяют получать
доступ к данным расположенным на мэйнфрэймах.
- COM+ application services. COM+ services создают
области транзакций и безопасности в применении к компонентам
бизнесс-логики, которые могут быть использованы для управления
данными, проходящими через EAI процесс.
Следующая диаграмма показывает основные области применения
вышеперечисленных продуктов. Необходимо заметить, что между различными
уровнями интеграции существует свой уровень взаимодействия, который
построен на определенных сетевых технологиях и обеспечивает
низкоуровневое взаимодействие для более высоких уровней интеграции.
Спецификация EAI также описывает эти уровни взаимодействия.
На основе данной архитектуры с применением анализа структуры
бизнесс-процессов при помощи BizTalk Server может быть принято несколько
решений о применяемой модели построения распределенной, гетерогенной
корпоративной системы:
- Classic hub-and-spoke messaging integration solution
Интеграция на уровне приложений. Создается центральный логический
hub, который производит трансформацию данных, маршрутизацию,
реализует службы приема и доставки, а также другие дополнительные
службы. Таким образом, решаются основные проблемы возникающие при
интеграции гетерогенных приложений. В этом случае различные
распределенные приложения взаимодействуют с хабом при помощи
сообщений, а хаб производит всю остальную работу по интеллектуальной
обработке сообщений и управлению состоянием данных процессов.
- Hub-and-intelligent-spoke, distributed messaging integration
solution
Это также вариант интеграции на уровне приложений. Как и в
предыдущем решении, центральный логический хаб производит
трансформацию данных, маршрутизацию, реализует службы приема и
доставки, а также другие дополнительные службы, но существуют другие
узлы, которые выполняют те же функции. Это приводит к тому, что
существует центральный хаб и распределенные узлы обработки, которые
могут интегрировать приложения локально, а также взаимодействовать с
центральным хабом.
- Business process orchestration solution
В этом случае производится как интеграция процессов, так и
интеграция приложений. "Orchestration" services (т.е. BizTalk
Server) используются для автоматизации функций высокоуровневых
бизнесс-процессов, оставляя службам окружения обработку состояния,
транзакций, ошибок, процесса выполнения приложений, конкурентности
транзакций и других основанных на правилах функций
бизнесс-процессов. Создание таких более сложных служб (котрые
называются "state engine") как части различных процессов на
определенных платформах может предполагать или не предполагать
использование возможности трансформации данных службами ядра.
- Web Services solution
Применяется для интеграции приложений и процессов с пересечением
границ глобальных доменов безопасности. Web Services solution обычно
характеризуется применением стандартизованных технологий обмена
сообщениями для представления существующих приложений в качестве
Web-служб или для комбинирования взаимодействия Web-служб в более
высокоуровневые бизнесс-процессы (также часто применяется для
взаимодействия служб не основанных на Web).
Технология CORBA:
- Сложная технология по большей части теоретически описанная в
спецификациях OMG. Не составляет единый программный продукт. Вместо
этого наблюдаем набор служб различных производителей программного
обеспечения. Труден выбор между продуктами, предоставляемыми
различными поставщиками, хотя на данный момент уже есть проверенные
комплексы служб, которые были где-то с успехом использованы.
Стоимость данных продуктов не низкая, а скорее всего, в
совокупности, в несколько раз превышает стоимость решения,
основанного на .Net Framework.
- Содержит все основные службы для разработки кроссплатформенной
корпоративной системы. Со средствами разработки - хуже. Их нужно
подбирать в индивидуальном порядке, хотя нельзя сказать, что их
сильно не хватает. Но можно сказать, что даже сам процесс
организации разработки программного обеспечения под CORBA может сам
по себе быть сложным и длительным и требовать затраты больших
ресурсов. Что уж говорить о самом процессе разработки корпоративной
системы. Он может вылиться в годы кропотливого труда, о чем говорит
и опыт других разработчиков имевших дело с CORBA. Хотя, конечно же
это можно объяснить новизной технологии для разработчиков. Но это не
снимает проблемы и не улучшает положения несчастного разработчика,
привыкшего к технологиям Microsoft, которые не собираются умирать.
Как отмечалось ранее, большинство рабочих мест пользователей
использует ОС семейства Windows. Microsoft не будет поддерживать
виртуальную машину Java на ОС Windows, либо же будет поддерживать ее
так, что это создаст непредсказуемые проблемы для пользователя (см.
подраздел "Работа виртуальной машины на различных платформах"). В силу
этого, использование решений для создания корпоративной системы на
основе гибрида Java-CORBA в данном обзоре почти не рассматривалось. Но
для полноты картины можно рассмотреть, что же все-таки предлагается
основным противником Microsoft - Sun Microsystems.
В противовес .Net Sun выдвигает свою разработку в области
распределенных систем - Jini. Работа над технологией была начата в конце
1999 года. В октябре 2000 года вышла первая спецификация архитектуры
технологии Jini[tm]. Сначала технология была больше известна под
названием Sun ONE (Open Network Environment). С развитием Java
технологию было решено переименовать в Jini для большей созвучности с
названием языка. В настоящий момент Jini[tm] является торговой маркой
Sun Microsystems.
Технология Jini состоит из трех основных компонентов:
- Инфраструктура. Включает в себя распределенную систему
защиты, которая интегрирована в RMI (Remote Method Invocation),
представляющий собой механизм для нахождения, активации и захвата
объектов сервисов. Инфраструктура состоит из объектов, использующих
протоколы для передачи информации во время транзакций. На уровне
транзакций происходят запросы и передача информации. Для поиска
объектов и передачи информации между ними используется менеджер
транзакций (transaction manager). Обязанности менеджера транзакций
этим не ограничиваются. Помимо этого, он обязан координировать
работу системы во время выполнения запросов и передавать найденую по
этим запросам информацию;
- Модель программирования использует язык программирования
Java и компоненты JavaBeans[tm] для организации интерфейсов
транзакций и написания приложений, использующих модель
распределенных вычислений;
- Сервисы имеют определенный унифицированный интерфейс и
набор методов, посредством которых возможно общение с ними.
Реализация сервисов не требует использования программной модели
Jini, однако эта модель необходима при взаимодействии сервисов между
собой. Причем сервисы в этом случае чем-то подобны процессам в Unix.
Каждый сервис может использовать другие сервисы для выполнения своих
задач, а также порождать новые сервисы, специализирующиеся на
решении определенных вопросов;
Поиск сервиса, который может выполнить определенную задачу,
происходит, приблизительно, по такому сценарию: объект клиента,
расположенный на компьютере пользователя посредством провайдера сервисов
(Service Provider), объекта, "специализирующегося" на поиске объектов
сервисов, находит необходимый сервис.
При нахождении необходимого объекта, он исследует его, исходя из
параметров соответствующего запроса. Это исследование найденого сервиса
происходит посредством проверки его свойств.
После этого подходящий сервис копируется на локальный диск
компьютера. Последующие действия с ним происходят ,как с локальным
объектом, с помощью вызова его методов, что, в некоторой мере,
разгружает трафик.
Все объекты, которые используются во время такого взаимодействия,
написаны на Java и включают интерфейс общения с сервисами.
В Jini используются, в основном, технологии, разработанные
исключительно фирмой Sun Microsystems. Как заявляют представители Sun
это не является недостатком Jini, скорее наоборот. За счет этого, якобы,
достигается однородность разработки приложений. Это значит, что для
разработки полнофункциональных, распределенных приложений, использующих
все преимущества технологии Jini, нет необходимости в изучении различных
программных продуктов, как обстоит дело с .NET (аргументы в противовес
такому заявлению см. в приложении "Отрывки из интервью Grady Booch MSDN
Magazine"). Также, создатели Jini заявляют, что для разработки
приложений достаточно знать небольшой набор основных компонентов и
технологий языка Java. Но этому противоречит приведенный ниже список
технологий распределенных вычислений (в особенности CORBA), который,
вместе с Java, включает спецификация Jini:
- Виртуальная машина Java (JVM) позволяет запускать
байт-код на любой платформе с JVM. За счет этого достигается
кроссплатформенность системы;
- Язык программирования Java служит для написания
приложений, интерфейсов и обслуживания транзакций посредством
использования набора компонентов Java Beans[tm]. Программы,
написанные на этом языке, запускаются на любой платформе, содержащей
JVM;
- Java Server Pages (JSP) технология, подобная ASP+ в .NET,
использует отрезки кода, написанного на Java и перекомпилированного
в байт-код Java;
- CORBA, технология позволяющая программам использовать
общий набор объектов на любой платформе с предустановленным ORB
компонентом;
- Для передачи данных и организации связи между удаленными
объектами используется набор компонентов, которые базируются на
JDBC, EJB, Java XML Libraries. С помощью этого набора можно
создавать надстройки над НTTP протоколом и организовывать
транзакции;
Технология Jini разрабатывалась с целью создания системы, которая бы
требовала к себе мало внимания при обслуживании, успевала за постоянным
изменением и наращиванием системы и обеспечивала постоянную доступность
сервисов посредством интернет, 24 часа в сутки и 7 дней в неделю.
Безопасность системы и конфиденциальность информации передаваемой в сети
достигается за счет распределенной системы безопасности. Наращиваемость
систем возможна за счет добавления новых, наследования и изменения
старых сервисов, доступных посредством интернет. Постоянная доступность
становится возможной за счет рассредоточенности системы, в которой можно
изменять приложения беспрерывно, так, что сервис будет доступен из
интернет 24 часа в сутки и 7 дней в неделю.
Состояние корпоративной программной среды типичной организации,
объективные и субъективные факторы ее развития и окончательные выводы.
- Основная масса компьютеров базируется на платформе Intel или AMD
несколько компьютеров Compaq, Sun и т.д..
- Используемые операционные системы Windows 98, Windows NT 4,
Windows 2000, Linux, другие UNIX-подобные ОС. Основная и
единственная операционная система, установленная на рабочих местах
пользователей - Windows. Большинство серверов работает также под
Windows. Часть серверов работает под Linux или другими
UNIX-подобными ОС.
- Основное оффисное программное обеспечение - MS Office.
- Основная почтовая программа MS Outlook, MS Outlook Express.
- Основной и единственный Internet Browser - MS InternetExplorer.
- Основная система документооборота работает на основе Windows и
MS Exchange.
- Основной Web-сервер Apachie на платформе UNIX или Windows.
- Основная СУБД MS SQL Server, также дополнительно используется MS
Access, Interbase For Windows.
- Основное средство разработки программ - Borland Delphi For
Windows.
- Программное обеспечение собственной разработки создано на Delphi
для ОС Windows, естественно, перенос его на другие платформы не
возможен, по причине средства разработки и завязанности, по
определению, на ОС Windows. Тот факт, что часть программного
обеспечения создано по трехзвенной технологии с использованием,
например, Midas не увеличивает его переносимость, так как сервера
приложений сделаны тоже под Windows и переделать их под что-либо
другое (например, CORBA) не так легко, как кажется.
После описания ключевых позиций текущего состояния вычислительной
среды организации, можно сделать общее замечание в отношении
возможностей перехода разработчиков программного обеспечения на какую
либо из современных технологий разработки корпоративных приложений,
подобную CORBA или .Net. Как видно из вышеприведенного описания
вычислительной среды не применяется ни одна из известных корпоративных
технологий разработки программного обеспечения. Разработка производилась
"кусочно-непрерывным" методом. В основном, в зависимости от прихотей
некоторых "сильных" личностей. Но в дальнейшем проводить такую политику
невозможно, так как технологии, сравнение которых производилось в данном
обзоре, как CORBA-Java, так и .Net Framework - серьезные технологии,
требующие тщательного планирования и проектирования. Обе технологии -
новы для организации. Но эти замечания имеют общий характер. На самом
деле, различия все же имеются. И, в частности, для организации не
безразлично какую из них применять.
Какие же требования предъявляет организация к своему программному
обеспечению ?
- Чтобы ни программное обеспечение, ни его разработчики не
доставляли слишком много хлопот. Это означает, что в идеале никакие
программы, компьютеры и программисты не должны были бы быть заметны,
как будто их вообще не существует. Компания жила бы своей
бизнесс-жизнью со своими бизнесс-процессами, обычными, понятными
всем, человеческим процессами.
- А если быть более серьезным, то компании нужно чтобы программы
выполняли свои функции и в первую очередь, автоматизировали бы ее
бизнес-процессы на том уровне, который позволял бы поддерживать
конкурентоспособность с другими подобными организациями, то есть, за
счет автоматизации рассчитывают получить выигрыш в конкуренции. Это
достигается тем, что автоматизация организует и упорядочивает данные
и позволяет ускорять их обработку. Естественно, что и само развитие
программного обеспечения организации должно идти в ногу со временем.
То есть, создание необходимых программ не должно отставать от
потребностей. Это означает, что разработчики программного
обеспечения должны использовать в своей деятельности именно рабочие
инструменты, а не средства для научных исследований.
Как же можно достичь этих целей?
Представим себе несколько предполагаемых моделей развития
программного обеспечения типичной организации, описанной выше.
- Принимается решение взять в качестве корпоративного стандарта
разработки программного обеспечения какую-либо технологию на основе
симбиоза Java-CORBA. Это означает, что:
- Во-первых, CORBA требует тщательного планирования
распределенной системы объектов. По этой причине необходимо
произвести реинжиниринг существующего программного обеспечения,
проведя несколько циклов анализа - проектирования. Можно, также
предположить несколько другой вариант, без полного
реинжиниринга, а с постепенным переходом на другую платформу.
Что будет вариантом кусочно-непрерывного метода. Но такой подход
в несколько раз замедлит процесс создания корпоративной системы
даже по сравнению с полным реинжинирингом, который и сам по себе
не быстрый процесс. Так как, даже при полном реинжиниринге
все-таки производится переход на другую платформу. Кроме того,
аналитикам и проектировщикам необходимо очень хорошо знать и
чувствовать архитектуру CORBA, так как это довольно тонкая
материя и ошибки в проектировании сразу обернуться плохой
производительностью системы или же ее неработоспособностью.
Следовательно, прежде чем будет создан жизнеспособный проект
системы, скорее всего будет необходимо совершить не только
несколько циклов анализ-проектирование, но и несколько циклов
анализ-проектирование-реализация.
- Во-вторых, необходимо будет создать всю инфраструктуру
данной технологии, так как на платформе Windows изначально, за
исключением виртуальной машины Java производства фирмы
Microsoft, не существует даже намека на нее. Это означает замену
операционной системы на части компьютеров, развертывание
компонентов Java-CORBA на всех компьютерах, настройку этой
системы.
- В-третьих, программисты переходят с основного средства
разработки, каким является Delphi на данный момент на какую-либо
среду, поддерживающую язык Java. Такая необходимость диктуется
тем, что гибриды Java-CORBA всегда понимают только язык Java и
ориентированы на архитектуру вычислений фирмы Sun Microsystems.
Кроме того часть программистов придется переучивать на другую ОС
при переходе с привычной платформы Windows.
- В-четвертых, уже в процессе разработки необходимо
переучивать пользователей, так как интерфейс реализуемой системы
наверняка будет отличаться от привычного для пользователя
Windows. Фирма Sun конечно же позаботилась о средствах создания
пользовательского интерфейса, но, естественно, это не может быть
тем же самым, что реализовано в средствах разработки под
Windows. Хотя бы по причине извечного противостояния Microsoft и
Sun.
- В-пятых, в случае кусочно-непрерывного процесса встает
вопрос - а к чему же в конечном итоге приведет разработка? Либо
система так и останется кусочно-непрерывной, часть программистов
будет работать на Java, часть программистов - на Delphi, часть
на каком-либо птичьем языке и все будут довольны сами собой.
Либо, вся система постепенно переходит на платформу Java-CORBA с
постепенным отмиранием старого, непрогрессивного и
несовременного. Но в этом случае создается повышенный риск
развертывания событий в соответствии с вариантом, описанным в
следующем параграфе и соответствующим параличем деятельности
компании.
- В-шестых, в любом случае как полного реинжиниринга, так и
постепенного перехода можно указать на один изьян данного
варианта развития корпоративной системы. Это ненадежность
базирования разработки на виртуальной машине Java. Для мобильных
наладонников и стиральных машин в сельской местности JVM еще
может быть и сойдет, так как там даже и не слышали об ОС
Windows. Но в типичной организации основная ОС рабочих мест
пользователей - Windows. По этой причине, а также как отмечалось
выше по причине серьезной тяжбы Microsoft и Sun из-за JVM, и
отказа Microsoft от распространения даже своей JVM, не говоря
уже о JRE фирмы Sun не стоит в настоящий момент ориенироваться
на использование виртуальной машины Java на базе ОС Windows.
- В-седьмых, внедрение системы и ее обслуживание будет
возможно, но будет сопряжено с повышенной сложностью настройки и
конфигурирования, так как CORBA всегда отличалась сложностью и
запутанностью конфигурирования.
- Принимается решение взять в качестве корпоративного стандарта
разработки программного обеспечения технологию CORBA в чистом виде.
Это означает, что:
- Во-первых, см предыдущий вариант.
- Во-вторых, необходимо будет создать всю инфраструктуру
данной технологии, так как на платформе Windows изначально не
существует даже намека на нее. Это означает замену операционной
системы на некоторых компьютерах, развертывание компонентов
CORBA на всех компьютерах, настройку этой системы.
- В-третьих, программисты не будут переходить с основного
средства разработки, каким является Delphi на данный момент на
другое. Части же программистов все же придется перейти с
привычной платформы Windows на другую ОС (для создания серверных
объектов). Но, хотя программисты не переучиваются с привычного
языка на другой, все равно им приходится нелегко. Так как им,
бедным, придется создавать самим, вручную все то, что было
выкинуто из данного варианта развития корпоративной системы
вместе с инфраструктурой Java. Это тяжелый и неблагодарный труд,
так как все что они создадут будет все те же колеса, которые не
раз изобретали до них. Кроме того, наверняка такое программное
обеспечение будет глючным и примитивным. Такой вывод следует из
сравнения возможностей маленькой команды разработчиков которая
по определению не обязана состоять из гениев, с мощной
корпорацией, например, Sun Microsystems.
- В-четвертых, все же пользователей придется переучивать, так
как интерфейс реализуемой системы будет отличаться в силу
архитектурных особенностей CORBA.
- В-пятых, в случае кусочно-непрерывного процесса встает
вопрос - а к чему же в конечном итоге приведет разработка? Либо
система так и останется кусочно-непрерывной, часть программистов
будет создавать клиенты и серверы CORBA, часть - создавать
"традиционные" приложения на Delphi, часть ничего не делать, а
часть, может быть перейдет на технологию .Net. Но такой вариант
развития означает полную дискредитацию идеи создания
корпоративной системы. Так как системы-то как раз и не будет.
Будет как и в старые добрые времена куча программ и программок
между которыми нужно будет делать массу переходников. Другой
вариант - вся система постепенно переходит на платформу CORBA с
постепенным отмиранием старого. Но, в силу трудоемкости
изобретения колес (т.е. программирования инфраструктуры
приложений CORBA) такая разработка затянется на многие годы и
устареет к моменту ее развертывания (так может произойти даже в
том случае, если не учитывать, что CORBA сама по себе уже
несколько устаревшая технология).
- В-шестых, как в случае полного реинжиниринга, так и
постепенного перехода можно указать на один изьян данного
варианта развития корпоративной системы. Это ненадежность
базирования программного обеспечения созданного по технологии
CORBA на ОС Windows. Создание корпоративной системы будет
сопровождаться необходимостью налаживания взаимодействия
сервисов и клиентов CORBA с сервисами операционной системы и
приложениями Windows, которые основаны на технологии COM. Во
внимание нужно принимать только CORBA-COM взаимодействие, так
как только оно стандартно описано в спецификации CORBA. Но COM
уже устаревшая технология Microsoft, которая не будет
развиваться и поддержка ее будет сокращаться. Кроме того,
Microsoft не зря отказалась от COM. Это произошло в силу
сложности и глючности данной технологии. Поэтому такое
взаимодействие двух технологий кроме бесперспективности еще и
сложно в реализации. Значит, базируя разработку CORBA-системы на
ОС Windows в скором времени получаем, например, несовместимость
с новыми версиями MS Office, службами ОС и т.д.. Нужно
учитывать, что Windows 98 доживает последние деньки и, в скором
времени, Microsoft может объявить о прекращении поддержки
Windows 98, как она сделала в отношении Windows 95.
- В-седьмых, внедрение системы и ее обслуживание будет
возможно, но будет сопряжено с повышенной сложностью настройки и
конфигурирования, так как CORBA всегда отличалась сложностью и
запутанностью конфигурирования.
- Принимается решение взять в качестве корпоративного стандарта
разработки программного обеспечения технологию .Net Framework. Это
означает, что:
- Во-первых, .Net также требует тщательного планирования
распределенной системы. Можно произвести реинжиниринг
существующего программного обеспечения. Но в случае применения
технологии .Net можно с большим успехом обойтись без полного
реинжиниринга. Постепенный переход возможен без создания
кусочно-непрерывного метода разработки программного обеспечения.
Это происходит в силу совместимости технологий Microsoft снизу
вверх. Часть системы может работать на старой технологии, часть
на новой, причем способы взаимодействия этих частей не нужно
придумывать и реализовывать, их предоставляет Microsoft. В
последствии старая часть заменяется. Такой подход конечно
замедляет создание корпоративной системы, но, вместе с тем, не
прерываются бизнесс-процессы организации. .Net проще чем
технологии Java_CORBA и поэтому может понадобиться меньше циклов
проектирования для создания спецификаций системы. Кроме того,
аналитикам и проектировщикам "роднее" среда Windows,
предоставляющая, к тому же, собственные мощные средства
проектирования, разработки и сопровождения приложений. Вообще,
на основе .Net и Windows можно построить совершенно правильный и
современный цикл разработки корпоративной системы. Это позволяют
сделать такие продукты, как MS Visio, MS Visual Studio .Net, MS
Visual Source Safe, MS Installer, MS Office. Причем, эти
продукты вместе с другими средствами операционной системы и
приложениями составляют единую среду полностью удовлетворяющую
потребности разработчика. Что разительно отличается от
кусочно-непрерывного состояния средств разработки применяемых
для технологии CORBA. Единую более-менее полную и современную
среду предоставляет гибридное решение на основе Java-CORBA, но
проблемы с JVM внушают опасения в смысле ее использования на
практике. Кроме того, эта среда разработки все равно уступает
решению на основе .Net - Windows.
- Во-вторых, нет необходимости в создании инфраструктуры .Net
на платформе Windows. Развертывание .Net заключается в запуске
лишь одного экзешника и производится в течение нескольких минут
на любой операционной системе семейства Windows начиная с
Windows 98. Другие службы не входящие в .Net но необходимые для
работы технологии поставляются вместе с ОС. Никакого
специального конфигурирования не требуется. В случае же
использования ОС отличных от Windows, возможно, потребуется
дополнительное конфигурирование. Но, даже если его сложность
сравнима с конфигурацией CORBA (более сложную настройку чем
CORBA нельзя брать в расчет, так как такую систему можно считать
просто неработоспособной), то все равно преймущество на стороне
.Net по причине меньшего количества серверов с ОС отличной от
Windows.
- В-третьих, программисты могут переходить с Delphi на другой
язык программирования, а могут и не переходить. Почему? Потому,
что если они продолжают программировать на Delphi, то созданные
программы можно считать макетами или прототипами реальных
программ, которые в последствии будут работать на платформе
.Net. Это возможно в силу заявления фирмы Borland о планируемом
выпуске к концу 2002 г. Delphi, Builder и других средств
разработки поддерживающих технологию .Net.
- В-четвертых, пользователей не придется переучивать приемам
работы, так как интерфейс реализуемой системы будет абсолютно
идентичным предыдущим системам на основе ОС Windows.
- В-пятых, в случае кусочно-непрерывного процесса встает
вопрос - а к чему же в конечном итоге приведет разработка?.
По-видимому как раз постепенный переход на технологию .Net и
есть оптимальный вариант построения корпоративной системы. Это
объясняется теми рамками, в которые нас загоняют разработчики
технологии .Net. Можно предположить, что фирма Microsoft сама
желала бы чтобы все вдруг разом перешли на ее новую прекрасную
технологию. Но осознавая, что все-таки для большинства
организаций это невозможно в силу использования на практике
множества других технологий в которые были сделаны немалые
капитальные вложения, Microsoft очень хорошо продумала методику
мигрирования существующих приложений на платформу .Net. Кстати,
для рассматриваемой типичной организации предыдущее замечание о
капитальных вложениях в другие технологии не существенно, так
как их не было, а значит, переход на .Net Framework с платформы
Windows на ту же платформу Windows сильно облегчается. Но, все
же есть смысл постепенно переходить на данную технологию, так
как процесс перехода хорошо разработан Microsoft и, к тому же,
есть смысл не прерывать бизнесс-процессы компании во избежании
осложнений с руководством компании.
- В-шестых, ОС Windows является основной ОС, используемой в
организации. Перевод пользовательских рабочих мест под
управление другой ОС в ближайшем будущем не только не может
прогнозироваться, но даже если кто-либо вдруг решит это сделать,
то можно смело предсказывать катастрофические последствия
подобного деяния. Такое можно сравнить со стихийным бедствием,
которое остановит и дезорганизует всю деятельность организации
на долгое время. Либо это можно сравнить с диверсией
направленной на подрыв деятельности в интересах какой-либо
конкурирующей организации. Несовместимость же .Net Framework со
своей родной ОС можно увидеть только в страшном сне. Поэтому
развертывание данной технологии на базе Windows, являющейся
основной ОС не только в данной типичной организации но и во всем
мире дает неоспоримые преимущества перед всеми остальными
технологиями.
- В-седьмых, внедрение системы и ее обслуживание вряд ли будет
слишком сложным. Системные и сетевые администраторы давно
отмечают на порядок более простую настройку ОС Windows по
сравнению, например, с UNIX. Можно предполагать, что единая
идеология конфигурирования продуктов Microsoft поддерживается и
в отношении .Net Framework. Кроме того, в документации к .Net
Framework указывается, что ее разработчиками были предприняты
усилия для дальнейшего упрощения конфигурирования системы. Они
исходили из опыта создания предыдущих программных продуктов для
Windows, а также анализировали опыт эксплуатации систем
распределенной обработки данных от других производителей
программного обеспечения. В результате можно ожидать, что и
престарелый сисадмин с похмелья сможет справиться с установкой
данной системы.
Общие выводы.
Сравнение двух технологий: .Net Framework и Java-CORBA показывает,
что каждая из этих технологий имеет свои переимущества и свои
недостатки. Хотя, все-таки, .Net на фоне CORBA выглядит более
современной и готовой к использованию технологией. Можно сделать вывод,
что применение технологий определяется конкретными условиями,
существующими в той или иной организации. В частности, это основная
операционная система, которая используется на рабочих местах
пользователей, капитальные вложения в другие технологии сделанные ранее
и т.д.
Анализ состояния программного обеспечения типичной
среднестатистической организации показывает, что имеет место случай,
который можно назвать "состоянием чистого листа". То есть, не
используется и не использовалась ни какая технология управления
распределенными корпоративными данными. С одной стороны это печальный и
удивительный факт, но с другой стороны такое состояние, сложившееся
именно в момент выхода мощнейшей платформы разработки распределенных
корпоративных приложений Microsoft .Net Framework - счастливый случай.
Поэтому возникает возможность начать все с чистого листа используя
наиболее современную, мощную и пригодную для коммерческого применения
технологию - .Net Framework. Можно только посоветовать брать быка за
рога и вперед, в светлое будущее - успех гарантирован.
Литература.
- Дирк Слама, Джейсон Гарбис, Перри Рассел "Корпоративные системы
на основе CORBA", М., 2000 г.
- Спецификация CORBA 2.6.1 консорциума OMG.
- Microsoft Developer Network.
Приложение 1.
Обзор источников Internet с информацией о технологиях CORBA и .Net
Framework.
Отрывки из интервью Grady Booch MSDN Magazine.
Grady Booch всемирно известен своим огромным вкладом в создание
современных технологий анализа, моделирования и разработки программного
обеспечения. С момента образования в 1980 г. Rational Software
Corporation, он был основным разработчиком данных методологий. Grady
один из авторов Unified Modeling Language (UML). Он автор шести
бестселлеров в области компьютерных наук, в том числе, "The Unified
Modeling Language User Guide" (Addison-Wesley, 1999) и "Object-oriented
Analysis and Design with Applications" (Addison-Wesley, 1994).
MSDN Magazine: Как вы можете охарактиризовать тенденции и
изменения происходящие за последние 5 лет в области разработки
программного обеспечения и как вы можете описать ваше влияние на данные
изменения?
Grady "...Я думаю, что пришествие такой технологии, как
Microsoft .NET Framework представляет собой реализацию программной
индустрии которая содержит минимальный средний, промежуточный слой.
Технология действительно представляет правильное разделение ролей тех,
кто разрабатывает программы и тех, кто должен создавать архитектуру
системы, потому что в .NET представлено большинство элементов
инфраструктуры, которые программисты ранее должны были создать
собственными руками. Более того, технология содержит в себе так много
реализаций прмышленных стандартов, например, SOAP and XML, что по этой
причине различным предприятия и организации становится намного легче
создавать гораздо более сложные и продвинутые программные системы,
отвечающие целям их бизнеса...".
MSDN Magazine: Какой была ваша первая реакция, когда вы узнали
про продвижениие технологии .NET фирмой Microsoft
Grady "...Я этому очень обрадовался, так как я знал о мучениях
разработчиков имевших дело с технологиями COM/COM+ фирмы Microsoft на
одном полюсе мира программного обеспечения и не микрософтовскими
технологиями на другом полюсе мира CORBA. Я всегда считал, что эти
технологии более сложные, чем это должно быть. Я рукоплескал восшествию
технологии .NET на пьедестал, по причине того, что она освобождает
программистов от ручного создания многих тривиальных механизмов. Я,
также, осознал, что .NET является следующим шагом и переходом на болеее
высокий уровень абстракции. Ранее люди не знали ничего подобного. Ранее
были операционные системы и было промежуточное программное обеспечение.
Сейчас есть такие технологии, как .NET котрые повышают уровень
абстракции таким образом, что я, как разработчик, могу концентрироваться
на сущностях, которые действительно для меня важны - в основном, это
суть моего бизнесса - и я могу почти не заботиться об остальной
инфраструктуре вычислительной среды. Я приветствую все, что уменьшает
сложность и дает возможность создавать приложения более качественно и
быстро. .NET удовлетворяет этим требованиям".
MSDN Magazine: Visual Studio .NET упростила смешение различных
языков в рамках одного проекта. Что вы думаете о возникающих
возможностях и проблемах, которые может породить данное решение?
Grady "...Для меня не так важен язык, сколько важны среды
разработки, инструменты и их компоненты.
В практике создания корпоративных систем я наблюдал очень, очень мало
проектов, которые бы использовали лишь один язык программирования.
Недавно я беседовал с архитектором компании, которая разрабатывает
сотовые телефоны. Он рассказал мне про телефон следующующей генерации,
который использует множество различных языков, начиная с языка
Assembler. Это же наблюдается и в большинстве современных проектов. Они
не единоязыковые, они не гомогенные, они гетерогенные. Нравится вам это
или нет, реальность такова, что организация, разрабатывающая и
используящая программное обеспечение вынуждена иметь дело со многими
языками программирования. Отдельно взятая команда может использовать
один язык, но в масштабах всей организации вы всегда обнаружите
использование многих языков по причине различных задач, выполняемых
данной организацией. Поэтому, все что может заполнить разрыв и разрушить
стены между этими языками приветствуется...".
Borland brings .Net into view
By Matt Berger
February 12, 2002 5:16 pm PT
SAN FRANCISCO
Накануне выхода в свет Visual Studio .Net software development suite
фирмы Microsoft, Borland Software сделала заявление о поддержке среды
разработки .Net в следующих версиях своих программных продуктов.
В течение второго полугодия 2002 г. Borland выпустит релизы Borland
Delphi, Borland C++ Builder и других сред разработки, которые будут
содержать поддержку создания приложений .Net для систем на платформе
Intel.
Продукты будут содержать поддержку Microsoft .Net Framework,
программного окружения, которое необходимо для запуска приложений,
созданных по технологии .Net. Также будет поддерживаться ASP.Net (Active
Server Pages. Net), программное обеспечение фирмы Microsoft для Web -
хостинга и промышленные стандарты XML (Extensible Markup Language).
Средства разработки будут содержать поддержку Microsoft Intermediate
Language (MSIL), который является промежуточным кодом, служащим для
интеграции приложений, написанных на других языках программирования в
приложения .Net. Такое решение принято фирмой Borland в силу того, что
Microsoft заявила о реализации в Visual Studio .Net поддержки разработки
программ более чем на 20 различных языках. Такие приложения будут
компилироваться в MSIL перед тем, как их можно будет запустить на
платформе .Net...
Платформа Microsoft .NET с точки зрения ее создателей
Отрывки из интервью с Андерсом Хейлсбергом - руководителем проекта
создания и развития языка программирования C# и основным участником
разработки Microsoft .NET Framework, также известен как один из основных
разработчиков Delphi.
КомпьютерПресс: Следует ли ожидать более тесной интеграции
.NET с серверами приложений сторонних производителей, кроме
Web-сервисов, например прямого доступа к EJB, поддержки CORBA?
А.Х.: Поддержка прямого доступа к EJB означает добавление Java
поверх имеющихся библиотек, что мне не представляется целесообразным. Я
думаю, что стратегия, связанная с развитием технологии XML Web-сервисов,
наиболее подходит для поддержки интеграции с такими серверами
приложений. Отметим, что IBM, как и другие крупные игроки рынка
программного обеспечения, относятся к указанной стратегии более чем
серьезно и поддерживают ее. Именно поэтому я считаю, что интеграция на
основе этой технологии - вполне реальное явление.
Лично я полагаю, что технологии, подобные CORBA, нeдостаточно
масштабируемы. В масштабе локальной сети эти технологии решают многие
проблемы, но, как только мы начинаем работать в масштабе континента,
применение таких технологий может создать целый ряд проблем. Главная из
них в том, что целью данных технологий является полная изоляция
программиста от передачи данных. Не получая отклика от объектов, к
которым вы обращаетесь, вы не знаете, что именно происходит при передаче
данных, и потому должны что-то изменять в объектах, вызывать их снова и
снова, чтобы разобраться в происходящем.
Даже ограниченная скорость света является проблемой, если масштаб
приложений таков, что вы охватываете и Европу, и США. Именно по этой
причине стоит вернуться к технологиям распределенных вычислений,
основанных на сообщениях, таких как применение Web-сервисов. Надежная
передача сообщений дает шанс обеспечить большую масштабируемость,
поэтому мы так глубоко верим в Web-сервисы.
ТЕХНОЛОГИЧЕСКИЕ ПЕРСПЕКТИВЫ. Анализ .NET.
Маду Сиддалинджайя (Madhu Siddalingaiah)
8 Ноября 2000 г. -- Microsoft представила свою новую
web-стратегию, называемую .NET. Информации о платформе .NET мало, но
некоторые ее сходства с платформой JavaTM видны уже сейчас. Является ли
.NET радикально новой и передовой платформой, как заявляет Microsoft?
Или это другой путь для Windows-разработчиков, которые еще не перешли на
платформу Java?
.Net состоит из трех основных частей: набора framework-ов уровня
приложений, набора базовых framework-ов, и независимой от языка
исполняющей среды (common language runtime, CLR). Как предполагает
Microsoft, это позволит разработчикам создавать устойчивые программные
продукты, используя общий набор API. Архитектура - определенно в духе
90-х. Динамическая, объектно-ориентированная среда исполнения, в
противоположность статическому окружению как в C/C++ или VB. Набор API
доступен из любых поддерживаемых средой исполнения языков. Имеется
прямая поддержка сетевого взаимодействия и распределенных вычислений.
Явное улучшение того, что Microsoft предлагала Windows-разработчикам
ранее. Но эти улучшения определенно не являются новыми или передовыми. В
большей степени платформа .NET предназначена для улучшения работы тех
разработчиков, которые пишут только под Windows. По существу, .NET это
попытка помочь программистам на Visual C++ и Visual Basic начать идти в
ногу со временем.
В основе платформы .NET лежит независимая от языка исполняющая среда
(common language runtime). Эта среда, обеспечивающая также сборку мусора
и контроль типов, исполняет код на внутреннем языке (internal
[intermediate] language, IL). Андерс Хейлсберг (Anders Hejlsberg),
архитектор исполняющей среды, признал, что такая концепция не нова и
сравнил ее с интерпретатором пи-кода, таким как UCSD Pascal. Хейлсберг
показал, что использование промежуточного внутреннего языка (IL) имеет
ряд преимуществ, таких как возможность поддержки различных процессорных
архитектур и введение контроля типов. Хейлсберг также отметил, что IL
может быть верифицирован перед исполнением, что повышает безопасность.
Конкретные детали пока еще неизвестны, поэтому сложно объективно оценить
эту среду выполнения или сравнить ее с виртуальной машиной Java (JVMTM).
На основе доступной информации можно сделать вывод, что обещанная CLR
предназначена для достижения многих из тех целей, которые уже
реализованы и проверены временем в виртуальной машине Java.
CLR имеет доступ к набору базовых framework-ов, или общих классов.
Таковыми являются классы для сетевого взаимодействия, ввода-вывода,
безопасности, коллекций, интернационализации и т.д. Классы
рассортированы по функциональным группам при помощи пространств имен.
Это не очень сильно отличается от пакетов Java. Но поражает тот факт,
что имена этих классов удивительно похожи на имена классов из Java core
API.
Framework-и приложений включают в себя улучшенные active server pages
(ASP+) и ActiveX Data Objects (ADO+) вместе с новыми компонентами
пользовательского интерфейса (WinForms и WebForms). Страницы ASP+ могут
компилироваться в промежуточный язык так же, как и JavaServer PagesTM в
конечном итоге компилируются в Java байткод. Но для ASP+ нет независимых
поставщиков, в то время как существует множество поставщиков продуктов
на базе JSPTM для различных платформ. Кроме того, проект Apache перенял
reference-реализацию JSP и поддерживает ее как freeware.
Microsoft также анонсировала новый язык программирования с названием
C#. C# - язык со сборкой мусора из семейства C/C++. Он обладает
некоторым сходством с языком Java. C# - полностью
объектно-ориентированный язык, в нем существует единственный базовый
класс и множественное наследование, реализуемое при помощи интерфейсов.
Оценка различий между языками Java и C# главным образом субъективна,
сложно аргументированно доказать кто из них действительно лучше.
Microsoft заявила о том, что C# будет передан органам стандартизации.
Это звучит ободряюще, но C# - это только язык, но не платформа .NET
целиком. Microsoft не только не заявляла, но даже и не намекала на то,
что платформа .NET целиком может быть представлена для стандартизации.
Тем не менее, разработчики, проектирующие приложения на C#,
оказываются в ловушке. Любое более-менее серьезное приложение нуждается
в использовании высокоуровневого API (например, для доступа к базам
данных и т.д.) который наверняка не будет входить в состав библиотек,
представленных для стандартизации. Это не означает, что 100% кода вашего
приложения будет привязано к .NET в результате закрытости платформы -
только лишь одна его критическая часть. Таким образом, любое серьезное
приложение наверняка будет крайне сложно портировать под другую
операционную систему. В результате Вы замыкаетесь на одного
производителя, и этот производитель - Microsoft. Язык Java, VM и API -
все эти составляющие части независимы от производителя.
Преимущество платформы Java по сравнению с .NET очевидно. Основное
отличие в том, что платформа Java - зрелое кроссплатформенное решение,
не привязанное к какой-либо операционной системе. Что нельзя сказать о
.NET - решении только для Windows. Даже если независимая от языка
исполняющая среда (common language runtime) будет портирована под другие
операционные системы, это всего лишь часть .NET. Многие из базовых
компонент и все framework-и уровня приложений непосредственно связаны с
Windows. Это означает, что серьезные приложения, построенные на
платформе .NET, будут работать только под Windows.
В отличие от .NET, любая совместимая реализация среды исполнения Java
содержит в точности один и тот же набор базовых API, независимо от
операционной системы. Совместимые JRE существуют для Windows, MacOS,
Linux, Solaris, даже для OS/390. Это означает, что код на Java может
быть написан и отлажен на десктопе, а потом перенесен на мощнейший
сервер или даже mainframe. Приложение, написанное для платформы .NET
будет работать только на платформе Microsoft. Очевидно, что основная
задача .NET - утвердить зависимость от платформы. Microsoft раскручивает
.Net как передовую и новую платформу, но реально это просто
модернизированный комплект наручников для разработчиков.
Платформа Java означает выбор. Sun не единственный поставщик
платформы Java. IBM, Symantec, Apple, а также множество проектов open
source разработали реализации платформы Java и инструментарий для
множества операционных систем. С платформой Java разработчики имеют
выбор инструментария, в то время как Microsoft настойчиво склоняет их в
сторону Visual Studio (или другому инструменту, подключаемому к Visual
Studio).
Независимые эксперты проинспектировали общедоступный исходный код
платформы Java на предмет проблем с безопасностью. Признаков того, что
Microsoft когда-либо целиком откроет исходный код платформы .Net, нет.
Платформа Java означает выбор для корпораций, где среда исполнения
Java может быть получена из разных источников, и является
взаимозаменяемой. Sun поставляет reference-реализацию платформы Java 2,
Enterprise Edition. Многие другие производители предлагают устойчивые,
промышленные решения на базе J2EE, такие как BEA Weblogic, IBM
Websphere, Bluestone Saphire/Web. Все эти решения конкурируют по
производительности и инструментальной поддержке, здесь нет вопросов
совместимости и беспокойства по поводу замыкания на поставщика. Код на
Java, написанной для любого из этих серверов приложений, может быть
перенесен на любой другой сервер приложений без изменения. Это явное
конкурентное преимущество в сегодняшней гетерогенной среде.
Заключение
Нет сомнений, что Microsoft пришла к такому же выводу, как и любой
другой в индустрии: платформа Java - превосходная технология,
пользующаяся громадным успехом. Вместо того, чтобы принять
кроссплатформенное, нейтральное по отношению к производителю решение,
которым является платформа Java, Microsoft все еще проталкивает
одноплатформенное, ориентированное на одного производителя решение.
Платформа .NET - шаг вперед для программистов на Visual C++ и Visual
Basic, но это лишь еще одна проприетарная платформа Microsoft, которая
приковывает разработчиков к Windows, пусть даже и .NET-овскому варианту
Windows.
Compaq строит мост между .Net и Java
05.03.2002
Подразделение Compaq Global Services заключило соглашение с компанией
Iona Technologies об использовании ее платформы Orbix E2A для создания
набора служб интеграции систем уровня предприятия. С точки зрения
руководства Compaq, платформы J2EE и .Net будут применяться на
предприятиях на равных, в связи с чем пользователям потребуется
возможность интеграции гетерогенных сред. Цель договора с Iona -
создание широкого круга служб и решений для автоматизации
бизнес-процессов, совместной работы и интеграции, не зависящих от
применяемых базовых платформ, приложений и сред разработки.
Мэтт Лоуни (Matt Loney), ZDNet UK
Пропасть между позициями IBM и Microsoft по вопросу
веб-сервисов стала еще шире, после того как в прошлый уикенд
проповедники веб-сервисов каждой компании схватились по поводу
преимуществ, предлагаемых при создании взаимодействующих
интернет-приложений платформами .Net и Java 2 Enterprise Edition (J2EE).
Старший консультант по архитектуре из IBM Кит Эдвардс (Keith Edwards)
и менеджер группы технической пропаганды .Net Microsoft Нил Хатсон (Neil
Hutson) выступили на отраслевой конференции NetEvents в Монтрё
(Швейцария).
Эдвардс обрушился с критикой на модель программирования Microsoft
.Net (она разработана после того, как Sun доказала в суде, что Microsoft
присвоила язык Java), утверждая, в частности, что решение Microsoft о
поддержке десятков языков программирования принципиально ошибочно. "Я ни
разу не слышал, чтобы программист просил: "Дайте мне пять языков
программирования"", - заверил он, подчеркивая при этом широкое
распространение языка Java. Эдвардс признал, что программистов на языке
Visual Basic тоже много. В то же время он отметил, что, хотя этот язык и
подходит для приложений клиент-сервер, "модель .Net требует его
адаптации". Кому-то эти изменения покажутся небольшими, но для тех
программистов, которые ориентируются на модель клиент-сервер, они
существенны.
"Даже Microsoft говорит программистам, что на адаптацию потребуется
от шести месяцев до двух лет", - сказал он. Язык Microsoft С# Эдвардс
тоже раскритиковал: по его словам, единственное его назначение -
"сымитировать то, что уже дает Java". Какой бы выбор ни сделали
разработчики, им придется переучиваться: с Visual Basic 6 на Visual
Basic .Net, на C# или на Java. "Язык Java уже освоен, так что, если уж
все равно переучиваться, почему бы не выбрать открытую структуру,
которая позволяет исполнять программы на чем угодно?" - говорит Эдвардс.
Парируя аргументы IBM, Хатсон разъяснил позицию Microsoft следующим
образом: один язык не может отвечать всем требованиям. "Мы позволяем
предприятиям поддерживать Cobol, Java и все прочие языки на платформе
.Net", - сказал он, добавив, что есть огромное число программистов на
Visual Basic, которым будет нетрудно освоить C#, так как он опирается на
существующие языки. "C# основан на Java и C++, - сказал он. - Но этот
язык обладает функциональностью, которая потребуется от новых языков в
будущем. Для его освоения нужно не так уж много времени".
Эдвардс подчеркнул, что там, где это имеет смысл, IBM будет
поддерживать Microsoft .Net Framework. "Но приложения, в которые
предприятия более 30 лет вкладывали средства, ни в коем случае не
пропадут. Подход IBM заключается в том, что компаниям следует строить
веб-сервисы на абсолютно эластичной открытой структуре. J2EE всегда
обеспечит программистам полную независимость на любой аппаратной
платформе", - заявил Эдвардс.
О слиянии .Net и Java.
Дэн Мезик (Dan Mezick), специально для ZDNet
15 февраля, 2002, 10:22
КОММЕНТАРИЙ - Борьба между Microsoft и Sun Microsystems за
пристрастия программистов в самом разгаре, но черта между конкурирующими
платформами разработки ПО уже начинает размываться.
Причина проста: то, что я называю Java.Net, из мелкой ряби переросло
в заметную волну. На рынке появляются продукты bridgeware, такие как
кросскомпиляторы, между тем и сами производители платформ выпускают
инструменты, наводящие мосты между Java и .Net. Такое ползучее слияние
платформ Java-J2EE и Microsoft .Net вызывает среди программистов во всем
мире дискуссии о том, к чему это ведет и куда разработчикам податься.
Какие же силы заставляют сближаться .Net и Java? Во-первых, это
Microsoft Intermediate Language (MSIL), который служит преддверием
технологии Common Language Runtime, лежащей в основе .Net. Он открывает
широкие возможности для кросскомпиляции - когда конечный результат
рассчитан как на .Net, так и на Java. В числе таких возможностей
преобразования из MSIL в байт-код JVM, из MSIL в Java и из Java в MSIL.
И это только начало.
Кому это выгодно?
Любое слияние в каком бы то ни было направлении будет лить воду на
мельницу Microsoft. Так как Java - уважаемая платформа, всякое
соприкосновение с ней записывается претенденту в чистый актив.
Рассмотрим следующие варианты:
- Любые действия разработчиков, направленные на слияние, приведут
по крайней мере к частичному использованию комплекса Visual
Studio.Net, который вышел на прошлой неделе и позиционируется как
лучшая интегрированная среда разработки. Так что всякое действие по
слиянию с использованием VS.Net явно на руку Microsoft.
- Java-программисты быстро освоят среду .Net, так как свойства
объектов и языка Java/J2EE и C#/.Net практически идентичны. Причем
Java-разработчику перейти на .Net гораздо легче, чем традиционному
программисту на платформе Microsoft (читай: VB).
- Каждый Java-разработчик, освоивший .Net, потерян для разработки
приложений J2EE - по крайней мере теоретически.
- Наконец, и это, пожалуй, самое важное, экономные директора по
информационным технологиям, всерьез воспринимающие .Net, будут
искать способы использовать (а отчасти и удовлетворить) интерес
разработчиков к Java, предлагая им создавать приложения .Net.
Некоторые другие недавние разработки, способствующие слиянию Java и
.Net, также указывают на то, чем все это может закончиться.
Microsoft выпустила инструментарий JUMP и компилятор J#.Net,
максимально упрощающие переход с Java на C#. Сам язык C# имеет целью
сделать процесс портирования Java-программ быстрым, простым и
безболезненным.
Halcyon Software выпустила iNet, транслятор из C# в байт-код JVM,
включаемый в комплекс инструментов Visual Studio.Net. iNet позволяет
использовать C# для генерации байт-кода Java, который затем может
выполняться в виртуальной машине Java. Фишка в том, что разработчик
программ, которые должны выполняться в среде Java, работает, учится на
языках .Net и привыкает к ним.
Remotesoft выпустила Java.Net, инструментарий для выполнения родного
Java-кода в среде .Net. Это средство слияния делает .Net средой
исполнения программ, написанных в Java. Продукт обеспечивает доступ к
библиотекам классов Java через языки .Net и перевод родного исходного
кода Java в .Net-совместимые C# и MSIL.
Последствия всего этого очевидны. MSIL по определению предназначен
для трансляции и кросскомпиляции. Это ведет к появлению большого числа
соответствующих инструментов. Можно ожидать, что ИТ-бюджеты
распределятся между двумя доминирующими платформами: J2EE и .Net. Можно
предположить также, что ИТ-менеджерам будут очень полезны - и,
следовательно, затребованы ими - мощные инструменты кроссплатформной
трансляции. Такой спрос породит новые инструменты слияния. А это
означает, что в конечном итоге победит, по всей видимости, Microsoft,
так как J2EE и Java представляют собой лежачий камень и служат мишенью -
в буквальном смысле.
Сравнение скорости выполнения кода, генерируемого компиляторами C#,
Java, VC6, Intel C++, Delphi.
Из статьи "Кто сегодня самый шустрый?"
Владислав Чистяков
Вызов метода объекта (Mehod call)
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net) |
2.51 |
2.16 |
| Java3 |
8.90 |
4.20 |
| VC 61 |
13.89 |
0 / 5.78 |
| Intel C++1 |
0.00 |
0 / 6.32 |
| Delphi |
17.58 |
6.50 |
| VB 62 |
493.97 |
204.00 |
- Intel C++ compiler в режиме максимальной оптимизации (/O3 /QaxK
или /O3 /QaxM) интерпретировал пустые или содержащие мало кода
функции как inline-функции. В результате этого метод Test и его
вызовы были полностью соптимизированы, то есть выброшены из
программы и заменены на конечный результат. Надо признать, что если
в VC-варианте реализацию методов оставить в теле класса (даже без
пометки их как inline) VC начинает делать то же самое (так как таким
образом объявленные методы считаются inline по умолчанию). Но
качество оптимизации у VC оказалось несколько лучше, и он смог
больше кода привести к статическим расчетам. В VC есть также и
отдельная опция (/Ob2), заставляющая интерпретировать все (по выбору
компилятора) вызовы как inline. Ее установка тоже приводит к тому,
что этот тест полностью оптимизируется в статическое вычисление.
Однако для чистоты эксперимента мы приводим время, которое требуется
для вызова метода. На практике есть смысл включать эту опцию,
поскольку объем кода при этом увеличивается не так радикально, а
производительность может вырасти значительно.
- VB 6 не может создавать классов в полном понимании ООП. Вместо
этого он создает COM-объекты. Вызов метода COM-объекта медленней,
чем fastcall, применяемый в других языках, но даже это не может
оправдать таких "зверских" накладных расходов. VB-программистам
можно посоветовать побыстрее перейти на VB.Net, а пока этого не
произошло, избегать частых вызовов функций (особенно из отдельных
классов) и реализовывать критичные к скорости алгоритмы на C++
(запаковывая их в методы COM-объектов и DLL-библиотек).
- Для оптимизации теста в Java к классу был применен модификатор
final. По умолчанию все методы в Java являются виртуальными. Причем,
в отличие от C++ и C#, Java от Sun не пытается вычислить, что метод
можно вызывать без виртуальной таблицы. Это приводит к замедлению
работы. Методы, помеченные как final, становятся не виртуальными.
Мне кажется, идеология C++ (принятая в C# и Delphi) более практична,
но это сугубо личное мнение. К сожалению (несмотря на вкусы), final
приводит к некоторым нежелательным последствиям. Так, метод,
помеченный этим модификатором, не может быть "перебит" в
классе-наследнике, а если помечен класс, то от него вообще нельзя
порождать потомков. Конечно, можно забыть про final, но как
показывают наши испытания, если закомментировать final в описании
класса CTest1, скорость вызова метода падает с 4.13 до 14.47, т.е.
почти в три раза. Что же поделаешь - расплата за универсальность.
Надо заметить, что остальные языки этого обзора по умолчанию создают
обычные (не виртуальные) методы. Чтобы сделать метод виртуальным,
необходимо пометить его специальным ключевым словом (обычно
virtual). Исключением является VB 6. Он вообще не поддерживает
наследования, и, как следствие, виртуальных методов. Однако, по
иронии судьбы, так как классы VB 6 являются COM-объектами, вызовы
все равно делаются через виртуальную таблицу (необходимую для
реализации COM-интерфейса).
Вызов виртуального метода объекта (virtual mehod call)
| |
PIII 800 |
AMD 1400 |
| в секундах |
| VC 61 |
15.10 |
5.8 / 6.49 |
| Intel C++ |
15.08 |
6.50 |
| Delphi |
21.35 |
7.01 |
| C# (.Net) |
15.66 |
7.22 |
| Java3 |
29.15 |
14.48 |
| VB 62 |
|
204.00 |
- Первый результат VC - это результат, полученный при
установленной опции, позволяющей компилятору автоматически делать
inline-подстановки функций.
- У VB 6 нет понятия наследования, а значит, нет и виртуальных
методов. Однако, как уже говорилось, все методы объектов в VB
являются методами COM-интерфейса, а значит пользуются техникой
виртуальных таблиц. Т.е. любой метод в VB является виртуальным.
Однако, повторюсь, таких тормозов это не объясняет.
- Лидер нашего первого теста оказался в аутсайдерах в этом тесте.
Но не это больше всего огорчает, а огорчает тот факт, что в Java все
методы по умолчанию являются виртуальными. На практике это может
привести к тому, что Java-приложение окажется медленнее, чем
приложения на других языках, и виной тому будет не слабость
JIT-компилятора, а просто невнимательность или незнание
программиста. Мне кажется не очень правильным перекладывать вопросы
производительности на программиста. Ему ведь и так достанется. Но
многие Ява-программисты считают по-другому. Так, что вам решать
хорошо это или плохо. :)
Доступ к членам класса
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net) |
3.99 |
3.54 |
| Java |
7.55 |
4.85 |
| VC 61 |
8.84 |
1.44 / 5.06 |
| Intel C++ |
8.80 |
5.04 |
| Delphi |
8.79 |
4.34 |
| VB 6 |
118.69 |
76.53 |
- Первая цифра в тесте VC была получена с включенной опцией
"inline-подстановки (раскрытия) функций в любом подходящем случае".
Quick Sort (быстрая сортировка)
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net)2 |
16.73 |
9.50 / 9.17 |
| Java |
24.49 |
12.50 |
| VC 61 |
16.61 |
8.58/ 8.70 |
| Intel C++ |
17.63 |
9.20 |
| Delphi3 |
16.77 |
13.59 / 9.60 |
| VB 6 |
27.01 |
14.07 |
- Первый результат VC - это результат, полученный при
установленной опции позволяющей компилятору автоматически делать
inline-подстановки функций.
- Тест C# был сделан в двух видах - нормальном и "unsafe". Как вы
наверно уже догадались, первая цифра - это время в нормальном, а
вторая в unsafe-режиме. В нормальном режиме компилятор C# вставляет
проверки выхода за границы массива. Отключить такие проверки
невозможно, но C# поддерживает unsafe-режим. В этом режиме C#
превращается в старый добрый C, позволяя пользоваться указателями.
Причем C# имеет конструкцию fixed позволяющую превратить в указатель
любой тип C#. При этом в следующем выражении (в одном или в блоке)
можно безопасно пользоваться указателем. Вам гарантируется, что
сборщик мусора не переместит или освободит память, занятую объектом.
После выхода из области действия конструкции fixed указатель
становится не действительным, а памятью снова начинает управлять
сборщик мусора. Именно этим мы и воспользовались чтобы выяснить на,
что способен C#, если программист не боится сложностей и готов на
все.
- В Delphi runtime-проверки выхода за пределы массива и
переполнения можно включать или отключать в свойствах проекта.
Первое число в таблице - результат с отключенными
runtime-проверками, а вторая - с включенными. Если же проверки
включить, Delphi начинает делить последнее место с VB 6, проигрывая
всем остальным участникам, выполняя этот тест за 13.59 на AMD1400.
Хочется сделать еще одно замечание. Мы наступили на забавные, но
потенциально очень неприятные грабли. Дело в том, что все
современные языки умеют передавать параметры методов как по
значению, так и по ссылке. В Delphi для этого используется ключевое
слово var. Его необходимо указывать перед параметрами. Все это
понятно, но Delphi оказалась единственным компилятором требующим
указания модификатора передачи параметра по ссылке для массивов.
Оказалось, что Delphi с упорством, достойным лучшего применения,
запихивает массив в стек. Думаю, не надо разъяснять, как такая
"забота о программисте" отражается на производительности. Но
производительность страдает при относительно небольших размерах
массивов, в нашем же случае один из массивов имел размер немногим
менее ста мегабайт... Получив сообщение об ошибке, мы попробовали
трассировать программу под отладчиком, но не тут то было. Пару раз
Delphi попросту зависло, еще пару выдало загадочное сообщение. Да и
сама ситуация сбивала с толку. Ну, да ладно... Через пару минут
тупого разглядывания кода мы поняли, в чем проблема, и устранили ее.
Мы понимаем, что сами виноваты, но надо было слышать те слова,
которыми мы вспоминали в эти минуты Borland и все компьютеры вместе
взятые.
Пузырьковая сортировка
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net)2 |
8.16 |
6.20 / 5.29 |
| Java |
20.63 |
10.37 |
| VC 63 |
7.20 |
5.02 |
| Intel C++3 |
7.23 |
4.85 |
| Delphi1 |
9.53 |
12.31 / 5.33 |
| VB 61 |
14.48 |
21.76 / 8.46 |
- Цифра, приведенная перед результатами тестов Delphi и VB 6 - это
время выполнения этого теста с включенной проверкой выхода за
границы массивов. Она приведена не для того, чтобы как-то унизить
эти средства разработки, а чтобы вы могли оценить качество
реализации алгоритма проверки выхода за границы массива в Java и C#
(в остальных языках такие проверки не реализованы). Заметьте, время
Java, языка, который мы считаем интерпретируемым, оказалось вдвое
меньшим, чем у VB 6, и на 20% меньшим, чем у Delphi, которая без
этих проверок показала результат близкий к лучшему. C# вообще был
вне конкуренции в этой области. 6.2 - это результат, достойный
компилятора, не выполняющих никаких runtime-проверок. Но, похоже,
это результат не предел. Господа из Microsoft уже поговаривали о
верификации кода. Правда, эти разговоры были связаны с
безопасностью, но кто мешает вместо выполнения runtime-проверок
заняться интеллектуальной деятельностью? Конечно, из-за того, что не
вся информация доступна во время компиляции, нельзя заменить все
runtime-проверки на статический анализ, но можно же вынести проверки
из тел циклов и рекурсивных функций.
- Как и в прошлом тесте, в этом приводятся результаты работы теста
C# в обычном и "unsafe" режиме. Выигрыш составил примерно 10%.
Оптимист скажет: есть поле для маневра и ручной оптимизации.
Пессимист: можно было бы и пограмотней проверки вставлять. :) Но как
бы то ни было, C# занял первое место в подпольном тесте на лучшую
организацию runtime-проверок. Однако в варианте с runtime-проверками
C# проиграл лидеру почти 30%. Так что Microsoft есть над чем
работать. Ведь тест в unsafe-режиме показал, что разрыв (в 10%) есть
и без runtime-проверок.
- Разрыв между VC и Intel C++ был настолько мал, что на разных
платформах они заняли разные места. Делая скидку на неточность
вычислений можно даже сказать, что они поделили первое место.
Подсчет p (целочисленные вычисления)
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net) |
10.35 |
6.90 |
| Java |
10.99 |
7.56 |
| VC 6 |
10.76 |
7.17 |
| Intel C++ |
10.08 |
6.84 |
| Delphi |
10.34 |
6.80 |
| VB 6 |
20.49 |
8.74 |
Tree sort
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net)5 |
33.66 |
23.60 |
| Java4 |
22.91 |
16.20 |
| VC 61 |
14.75 |
11.85 |
| Intel C++1 |
14.67 |
12.31 |
| Delphi2 |
13.96 |
11.40 |
| VB 63 |
|
|
- При повторном тесте время составило около 35 секунд (что на VC
6, что на Intel C++) - это при тестировании на AMD, на PIII 800
повторный тест занял 39.34 секунды. При этом компиляция
производилась с многопоточной версией MFC, а стало быть, и с
блокировками при выделении и освобождении памяти. После
перекомпиляции проекта с однопоточной версией MFC повторное
выполнение не приводило к заметному снижению быстродействия.
Замедление при повторных тестах вызвано неоптимальной работой
стандартных (Win 32 API) функций работы с хипом
(HeapAlloce/HeapFree) в W2k. По большому счету, ни VC, ни Intel C++
к этому отношения не имеют. Но тестовое приложение писалось с
использованием библиотеки MFC, которая в release-версии пользуется
функциями HeapAlloce/HeapFree. Мы попытались создать отдельный хип,
заменив методы new и delete. Но это ничего не дало. Единственное,
что повлияло - это пересоздание (уничтожение и последующее создание)
хипа перед каждым тестом. При этом время выполнение теста было
одинаковым. К сожалению, в реальных приложениях такие фокусы
проходят с трудом. Но если скорость выделения памяти (а именно она в
основном влияет на скорость создания объектов в нашем тесте)
критична для вашего приложения, и в вашем приложении используется
многопоточная библиотека, можно обратиться к библиотекам сторонних
разработчиков. Например, к библиотеке выпускаемой компанией
MicroQuill (www.microquill.com). Судя по рекламе, они не только
используют более быстрые алгоритмы, но и приводят к хорошему
масштабированию на мультипроцессорных системах. Можно также
попытаться создать свою реализацию (вот только не факт, что она
окажется более качественной, чем аналог от Microsoft), попытаться
найти бесплатную реализацию или плюнуть, ведь подобного экстрима не
так-то просто добиться в реальной жизни. Надо отметить, что
производительность тестов C++ может резко подняться, если Microsoft
перепишет функции управления хипом в будущих версиях Windows.
Проводя эксперименты, мы выявили некоторую информацию, которая может
показаться вам интересной. Реальное время создания дерева заняло 10
секунд (в тесте на PIII 800). Т.е. 4 секунды производится
освобождение занятой памяти. Освобождение заняло почти половину (!)
времени теста, и это при нефрагментированной памяти. При втором
проходе результаты были вообще плачевны. Мы не будем их приводить,
так как не уделили этой проблеме должного внимания.
- Delphi стала победителем и этого теста. Но это не главное, в
конце концов она не намного опередила своих соперников. Главное, что
время теста Delphi почти не увеличилось (!) при повторном проходе!
Это говорит, что функции работы с хипом в Delphi действительно
хороши. И это без дополнительных библиотек и хитростей. Мы провели
препарирование победителя и выявили, что в Delphi полностью
переписана работа с хипом. Для больших кусков памяти используется
прямая работа с VirtualAlloc (и т.п.), а для небольших блоков памяти
создана хитрая структура, группирующая блоки одинакового размера и
хранящая их в отдельных буферах. Чтобы серьезно разобраться в том,
как в Delphi сделаны функции работы с хипом, потребовалось бы
слишком много времени, да и задача эта в наши планы не входила. Тем
же, кто хочет знать больше, мы советуем обратиться к исходникам,
прилагающимся к Delphi, благо их никто не скрывает. Правда, они (как
и большая, системная часть кода VCL) не документированы, так что
придется ползти на животе.
- VB 6, как известно, об объектной ориентации вообще слышал мало.
Он не поддерживает наследования, а стало быть, наш тест в полной
мере выполнить не может. Не будем домысливать, но шансы на серьезные
позиции в этом тесте у него не велики.
- Java отказалась работать с настройками по умолчанию еще при
попытке загрузки 100 МБ массива, выдав сообщение о нехватке памяти
(и это, как вы помните, при 384 МБ RAM на одной машине, и 512 - на
другой). Чтобы заставить ее поверить, что на машине есть еще
оперативная память, нам пришлось применить не шибко стандартную
опцию -Xmx256m, тем самым объясняя Java, что на машине есть минимум
256 MB RAM, которые она может использовать. Но для данного теста и
этого параметра оказалось недостаточно, и пришлось уверить Java в
том, что на машине есть 400 МБ (с помощью опции -Xmx400m), после
чего она-таки уверовала, что памяти достаточно и смогла выполнить
тест. Остальные подопытные не сомневались в количестве оперативной
памяти, но расходовали ее более экономно. Наличие такой опции само
по себе не проблема, но то, что ее значение по умолчанию не завис от
объема оперативной памяти - это плохо.
- В новые языки/платформы типа C# и Java встроены модные ныне
"сборщики мусора". Это программные сущности, призванные радикально
ускорить выделение и освобождение небольших кусков памяти (так
присущих ООЯ). Нам говорят примерно следующее: GC (сокращение от
Garbage Collector) вообще не занимается лишним освобождением памяти.
Вернее, он пытается отложить этот неприятный (для него) момент на
как можно более поздний срок. Т.е. пока есть свободная память, ее
будут занимать, занимать и занимать, а когда память иссякнет, или
когда процессор будет менее загружен, начнется процесс сборки
мусора. При этом процессе выявляются и освобождаются неиспользуемые
области памяти. Используемые области памяти при этом могут
передвигаться, наподобие того, как это происходило в Windows 3x.
Красота, да и только! Но, что характерно, чем громче реклама, тем
менее стоящая идея (или реализация) за ней скрывается. Увы, в случае
с GC это правило работает стопроцентно. Ни C#, ни Java не показали
достойного результата. Java была лучше в абсолютном первенстве на
чемпионате для калек, показав относительно неплохой результат в 16.2
секунд, но при повторном тесте ее производительность могла
изменяться в пределах от одной до пятидесяти (50!) секунд. C#
показал хотя и стабильный, но самый низкий результат. Правда, C# (а
вместе с ним и вся платформа .Net) пока еще находится в beta-версии,
и к release-версии все может измениться. Но пока C# - явный
аутсайдер. Хочется предостеречь читателей от попытки делать далеко
идущие выводи о GC как таковом и их реализациях в Java/.Net. Данный
тест далек от реальных условий и не учитывает некоторых тонкостей
(типа различных стратегий GС в Java).
String-тест
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net) |
7.18 |
3.38 |
| Java |
7.55 |
3.48 |
| VC 6 |
15.40 |
6.08 |
| Intel C++ |
14.40 |
3.39 |
| Delphi |
22.28 |
10.97 |
| VB 6 |
22.30 |
10.20 |
Float-Тест
| |
PIII 800 |
AMD 1400 |
| в секундах |
| C# (.Net) |
39.28 |
12.24 |
| Java |
39.05 |
12.98 |
| VC 6 |
39.08 |
12.26 |
| Intel C++ |
0.50 |
0.29 |
| Delphi |
39.35 |
12.24 |
| VB 6 |
46.54 |
15.13 |
Выводы.
...Можно с уверенностью сказать, что C#/VC.Net и Java - это
языки/среды, на которых можно создавать высокопроизводительные
приложения. Особенно это касается C#. Интересно, что p-код (из которого
состоят выполняемые файлы) обоих сред не только не является недостатком,
но и наоборот является преимуществом. Дело в том, что оптимизация
производится в момент компиляции, причем под конкретный процессор. Это
значит, что все среды, создающие машинный код, могут производить
оптимизацию только под один известный им процессор (В VC использовалась
оптимизация под Pentium Pro, в Intel C++ под PIII, Delphi не сообщила о
своих планах по этому поводу). P-код ориентированные платформы (VC.Net и
Java) производят компиляцию в машинный код перед запуском или во время
исполнения программы (.Net-приложения могут быть прекомпилированы в
момент инсталяции или вручную с помощью утилиты ngen (что, собственно,
мы и делали). Но не следует забывать, что в .Net p-код никогда не
выполняется в режиме интерпретации, т.е. даже без применения ngen будет
производится компиляция, но при каждом запуске исполняемого модуля.).
Естественно, в этот момент уже известен процессор и другие
характеристики системы, на которой должен будет выполняться
компилируемый код. Теоретически это должно давать p-код ориентированным
платформам фору, за счет использования более производительных
инструкций. Но как показывают наши тесты, пока это только теория. По
всей видимости дело в том, что большинство кода попросту не использует
новые высоко производительные команды процессоров, а во вторых они пока
не избавились от "детских болезней" присущих всем новым продуктам.
Однако потенциал велик. C# отчетливо доказал, что язык нового поколения
способен создавать код не только сравнимый по скорости с лучшими
образцами старого мира, но и превосходящий их! А так как Microsoft и Sun
готовы вкладывать поистине невообразимые деньги в развитие своих детищ,
то у этих языков/платформ большое будущее. Так что, похоже, появившиеся
в СМИ заявления о том, что Microsoft планирует заморозить развитие Win32
API, языка C++ и COM, и перевести всё и вся на новую технологию .Net,
являются правдой. Но как показало наше тестирование, для нас с вами это
не представляет угрозы.
IONA начинает поставку новых редакций своей интеграционной платформы
8 февраля 2002 г.
Компания IONA, известная своим программным обеспечением для
интеграции приложений, объявила о готовности двух новых редакций
платформы Orbix E2A Web Services Integration Platform - Collaborative
Edition и Partner Edition.
Orbix E2A обладает всем необходимым для обеспечения совместной работы
Web-сервисов и корпоративных систем. В отличие от предложений других
поставщиков, где Web-сервисы представляют собой дополнительную
возможность, для данной платформы они являются основой. При этом
устраняются барьеры на пути интеграции технологий J2EE, .NET, CORBA,
приложений, работающих на мэйнфреймах, а также промежуточного
программного обеспечения, ориентированного на управление доставкой
сообщений. Orbix E2A позволяет организациям создавать, развертывать и
управлять Web-сервисами, добиваясь при этом повышения эффективности
работы и получения отдачи от инвестиций, сделанных в информационные
технологии ранее....
Форум Программиста
Новости
Обзоры
Магазин Программиста
Каталог ссылок
Поиск
Добавить файл
Обратная связь 