Стремительное развитие сети Internet уже диктует свои правила на то, каким должно быть программное обеспечение. Никто уже не может представить себе работу без программ – почтовых клиентов, Internet браузеров, программ для работы с ftp серверами и прочими сервисами, предлагаемыми в Internet.

Эра развития Internet берет свое начало с того момента, когда министерство обороны США объявило о создании первой глобальной сети под названием APRAnet. До этого существовали сети масштаба предприятия, университетов, и небольших фирм. Но и они оказали немаловажную роль в развитии программного обеспечения. Сначала существовали сети масштаба маленькой фирмы или организации, и люди в целях экономии пространства на своих жестких дисках, создавали центральный сервер, который являлся хранилищем информации - так называемые файл-сервера. Затем мощности компьютеров росли, но росли и потребности фирм и предприятий, требовался постоянный учет и анализ о состоянии дел на фирме, о количестве сотрудников, о проделанной работе и выплаченной заработной плате - так появились сервера баз данных, которые облегчили жизнь бухгалтерам, работникам отделов кадров, почтальонам. С появлением Internet, сервера баз данных сейчас помогают узнать расписание движения транспорта, статистику о курсе валют и колебании температуры.

Но в тоже время качество и размеры программного обеспечения растут, растет соответственно и его стоимость. А теперь представьте ситуацию, когда какой либо программой Вы пользуетесь не более чем раз в месяц, и то всего несколько минут. Стоит ли ее покупать? Для Вас, как для реального потребителя товара, наиболее благоприятным вариантом было бы взять ее в аренду, на те самые несколько минут. Вот тут и проясняется будущее нового направления в развитии Internet – «сервер приложений».

Через несколько лет не будет необходимости окупать ПО. Его можно будет взять на прокат. Но уже сейчас стоит острая проблема – как образом надо предоставлять такие услуги, как должно функционировать ПО.

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

Появление новых средств для разработки программного обеспечения от многих разработчиков требует более тщательного анализа поставленной задачи для принятия конкретного решения. Сейчас, для реализации «сервера приложений» существует 2 независимые технологии – DCOM, NET от Microsoft и CORBA+JAVA от SUN Microsystem. Основной задачей остается, какие инструментальные средства необходимо выбрать.

Целью данной работы является создание и исследование сервера приложений. Для этого необходимо решить следующие задачи:

1. Определить эффективность инструментальных средств – провести исследование и выдать сравнительные характеристики двух существующих сред разработки.

2. Определить основные концепции функционирования сервера приложений.

3. Провести исследование на определение минимальной пропускной способности сети для нормального функционирования сервера приложений.

4. Определить теоретические расчетные данные, предъявляемые к аппаратному обеспечению.

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

CORBA – это концепция, разрабатываемая от стандарта к реализации большим количеством организаций. СОМ – частная концепция Microsoft, исходящая из потребностей прикладного программиста и оформляемая в законченный стандарт. По существу, COM является стандартом "де-факто", изложенным корпорацией Microsoft в нескольких спецификациях.

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

СОМ – общая технология взаимодействия объектов стандартизующая как сами объекты, так и методы их взаимодействия. Это спецификация, строящаяся на базе эталонных реализаций.

И то, и другое – стандарты. Оба они, как стандарты, переносимы и независимы от платформы. Преимущество стандарта Microsoft в том, что он создается одной мощной компанией, являющейся крупнейшим игроком на конкурентном рынке программного обеспечения. Мicrosoft старается сделать универсальной и переносимой реализацию, выполненную для конкретных нужд. Для этого Microsoft использует другие открытые стандарты и участвует в работе стандартообразующих организаций, в том числе OMG. Следствием является то, что эталонная реализация сама по себе становится спецификацией. OMG принципиально не располагает такой возможностью. Отсутствие эталонных реализаций CORBA приводит к тому, что для физической совместимости ORB разных производителей необходимо производить отладку и вносить специфический код для каждого из них. СОМ же, позволяя производить отладку на эталонной реализации, гарантирует совместимость приложений разных разработчиков. Если бы OMG кроме стандарта создавала эталонную реализацию, Microsoft проигрывал бы п о всем статьям. Но поскольку это не так, подход Microsoft производительнее и создает меньше конфликтных ситуаций.

