Invoking a GWT servlet from a java application

[Antonio Leonforte]

Hi, we have created a pretty complex web application using GWT. For
stress-testing purposes we would like to create a java program
"pretending" to be the browser running the real JS client, that is,
issuing http requests the way the real JS client would do within a
browser.

Ideally, we need a sort of proxy-generator getting as an input the
interface of the services available server-side and generating for us
the full java code of the proxy.

Does such a proxy-generator exist ? Is it there another way to easily
invoke GWT services from a java application ?
Thanks.

Antonio.

[Gayan Pathirage]

This will not clearly address your problem.

But you can simulate user inputs using Chickenfoot (End user
programming tool for Firefox by MIT)

its pretty good tool and easy to use



On May 2, 11:23 pm, Antonio Leonforte <antonio.leonfo...@fhoster.com>
wrote:

[jsantaelena]

I'm iteresting on it too. If we want to share a GWT servlet with other
non-GWT applications, we can adopt the GWT "RPC protocol" as ours
application protocol. What you think about it guys?

[Carl Scott]

@see
http://gogocarl.blogspot.com/2008/04/internet-alternative-to-gwts-rpc.html

It sounds like you're pretty deep into development at this point, but
issues like these are exactly why I feel like you're digging a grave
with RPC, versus something like the above which would suit your exact
purposes.

My input, though, is that I feel like since a means already exists,
though outside the scope of RPC, I don't see an implementation coming
any time soon. I would turn to some third-party emulation resources
like Gayan suggested, or could you not just write a separate GWT class
that invokes these RPC calls within the scope of your client?

--
Carl Scott
Software Developer, Solertium Corporation



On May 2, 2:23 pm, Antonio Leonforte <antonio.leonfo...@fhoster.com>
wrote:

[gregor]

Hi Antonio,

I think creating your own stress test environment would be non-trivial
to say the least, but there are plenty of tools designed for the
purpose, although in practice I've found they are not that easy to
use. Theoretically there should be no problem stress testing GWT RPC -
any of the these tools should be able to record the RPC requests for a
test case and play them back.

http://www.radview.com/
http://www.proxy-sniffer.com/
(NB: there's some good video tutorials on this next one)
http://www.neotys.com/load-testing-tool/demo.html
http://jakarta.apache.org/jmeter/

However this post from last year indicates that JMeter appears to be
mangling the GWT RPC requests somehow, and no resolution is posted:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/df7f936f8d13f79f/d8fcb875f90f414e?lnk=gst&q=stress+test+RPC#d8fcb875f90f414e

That doesn't mean, of course, that JMeter will still do this with GWT
1.4x or 1.5. Nor does it mean the commercial tools will either.

There is one problem I can think of with GWT RPC in relation to this:
most stress testers enable you to inject random request parameters
(e.g. from some source file) into the requests to simulate realistic
use conditions (different id's etc). GWT RPC does not AFAIK use
parameters - AFAIK all the data is embedded in the main request body
(i.e. in the transferred Java object representations). It may make it
tricky to simulate typical loads without creating dozens of individual
test scripts for the same basic use cases as I can't see how these
tools could inject variable elements into GWT's RPC protocols.

regards
gregor


On May 4, 12:40 am, Carl Scott <carl.sc...@solertium.com> wrote:
> @seehttp://gogocarl.blogspot.com/2008/04/internet-alternative-to-gwts-rpc...

[Antonio Leonforte]

Hi, thank you all.

Using browser extensions like Selenium or Chickenfoot might be good
for functional testing, but it's practical for stress and load
testing, because it would need to run one browser for each individual
user you want to simulate, which is inefficient in terms of resources
and even a bit complicated to orchestrate. Even coding a fake GWT
client for testing purposes would suffer from the same problem.

We have been investigating on RPC sniffing/playback tools (like Jmeter
and others). As far as I understand, with these tools you can somehow
tamper the pre-recorded RPC calls and replace simple stuff like the
session Id. Unfortunately, our GWT application requires and returns
quite complex parameters, and it's really not trivial to alter them in
pre-recorded RPC calls (and that's a must, for instance when you have
to delete new objects generated by previous calls, whose ID has been
assigned by the server).

I only see two ways out...
1) Google releases a java-proxy generator, ie a code generator taking
the GWT service interface as an input and generating the full code of
a java proxy (the equivalent of a CORBA or RMI stub)
2) We open-up our GWT server side by using a more open approach like
RestLet, as suggested by Carl

It would be really interesting to hear something from the GWT staff,
because I don't think we are the only ones who need to invoke GWT
services from a plain java application...

Antonio Leonforte
fhoster.com

[Jose Santa Elena]

I'm iteresting on it too. If we want to share a GWT servlet with other non-GWT applications, we can adopt the GWT "RPC protocol" as ours application protocol. What you think about it guys?

[mP]

This is the wrong approach - there is no sensible reason or need to
use the gwt rpc protocol

Your gwt rpc servlet should forward all requests to the impl class. If
you need to call the rpc from other non gwt clients create one could
create a web service that also calls the same target impl class. If
there are needs for other clients add a facade and have it eventuyally
call your impl. The only common denominator in all the above use cases
is the impl class, this should not include gwt rpc.

