Как уже заметил Осв, концепции смешиваются вместе.
В приложении EAR у вас могут быть отдельные веб-модули и EJB-модули. Модули EJB традиционно ориентированы на бизнес-логику, доступную посредством локальных или удаленных (RPC / RMI) вызовов. Поскольку одно из применений веб-сервисов - это RPC, имело смысл предоставить поддержку модуля EJB для этих технологий. С чисто технической точки зрения это просто еще один протокол для выполнения RPC.
Однако понятия веб-модуля и веб-службы также естественным образом перекрываются, поэтому, конечно, веб-модуль также поддерживает эту технику (не в последнюю очередь, потому что веб-службы - это больше, чем просто RPC).
Дальнейшее размытие линий объясняется тем фактом, что EJB-компоненты когда-то предназначались для помещения в модуль EJB, но в настоящее время их можно использовать так же хорошо, как и в веб-модуле.
В будущих версиях Java EE, скорее всего, будут еще более размыты границы, когда многие контейнерные сервисы (такие как транзакции, пулы и т. Д.), Которые теперь являются свойствами EJB-компонентов, будут отделены от них и станут доступны через аннотации CDI поэтому их можно применять ко всем «веб-компонентам» напрямую.
Таким образом, веб-модуль действительно является надмножеством модуля EJB.
Функция модуля EJB по-прежнему заключается в том, что он позволяет создать слой функциональности под веб-слоем, который изолирован с помощью загрузчиков классов. Это означает, что веб-модуль может ссылаться на классы, которые вы определяете в модуле EJB, но не наоборот. Кроме того, в модуле EJB недоступны чистые методы представления, такие как Servlet, JSP и JSF, и на данный момент нет никаких планов сделать эти методы доступными там.