Здравствуйте, 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'у статически настроить связи между бинами и/или клиентом и бинами.