Java RMI: архитектура для НЕ прохождения объекта, просто выставляя его методы экземпляру на стороне клиента - PullRequest
Новая
       31

Java RMI: архитектура для НЕ прохождения объекта, просто выставляя его методы экземпляру на стороне клиента

0 голосов
/ 18 февраля 2012

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 19 февраля 2012

Когда вы расширяете 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, клиенту будет возвращена только заглушка, и когда клиент вызовет для него метод, метод будет выполнен на сервере.

...