[Kazimierz Pogoda]

On Mon, May 5, 2008 at 11:19 PM, mP <miroslav...@gmail.com> wrote:
>
> Your gwt rpc servlet should forward all requests to the impl class. If
> you need to call the rpc from other non gwt clients create one could
> create a web service that also calls the same target impl class. If
> there are needs for other clients add a facade and have it eventuyally
> call your impl. The only common denominator in all the above use cases
> is the impl class, this should not include gwt rpc.

We are planning a project, where we are using the same RPC interface
for GWT app and for RMI client. In the beginning I though it would be
the most convenient to use GWT RPC service directly from Java client.
Eventually I found that there is no such possibility.

Then I realized being wrong in my assumptions. GWT RPC protocol is
strongly bound to HTTP protocol. For example client request
authorization is based on HttpSession. We want to have analogous
mechanism in RMI code, probably implemented with help of JAAS.

We came to exactly the analogous solution you are proposing here -
separate RMI and GWT RPC remote services being facade (with
authorization control) to some general target implementation.

The main obstacle now is how to implement authorization control for
specific GWT RPC methods. We cannot use something like acegi filter
before the request hits GWT RPC service. We are thinking about
extending RemoteServiceServlet adding JAAS authorization on method
level there.

--
"Meaning is differential not referential"

kazik 'morisil' pogoda
http://www.xemantic.com/ http://blog.xemantic.com/

[Antonio Leonforte]

Hi Mp,
the point for us is *not* making our target implementation available
to non-GWT clients. Our objective is to stress/load test the *entire*
server-side, including the GWT servlet and how it dispatches calls to
the target implementation classes. The solution you propose is not
good for us, because it would not test the entire server-side as it
would work in production, but just the target implementation classes
(through a fake web-service that would never exist in production).

I believe that it is a good practice to test *exactly* what you are
going to put into production, as a black box, so I don't want to add a
new interface beside GWT-RPC just for the sake of testing... I hope
you see my point.

What we are doing now is creating a fake GWT client programmatically
generating custom GWT-rpc calls. Then we open multiple independent
instances of firefox with the "-no-remote - P profile" options. This
way we can simulate a few dozens of concurrent users, but that's
really a primitive way to stress test. Again, having a java-proxy
generator for a given GWT service would be much better for us...

[gregor]

Hi Antonio,

A bit more info you might be interested in:

1) I did some tests on RPC call times recently, the results posted
here:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/b6c60ad593dd66cb/59a6056f21e3f929?lnk=st&q=GWT+1.5M2+RPC#59a6056f21e3f929

Note that the results are very, very different in different
situations, so there is obviously "stuff" going on behind the scenes.
If you try to mimic the calls, you would have to be certain that the
mimic was a true reflection of live deployed running performance which
might not be easy. Also note that the speed of GWT RPC when deployed
is very fast.

2) I came across this video cast from a guy in Yahoo in which his main
point is that "from the user's perspective" (which may be very
different from the reality) server calls amount to aprox 5% of wait
times for web page. The other 95% is caused by work done by in browser
itself.

http://www.contenttype.org/blog

regards
gregor



On May 6, 9:50 am, Antonio Leonforte <antonio.leonfo...@fhoster.com>
wrote:

[Kevin VanDenBreemen]

I agree with Antonio. Despite what the user's experience might be on
account of the overhead of in-browser execution of javascript, a
stress test on the server-side application tier that a GWT app
interacts with is most critical to a performance test. As I and my
team see things, Google can and should take care of making sure GWT's
javascript performs well enough to be competitive with other client-
side widget API's out there. But it is we the developers of GWT
applications that need to be able to test our own RemoteServiceServlet
extensions to ensure they perform well.

Even if only 1 percent of the the user experience time is taken up by
RPC calls, if there is a significant enough number of users browsing
the site that number will grow. As it stands, Google's RPC protocol
is so opaque that it is nearly impossible to test. Instead, the only
option available is hammering the servlets with a series of pre-
recorded requests and hope that the results will be telling enough to
uncover performance lags. This is not how a serious web development
company's testing team conducts itself.

On May 6, 1:31 pm, gregor <greg.power...@googlemail.com> wrote:
> Hi Antonio,
>
> A bit more info you might be interested in:
>
> 1) I did some tests on RPC call times recently, the results posted
> here:
>

> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

>
> Note that the results are very, very different in different
> situations, so there is obviously "stuff" going on behind the scenes.
> If you try to mimic the calls, you would have to be certain that the
> mimic was a true reflection of live deployed running performance which
> might not be easy. Also note that the speed of GWT RPC when deployed
> is very fast.
>
> 2) I came across this video cast from a guy in Yahoo in which his main
> point is that "from the user's perspective" (which may be very
> different from the reality) server calls amount to aprox 5% of wait
> times for web page. The other 95% is caused by work done by in browser
> itself.
>
> http://www.contenttype.org/blog
>
> regards
> gregor
>

> On May 6, 9:50 am, AntonioLeonforte<antonio.leonfo...@fhoster.com>