COM является платформно-независимой, объектно-ориентированной технологией, позволяющей создавать бинарные компоненты. Эти компоненты можно использовать как локально, так и в распределенном сетевом окружении. COM служит основой для: OLE (технология составных документов), ActiveX-объектов и элементов управления ActiveX, DCOM, COM+.

На базе COM создано большинство новейших продуктов (MS Office, MTS,…) и технологий Windows (Automation, Drag & Drop, ...).

DCOM (Distributed COM) – это расширение COM, делающее эту модель распределенной, то есть позволяющей вызывать COM-объекты, находящиеся на другом компьютере в сети.

MTS (Microsoft Transaction Server) – это сервер приложений позволяющий создавать распределенные приложения, поддерживающие транзакции. Вопреки распространенному мнению, хотя слово «транзакция» входит в название этого сервера, приложения создаваемые на базе MTS совершенно не обязаны использовать предоставляемый механизм транзакций.

COM+ – это эволюция COM и MTS. COM+ полностью встроен в Windows 2000. Он существенно расширяет возможности своих предшественников. COM+ обратно совместим с DCOM, MTS и COM, и позволяет создавать распределенные приложения, клиентские части которых можно запускать на старых ОС (Windows 9x и Windows NT).

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

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

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

Любой частный стандарт, поддерживаемый отдельным производителем (оставляя в стороне вопрос о его открытости) вынужден следовать исторически сложившейся линии развития, что рано или поздно входит в противоречие с интересами потребителя.

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

CORBA является концепцией, а не ее реализацией. Когда мы говорим "COM", то понимаем под этим скорее набор конкретных средств – элементов операционной системы, библиотек, утилит и т.п., являющихся составной частью того, что называется Microsoft Windows. Под термином "CORBA" понимается именно сложная и развитая концепция, сформулированная на уровне специального языка описаний – IDL. Реализации же этой концепции могут сильно отличаться друг от друга по различным критериям, наиболее важным в том или другом случае. VisiBroker (разработки Visigenic/Borland/Inprise/Corel) и Application Server, BEA WebLogic, Iona Orbix, Oracle Application Server и "картриджи" Oracle, IBM BOSS – все эти продукты используют те или иные возможности CORBA.

Под "стандартом" применительно к CORBA понимается то, что официально утверждено консорциумом OMG. Надо сказать, что это очень высокий уровень "легитимности", так как авторитет OMG в компьютерном мире чрезвычайно высок. OMG представляет собой некоммерческую организацию, являющуюся содружеством разработчиков программного обеспечения и его потребителей, объединивших свои усилия для создания спецификаций этой технологии. В настоящий момент в OMG состоит более 800 членов, включая всех сколько-нибудь серьезных производителей программного обеспечения (и даже c недавнего времени Microsoft). Первая спецификация CORBA появилась в 1991 г. Новые возможности официально считаются добавленными в CORBA в момент утверждения соответствующей спецификации. Как правило, в разработке спецификации участвуют крупнейшие специалисты в данной области. Разработка реализации – задача конкретной фирмы. Обычно от утверждения спецификации до появления высококачественной реализации проходит довольно много времени – иногда несколько лет . В настоящий момент стандартизовано отображение языка IDL на 6 языков программирования – Ada, C, C++, Cobol, Java и Smalltalk. Существуют также отображения на Pascal (точнее, Delphi), Perl, Python и еще несколько языков, но они не стандартизованы.

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

В таблице 1 приведены результаты тестов, целью которых является сравнение скорости вызовов в COM и CORBA. Для этого были созданы объекты, содержащие пять методов.

Каждая строка таблицы отражает вызов одного из методов. Первый метод имеет входной целочисленный параметр. Остальные имеют in/out параметр - массив целых (256 (1 килобайт), 512 (2 килобайта) и 1280 (5 килобайт) элементов соответственно). В первом столбце указан объем передаваемых методом данных. Учтите, что данные передаются в обе стороны.

