Choosing the right architecture Silverlight web app accessing JSP webpages

I require an architecture solution that can be implemented for my problem. We have a JSP website that runs on 开发者_Go百科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.

---

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.