JNDI в .Net / PHP / IPhone - PullRequest
Новая
       2

JNDI в .Net / PHP / IPhone

0 голосов
/ 03 августа 2011

Позвольте мне объяснить вам полную ситуацию, в которой я сейчас застрял.

Мы разрабатываем очень сложные приложения в GWT и Hibernate, мы пытаемся разместить клиентский и серверный код на разных серверах из-затребование.Теперь я могу добиться этого, используя JNDI.

Здесь возникает сложная часть: клиент должен иметь это приложение на другой платформе, база данных будет одинаковой, а методы будут одинаковыми, скажем, версия нашего приложения для iPhone / .Net.мы не хотим снова генерировать код сервера, потому что он будет одинаковым для всех.

Я пытался использовать оболочку WebServices в верхней части моего серверного кода, но из-за сложности архитектуры и зависимостей классов я не могу этого сделать.Например, давайте рассмотрим код ниже. 

    class Document {
        List<User>;
        List<AccessLevels>;
     }

В классе документа есть список пользователей, список уровней доступа и многое другое, а также то, что другие классы имеют больше списков.Некоторые важные серверные методы принимают Class (Document или любой другой) в качестве входных данных и возвращают некоторые другие классы в выходные данные.И мы не должны использовать сложную архитектуру в WebServices.

Итак, мне нужно придерживаться JNDI.Теперь я не знаю, как я могу получить доступ к вызову JNDI для любого другого приложения ???

Пожалуйста, предложите способы преодоления этой ситуации.Я открыт для технологических изменений, которые означают JNDI / WebServices или любую другую технологию, которая хорошо меня обслуживает.

Благодарю вас,

С уважением,

1 Ответ

1 голос
/ 03 августа 2011

Я никогда не видел, чтобы JNDI использовался в качестве механизма межпроцессного взаимодействия между запросами и ответами.Я не верю, что это будет продуктивная линия атаки.

Вы считаете, что веб-службы неприемлемы, когда полезные нагрузки сложны.Я не согласен, я видел много успешных проектов, использующих довольно большие полезные нагрузки, со многими вложенными классами.Тривиальный пример: клиенты с заказами с линиями заказов с продуктами с ... и т. Д.

Очевидно, что размеры полезной нагрузки желательно сохранять небольшими, затраты на сериализацию и сетевые затраты будут выше, а большие объекты будут дороже.Но гораздо предпочтительнее иметь одну большую просьбу, чем много маленьких.«Занятый» интерфейс не будет хорошо работать в сети.

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

В этом случае вам нужно создать слой "адаптера".Это скучная работа, но независимо от того, какую технику межпроцессного взаимодействия вы используете, вам потребуется это сделать.Вам нужно то, что я называю объектами передачи данных (DTO) - они представляют полезную нагрузку, понятную клиенту, использующую только классы, приемлемые для клиента, и которые сервер может использовать и создавать.

Предположим, что выиспользовать технологию XXX (JNDI, веб-сервис, прямой вызов сокета, JMS) 

  Client --- sends Document DTO --XXX---> Adapter transform DTO to server's Document

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

За создание адаптера отвечаети понимание DTO.

Я считаю, что работать с веб-сервисами RESTful с использованием JAX / RS очень легко, если у вас есть набор DTO, и создание веб-сервисов занимает считанные минуты.

...