К этой таблице необходимо дать кое-какие пояснения. Дело в том, что, хотя стандарт CORBA и предусматривает сервис защиты, но на практике он не реализован большинством производителей CORBA-серверов. COM+ же не только поддерживает защиту, которая просто включена в ОС от Microsoft, но она к тому же еще по умолчанию включена в довольно-таки суровый режим, а именно в режим Call - режим проверки безопасности при каждом вызове удаленного объекта. Из-за принятого по умолчанию режима имперсонации клиент (вернее, прокси удаленного объекта) при каждом вызове помещает в RPC-буфер данные о защите потока, из которого происходит вызов. Сервер распаковывает эти данные и проверяет условия защиты. Естественно, все это занимает некоторое время. Отнимает время и мониторинг, хотя и не так много как защита. Мониторинг в COM+ тоже включен по умолчанию. Он позволяет визуально контролировать, сколько объектов того или иного класса загружено в данный момент, находится ли некоторый объект в вызове, определять продолжительность по следнего вызова и т.п.

В общем случае время, затрачиваемое на защиту и мониторинг не велико, исходя из тестов оно составляет от половины времени требующегося для вызова до сотых долей, в зависимости от количества и размера параметров. В CORBA есть два типа вызовов методов - динамический и статический, но, по существу, маршалинг в обоих случае осуществляется одинаково. И в первом, и во втором случае запаковкой параметров в stream занимается клиентское приложение. Разница лишь в том, что в первом запаковка скрыта в стабе, а во втором осуществляется явно. В COM код маршалинга, а значит, и код запаковки данных, содержащихся в параметрах, отделены от приложения. Более того, код маршалинга разделяется между несколькими приложениями, запущенными на одном компьютере и может иметь разную природу. Есть два типа маршалинга: proxy/stub и typelib-маршалинг. Proxy/stub-маршалинг похож на маршалинг в CORBA, с той лишь разницей, что и proxy и stab помещаются не в само приложение, а в отдельную DLL-библиотеку. Typelib-маршалинг подразумевает отсутствие кода маршалинга для конкретного интерфейса. Вместо этого используется библиотека типов. Она уже содержит некоторую информацию об интерфейсе. Если при передаче указателя на интерфейс в другой апартамент или другое приложение COM определяет, что для интерфейса отсутствует статический proxy/stub, то он читает соответствующую библиотеку типов и создает на ее базе динамический proxy/stub. Естественно, что у этих способов может оказаться разная производительность. Чтобы оценить разницу в скорости, приводятся результаты тестов обоих вариантов. Первый тест CORBA использует статический массив и маршалинг, аналогичный proxi/stub-маршалингу из C++-примера для COM, только код маршалинга в CORBA включается непосредственно в код сервера и клиента.Второй использует DII (Dynamic Invocation Interface) для динамического вызова методов удаленного объекта. Динамический CORBA-тест превосходит своего COM-аналога, но в CORBA используется только динамический вызов на клиенте, сервер обрабатывает вызов так, как будто он сделан статически, а COM, в виду специфики IDispatch и на серверной стороне принимает вызов динамически, преобразовывая динамический вызов в статический уже на сервере. Возможно, положение изменилось бы, если динамической была бы и серверная сторона обоих испытуемых, но это уже тема для отдельной статьи.Можно сказать, что COM и CORBA работают примерно с одинаковой скоростью. Неизвестно, как изменится обстановка, если к CORBA подключить сервис защиты. У CORBA есть некоторое преимущество при динамическом связывании, но при грамотной реализации динамических вызовов в COM разница становится очень незначительной.И CORBA, и COM ведут себя примерно одинаково при параллельном запуске нескольких копий тестовой клиентской программы.Но все это относится к сетевым вызовам. На локальном компьютере COM значительно, в два-три раза опережал CORBA. По-видимому, дают себя знать настольные корни COM и OLE.

Тесты производились на сети 10-МВ Ethernet, работающей под управлением Windows 2000 Server (SP1). В качестве клиентских и серверных компьютеров применялись ПК на базе Intel PII/Celeron от 233 до 450 МГц, работающие под управлением Windows 2000 Professional (SP1). Загрузка процессора сервера (Celeron-400) в обоих случаях составляя около 30-40 процентов.

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