Платформы для создания корпоративных решений: Microsoft .NET или J2EE?
Архитектура корпоративных приложений
Аргументы в пользу выбора одной из платформ
Настоящая статья посвящена платформам для создания корпоративных решений. Не секрет, что сейчас архитекторов приложений волнует другой вопрос: какую из платформ следует выбрать в качестве основы создания корпоративного решения — Microsoft .NET или J2EE (Java 2 Enterprise Edition)? Сравнению этих платформ как с технологической, так и с экономической точки зрения в последние полтора года посвящено немало публикаций, к которым могут обратиться те, кто интересуется деталями реализации платформ и приложений, на них базирующихся, а также особенностями материальных затрат при реализации основанных на этих платформах проектов.
ель
данной статьи — ответить на вопрос, в чем заключаются наиболее важные различия
этих двух платформ; судя по письмам читателей, ясное представление об этом до
сих пор имеется далеко не у всех разработчиков и других IT-специалистов.
Согласно данным Gartner Group Research, поляризация между Microsoft .NET и J2EE, с которой в данный момент приходится иметь дело IT-менеджерам, приведет к тому, что эти две платформы в ближайшее время окажутся доминирующими при создании новых корпоративных приложений, при этом 45% всех вновь разрабатываемых проектов будут так или иначе иметь дело с обеими платформами (рис. 1). Отметим, что, согласно Gartner, с вероятностью 70% широко применяться будут обе платформы (источник: Gartner — .NET vs Java: Competition or Cooperation).
Приведенные данные свидетельствуют о том, что в ближайшее время ни одна из двух указанных выше платформ для создания корпоративных приложений не будет явно доминировать над другой и, следовательно, архитекторы подобных приложений будут вынуждены выбирать одну из них и применять средства интеграции (такие как Web-сервисы XML) для того, чтобы использовать сервисы, выполняемые на второй. В настоящей статье мы никоим образом не претендуем на роль советчиков относительно выбора платформ и средств интеграции, однако попробуем рассмотреть, в чем принципиальное различие между этими платформами и в какой степени они поддерживаются ведущими производителями средств разработки, серверов приложений и СУБД.
Архитектура корпоративных приложений
рхитектуры
корпоративных приложений, основанных на обеих платформах, имеют много общего.
Как правило, современные приложения масштаба предприятия логически делятся на
три звена, первое из которых предоставляет сервисы данных (реально роль этого
звена выполняет сервер баз данных), второе — сервисы бизнес-логики (в случае
обеих платформ они обычно реализуются в виде компонентов, выполняющихся под
управлением серверов приложений либо runtime-среды), третье — презентационные
сервисы, которые могут представлять собой либо GUI-приложения, либо Web-браузеры
(рис. 2).
Отметим, что обе платформы изначально предназначались для упрощения создания, внедрения и сопровождения многозвенных приложений. Следует подчеркнуть, что главным образом речь может идти именно о применении этих платформ при реализации сервисов бизнес-логики.
 |
