VMware покупает SpringSource

>как балансер перед Tomcat + видел в нете, что HTTPD лучше статику отдает чем Tomcat.

вопрос не в том, ради чего httpd используется с томкатом, а в том, зачем спрингу нужно платить зп разработчикам httpd, если он(httpd) нужен только в качестве простого кэшэра/балансера?

Да не за что. Спрашивай если еще чего не ясно.

>а в том, зачем спрингу нужно платить зп разработчикам httpd,

http://www.springsource.com/products/ers

> От явы нужен только эклипс. Сама ява больше не нужна.

Я бы сказал - нужен эклипс, переписанный на C/C++.
А то он всё задумчивей и задумчивей становится с каждым релизом.

> HTTPD лучше статику отдает чем Tomcat

Это не так

Специально для очень умных. Не перепишите. А что бы дошло ответьте на следующий вопрос - будет ли быстрее линкус если его полностью переписать на ассемблере?

>Я бы сказал - нужен эклипс, переписанный на C/C++.

Вот уж будут ТАКИЕ_ТОРМОЗААААА.

>А то он всё задумчивей и задумчивей становится с каждым релизом.

Естественно. С каждым релизом она от плагинов тяжелеет процентов на десять.
Не пробовали отключать неиспользуемые плагины?

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

JEE - другая технология. более тяжелая, но более стандартихованная. большие компании предпочитают более стандартные решения, потому выбор за JEE. Малые - как поезет.

> ну и если так то вопрос больше о популярности, что из этих двух серверов вероятней встретить и в каком сегменте?

зависит от архитекторов которые начинали проект. На нынешний момент JEE догоняет Spring по простоте.

Из личного опыта скажу, что у нас больше проектов на Tomcat (+ Spring) чем на JEE серверах (JBoss & WebSphere)

+1000

Пенреписывать на кресты это маразм... лет 20 потом будут лечить типичные для сей глюки и как всегда нихрена ничо не выличат.. дай бог костылями подпрут дабы не шатался..

> В более тяжелых корпоративных проектах вообще обычно либо Bea WebLogic (ныне Oracle) либо IBM WebSphere. А JBoss это такой среднячок.

JBoss выбегает вперед когда большая система и требуется множество серверов развернутых в виртуалках.

PS был смешной проект где ноды в кластер добывлялись на ходу - так там на лицензиях можно было бы разориться. Использовали JBoss (хотя там вообще много чего было прикручено и Tomcat тоже применялся).

Э, народ! Что за уныние? Неужели вы думаете, что они его покупают, чтобы закопать? Надеюсь, теперь Spring станет ещё лучше.

// Spring user

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

небольшой пример: JBoss в дефолтовой инсталляции имеет настроенную кластерную конфигурацию. Работает просто - запускаешь на нескольких компах в локальной сети и сервера сами снюхиваются.

> Зависит от того что ты подразумеваешь по j2ee. Я например уже скоро десятку лет как программирую яву на серверах и наблюдаю эволюцию j2ee в основном со стороны - чему несказанно рад. Особенно учитывая исторю в которой каждая обявленная новым киллером тяжелая спека через два года объявлялась эпик файлом и упрощалась:)

у меня опыта поменьше. Но да шутку с упрощением застал.

Будем надеяться что JavaEE 6 будет достаточно простой чтобы не стать очередным "epic fail" ;)

> Будем надеяться что JavaEE 6 будет достаточно простой чтобы не стать очередным "epic fail" ;)

Для этого надо убрать оттуда EJB. :D

>что там есть из альтернатив со сравнимыми возможностями?
Spring.NET?
:)

По моему у них и так давно community edition и отдельно платный, для Enterprise-а

> По моему у них и так давно community edition и отдельно платный, для Enterprise-а

Что за хрень?

http://www.linux.org.ru/view-message.jsp?msgid=3107711&page=-1

Что-то странное, а что мешает чекаутнуть изменения из vcs?

JBoss Seam?

> JBoss Seam?

EJB + JSF + whatever = нет пути :)

>> Будем надеяться что JavaEE 6 будет достаточно простой чтобы не стать очередным "epic fail" ;)

> Для этого надо убрать оттуда EJB. :D

Stateless EJB - это обычный Spring bean, а Statefull EJB - bean prototype.

