2010-01-30 2 views
2

Небольшой контекст: я хотел бы отделить приложение Java, которое я пишу, в более или менее типичную модель сервер-клиент. Я бы предоставил «сервер», который заботится о бизнес-логике и настойчивости, но пишут его очень ориентированно на обслуживание. Любой интерфейсный код (GUI) затем будет вызывать сервер для обеспечения функциональности в удобной для пользователя форме.Параметры перенаправления Java Spring

Поскольку я пишу приложение с использованием Spring (и рамки ORM), имеет смысл исследовать обычных подозреваемых, чтобы выявить функциональность сервера, причем обычные подозреваемые являются RMI, Spring HTTP, Hessian, веб-сервисы, и т. д. (параметры, поддерживаемые пружиной). Они хорошо документированы, как в справочной документации, так и здесь.

Однако, для фактического вопроса: существуют ли менее очевидные, более экзотические варианты, которые я мог бы рассмотреть, чтобы разоблачить мои серверные сервисы?

Важно (как всегда) обеспечить правильный баланс между простотой использования (от интерфейсного POV), производительностью и масштабируемостью. Например; поскольку я думал о возможности интеграции Spring-BlazeDS на сервере (для клиентов Flex/AS3), мне стало ясно, что BlazeDS предоставляет API-интерфейс Java для вызова служб AMF.

Любые указатели очень ценятся.

+0

Ваш выбор уровня переадресации определяется вашим выбором клиента и сервера. Очевидно, что у вас сервер java, но ваш клиент определенно является Flex? – skaffman

+0

Вот что, может быть, я не делал этого достаточно ясно: клиент для меня на этом этапе тривиален. На этом этапе: «Мне не важно, какие технологии клиент собирается использовать». Я собираюсь разработать Flex один сам, поэтому BlazeDS определенно находится, но я также хотел бы предоставить достаточно услуг, чтобы позволить сторонним интерфейсам. – tmbrggmn

ответ

4

Я бы порекомендовал BlazeDS, если у вас есть внешний интерфейс Flex и Spring HTTP, если нет. Оба исключают непроизводительную работу, связанную с необходимостью перевода XML в объекты и обратно.

Spring HTTP особенно привлекателен тем, что вы можете писать интерфейсы сервисов POJO Spring так же, как и всегда, откладывая выбор для демонстрации через удаленный HTTP до конца. Вы держите свои варианты открытыми таким образом. Если вы решите, что более поздние веб-сервисы работают лучше для вас, вы можете продолжать использовать один и тот же интерфейс POJO Spring.

+0

Правильно ли я говорю, что с использованием HTTP-экспортера Spring/invoker вы, по сути, вынуждаете потенциальных клиентов использовать Spring (если они хотят позвонить этим сервисам)? Я предполагаю, что единственным истинным языком/рамкой агностики будет веб-службы. – tmbrggmn

+0

Правильно. Если вы используете перенастройку Spring HTTP, клиентам придется использовать Spring-клиент, чтобы получить право на маршалинг/unmarshaling. Веб-службы являются агностиками. Помните, что они не должны быть синонимом SOAP/XML. Те могут заблокировать вас. (например, Axis) REST - отличный способ пойти так же хорошо. – duffymo

+0

+1 - мы все время используем службы HTTP в нашем клиент-серверном приложении, так как нам нужно беспокоиться только о клиентах Java. Работает как чемпион! – aperkins

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