Зачем делать EJB, а не веб-сервис?

Question

Я бы подумал, что по этому поводу имеется много информации, но я не нашел ничего, что действительно отвечало бы на мой вопрос.

Каковы преимущества создания EJB, а не веб-службы? Единственное явное преимущество, которое я могу придумать, - это производительность. Тем не менее, я не могу найти точных данных о том, насколько эффективнее EJB.

С веб-сервисами я могу придумать множество преимуществ, в том числе совместимость между java / .net и упрощение работы в сети через брандмауэр / прокси, поскольку он использует http. Что из того, что EJB-компоненты предлагают в отличие от веб-сервисов, предлагают новые стандарты, такие как WS-ReliableMessaging, WS-AtomicTransactions, MTOM и т. Д. (Предполагается, что они полностью протестированы на совместимость между Sun и MS)?

Я никогда не работал ни с чем, кроме базовых веб-сервисов, поэтому, возможно, кто-то, имеющий опыт работы с более продвинутыми стандартами веб-сервисов, мог бы сказать мне, что все это работает не так, как утверждают производители?

Answer 1

Во-первых, EJB и WebServices не являются исключительными альтернативами, на самом деле вполне разумно создать EJB и предоставить ему доступ как к интерфейсам IIOP, так и к интерфейсам веб-служб.

Итак, здесь есть два вопроса:

1. Какая хорошая технология внедрения для многократно используемой части бизнес-логики.
2. Какой стиль вызова использовать для бизнес-логики? Такие соображения, как, например, когда RMI / IIOP является хорошим выбором? Когда SOAP / HTTP? Когда SOAP / JMS ... и т. Д.

Написание EJB3 EJB довольно проста и дает такие преимущества, как транзакционность, безопасность, пул экземпляров и управляемая масштабируемая инфраструктура - это окупается серьезной корпоративной логикой. (Вы также можете посмотреть на другие фреймворки, такие как Spring, в качестве альтернативы.)

Теперь о стиле вызова. Ясно, что когда требуется взаимодействие с (скажем) .NET, тогда полезны веб-службы. Но в мире чистого Java, особенно когда логика и «клиент» могут быть развернуты в одной и той же JVM, использование локальных интерфейсов EJB действительно будет более производительным, чем веб-службы. При удаленном вызове сравнение производительности между RMI / IIOP и веб-службами не столь очевидно, в некоторых случаях веб-службы на самом деле работают достаточно хорошо. Для меня контраргумент использования веб-сервисов заключается в том, что в прошлом было много проблем взаимодействия, проблема была связана с несоответствием версий между разными поставщиками - хотя, если вы делаете взаимодействие, то, я думаю, у вас всегда будут такие проблемы.

Answer 2

Доступ к услуге Если вы хотите поддерживать не Java-клиента java-сервиса, используйте веб-сервис. Для потребителя Java IIOP мог бы быть выбором.

Реализация услуги Если вы хотите, чтобы контейнер предоставлял такие функции, как управление транзакциями, используйте EJB для реализации сервиса.

Answer 3

Я не хочу быть саркастичным, но большинство реализаций EJB, которые я видел до EJB 3, казалось, были разработаны для обеспечения безопасности работы. Это мой анекдот, за что он стоит.