Доброго дня...

Уважаемые, существует два бина из разных EAR- приложений...

Адрес в одном приложении...


Банк в другом приложении...



В Банке существует связь с адресом
    

Если бы оба бина сидели в одном EAR - проблем бы не было... а так на попытку продеплоится - выдает ошибку... 

При компиляции проблем нет - я просто указал проект-jar Адреса как библиотеку Банков...
Есть ли корректный способ решить эту проблему??

Добавлено @ 18:11 
  то есть основной вопрос - можно ли использовать эти самы связи между удаленными бинами... если нет - то как правильно организовывать ее через удаленные интерфейсы...??

Это сообщение отредактировал(а) Maverick - 12.3.2007, 18:00

EntityManager связан только одним persistence context.
Набор объектов, которые могут управляться данным экземпляром EntityManager, определяется persistence unit'ом, который определяет набор всех классов, связанных или сгруппированных приложением (т.е. EAR-файлом), и которые должны отображаться на одну и ту же базу данных.

То есть это невозможно? Так получается нельзя разнести бины по разным серверам? Тут, например, банки работают, а там, на другом сервере, адреса...? Не заманчиво.... А если придется потом остановить  что-нить для обновления или профилактики? Например, чтобы обновить банки - придется гасить все огромное приложение?? (Хотя ерунду говорю - если они так будут связаны, все равно остановятся)...

Ну хорошо - связь прямую сделать невозможно?? Как же правильно поступить?? Вызвать удаленный интерфейс и ручками растыкать все данные в setter и getter? Где это более правильно сделать? В самом бине? или в его сессионном фасаде?

Это сообщение отредактировал(а) Maverick - 13.3.2007, 09:10

Видимо придется делать такие бины не связанными - просто два разных бина могут общаться друг с другом, получая списки или отдельные объекты. И связи между ними на уровне сервера приложений уже не делать - только логическая связь внутри самих бинов. Что-то других мыслей нет пока.

    где это правильно намутить? в самом бине или его сессионном фасаде?

Вопросы растут как ком снежный... В каком виде тогда представлять адрес в банке?? Просто в виде числового идентификатора-указателя на адрес в таблице адресов? Судя по всему EJB3 тоже не сильно распространен??

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

Вот только , если банк будет часто дёргаться и адреса подтягиваться - может нет смысла их по разным еаркам? Или адреса будут использоваться не только для банков? Типа "словарь данных"?
Тогда через фасад - получение банком адреса унифицированым методом.
Для скорости(если понадобится) - кэш адресов на стороне банков(в логике фасада)

Добавлено @ 15:39 

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

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


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

Структуры данных максимально простые пока - только бы понять как правильно сделать... 

Вот есть Банк - идентификатор, наименование... это будет бин... к нему сессионный фасад с EntityManager... У этого фасада два интерфейса - локальный и удалённый (мутим все, до чего дотягиваемся)... Аналогично, есть Адрес - идентификатор, название улицы... с теми же фасадом и интерфейсом... 

Как сделать так, чтобы Банк автоматом писал изменения в своём Адресе?? Вот и вся задача... 

Я уже в третий раз пол-проекта переписываю... EJB1, EJB2, теперь вот EJB3...  

Аха... таки "словарь данных"



То есть?  Это не термин - это я так выразился. Это означает, что метод будет возвращать Value Object по параметру с айди адреса. И этот метод будет использоваться как банками так и всеми остальными частями системы.


То есть с тем же фасадом? 
Сделай фасад Banks и фасад Addresses
Когда вызываешь Banks.getBankByName("Bank of Taiwan")  - в этом методе фасада вытягивается банк из энтити, получается айди адреса, вызывается метод Adresses.getAddressById(45454), получаешь ValueObject адреса, перегоняешь из него данные в объект BankValueObject(туда же данные из бина банк). Вуаля - все данные по банку - в одном объекте - можно отдавать "на клиента". 
BankValueObject можно кэшировать для скорости в фасаде

А нельзя в качестве ValueObject использовать тот же самый Entity? Ведь какой смысл создавать такой же класс только без аннотации?

Добавлено @ 10:38 
Фасады, естественно, разные.. "те же" в смысле аналогичные... 

Честно говоря, до еджиби 3 ещё никак руки не дойдут - всё дела да дела... Если верно помню - то именно так и обстоят дела. И это одна из фич - "бин = трансфер обжект". Но это поищи у сана на сайте.

Ага... значится, мысль правильная...