GWT is a very convenient platform and is suitable for projects of all sizes, especially since 2.1. The Google Wave team has helped GWT develop APIs and methods that really help use GWT for large projects. Regarding the .NET experience, this may be a steep learning curve, but the GWT Getting Started Guide for Google is a good place to start, and you should be able to hit the ground. One thing that people often forget is that GWT is actually just a compiler that emulates parts of the JRE, and in the end it's just HTML, CSS, and Javascript.
There are many options for back technologies, but there are actually two decisions you must make. First, you will need to resolve the issue of the network / communication layer. As I can see, you have 3 main options for the type of messages before we even begin to implement it: GWT-RPC, REST (XML or JSON) or SOAP. I prefer REST with JSON, however, if you do not need to disclose your services outside of GWT, you might be better off with GWT-RPC. If you decide to go with REST or SOAP, you can even refuse to use the back of Java, and instead use .NET to stay in your comfort zone. For this, I would write XSD to describe your data model and use .NET to save and display your data as JSON via REST. You can then use JAXB to generate the Java representation of these classes for use in your GWT client, however you will have to separate all the XML annotations and modify them to work as overlay types .
Secondly, you will need to determine your level of persistence. Many people prefer Hibernate, but I prefer JPA, or itβs great for enterprise applications. The advantage of using Java feedback with GWT-RPC communications is that you can use RequestFactory with EntityProxy , so you only need to support one version of the object from the client through the save layer.
source share