Если же EJB persistence - это это JPA, так Spring с тем же JPA и работает.

В чем разница то?

> EJB + JSF + whatever

Все это необязательно. Seam не завязан ни на EJB, ни на JSF. Wicket+POJO отлично с симом живут.

>enterprise

>плохая новость для OpenSource

пашутил?

>PS от себя добавлю, что по моему мнению, это плохая новость для OpenSource.

просто ничем не мотивированное утверждение...

Главное чтобы с JBoss Seam ничего не случилось (все остальное в топку), надеюсь на порядочность Red Hat, тем более что у RH финансовые показатели по кризису вроде вполне даже удачные.

>систем связанных с упрощение разработки enterprise приложений на java, языка Groovy и фреймворка Grails.

>PS от себя добавлю, что по моему мнению, это плохая новость для OpenSource.

от себя добавлю, опенсорсу на это начхать. с эйфелевой башни. ни одна из перечисленных финтифлюшек мне за эти годы не понадобилась, как и знакомым линуксоидам/бздунам

а кодеры сами виноваты, надо было на лицензию смотреть и думать о возможностях форков

А меня вот новость чо-та совсем не порадовала, верните как было

Ну не сказал бы, что новость чем-то плохая.

1) Ребята там реально хорошие вещи делали и деньги за дело получили.
2) Лицензия продукта - апачевская, так что "если чо" - форкнуть можно будет.

Тем, кто интересуется SpringFramework vs JEE могу сказать, что первое решение обладает большой гибкостью (можно подключить и использовать только то, что нужно), а второе (если не вспоминать тяжелые времена J2EE 1.4 и тем более J2EE 1.3) - простотой развертывания и наличием "из коробки" некоторых нужных для корпоративных приложений вещей (аля распределенные транзакции, или JCA).

Вот с выходом JEE 6 позиции SpringFramework могут пошатнуться, ибо спека от Sun^WOracle тоже предполагает модульность.

> аля распределенные транзакции

Если бы Вы увидели, на сколько легкий и простейший подход к некоторым подходам к транзакциям у JBoss Seam - сразу бы бросили все. ;)

Вот, смотрите - Вы привыкли к контексту запросу (Request), контексту сессии (Session), контексту приложения (Application).

Вы находитесь на сайте. Что-то выбрали, перешли на следующую страницу. Там выбрали, перешли еще раз на следующую. Потом отменили, вернулись назад (например ищите драйвера). И так десять раз подряд. Ладно, пускай 4 раза. ;)

Смотрите, при каждом переходе - вы передаете парметры между этими переходами. Параметры у вас - то в запросе, то в сессии. Ну, разные бывают параметры, примерно я прав?

Допустим у вас таких страниц - 20. А то и 50 (жизненно, верно?)

Допустим, что в ряде случаев - Система была вынуждена "сбрасывать" данные в БД. Сущности, не сущности, это не очень важно, но вот вам и - постоянные (возможно) обращения к БД, вопросы по транзакционности этого процесса.

Без предвзятого мнения - все это, в прицнипе, очень реально, такой/такие примеры? Не правда ли? (речь, в конечном итоге, идет о том, чтобы разработчикам было легче, нам с вами).

А теперь представьте - что вам, в дополнении к имеющимся контекстам запроса, сессии, приложения - дают еще несколько. Самый главный, в данном случае - контекст Conversation (контекст Диалога).

Вы изначально, вот как юзер взял где-то старт, и пошел бегать по страницам вашего сайта - даете ему этот контекст диалога, и в нем, ТОЛЬКО в этом контексте - сохраняете все "промежуточные" переменные/данные. Конечно, если он, юзер, на каком-то шаге своего "забега", по логике вещей, делает break этого своего бега - вы так же с помощью опции - рубите и перевоссоздаете контекст диалога.

Контексты диалога - могут быть вложенными, один в другой. Например вы хотите, считаете нужным/удобным - чтобы организовать _диалог_ с юзером - в пределах всего одной странички сайта. - Организовать ОГРОМНОЕ (по сложности), многофункциональное взаимодействие с ним - чтобы он выбрал слева на страничке какие-то вещи в комбобоксах, списках, потом - справа он увидел контекстную инфу (возможно ajax) - он снова чтобы выбрал и снова смотрит новую инфу. - Без проблем, все ваши задумки - в пределах родительского или вложенного контекстов разговора (с юзером).

