2012-02-18 2 views
0

У меня есть большой Java-API и по соображениям безопасности я пытаюсь разделить его на клиентский интерфейс, архитектуры сервера приложений. Я уже определил, что нет так называемых «Java-серверов приложений» (frameworks), которые могут помочь мне здесь, но если я ошибаюсь, укажите мне то, что не ограничивается веб-приложениями. То есть я запускаю собственный сервер приложений.Java RMI: Архитектура для НЕ передавая объект, просто подвергая его методам клиентскому экземпляру

Существующий API уже доступен через вызовы методов в экземпляр экземпляра одного «объекта», который реализует то, что необходимо сделать.

IIUC (Если я правильно понимаю), я могу настроить сервер RMI, который создает экземпляр отдельных объектов API-объекта - может быть, создать пул из них - и затем «передать их» в качестве экземпляров объекта во входящие вызовы RMI от клиентов которые запрашивают экземпляр. Затем они могут вызывать любые методы этого экземпляра, и вся фактическая обработка этих методов происходит со стороны сервера, и любые результаты возвращаются через механизм RMI.

Пока все хорошо, я думаю. Теперь для сложной части я хотел бы пояснить, пожалуйста:

Если у меня все получилось, я также понимаю, что либо все методы и атрибуты раскрываются (через «extends UnicastRemoteObject» или я могу ограничить атрибуты и методы, которые я хотел бы получить удаленно, создав определение промежуточного класса, все методы которого определены в интерфейсе.

Правильно ли я понимаю, что, используя этот подход, я могу иметь свой оригинальный API как есть, и нужно только создать этот «инкапсулирующий класс», который раскрывает то, что нужно разоблачить?

И перейдем к более продвинутому дизайну, поскольку создание экземпляров стоит дорого, я бы хотел, чтобы t o иметь пул предварительно созданных экземпляров; мне нужен еще один класс, который создает кучу этих экспонируемых объектов, а затем «возвращает» их вызывающему клиенту? Или я могу сделать это как-то в рамках существующего механизма RMI или в моем инкапсулирующем классе API-Server?

+0

Я бы предпочел написать прототип вместо того, чтобы задавать все эти (нетривиальные) вопросы ... – home

+0

@home - Я на самом деле сделал это - здесь есть милый маленький: http://littletutorials.com/ 2008/07/14/the-10-minutes-get-started-with-rmi-tutorial/Проблема в том, что иногда сложно сказать, где именно происходит обработка. –

+1

EJB3 с отдельными локальными и удаленными интерфейсами звучит так, как вы хотите.Контейнер также предоставит вам массу полезных услуг: управление трансацией, безопасность, объединение, настойчивость и многое другое. – Perception

ответ

1

При расширении UnicastRemoteObject (или экспортировать Remote объект) и реализовать интерфейс, который расширяет Remote, методы, объявленные в этом интерфейсе Remote подвергаются для удаленного вызова. Когда эти методы вызываются клиентом, выполнение метода происходит на сервере. Только данные, содержащиеся в результате метода, подвергаются клиенту.

Если вам нужны несколько экземпляров удаленного объекта, вы можете связать их в реестре под разными именами или создать другой удаленный тип, который возвращает экземпляры вашего Remote. Вот простой эскиз:

interface MyService extends Remote { 
    void doStuff() throws RemoteException; 
} 

interface MyServiceManager extends Remote { 
    MyService getService() throws RemoteException; 
} 

Вы бы затем связать один экземпляр MyServiceManager в реестре RMI, чтобы клиенты могли найти его. Экземпляры MyService не должны быть связаны в реестре; анонимные экземпляры будут возвращены через MyServiceManager. Поскольку эти объекты также являются Remote, на клиент будет возвращен только заглушка, и когда клиент вызывает метод на нем, метод будет выполняться на сервере.

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