选择正确的体系结构 Silverlight Web 应用程序访问 JSP 网页
我需要一个可以解决我的问题的架构解决方案。我们有一个在 apache 上运行的 JSP 网站，而 apache 在 UNIX 服务器上运行。客户决定该网站的前端应使用 Silverlight 进行设计。
当我们进行概念验证时，我们所做的如下：
设计一个示例 silverlight Web 应用程序（仅登录屏幕和帐户摘要页面）。使用 .net Webclient 类，我们调用 .jsp URL，读取并解析响应，将它们转换为 C# 对象，并将这些对象/数据绑定到我们的 UI。我们还了解到可以在 apache/unix 平台上托管 silverlight Web 应用程序，因为 silverlight 应用程序只会被下载（仅 *.xap 文件就足够了）并且所有执行都发生在客户端。
我们尝试这种方法只是因为我们的经理（来自大型机背景）只是要求我们重用现有的 *.jsp 代码/网站。
现在有几个问题需要考虑。该会话是在 .jsp 代码/网站中创建的，并且 silverlight 无法控制或访问该会话。我们用来解析 *.jsp 响应的代码并不是很好维护的代码。
大多数情况下，*.jsp 返回的响应采用 JSON 形式，我可以将它们解析为 JSONArray 并在我的代码中使用它，或者进一步将它们转换为我的实体。
我们不确定在不久的将来是否会遇到任何其他问题。
所以我的计划是 1) 不是通过调用 URL 来重用 *.jsp 代码，为什么我们不能在 .net 本身中编写整个应用程序
2) 让 java 开发人员编写一些 java webservices 来公开服务以返回数据我们需要并且 silverlight 只能使用这些服务。
任何想法或评论都非常感激。
I require an architecture solution that can be implemented for my problem. We have a JSP website that runs on apache which runs on a unix server. Clients decided that the front end for this website should be designed in Silverlight.
When we did our Proof of Concept what we did is as follows:
Designed a sample silverlight web application (Just the login screen and account summary page). And using the .net Webclient class we invoked the .jsp URLs, read and parsed the response, converted them in to C# objects and binded those objects/data to our UI. We also came to know that it is possible to host a silverlight web app in apache/unix platform since, the silverlight app is only going to get downloaded(*.xap file alone is enough) and all the execution happens in the client side.
we tried this approach just because our manager(from MAINFRAME BACKGROUND) just asked us to reuse existing *.jsp code/website.
Now there are several problems that need to be considered. The session is created in the .jsp code/website and silverlight does not have control or access to that session. And the code that we use to parse the *.jsp response is not a great code to maintain.
Most of the times the response returned by *.jsp is in the form of JSON, and I can parse them in to JSONArray and use it in my code or further convert them in to my entities.
We are not sure if we will be facing any other problems in near future.
So my plan was
1) instead of reusing the *.jsp code by invoking the URLs why cant we write the whole application in .net itself
2) Let the problem be given to the java developers to write some java webservices to expose the services to return the data that we need and silverlight can only consume those services.
Any thoughts or comments are really appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
需要明确的是，Silverlight 客户端调用的 .jsp 页面返回的是 HTML 还是 JSON？如果是 HTML，那么是的，绝对需要重写该应用程序以通过某种 Web 服务返回数据。解析 HTML 实在是太脆弱了，无法使其成为应用程序的支柱。但是，如果它们返回 JSON，那么解析 JSON 是一种合理的方法。在这种情况下，您基本上可以将 JSP 页面视为一种 REST API，尽管手动调用反序列化步骤有点麻烦，但它可能只占整个应用程序的一小部分，我也不会担心关于它的很多。
也就是说，创建真正的 Web 服务无疑是一种更优雅的架构，无论是 .NET 还是 Java，无论是 REST（使用 JSON 或 XML）还是 SOAP。我非常确定，您会发现，与基于 Java 的 Web 服务相比，.NET/WCF 在各种小而重要的方面与 Silverlight 配合得更加干净，即使它们都基于 SOAP。真正的问题是平衡创建“真正的”Web 服务（无论是 .NET 还是 Java）所需的工作与维护不太优雅的 Silverlight 反序列化代码所需的工作。如果没有更多的信息，这里的任何人都无法希望明智地回答这个问题。
我不太确定“会话是在 JSP 代码中创建的，而 Silverlight 无法控制或访问该会话”是什么意思。如果您的意思是“Silverlight 无法直接访问 JSP 后端会话中缓存的任何内容”，那么这当然是正确的。如果您的意思是“任何 Silverlight 调用都将被解释为属于与直接来自 Web 浏览器的调用不同的会话”，则这不一定是正确的。默认情况下，所有 Silverlight HTTP 访问都会通过浏览器自己的 HTTP 堆栈，因此，如果用户通过浏览器/HTML 登录，并在后端 Web 服务器上创建了会话，则默认情况下，来自 Silverlight 的任何调用都将被解释作为同一会话的一部分。 Silverlight有自己的替代 HTTP 堆栈，例如，它能够比浏览器堆栈通常同时打开更多的客户端请求。而且该堆栈维护自己的 cookie 数据库，因此从备用 Silverlight HTTP 堆栈对 Web 服务器的任何调用都将被有效地视为来自同一计算机上的不同 Web 浏览器。但在 Silverlight 开始使用备用堆栈之前，您必须启用它。 （这有意义吗？）请参阅 此处了解更多详情。
So just to be clear, are the .jsp pages called by the Silverlight client returning HTML or JSON? If HTML, then yes, absolutely, you need to rewrite that application to return data via some sort of web service. Parsing HTML is just way too damned brittle to make it the backbone of your application. However, if they're returning JSON, then parsing JSON is a reasonable approach. In that case, you could basically treat the JSP pages as a sort of REST API, and although invoking the deserialization step manually is a bit of a pain, it's likely a pretty small part of your overall application, and I wouldn't worry too much about it.
That said, it's certainly a more elegant architecture to create a true web service, whether .NET or Java, whether REST (with JSON or XML) or SOAP. You'll find, I'm pretty sure, that .NET/WCF works much more cleanly with Silverlight in all sorts of small but important ways than a Java-based web service does, even if they're both based on SOAP. The real issue is balancing the work required to create a "real" web service (whether .NET or Java) with the work required to maintain the somewhat less elegant Silverlight deserialization code. And that's not a question anybody here could hope to answer intelligently without a great deal more information.
I'm not quite sure what you mean by "the session is created in the JSP code and Silverlight does not have control or access to that session". This is true of course if you mean, "Silverlight can't directly access anything cached in the JSP backend session." This isn't necessarily true if you mean, "Any Silverlight call would be interpreted as belonging to a different session than a call straight from the web browser." By default, all Silverlight HTTP access goes through the browser's own HTTP stack, and consequently, if the user has logged in via the browser/HTML, and has created a session on the backend webserver, by default, any call from Silverlight would be interpreted as being a part of that same session. Silverlight does have its own alternative HTTP stack that, for instance, has the ability to open up more client requests simultaneously than the browser stack typically does. And this stack maintains its own cookie database, so any calls to the web server from the alternative Silverlight HTTP stack would effectively be treated as if they were coming from a different web browser on the same machine. But you would have to enable the alternate stack before Silverlight starts using it. (Does that make sense?) See here for more details.