В САМОМ КОНЦЕ диалога с юзером, когда вы его УГОВОРИЛИ КУПИТЬ ЭТУ ДОЛБАННУЮ МАЙКУ за $9.99 - в самом конце вы и делаете сброс, дамп, данных в БД.

И изначально, и в конце - вы давали юзеру только один контекст, вернее - использовали в основном один, туда сохраняли все данные, выбор его и т.п. Кэш, отличный кэш для данных. Менеджер сущностей сбросил данные в самом конце, или не сбросил данные в БД вообще, если юзер так и не купил майку, отказался, в итоге, на 20-ом шаге, от покупки.

На сколько удобно "тащить" переменные - БЕЗ ЕДИНОГО КОНТЕКСТА ДИАЛОГА? А?

Вспомните, как инициализируются бины заднего плана, которых на одной странице может быть, вполне реально - что и 3, 4 штуки - они все инициализируются (вызовы конструкторов), права там доступа могут реализовывать, КАЖДЫЙ из них - отвечает за свою логику...

Вы хотите сказать - так можно в сессии все хранить! - Можно. Но так обычно лично Вы - не делали, верно? Не захламляли, кидая туда все, что только можно.

Или захламяли, но все капельку? ;) Хорошо, а потом юзер уходил в другие разделы сайта, а тут у вас в сессии что-то оставалось, ошметки, обрывки, сохраненные значения, зачастую - совершенно так лишние. Хлам - он и в Африке хлам, как говорится.

Память зря заюзали клиентского компа юзера, бегающего по другим разделам этого сайта...

А теперь еще один контекст - бизнес-контекст. Он (если вы его используете) - дает возможность "вести общение" - сразу со многими юзерами (например они общаются или работают над каким-то документом), помимо этого - бизнес-контекст обладает свойством персистентности - ваш юзер разлогинился, или сервер упал, или юзеры ушли спать - ничего, назавтра вы им поднимете бизнес-контекст, где будут сохранены все их данные.

Вкусно, или нет? Слова "ну, примерно похожее есть и, во всяком случае я могу через request все передавать" - а Вы разве не хотите сделать себе - жизнь намного проще?

Могу в некоторых вещах, сказанных выше, немного ошибаться. При нахождении противоречий (просто я уже пол года не программировал с использованием Seam, а когда программировал, то не все использовал, к сожалению) - просьба, большущая просьба меня проинформировать, тут у меня книга под рукой по Seam 2, мне тогда интереснее будет почитать в ней, узнать что-то новое, лучше разобраться, освежить в памяти ну и все такое.

Открыт для критики...

Пока что conversation-ов в JEE нету, но над JSF 1.2 (который входит в JEE) многие библиотеки предлагают решения для таких задач. В спринге для этого есть WebFlow (поработать с ним не пришлось - пока что только доку смотрел), где такие вещи организуются очень легко. Может быть в JSF 2.0 тоже добавят такой контекст (тут меня могут поправить те, кто уже смотрел спеку).

Кстати, когда сим только ещё появлялся, я очень внимательно смотрел на него. Только мне он не подошел. И, судя по примерам сима и по вашим словам те, кто его использует, очень не любят "лазить в БД" (помню, в примере booking-га там все отели сначала вычитывались в бин, а уже потом по ним делалась фильтрация). Но чтобы пресечь холивар соглашусь, что в некоторых случаях такой подход себя оправдывает.

Так же помню начинающего пхп прогера, который всё хотел "чтобы страница формировалась всего лишь за 3 запроса к mysql". Откуда берется эта ненужная "оптимизация", я не понимаю.

> Может быть в JSF 2.0 тоже добавят такой контекст

Вряд ли будет или имеется что-то сравнимое. Почему:

1) Seam ИСПОЛЬЗУЕТ оба фреймворка - JSF и EJB 3.0, при этом он не только связывает их работу ВОЕДИНО (у каждого из них есть внешний API, оставленный, чтобы кто-то потом смог вот так их связать вместе), но и УБИРАЕТ НЕДОСТАТКИ ИХ, ДОПОЛНЯЕТ, ГДЕ НУЖНО, НЕОБХОДИМЫМИ ФИЧАМИ.

