Определение терминов важно
При проведении сравнений важно определение терминов. EJB является
компонентная модель. Он определяет постоянство, транзакцию, удаленное взаимодействие, активацию и
возможности безопасности (и, возможно, другие) для компонентов, которые работают в
контейнер.
Вы можете посмотреть на сопоставимые технологии в .NET, если это то, что вы
после - технические возможности компонентной модели.
С другой стороны, некоторые люди используют «EJB» в качестве термина, чтобы свободно ссылаться на
J2EE (или Java EE?). В этом случае это относится не просто к компонентной модели, но
к набору связанных технологий Java, обычно связанных со стороной сервера
приложения, включая компонентную модель. Это может даже включать наборы инструментов, которые, конечно,
только косвенно связаны с компонентной моделью. Если , то является
сравнение, тогда это более точно описано как "J2EE против .NET".
Тем не менее, другие люди могут использовать даже более нечеткое определение для EJB, чтобы
включают такие вещи, как возможности веб-сервисов, REST / XML-коммуникации или
другие вещи, которые строго находятся за пределами Java EE или EJB. Другими словами, когда они говорят «сравнить EJB с .NET», они действительно имеют в виду сравнивать «серверные Java-платформы и серверные .NET». Последнее кажется мне гораздо более практичным сравнением, чем сравнение, скажем, компонентных моделей.
При проведении сравнений важно четко понимать, что именно
сравнивается.
EJB - компонентная модель
В EJB вы определяете объект и помечаете его как Session Bean или Entity
Bean. Есть также позднее добавление Бина, управляемого сообщениями. Три
вкусы компонента в EJB. Бин Session получает активацию - как это
начинается и, возможно, «пассивируется» во времена высокого ресурса
раздоры на сервере / контейнере. СБ также получает безопасность и
услуги удаленного взаимодействия.
Основная идея состоит в том, чтобы определить объект и затем прикрепить к нему атрибуты,
либо через дескриптор развертывания или через атрибуты в коде,
аналог для которого называется аннотации в Java.
Наиболее близким к EJB Session Bean является объект .NET. В любом .NET
приложение, вы можете пометить объект с атрибутами транзакции, просто
как EJB SB. Вы можете сделать его удаленным, если хотите, с .NET
Remoting и больше атрибутов. За пределами COM + нет технологии пассивации в
.СЕТЬ; .NET просто игнорирует объединение как вообще интересную вещь, связанную с
объекты в памяти, и, как следствие, нет никакого подхода к активации / пассивации в .NET, как в EJB.
sidebar # 1: это не совсем так. В .NET возможность Workflow предоставляет возможность для длительных операций, которые могут и будут пассивированы и повторно активированы. Но Workflow - это отличная метафора от «серверных объектов» или «сервисов», которая является центральной точкой большинства серверных архитектур приложений, использующих .NET.
sidebar # 2: Раньше дизайнеры серверных платформ думали, что все захотят использовать пул объектов для повышения эффективности. Теперь выясняется, что JVM и .NET CLR достаточно быстры при создании объектов, а памяти достаточно, что в общем случае пул объектов не имеет практического применения. Это больше не интересно в общем случае, хотя все равно приносит хорошие дивиденды для дорогих объектов, таких как соединения с базой данных.
Как и в EJB, в .NET вы можете прикрепить защиту
атрибуты объекта, чтобы позволить ему работать или не запускаться на основе
личность звонящего или другое «доказательство».
Бобы сущностей - это другое животное. Хотя настойчивость и удаленное взаимодействие могут
в большинстве практических руководств рекомендуется
Бин сущности не предоставляет удаленный интерфейс. Вместо этого рекомендация требует
сессионный компонент для вызова объектного компонента. Итак, давайте просто рассмотрим EB какпостоянные объекты.
В .NET здесь есть куча альтернатив. LINQ-to-SQL дает один
вариант - с ORM и постоянными сервисами. Сущность ADO.NET
Framework - это, пожалуй, более сопоставимая технология. Конечно все остальные
услуги в .NET - безопасность транзакций, удаленное взаимодействие и т. д. - также могут быть
применяется к объектам, которые используют ADO.NET Entity Framework или LINQ.
С другой стороны, в зависимости от того, где вы находитесь в EJB
зонтик, может быть лучше сравнимо. Если вы в первую очередь используете EJB для
удаленное взаимодействие - и с появлением REST, SOAP и других легких
протоколы, почти никто не делает это больше, насколько я могу сказать - тогда
лучше сопоставим в .NET это WCF.
Наконец, сравнимыми с EJB MDB являются .NET Queued Components.
EJB Remoting
У всех этих типов EJB есть некоторые общие аспекты, такие как удаленные интерфейсы. На самом деле большинство архитекторов рекомендует не распространять свои EJB-компоненты. Другими словами, они отговаривают людей использовать аспект удаленного взаимодействия, который так часто обсуждается. Вместо этого сервлет должен вызывать локальный EJB-компонент, а не вызывать его на удаленной машине. Это Первый закон Фаулера : Не распространяйте свои объекты .
С другой стороны, иногда вы должны.
WCF - это коммуникационная структура в .NET, и этот аспект в .NET наиболее сопоставим с удаленным взаимодействием EJB. Но они не эквивалентны. WCF - это платформа общего назначения для удаленной связи, поддерживающая синхронизацию и асинхронность, множественные протоколы и расширяемую модель транспорта и каналов, в то время как удаленное взаимодействие EJB довольно ограничено.
Правильно ли начинать с EJB?
EJB ничего не говорит (насколько я знаю) о веб-сервисах или REST,
или управление или облегченные фреймворки, или даже HTML, или инструменты для разработчиков. Начиная
сравнение с «EJB против blank » искусственно сдерживает дискуссию
совсем немного. Это создает обсуждение таким образом, что это не может быть
оптимальный.
В EJB нет ничего для обработки, например, метафоры HTML-страницы.
Вы получаете это в сервлетах или их двоюродных братьях (портлетах и т. Д.), Некоторые из которых находятся в собственно J2EE. Но, строго говоря, вывод HTML не рассматривается в EJB.
Теперь, возможно, вы намереваетесь использовать одно из более широких определений
EJB. Для этого J2EE теперь добавил веб-сервисы в спецификацию. Но даже в этом случае, я не уверен, насколько уместно рассматривать спецификацию с разнообразием дополнительных основанных на Java фреймворков для веб-сервисов SOAP и REST.
Аналогичным образом, если вы хотите рассмотреть возможности пользовательского интерфейса, такие как портлеты, сервлеты и AJAX, и сравнить их с эквивалентами .NET, то вы далеко вышли за пределы EJB и J2EE и в целом на стороне сервера Java.
Это возвращается к моей более ранней точке - будьте ясны и точны в своем уме о том,
Вы заинтересованы в рассмотрении или сравнении.
Спецификации EJB и J2EE были амбициозными - пытались определить рамки для серверных приложений. Но всегда было временное отставание между тем, что делали разработчики, тем, что говорили спецификации, и тем, что продавцы предлагали. Вы знаете, может быть, между завершением новой версии спецификации J2EE и выпуском совместимого сервера от IBM был годичный лаг.
Из-за этого все закончилось тем, что стало чем-то искусственным. Спецификация описывала то, что люди уже делали. Такие вещи, как Spring, выходили, и J2EE ничего не говорил о них. Долгое время J2EE ничего не говорил о REST, Web-сервисах или AJAX. (Даже сейчас, это говорит о AJAX? Я не знаю.)
В свете дистанции между теорией спецификации и реальной практикой разработчиков, лучшим подходом может быть определение требований к приложению, изатем сравните соответствие EJB и других связанных технологий
приложения, которые вы хотите создать.
Другими словами - предположим, что одним из ваших требований является то, что приложение будет доставлено через браузер и будет иметь отзывчивость AJAX. В этом случае вам придется рассмотреть jQuery, и это нигде не рассматривается ни в J2EE, ни в EJB. Платформы AJAX доступны в различных продуктах (как Java, так и .NET). Например, Visual Studio использует jQuery для ASPNET AJAX. Но придерживаться спецификаций вроде не хватает этого материала.
Итог
Суть в том, что любое приложение, которое вы создаете с помощью EJB, может быть встроено
.NET и наоборот.
Я думаю, что сравнение как "EJB vs .NET" может заинтересовать как академическое
обсуждение, но если вы хотите получить практическое представление о том, какие технологии
используйте где, тогда вам нужно думать немного по-другому.
Вам необходимо определить и определить приоритеты требований, таких как скорость
разработка, стоимость развертывания, механизм развертывания, поддержка инструментов, поддержка платформы развертывания,
языковая поддержка, производительность, внешний вид пользовательского интерфейса, параметры пользовательского интерфейса и т. д. Затем сравните параметры с приоритетами
список.