Well, presumably you've properly versioned you're code so you're properly serializing/deserializing. This is a fundamental problem with deserializing with a different version of code than it was serialized with. It also exists with passing things using JSON or any serialization scheme. I think using JVM serialization results in less code, is more flexible, & is faster than any other scheme.
Don't have much experience with protocol buffers, but http://ahlawat.net/wordpress/?p=185 suggests that their slightly slower although more efficient in terms of bandwidth. If you're not using different languages, it'll result in having to maintain the message format explicitly as opposed to implicitly in your java code. On Thu, Apr 23, 2009 at 10:03 AM, jhulford <[email protected]> wrote: > > Depending on how you're updating your code across your multiple > servers, JVM serialization can be a pain to try and deal with, > especially for code bases that are constantly being updated. > > I don't believe that you'll get far trying to use the GWT RPC stuff in > straight java. If JSON isn't for you, you can also look into something > like protocol buffers as the data interchange format. > > On Apr 23, 9:35 am, Vitali Lovich <[email protected]> wrote: > > Well, I'd imaginge there'd be a serious problem using the GWT > implementation > > - doesn't it use JSNI at points? You could try to write one inspired by > it > > using guice. > > > > The JSON transport is pointeless going between two java servers - just > use > > regular serialization. You'll see much faster performance & you don't > need > > to write any code for that (the JVM takes care of it for you). Also, the > > JVM serialization approach is far more robust & reliable & has less > > restrictions. > > > > For the asynchronous part, you could launch a new thread that establishes > a > > TCP connection & calls back your callback when it's done. > > > > Optionally, you could use UDP datagrams whereby the callback will happen > on > > the event loop. > > > > You still have to of course write thread-safe code either way. > > > > On Thu, Apr 23, 2009 at 4:23 AM, Salvador Diaz <[email protected] > >wrote: > > > > > > > > > Well, server-side code, the RPC implementations, are just normal java > > > servlets so you should be able to do anything your servlet container > > > allows you to do. > > > > > > (I can't > > > > test this code right now because the Google App Engine plugin on the > > > > Mac doesn't seem to run hosted mode correctly). > > > > > On the other hand, the google app engine only allows to use a subset > > > of java 6 so it's possible that your code example won't work without > > > modifications. You can use GWT and GEP without the app engine though > > > so you CAN test the code (just remove the app engine sdk from your > > > project). > > > > > Cheers, > > > > > Salvador > > > > > On Apr 23, 3:59 am, JavaJosh <[email protected]> wrote: > > > > Hello, > > > > > > I actually rather like the GWT RPC API and was hoping to use it for > > > > more than client/server communication - in fact, I want to use it for > > > > server/server communication. Here is some example servlet code: > > > > > > http://gist.github.com/100232 > > > > > > The callService() method would be designed to hit a different server, > > > > of course. > > > > > > BTW the attributes of GWT RPC that I like is the JSON transport, and > > > > the asynchronous API. I also like the idea of dealing with > > > > communications in a more homogeneous way. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