2) Seam использует двунаправленную инъекцию. В частности это означает и то, ну или как одно из следствий этого - что Вы можете использовать JavaBeans, вместо EJB 3.0, при почти все тех же фичах, которые присущи EJB 3.0. В частности это выражается тем, что enterprise-проект у Вас может быть в виде WAR-файла. Поверьте, все так. У меня начальство, когда я это все осваивал - уперлось рогом, что "EJB - это все тяжеловесно очень" (на самом деле EJB 3.0 - легковесный фреймворк, но все оценивают по EJB 2, там - да). И, вот, представьте себе - пришлось использовать именно эту возможность. Там очень мало отличий, по сравнению с EJB 3.0, поверьте мне на слово.

Где, в каком JEE-фреймворке - такое возможно, вот Вы мне скажите?

3) Seam комплектуется большим набором библиотек, СОВМЕСТИМЫХ между собой, и, на сколько это возможности - ПОСЛЕДНИХ ВЕРСИЙ. Например библиотека JBoss Hibernate. Например библиотека JBoss RichFaces (вам предоставляются тонны возможностей, например можно использовать айс-фейс). Кстати, JBoss Seam придумал создатель фреймворка JBoss Hibernate, а это один из стандартов в отрасли (есть и альтернативы, конечно же).

> И, судя по примерам сима и по вашим словам те, кто его использует, очень не любят "лазить в БД"

Хм. Если нужно чтобы при каждом переходе на новую страницу шли транзакционные запросы к БД - пожалуйста. Все в Seam можно. Только если бизнес-логика большинства приложений в том, что юзер начал делать какие-то выборы, а через 20 страниц у него выбор - подтвердить покупку или отказаться от нее, то по самой эффективной логике - в этом месте и нужно сделать транзакционную синхронизацию данных с БД.

В ином случае программист вынужден пользоваться тем, что он использует менеджер транзакций, который связывается с БД, и, возможно, при многих переходах пользователя, оперирую разными контекстами доступной транзакционности.

Зачем? По моему это "темной наследие" времен программирования EJB 2.0 и неСеамного программирования позднее.

Зачем держать транзакции?

Понимаете, в предложенном Вами подходе - Вы много времени уделите реализации технического функционала, который, если забыть о транзакционности - вообще лично Вам - не нужен. Одна морока. Вы в конце, когда пользователь сделает свой выбор - скинете или не скинете дамп в БД.

Этим существенно уменьшается нагрузка на БД, в том числе.

Seam предлагает вам сосредоточиться непосредственно на реализации бизнес-функционала, воспользоваться готовыми идеями, которые технически уже реализованы. С выйгрышем в производительности, в уменьшении нагрузки на БД, в уменьшении времени разработки, без потери, технически, хоть одной из фич. Если угодно - пожалуйста, на каждый чих пользователя можно слать запросы к БД. Вопрос - зачем?

Это не любите/нелюбите - такой подход по всей логике лучше.

> 3) Seam комплектуется большим набором библиотек, СОВМЕСТИМЫХ между собой, и, на сколько это возможности - ПОСЛЕДНИХ ВЕРСИЙ.

Т.е. Maven Вам не нужен. И Вы имеете тонны, просто тонны всего. На любой вкус и цвет. Хотите почту - пожалуйста! Не нравится JSF - пожалуйста, есть альтернативы, раз Вам так хочется (что-то на счет этого писали выше, на этом форуме). Веб-сервисы - пожалуйста! И т.д.

Мне кажется, что у вас несколько упрощенное понимание того, что означают транзакции (они, как ни странно, есть не только в БД)... Ну да не суть. Сим - мощный фреймворк и для своих задач он подходит очень хорошо. Но это не панацея, и пихать его ВЕЗДЕ не следует.

> Мне кажется, что у вас несколько упрощенное понимание того, что означают транзакции (они, как ни странно, есть не только в БД)... Ну да не суть. Сим - мощный фреймворк и для своих задач он подходит очень хорошо. Но это не панацея, и пихать его ВЕЗДЕ не следует.

В данном конкретном случае - да, показан только один аспект транзакций.

Приведите пример, где Seam не очень, не совсем подходит, для JEE.

:)

> Приведите пример, где Seam не очень, не совсем подходит, для JEE.

