Your authentication would be better handled outside of GWT (i.e; SSO or form-based login). But for the application itself, that approach sounds reasonable. By putting the SOAP client in a servlet, you have access to a wide range of libraries that you can use to interact with the SOAP services, and you won't have to mess with marshalling/ unmarshalling messages at all. I have seen a lot of projects that use this approach.
You aren't likely to find any "framework" that interacts with SOAP services from the browser. Like gregor said, it would be extremely slow to handle those messages in javascript. You also might consider Applets. On Jan 13, 8:52 am, Paranoid Android <paranoid.fa...@gmail.com> wrote: > Thank you for the tip.. I've looked around the Web for days and I'm > gaining a clearer view about technologies and possible > architectural solution for my requirements. > I'm especially doubtful about the possible integration of techonlogies > like GWT on the GUI and an ESB like servicemix. > ESB seems to be a required component of my solution, but I if I've > understood well the basics of GWT, I've to go through "two level of > indirection" to retrieve data to display, for example, in a GUI > widget. > First an RCP call initiated by the GUI (e.g. authentication on login > of the user) to some business components (servlet). > Than, if authentication is implemented as a web service, this servlet > must interact with the ESB to request the authentication service. What > makes me doubtful is the presence of the "servlet" between the GUI and > the ESB... > > Am I wrong? > > On Jan 13, 2:42 pm, gregor <greg.power...@googlemail.com> wrote: > > > Yes, you can theoretically invoke web services exposed on your server > > directly from GWT client using the GWT HttpRequestBuilder. > > > 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, and particularly to GWT RPC. In other > > words your application will run many times slower, and you will have > > to write hundreds of lines of code to create, serialize and > > deserialize large XML strings. Javascript runs very slowly compared to > > Java, so creating and parsing huge XML messages is a big problem. > > That's why people use JSON instead, and why GWT RPC is provided. Both > > are many times more efficient, both to write and to run, than SOAP. > > > If in any doubt about this, try it yourself. Set yourself a simple > > task like retrieving some user information from your server. Do it > > using an HttpRequest to a SOAP service. Then do it again using GWT > > RPC. Use a timer to measure the response times. Count the lines of > > code used on both server and client. Actualy I got that the wrong way > > round: do it with GWT RPC first, then start doing it with SOAP - it > > won't take long to get the point from just the LOC arguement, so you > > will save yourself some time. > > > On Jan 13, 12:36 pm, Paranoid Android <paranoid.fa...@gmail.com> > > wrote: > > > > Interesting..that's what I was also talking about. > > > The possibility to invoke web services directly from a GWT interface > > > to develop self contained UI gadget in some ways like portlets.. Is > > > this a completely wrong idea or can be useful? > > > > On Jan 13, 1:31 pm, Gabor Szokoli <szoc...@gmail.com> wrote: > > > > > First of all, what he said, I just have a tiny sidenote to add: > > > > > On Mon, Jan 12, 2009 at 7:05 PM, gregor <greg.power...@googlemail.com> > > > > wrote: > > > > >> In few words: is the GUI independent from the SOA choice > > > > > > yes > > > > > >> or is it also > > > > >> exploitable in some ways from the GUI? > > > > > > no - it's "exploitable" from the GWT RPC layer. > > > > > Or you can increase buzzword compliance by invoking a public-facing > > > > web service directly from the GWT client. > > > > We do this to minimize server load and security exposure (we have to > > > > publish the web service anyway.) > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
