Мне было интересно, зачем нам нужны отдельные Remote и Local intefaces для сеанса EJB 3.0 beans. Я предполагаю, что большую часть времени они оба определяли один и тот же контракт. Почему у меня нет общего интерфейса, и в моем Bean я должен просто сказать, что хочу, чтобы этот Bean был удален удаленно и/или локально.
спасибо Викас
Вот что говорит спецификация EJB:
Выбор между локальной и удаленной моделью программирования является конструктивным решением, которое делает Bean Поставщик при разработке предприятия bean.
Хотя можно предоставить как представление удаленного клиента, так и представление локального клиента для предприятия bean, более типично будет предоставлен только тот или другой.
Поэтому при написании Bean думать о том, кто является клиентом, очень маловероятно, что локальному клиенту потребуются те же методы или даже тот же Bean, что и удаленный.
Я не согласен с тем, что во время проектирования удаленное и локальное должно рассматриваться как тривиально изменяемое.
Во-первых, есть накладные расходы при удалённом вызове, поэтому при разработке удаленных интерфейсов вам необходимо тщательно изучить, правильно ли вы имеете размерность и размеры параметров. Таким образом, напоминание это будет относительно дорого полезно как разработчик.
Кроме того, учитывая, что параметры удаленных интерфейсов передаются по значению, а параметры локального интерфейса передаются по ссылке, существуют фундаментальные семантические различия между двумя случаями, поэтому вы можете выбрать дизайн двух интерфейсов по-разному.
Понятие "прозрачность местоположения" является опасным анти-шаблоном. Ваш дизайн абсолютно необходимо знать, делает ли он локальный вызов или удаленный вызов по многим причинам (обработка ошибок и производительность являются наиболее очевидными).
Удаленные EJB-интерфейсы отличаются от своих локальных копий, потому что подпись исключения должна отличаться для размещения связанных с сетью ошибок, которые могут возникать только при удаленном вызове. Оседление багажного ветки с дистанционным управлением на локальный интерфейс (как в случае с EJB 1) делает код ужасным. EJB 2 представил отдельные локальные интерфейсы для упрощения программирования для EJB, которые всегда были локальными.
Я считаю, что, когда вашему бизнесу нужны все ваши методы в Local, также необходимо подвергать удаленные клиенты, тогда
Этот подход может быть полезен для достижения @Local и @Remote того же интерфейса. Один и тот же метод можно получить локально, если требуется, и удаленно, если это необходимо, без каких-либо служебных накладных расходов.
Это моя мысль. Кто-нибудь, пожалуйста, дайте мне знать ваши мысли, чтобы подтвердить это.
Клиенты получают доступ к сеансу или сущности bean через интерфейсы bean. Контейнер EJB генерирует реализации интерфейса для обеспечения соблюдения и управления этим поведением, выступая в качестве канала для связи между клиентом и bean. В версиях до спецификации EJB 2.0 все beans были определены и реализованы как распределенные, удаленные компоненты. В результате два интерфейса, необходимые для beans, назывались домашним интерфейсом (который, в общем, определяет методы жизненного цикла) и удаленным интерфейсом (который, в общем, определяет функциональные бизнес-методы).
Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.
Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.
When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces:
beans должен работать в той же виртуальной машине - они, в конце концов, являются локальными. Параметры отправляются по ссылке, а не копируются, как в случае с удаленными интерфейсами и объектами. Неожиданные побочные эффекты могут возникнуть, если вы проигнорируете это различие и не кодируете соответственно. Как правило, решение использовать локальный или удаленный доступ зависит от:
Тип клиента. Если вы не всегда ожидаете, что клиент будет веб-компонентом или другим bean, выберите удаленный доступ.
Независимо от того, жестко или слабо связаны beans - если beans зависят друг от друга и часто взаимодействуют, рассмотрите локальный доступ.
Масштабируемость. Удаленный доступ по своей природе масштабируется и должен использоваться, если масштабируемость является важным фактором. С появлением локальных интерфейсов в спецификации EJB 2.0 большинство источников рекомендуют, чтобы объект beans почти всегда основывался на локальном доступе. С локальными интерфейсами большинство проблем с производительностью в отношении очень мелкого доступа к данным исчезают. Если клиент удален, стандартный шаблон проектирования использует клиентский интерфейс для доступа к сеансу bean, который затем действует как связь с объектом bean. Сеанс bean связывается с сущностью bean через локальный интерфейс (с точки зрения шаблонов, этот метод называется фазой сеанса, и он может фактически использоваться как в удаленном, так и в локальном контексте).
Хорошей причиной является то, что вы получаете доступ к EJB через свой интерфейс. Таким образом вы передаете параметр по значению при использовании удаленного интерфейса и по ссылке при использовании локального интерфейса. И знаете ли вы, почему это поведение? это имеет смысл: возможно, вы хотите, чтобы удаленное приложение обращалось к вашему бизнес-объекту, и поскольку передача по ссылке уменьшает задержку сети. Помните: удаленный доступ включает в себя процесс превращения объекта в байтовый поток - маршалинг - и процесс превращения байтового потока в объект - разматывание. Этот дополнительный шаг - Marshaling и unmarshaling - замедляет производительность приложения.