Когда нужно либо одновременно закоммитить транзакции в двух (и более) различных базах данных и в базе аудита операций (логирование) и отправить сообщение во внешнюю систему JMS, либо не менять ничего - а лишь сохранить записи аудита.

>> Приведите пример, где Seam не очень, не совсем подходит, для JEE.

> Когда нужно либо одновременно закоммитить транзакции в двух (и более) различных базах данных и в базе аудита операций (логирование) и отправить сообщение во внешнюю систему JMS, либо не менять ничего - а лишь сохранить записи аудита.

Да, так просто, "в лоб", в стандартной конфигурации Seam - он не может такое решить - я вспомнил что на данный день существует ограничение - Seam может работать с маппированной оберткой только одной СУБД.

Помню, помню. Как раз пытался. В моем проекте - немного изменили логику общения с БД.

Вообще интересный момент. Возможно ответ существует на форумах JBoss.

Отправить сообщение JMS - это можно. Там в ряде случаев с JMS могут быть вопросы, по моему - контекст диалога не действует в MDB (Message Driven Beam), но так, в принципе, вроде все архитектурно можно решить, ну а мощный Remote Layer у Seam (нюанс - я тогда возился и что-то у меня он не запустился) - должен избавлять от многих таких вопросов.

Спасибо что напомнили. Я честно признаю, что тут как минимум придется подумать.

> Message Driven Beam

Т.е. Message Driven Bean.

Я вам даже сразу могу сказать, что средствами самого Seam-а такие вещи вы в любом случае не сделаете. Вам либо самим придется прикрутить JOTM или же воспользоваться уже готовым решением - JEE.

Таким образом вывод один - использовать всё надо с умом. А универсальных супер-пупер фреймворков нет и быть не может.

ЗЫ. 1) Remote Layer - это вообще про другое. И вряд ли у Seam он более мощный, нежели у JEE. 2) интерес именно в отправке JMS сообщения в той же транзакции, а не просто в отправке.

> ЗЫ. 1) Remote Layer - это вообще про другое. И вряд ли у Seam он более мощный, нежели у JEE.

Нет, тут все правильно, просто у них много тем входит в "Remote Layer". Боюсь по памяти что и само название правильно ли дал, но у нас на фирме тоже возникли ко мне аналогичные вопросы, во время моего выступления. Там сразу темы 3 в это понятие входит, не совсем привычная трактовка, Ваш комментарий тут вполне логичен.

> И вряд ли у Seam он более мощный, нежели у JEE

Гм. Многие спецификации JEE у Seam идут как "нижний слой".

Многие вещи из Seam - продвигаются в качестве стандартов JEE.

Пример - WebBeans, который должен войти в спецификацию JEE 6.

> 2) интерес именно в отправке JMS сообщения в той же транзакции, а не просто в отправке.

При этом менеджер транзакций - не должен сам все на автомате делать, должны быть удобные механизмы по ручной настройки в разных бинах - какой транзакционный контекст в данном месте.

Желательно - аннотациями JPA, где это ЛОГИЧЕСКИ будет правильным (вспомним, что JPA - это интерефейсы, HIbernate - это конкретная реализация JPA).

В данном случае _логически будет правильным сказано_ - что JPA не имеет отношения к JMS.

Но Вы хотите, чтобы отправка JMS - участвовала в транзакционном процессе.

Все правильно?

Назову практически единственное отличие, каким недостатком обладает использование JavaBeana (в Seam!) от EJB 3.0

Формулировку привожу по памяти - у JavaBeans, которыми в Seam можно сделать практически все, что и используя EJB 3.0 - у этих JavaBeans "нет демаркационного управления транзакциями".

Другими словами - нет возможностей использовать EJB 3.0 - аннотаций для выставления и расширенного контекста персистентности, и выставлением контекста транзакций в каждом конкретном нужном нам участке кода.

Сам все это не использовал, но помню многочисленные примеры, где эти атрибуты выставляются.

Выставляются они аннотациями (при условии использования EJB 3.0 тут есть весь комплект), и сюда же, чисто в наш код - можно поместить отправку JMS.

Что не так? :)))

Ограничение, которые есть - указано мною выше - менеджер сущностей (EntityManager) у Seam, к сожалению, на данный день - может использовать только 1 dataSource.

