2015-01-15 2 views
0

Я новичок в EJB, поэтому, пожалуйста, не возражайте против глупого вопроса.Зачем использовать сессионный компонент вообще, если в конечном счете его HttpSession, который содержит состояние

У меня есть сомнение в том, что кто-то может решить с надеждой.

У меня есть следующий Stateful Bean:

@Stateful 
public class SessionBean implements SessionBeanRemote { 

    private int count = 0; 

    @Override 
    public int getCount(){ 
    count++; 
    return count; 

    } 

} 

И это клиент, который вызывает Bean (Servlet)

@Override 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
      throws ServletException, IOException { 
     InitialContext ctx; 
     HttpSession session = null; 
     SessionBeanRemote obj; 
     try { 
      if (session.getAttribute("myBean") == null) { 
       ctx = new InitialContext(); 
       obj = (SessionBeanRemote) ctx.lookup("SessionBean/remote"); 
       session.setAttribute("myBean", obj); 
      } else { 
       obj = (SessionBeanRemote) session.getAttribute("myBean"); 
      } 

      System.out.println(obj.getCount()); 

     } catch (NamingException ex) { 
      Logger.getLogger(TestServlet.class.getName()).log(Level.SEVERE, null, ex); 
     } 

    } 

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

А также мне было интересно, если можно сказать, что я изменяю аннотацию @Stateful на @Stateless, а затем выполняю тот же код на стороне клиента и сохраняю компонент в сеансе, а затем я могу извлечь тот же компонент из сеанса, затем в чем разница между лицами без состояния и состояниями, я знаю, что когда новый поиск выполняется, есть вероятность, что тот же самый факсимильный компонент может быть возвращен мне, где, как и в случае с компонентом stateful, он всегда является новым, когда мы выполняем поиск. Но так ли это?

P.S. Как я упоминал ранее, я новичок в EJB, и все сомнения основаны на том, что я понял из нескольких обучающих онлайн, и некоторых вопросов о SO. Я также пытался запустить его локально, но, к сожалению, я не могу развернуть приложение на GlassFish из-за ошибки «Исключение при загрузке приложения: ошибка инициализации EJB-контейнера». Я пытаюсь изучить это.

+1

В дополнение к хорошему ответу ниже, никогда не недооценивайте значение «это автоматически для меня». – chrylis

+0

@chrylis Но это не обрабатывается автоматически, после поиска я должен хранить его в HttpSession, чтобы всегда получать один и тот же экземпляр. Тогда почему бы не сохранить простой объект вместо bean-компонента. или почему бы не сохранить фасоль без состояния. –

ответ

0

Я попытаюсь дать вам упрощенный ответ.

Да, вы должны хранить ссылку на SFSB где-нибудь, в случае веб-приложения в сеансе http, но, как пишет Elliott, у вас могут быть и другие типы клиентов.

Некоторые преимущества Session Bean против POJO:

  • управления контейнером транзакций
  • органы безопасности контейнера
  • возможно удаленный доступ через удаленный интерфейс
  • позволяет развернуть в виде отдельного модуля (EJB) для потенциально лучшее повторное использование.

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

Ваш пример предельно прост, вы не используете транзакции, настойчивость, безопасность, поэтому нет смысла использовать SFSB или даже EJB вообще.

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

Итак, если вы планируете использовать некоторые из функций, которые я предоставил, вы можете воспользоваться EJB, иначе вы, возможно, довольны только Http-сессией и бизнес-логикой в ​​POJO.

+0

Это то, что новичок понял бы. :-) Спасибо, мой друг. Думаю, мне нужно взглянуть на Transaction, Security, чтобы лучше понять использование SFSB. @ Хотели бы вы узнать какое-нибудь место, где я могу получить примеры или учебные пособия для них. –

1

Это две несвязанные концепции.

Если вы разделяете озабоченность, и вы должны. Затем сеанс HTTP и сеанс (ы) EJB работают с логически отличными слоями. Сеанс http предназначен для хранения отдельного веб-браузера и состояния пользователя. Сессия EJB используется для хранения транзакционных, масштабируемых и отказоустойчивых и «прозрачных» (и, возможно, удаленных) ссылок (ов) в контексте клиента Enterprise-приложения.

Тот факт, что вы используете EJB для обслуживания веб-контента, не означает, что вы не можете использовать те же EJB (ы) для обслуживания клиентов JFC/Swing (или JavaFX).

+0

Прошу прощения, но вы могли бы немного упростить это. Как я уже сказал, новичок в этой концепции. –

+0

Этот ответ упрощен. Корпоративная версия Java очень сложна. Это дает вам множество инструментов. Например, вы можете создавать приложения, ** не имеющие веб-интерфейса. С помощью веб-интерфейса вы можете создавать приложения, которые ** не используют ** EJB (ы). Итак, какое приложение вы в конечном итоге строите и какие другие разработки вы должны создавать и поддерживать с другими системами? Вам нужны многоразовые модули? У вас есть высокая доступность и требования к SLA? Требования к масштабированию? –

0

EJB Сессии

Сеанс в EJB поддерживается с помощью SessionBeans над JVM сервера. Вы разрабатываете компоненты, которые могут содержать бизнес-логику или вычисления или динамические страницы, и которые могут использоваться клиентами. У вас есть два разных сеансовых компонента: Stateful и Stateeless.

Stateful: как-то связано с одним клиентом (каждый объект bean-объекта). Он поддерживает состояние для этого клиента, может использоваться только этим клиентом, а когда клиент «умирает», тогда сеансовый компонент «потерян». Жизненный цикл работоспособного компонента связывается с клиентом. (очень полезно в приложениях на основе ролей/системы)

Апатридов: сессионного компонент не запоминает состояние, и нет никакой гарантии, что тот же самый клиент будет использовать тот же лицо без боба, даже для двух вызовов одного после другого. Жизненный цикл EJB без учета состояния не отличается от одного из EJB Session Session Session.Ответственность EJB Container заключается в том, чтобы точно знать, как отслеживать каждый сеанс и перенаправлять запрос от клиента на правильный экземпляр Session Bean и на ту же работу для каждого.

Где:

HTTPSession: Она приобретается через объект запроса. Вы не можете создать экземпляр нового объекта HttpSession, и он не содержит никакой бизнес-логики или вычисления, а скорее места хранения объектов (для клиента как вывода или сервера в качестве входных данных), так и для связи двух или более систем по сети.

+0

@Sarx Исправить меня, если я ошибаюсь, но во всех случаях вам нужно сохранить ссылку на Stateful SB на клиентском сеансе (например, HTTP), так как каждый поиск в Stateful SB возвращает новый экземпляр. Так что я jsut интересно, почему бы не хранить простой объект, а не хранить боб. Что здесь особенного в этом bean-компоненте. –

+0

HttpSession предназначен только для идентификации пользователя, скажем, профилирования пользователя.Statefull session bean (создание нового объекта для каждого клиента) отслеживает вашу идентификацию и динамически заполняет данные соответственно (ролевая база) из базы данных, используя PersistenceContext. HttpSession - это сервер веб-технологий, который может поддерживать сеанс многими способами, такими как использование файлов cookie или переписывание URL-адресов, а сеанс EJB - сервер Java-технологий, поддерживающий состояние как объекты Java-приложения. Я думаю, что вы смешиваете их имена. – Sarz

Смежные вопросы