NET vs. Java
Олег Ремизов,
Что бы там ни говорили, но сегодняшний мир вычислений ориентирован в основном на сетевые приложения. В основе этих приложений лежит модифицированная архитектура клиент-сервер - так называемая трехуровневая архитектура. Отличительная ее черта - наличие на стороне сервера приложения, которое, собственно, и реализует бизнес-логику в среде сервера приложений. Приложение взаимодействует с сервером баз данных с одной стороны и с удаленной клиентской частью, которая обычно выполняется в среде веб-браузера или приложения с GUI-интерфейсом.
Распространение трехуровневой архитектуры повлекло за собой создание двух конкурирующих технологий - J2EE и COM+. И та, и другая представляют собой серверы приложений, где реализована большая часть логики, необходимой для обеспечения связки КЛИЕНТ-СУБД. Каждый из этих серверов предоставляет в распоряжение программиста набор правил, которым он должен следовать при реализации логики приложения. Другими словами, современный сервер приложений является хранилищем компонентов, реализованных в соответствии с определенными правилами.
Для чего вообще нужен сервер приложений и почему нельзя обеспечить прямой доступ пользователя к данным? Тому есть, по меньшей мере, три причины.
Прежде всего, для кэширования данных, которое позволяет значительно уменьшить нагрузку на сервер баз данных - и, соответственно, на компьютер, являющийся физическим хранилищем ваших данных. Конечно, это работает при условии, что сервер приложений установлен на другом компьютере.
Вторая причина, по которой эта технология сегодня столь популярна, это возможность как изоляции бизнес-логики от приложения-клиента, так и избежания написания сложных хранимых процедур на серверной стороне. Конечно, сегодня различные диалекты SQL, реализованные на серверах баз данных, позволяют делать с данными все или почти все. Практически это достаточно мощные процедурные языки, построенные на основе ANSI SQL92.
Но существуют, как минимум, три недостатка реализации логики с помощью хранимых процедур.
Первый и основной недостаток заключается в том, что необходим программист, который знаком с тем или иным диалектом SQL, для того чтобы держать бизнес-логику вашего приложения под контролем. Кроме всего прочего, SQL-скрипты достаточно сложны для понимания - даже если вы их сами написали всего пару дней назад. Как известно, SQL-код слабо структурирован и очень ограниченно поддерживает повторное использование кода, поэтому проще писать и сопровождать бизнес-логику на более мощном современном объектно-ориентированном языке.
Вторая причина: каким бы мощным ни был диалект SQL, реализованная на нем логика все равно будет работать в десятки, а то и в сотни раз медленнее, чем логика, реализованная на Java, C++ или C#.
Еще одна причина: слабая переносимость нестандартного SQL-кода. Написанием бизнес-логики на северной стороне вы фактически отрезаете себе путь к использованию других баз данных или делаете его очень дорогостоящим. Гораздо проще потом убедить клиента в том, что СУБД, которая используется в вашем приложении, лучше той, которая у него уже есть (хорошо, если у него вообще ничего нет), чем переписывать вашу логику для другого сервера баз данных. Иногда это просто невозможно.
То есть, говоря проще, приложение, построенное по современной архитектуре, должно использовать базу данных в режиме ANSI SELECT/UPDATE и не иметь значительной логики на стороне клиента. Вся логика должна быть реализована в промежуточном слое, называемом сервером приложений.
Когда принимается решение о применении трехуровневой архитектуры, следующим вопросом, который приходится решать, является вопрос о том, какой сервер приложений использовать. Можно вообще реализовывать свой сервер приложений - и такой подход в последнее время становится все более применяемым. Автор этой статьи знает, по крайней мере, два случая реализации таких серверов киевскими софтверными компаниями. В любом случае, решение в пользу использования того или иного сервера приложений или же реализации своего собственного ставит следующий вопрос: какой язык - а точнее, платформу - выбрать для реализации компонентов логики сервера приложений или самого сервера приложений?
Естественно, если существует жесткая привязка к платформе UNIX, то выбор сервера приложений или платформы для его реализации на сегодняшний день можно считать уже предопределенным - это Java2. В случае принятия решения об использовании готового сервера приложений будет выбран сервер стандарта J2EE - очевидно, что реализация компонентов внутренней бизнес-логики будет выполнена с использованием Java2.
Если вы собираетесь развернуть ваш сервер приложений на платформе Windows, то у вас есть альтернатива в виде C# и COM+. То, что COM+ работает в 2-4 раза быстрее, чем его аналоги, реализованные в соответствии с J2EE-стандартом, подтверждают многочисленные тесты, проделанные как сторонними фирмами, так и самой Microsoft. Объясняется это соотношением нейтив- и интерпретируемого кода: сервера приложений стандарта J2EE сами реализованы с использованием Java2, в то время как С#, напротив, служит только диспетчером, главная задача которого - вызов сравнительно быстродействующего исполнимого нейтив-кода COM+.
В случае принятия решения о создании своего сервера приложений, вы получаете возможность создать именно то, что вам нужно, после чего можете оптимизировать свое творение для нужных вам целей для каждого конкретного случая. Такой подход дает много преимуществ - но, в то же время, он не лишен недостатков.
Иногда программисты и вовсе отказываются от базы данных в пользу создания бизнес-классов и их последующей сериализации на диск. В случае не очень большого объема данных такой подход позволяет сэкономить на стоимости иногда не очень дешевого сервера баз данных. К тому же, такое приложение в некоторых случаях быстрее, чем приложение, использующее сервер баз данных или локальную СУБД в качестве хранилища данных.