Возможно в 3-ей версии Seam, это ограничение будет снято. Давно ее уже жду, вроде обещали этим летом. Смотрел на сайте, вроде зимой была даже бета 3-ей версии, сейчас там ничего не понял. Фиг его знает.

> А универсальных супер-пупер фреймворков нет и быть не может.

Чисто для обемена опытом, ни в коем случае не спора ради - чем "Ваш" фреймворк обладает из таким, что Вас интересует в этих вопросах и моих ответах?

> >Форкнуть никогда не поздно, тем более есть альтернативы - Google Guice. > это только DI, а Spring является интеграцией различных компонент в общее приложение.

А можно поподробнее про "интеграцию различных компонент в общее приложение"? Я понимаю, что DI это связывание компонент в кучу (и которое в Spring сделано весьма м.. пикантно). Что еще есть в спринге кроме DI, подходящее под категорию "интеграция компонент"? Его шаблоны для работы с СУБД? Ну так это просто обертка над JDBC, причем не самая лучшая. Гора классов для JMS и JMX - та же петрушка.

Пока что наблюдаю адский огонь в глазах народа но не вижу причины для этого. Кроме, конечно, эффективного пиара со стороны SpringSource.

1) Интересно, какой из фреймворков вы записали в "мои". Я пользуюсь тем, что мне больше подходит а не "из идеологических соображений". Сейчас спринга больше, чем JEE.

2) Я и говорю, что у сима есть некоторые ограничения (несколько баз данных, транзакции), что влияет на возможность его использования. Ну а если он поддерживает ПОЛНОСТЬЮ все фичи EJB 3.0 - то спорить не о чем.

> Что то пройдя по ссылки я нифига не понял зачем они VMware

Объясняю: Сейчас клиенту, чтобы развернуть ынтерпрайс приложение, нужно купить железо, купить или скачать сервер приложений или тот же spring, все настроить и поддерживать.

В последнее время стали делать по-другому: датацентр покупает мегамощные компьютеры, на каждом из которых поднимает несколько виртуалок (VMware), на виртуалках разворачивает всю инфраструктуру - ОС, СУБД, httpd, Tomcat, Spring (далее по выбору) и сдает такие виртуальные сервера в аренду.

Если все притереть друг к другу (wmware, spring), сделать нормальную панель управления, стандартизировать среду, в которую попадет ынтерпрайс приложение, то можно развить неплохой бизнес. Т.е. создать рынок не для хостинга LAMP приложений, а для хостинга spring приложений. Такое готовое решение можно затем либо продавать хостинг-провайдерам за мегабаксы, либо самим сдавать в аренду за килобаксы.

> 1) Интересно, какой из фреймворков вы записали в "мои". Я пользуюсь тем, что мне больше подходит а не "из идеологических соображений". Сейчас спринга больше, чем JEE.

Про спринг я и намекал... :)

> 2) Я и говорю, что у сима есть некоторые ограничения (несколько баз данных, транзакции), что влияет на возможность его использования. Ну а если он поддерживает ПОЛНОСТЬЮ все фичи EJB 3.0 - то спорить не о чем.

Кстати, на сайте Red Hat есть еще Seam. За деньги можно получить платный суппорт - это понятно, и такая модель монетизации - лично меня очень устраивает.

Комьюнити JBoss имеет большой список форумов, где худо-бедно могут подсказать, но особенно ценен там поиск, т.к. интересующий тебя вопрос - очень что возможно - интересовал и других. Лично мне поиск по форумам, по готовым ответам - очень помог.

Ну так вот. Не смотрел - чем отличается Seam в своем платном варианте...

Оч. любопытно...

> Ну а если он поддерживает ПОЛНОСТЬЮ все фичи EJB 3.0 - то спорить не о чем.

Симовскими компонентами могут быть любые бины (Stateless, Stateful, Entity) EJB 3.0. MDB тоже работают без проблем. Поэтому если симовское приложение использует EJB 3.0, то разумеется все фичи поддерживаются. По сути это EJB 3.0 + дополнительные фичи сима. Например, в вебомордии на базе JSF не нужны бэкин-бины - их функции выполняют EJB, не нужен faces-context.xml - навигация заменяется симовскими средствами, DI заменяется симовской bijection.