Выбор правильной архитектуры Веб-приложение Silverlight для доступа к веб-страницам JSP

Question

Мне требуется архитектурное решение, которое может быть реализовано для моей проблемы.У нас есть веб-сайт JSP, который работает на Apache, который работает на сервере Unix.Клиенты решили, что интерфейс для этого сайта должен быть разработан в Silverlight.

Когда мы сделали наше Подтверждение Концепции, мы сделали следующее:

Разработал пример веб-приложения silverlight (только экран входа в систему и страница сводки по учетной записи).Используя класс .net Webclient, мы вызывали URL-адреса .jsp, считывали и анализировали ответ, преобразовывали их в объекты C # и связывали эти объекты / данные с нашим пользовательским интерфейсом.Мы также узнали, что возможно разместить веб-приложение silverlight на платформе apache / unix, поскольку приложение silverlight будет только загружено (достаточно только * .xap-файла), и все выполнение будет выполняться на стороне клиента.

мы попробовали этот подход только потому, что наш менеджер (из фонового фона MAINFRAME) только что попросил нас повторно использовать существующий код * .jsp / веб-сайт.

Теперь есть несколько проблем, которые необходимо рассмотреть.Сеанс создается в коде .jsp / веб-сайте, и Silverlight не имеет контроля или доступа к этому сеансу.И код, который мы используем для разбора ответа * .jsp, не является хорошим кодом для поддержки.

В большинстве случаев ответ, возвращаемый * .jsp, имеет форму JSON, и я могу их проанализироватьв JSONArray и использовать его в моем коде или в дальнейшем преобразовать их в мои объекты.

Мы не уверены, столкнемся ли мы с какими-либо другими проблемами в ближайшем будущем.

Так что мой план был1) вместо повторного использования кода * .jsp, вызывая URL-адреса, почему мы не можем написать все приложение в самом .net

2) Пусть разработчикам java будет дана задача написать несколько java-веб-сервисов, чтобы разоблачитьсервисы для возврата данных, которые нам нужны, и silverlight могут использовать только эти сервисы.

Любые мысли или комментарии действительно приветствуются.

Answer 1

Итак, для ясности, страницы .jsp, вызываемые клиентом Silverlight, возвращают HTML или JSON?Если HTML, то да, безусловно, вам нужно переписать это приложение, чтобы вернуть данные через какой-то веб-сервис.Синтаксический анализ HTML слишком хрупок, чтобы сделать его основой вашего приложения.Однако, если они возвращают JSON, то разбор JSON является разумным подходом.В этом случае вы могли бы в основном рассматривать страницы JSP как своего рода REST API, и хотя ручное выполнение шага десериализации представляет собой небольшую боль, скорее всего, это довольно маленькая часть вашего общего приложения, и я бы не стал беспокоитьсямного об этом.

Тем не менее, безусловно, это более элегантная архитектура для создания настоящего веб-сервиса, будь то .NET или Java, будь то REST (с JSON или XML) или SOAP.Я уверен, что вы обнаружите, что .NET / WCF работает намного проще с Silverlight во всех видах небольших, но важных способов, чем веб-сервисы на основе Java, даже если они оба основаны на SOAP.Реальная проблема заключается в том, чтобы сбалансировать работу, необходимую для создания «реального» веб-сервиса (будь то .NET или Java), с работой, необходимой для поддержки несколько менее элегантного кода десериализации Silverlight.И это не тот вопрос, на который каждый мог бы надеяться ответить разумно без большого количества дополнительной информации.

Я не совсем уверен, что вы подразумеваете под "сеанс создан в коде JSP, а Silverlight не имеет контроляили доступ к этой сессии ".Конечно, это верно, если вы имеете в виду: «Silverlight не может напрямую получить доступ к чему-либо, кэшированному в бэкэнд-сеансе JSP».Это не обязательно верно, если вы имеете в виду: «Любой вызов Silverlight будет интерпретироваться как принадлежащий к другому сеансу, чем вызов прямо из веб-браузера».По умолчанию весь HTTP-доступ Silverlight проходит через собственный HTTP-стек браузера, и, следовательно, если пользователь вошел в систему через браузер / HTML и создал сеанс на внутреннем веб-сервере, по умолчанию любой вызов из Silverlight будет интерпретироваться.как часть той же сессии.Silverlight имеет свой собственный альтернативный стек HTTP, который, например, может одновременно открывать больше клиентских запросов, чем стек браузера.И этот стек поддерживает собственную базу данных cookie, поэтому любые обращения к веб-серверу из альтернативного стека HTTP Silverlight будут эффективно обрабатываться так, как если бы они поступали из другого веб-браузера на той же машине.Но вам придется включить альтернативный стек, прежде чем Silverlight начнет его использовать.(Это имеет смысл?) См. здесь для более подробной информации.