Заранее извиняюсь на возможную неточность в терминологии.
Ситуация такая.
Есть несколько интерфейсов, они реализуются в нескольких EJB-компонентах. Клиент должен получать только один интерфейс IpStart. Все остальные ему предоставляет этот интерфейс IpStart. Т.е. напрямую создавать экземпляры других интерфейсов ему нельзя. Как запретить такое создание?
Здравствуйте, Eugene Sh, Вы писали:
ES>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Eugene Sh, Вы писали:
ES>>>Заранее извиняюсь на возможную неточность в терминологии.
ES>>>Ситуация такая.
ES>>>Есть несколько интерфейсов, они реализуются в нескольких EJB-компонентах. Клиент должен получать только один интерфейс IpStart. Все остальные ему предоставляет этот интерфейс IpStart. Т.е. напрямую создавать экземпляры других интерфейсов ему нельзя. Как запретить такое создание?
А>>подробнее можно? какой EJB (session, entity...)? и что ты понимаешь под "Клиент должен получать только один интерфейс IpStart"? Насколько я понимаю, клиент получает home или local home interface через JNDI, а потом, используя полученный home, получает remote или local interface соответственно.
ES>Session EJB.
ES>Вобщем, нужно, чтобы клиент не мог получить home интерфейс остальных ejb`шек. Или, получив home интерфейс, не мог вызвать у него метод create. При этом другие ejb`шки должны спокойно получать home интерфейс и вызывать метод create.
Я не нашел ограничений в спецификации, которые бы мешали в бине в бине (назовем его DispatcherEJB) сделать бизнес-метод, который возвращает другой бин (точнее его remote interface). Т.е. в принципе можно сделать так:
// remote interface of DispatcherEJB
interface Dispatcher extends EJBObject {
public RealWorker getRealWorker() throws RemoteException;
}
а реализовать этот DispatcherEJB таким образом:
// implementation class of DispatcherEJB
class DispatcherBean implements SessionBean {
// . . .
public RealWorker getRealWorker() throws RemoteException {
try {
Context context = new InitialContext();
Object ref = context.lookup("ejb/RealWorker");
RealWorkerHome home =
(RealWorkerHome) PortableRemoteObject.narrow(ref, RealWorkerHome.class);
return home.create();
}
catch(Exception exc) {
throw new RemoteException("error", exc);
}
}
}
и естественно, в deployment descriptor'е DispatcherEJB должна быть прописана ссылка на RealWorkerEJB (в данном случае с ejb-ref-name содержащим строку ejb/RealWorker), а клиенту достаточно просто ссылаться на DispatcherEJB.
Если в deployment descriptor'е клиента НЕ прописать ссылку на RealWorkerEJB, то он и не сможет получить его home interface и, следовательно, не сможет создать.
Однако, такой подход, как мне кажется, оправдан только в том случае, когда определение того, какие реализации RealWorker'а использовать, -- является частью бизнес логики. Например, метод getRealWorker мог бы принимать некоторые параметры и в зависимости от них выбирать бины с различными JNDI именами. На мой взгляд, необходимость делать такой финт, возникает довольно редко. Гораздо лучше было бы Bean Provider'у прописать в deployment descriptor'е все ссылки на внешние бины, а Application Assembler'у статически настроить связи между бинами и/или клиентом и бинами.