|
J2EE
2EE
представляет собой спецификацию, реализованную в серверах приложений различных
производителей. Данная спецификация — результат совместной деятельности ряда
компаний, выпускающих программное обеспечение (включая IBM, BEA, Oracle), лидером
среди которых является Sun Microsystems; в настоящее время эти компании образуют
сообщество Java Community Process (JCP). Предполагается, что при идеальном соответствии
спецификации код приложения будет переносим между серверами приложений различных
производителей. Цель создания этой спецификации — предоставить потенциальным
пользователям возможность выбора серверов приложений и средств разработки из
нескольких возможных предложений разных производителей (на данный момент производителей
J2EE-совместимых серверов приложений и средств разработки существует около трех
десятков).
Для создания J2EE-приложений используется один-единственный язык программирования — Java. Java-приложения представляют собой скомпилированный из исходного текста байт-код, переносимый между платформами и интерпретируемый внутри виртуальной Java-машины (Java Runtime Environment, JRE), реализации которой существуют для разных платформ. J2EE-приложения выполняются внутри контейнеров, предоставляемых серверами приложений. Серверы приложений и средства разработки J2EE-приложений выпускаются разными производителями, включая BEA, Borland, IBM, Novell, Oracle, Sybase, Sun, и поддерживают широкий спектр платформ и СУБД. Согласно исследованиям аналитиков, 60% рынка J2EE-совместимых серверов приложений принадлежит компаниям BEA и IBM.
Один из недостатков J2EE с точки зрения разработки приложений — необходимость применения единственного языка программирования для решения абсолютно всех бизнес-задач. При этом одним из преимуществ этой платформы является возможность выбора поставщика программного обеспечения и создания решения, переносимого между операционными системами, что предоставляют многие производители J2EE-совместимых серверов приложений.
|
|
Microsoft .NET
отличие от J2EE, Microsoft .NET представляет собой не просто спецификацию, созданную
компанией Microsoft, но еще и реализацию этой спецификации для платформы Windows.
Приложения для этой платформы представляют собой переносимый код на промежуточном
языке MSIL (Microsoft Intermediate Language), сходным с байт-кодом Java. В процессе
выполнения приложения этот код заменяется в памяти на машинный код, оптимизированный
для данного процессора. Сам же MSIL-код получается при компиляции исходного
текста, созданного на одном из языков высокого уровня, для которых имеются соответствующие
компиляторы (сейчас таких языков около 30), причем все эти языки используют
общую библиотеку классов. Возможность создания приложений с помощью разных языков
является одним из несомненных преимуществ .NET. Хотя Microsoft .NET можно создавать
для разных операционных систем, на данный момент реализация этой платформы существует
только для нескольких версий Windows и частично для FreeBSD.
Отметим, что среда выполнения .NET-приложений Common Language Runtime, CLR (в определенной степени — аналог виртуальной Java-машины) предоставляет множество сервисов для этих приложений, например автоматическую сборку мусора, межъязыковое наследование, поддержку применения нескольких версий одного и того же компонента.
Говоря о серверных продуктах для этой платформы (аналогах серверов приложений), чаще всего вспоминают словосочетание Microsoft .NET Enterprise Servers — так называется семейство серверов различного назначения для платформы Windows. Тем не менее в течение ближайшего времени, пока не произошла смена версий всех этих серверов на более новые, содержащие встроенную среду выполнения .NET-кода Common Language Runtime, это словосочетание будет оставаться скорее маркетинговым термином, нежели отражением реального положения дел. Из средств разработки для этой платформы на данный момент доступно только одно — Microsoft Visual Studio .NET, а также более двух десятков компиляторов независимых производителей, большая часть из которых может быть использована совместно с Visual Studio .NET. Тем не менее компании Borland и Macromedia объявили о своих планах, связанных с выпуском собственных средств разработки для этой платформы; так, средство разработки для этой платформы от Borland следует ожидать в 2003 году.
Из недостатков Microsoft .NET стоит отметить то, что на данный момент применимость соответствующих приложений ограничена операционными системами Windows и FreeBSD. К достоинствам можно отнести более низкую стоимость решений, чем в случае применения J2EE, за счет более низких требований к аппаратному обеспечению, необходимому для выполнения серверной части приложений, возможности использования унаследованного кода и имеющегося опыта разработки на различных языках программирования, а также возможности создания с помощью технологии ASP .NET универсальных приложений, не зависящих от типа устройства, на котором выполняется клиентская часть.
|
|
Что общего у .NET и J2EE
тметим,
что обе платформы в силу сходного назначения имеют много общих черт. Обе они,
по существу, основаны на интерпретации кода или компиляции его «на лету» — в
случае J2EE роль среды выполнения играет JRE, в случае Microsoft .NET — CLR.
Обе платформы поддерживают компоненты, выполняющиеся в среднем звене многозвенных
приложений (Enterprise Java Beans, EJB — в случае J2EE, управляемые компоненты
— в случае .NET), а также средства создания динамических Web-страниц, содержащих
выполняемый сервером код (в случае J2EE это технология Java Server Pages (JSP),
в случае .NET — ASP .NET). И J2EE и .NET обладают собственными универсальными
механизмами доступа к данным: в первом случае это Java Database Connectivity
(JDBC), во втором — ADO .NET. Обе платформы удовлетворяют общим требованиям,
предъявляемым к средствам middle-ware, как-то: поддержка баланса за-грузки и
устойчивость к сбоям за счет резервирования и дублирования. Наконец, обе платформы
поддерживают технологию Web-сервисов XML, включая сопутствующие стандарты (SOAP,
WSDL, UDDI). Более того, сегодня Web-сервисы являются единственным способом
интеграции приложений, созданных с помощью этих двух платформ.
В отношении обеих платформ следует помнить, что их применение в любом случае потребует затрат на обучение разработчиков — либо языку и технологиям Java, либо созданию .NET-приложений. Впрочем, более простая модель программирования, применяемая в .NET, поможет слегка сэкономить на процессе обучения. Однако необходимо отметить, что для обеих платформ имеются библиотеки классов, дающие возможность освободить разработчика от написания многих рутинных процедур и функций, а также визуальные средства разработки, позволяющие генерировать значительную часть кода общего назначения.
С помощью обеих платформ возможно создание Web-сервисов, на данный момент являющихся единственной технологией интеграции этих двух платформ между собой, а также решений, отличающихся невысокой начальной стоимостью. Скажем, для реализации J2EE-решений существуют бесплатные версии серверов приложений (например, от Sun Microsystems, Hewlett-Packard и некоторых других производителей) и бесплатные операционные системы (такие как Linux), а некоторые .NET-решения могут требовать только наличия операционной системы семейства Windows. Обе платформы позволяют создавать решения, основанные на программных продуктах единственного производителя, поскольку производители серверов приложений, как правило, создают и средства разработки, а нередко и СУБД. Отметим также, что масштабируемость решений, созданных с помощью обеих платформ, чрезвычайно высока.
|
|
Аргументы в пользу выбора одной из платформ
ем
не менее можно назвать целый ряд аргументов в пользу выбора той или иной платформы.
В частности, выбирая платформу Microsoft .NET, лица, отвечающие за принятие
данного решения, отмечают более раннее появление у этой платформы полноценной
поддержки Web-сервисов, высокое качество Visual Studio .NET как средства разработки
и наличие большого количества разработчиков, знакомых с прежними версиями этого
продукта, простую модель программирования, возможность применения различных
языков программирования в одном приложении, высокую степень интеграции с операционной
системой.
В то же время аргументами в пользу выбора платформы J2EE могут служить наличие большого количества производителей и поддержка этой платформы на уровне всей индустрии, а не одного конкретного производителя, возможность легкого представления унаследованного кода в виде Web-сервисов (в случае Windows DNA, предшественника .NET, данная процедура также возможна, но не столь проста), поддержка в Web-сервисах общепринятого языка обмена данными между приложениями электронной коммерции ebXML, лучшие возможности применения унаследованных приложений за счет архитектуры Java Connector Architecture (JCA), возможность более широкого выбора аппаратных платформ и операционных систем для реализации серверной части приложений, а также большое количество Java-разработчиков на рынке труда.
Как видим, обе платформы имеют довольно много общего, обладая при этом определенными преимуществами и недостатками, которые следует учитывать при выборе платформы для реализации того или иного решения. В данном случае мы воздержимся от конкретных рекомендаций — кому-то нужна надежность, кому-то низкая стоимость, кто-то хочет сохранить средства, затраченные на создание унаследованного кода или на обучение разработчиков, кому-то нужно использовать имеющееся аппаратное обеспечение, а кто-то в силу специфики компании вынужден поддерживать обе платформы. Поэтому, принимая решение о выборе платформы для того или иного решения, в первую очередь следует учитывать потребности компании и требования к создаваемому решению.
