In-line: On Jan 14, 2:58 pm, Paranoid Android <[email protected]> wrote: > Some questions: > > 1) Using GWT-RPC model, can servlets (business logic) distributed like > standard web services are? e.g. can I invoke some business that > resides on another machine from a GWT client using RPC? >
No, you can't expose GWT RPC servlets to third parties like you can JSON or SOAP based web services. They are there for communication between your own GWT client and your server architecture. However your RPC servlet implementations can call any service on any machine they like. If you think you need to expose business processes to third parties, you need to work through the specific use cases you have for it. First invoke YAGNI (You Aren't Going To Need It). If YAGNI fails (i.e. you do need it, really) then specify exactly what it is you need to provide and to whom. There will be a range of engineering decisions to be made as a result of the answer to that question. These are some of the possibilities: 1) You have only one or two specific services you need to expose to a wide range of possible third party clients. In this case you could build your own client around GWT RPC for most transactions, which is the simplest. Then you might build just two or four extra servlets that supported a JSON and a SOAP interface for each of these particular services. 2) You want to expose a large number of your services so that other similar web sites can integrate them into their own pages (the mash-up scenario). JSON is by far the most popular method of doing this, supplanting SOAP. In this situation there is a strong case for using JSON for your own client as well as the same servlets will then support everyone. 3) You are building a system that is designed to provide an important resource to a wide range of possible clients as well as your own including complex functionality. An example might be a document management system. In this case you should place your business methods behind a suitable Session Facade. An example would be using Session EJBs, but you could also use Spring. In both cases your business methods can be automatically converted into WSDL definitions and web services end points. You own client can use GWT RPC to access the same business methods directly (i,e using local references) which is much faster. 4) You have a number of separate business systems within your organization, and you want to offer services over the web that use these systems in various combinations. In this case you would probably want to base everything (i.e. both your own client and your public third party services) around an ESB architecture. > 2) What about Restlets+GWT Some people like REST per se. If your server architecture is Java based, IMO opinion GWT RPC is the optimum. > 3) Do I need to expose JSON or SOAP interfaces for web services only > if I've to expose functionalities to third party web sites, as you > said, or they can be useful anyway? > I cannot think of any reason to implement SOAP interfaces except to expose a service to a third party. Some people like JSON per se to communicate with AJAX client. For me, if I have a a business process that outputs a result as, say, a List of Java domain objects, then why on earth would I want to transform them into JSON format to send to my own GWT client when I would then have to laboriously change them back into the original Java domain objects again? Why not just send the original objects over GWt RPC? > 4) What about SOAFaces for GWT-ESB integration? I think that depends on your chosen ESB > > Thank you > > 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 -~----------~----~----~----~------~----~------~--~---
