Some questions: 1)Using GWT RPC, can the servlets be distributed? e.g., the various servlets that perform business logic can be distributed like web services can?
On Jan 14, 3:39 pm, gregor <[email protected]> wrote: > Hi Gabor, > > Personally, I never use the term "web services" anymore. It can mean > anything to anybody. I prefer to be specific, so I speak of SOAP, > REST, JSON, XmlHttprequest, GWT RPC etc. as appropriate. > > I'm a GWT RPC person myself, but if I needed to expose services to > third party web sites for instance, I would choose JSON to do it. I > agree JSON (and REST) is a "web service" if a manager needs soothing > on the point. > > regards > gregor > > On Jan 14, 8:50 am, Gabor Szokoli <[email protected]> wrote: > > > Hi! > > > I completely agree with your comparison between GWT-RPC and SOAP XML, > > but it is just too convenient for me to reply to your post with the > > non-conflicting argument for JSON web services as a viable middle > > ground: > > > On Tue, Jan 13, 2009 at 2:42 PM, gregor <[email protected]> > > wrote: > > > In practice this is almost certainly an unfavourable option because > > > SOAP is a bloated over complicated XML based data exchange mechanism > > > by comparison to REST, JSON, > > > That's still a web service in my book. That's what we use in fact > > (REST with JSON), with SSL and basic authentication. > > The project is still in the pilot phase, but we are getting there. > > Client side performance does not seem to be an issue so far with our > > expected dataset sizes: modern cell phones seem to handle it fine. > > > > and particularly to GWT RPC. > > > GWT-RPC is probably the most efficient on the wire and in the client, true. > > On the upside we expose (develop, secure and load test) one interface > > for both human and machine consumption, and can use the server-side > > platform of our choice (currently Jersey) independently from client > > development (currently GWT). > > > > In other words your application will run many times slower, > > > Let them use Chrome ;-) > > Seriously, I very much like the idea of off-loading application state, > > data manipulation and GUI rendering all to the clients, leaving me > > with a stateless, cacheable, data-only server (plus the static > > download of the GWT client). > > Client hardware specifications are often within the order of magnitude > > of server nodes anyway (they may even exceed them in our case...) > > > > and you will have > > > to write hundreds of lines of code to create, serialize and deserialize > > > large XML strings. > > > Not as nice as GWT-RPC sure, but JSON and third party stuff like > > Restlet-GWT can help with that. > > (For the pilot we just roll our own to better understand what is going on.) > > > I keep bragging about this approach here to invoke constructive > > criticism, so please discuss. > > I know some of our cornerstone design conditions differ from the > > general case, so I'll list them here: > > - We need to publish web services functionally equivalent to the web GUIs > > anyway > > - Single-page, desktop-like applications > > - No need for SEO, no need to spy on users^W^W^Wcollect usage statistics > > - Applications may need to scale (both up to millions of users, and > > down to a few on restricted hardware.) > > > I think enough of these conditions hold for Marvin's case for him to > > consider this architecture. > > > Gabor Szokoli --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
