Java Version of GWT-RPC
Mike Wannamaker
want to have a Swing app version of it, I don't want to have to recreate
WebServices versions and I don't want to have to tell the client to open
up an RMI port. Couldn't I just use a JAVA version of the RPC call?
Why can't the java version just serialize the objects like the
javascript version does and send it to the client via HTTP? Has anyone
done this? And if so could they share?
Thanks
Mike
k-e-n
BIG QUESTION : are you trying to communicate from GWT and SWING to the
SAME server instance?
I have written an application which comes in two version, 'stand-
alone' Swing application and a GWT 'web-application'
The two UI implementations call the same code libraries.
I have it slightly easier than you in that the Swing version is
directly linked to the 'back-end' code, but moving to client/server
for the Swing version is not to difficult.
Obviously if you want a client/server Swing application you MUST have
some communication between the Swing 'client' and the Java 'server'
code.
RMI would seem a reasonable candidate for this, or JMS or anything
else that your server code supports.
Overall it is just a matter of keeping clear boundaries between UI
code and the code that does the 'work'.
GWT and Swing have similar widgets and similar event mechanisms, I
first wrote my application in Swing then 'ported' it to GWT.
I would suggest that you keep the interface between client and server
very thin - not a lot of method calls & keep the objects you send/
receive to be reasonably simple (no trees, maps, etc)
Client(XXX) -> Client-RPC(YYY) -> Server-RPC(YYY)-Layer => [request
data] Common Code [response data] => Server-RPC(YYY) -> Client(XXX)
[request data] [request
data]
[response data] [response data]
In one case XXX=Swing with YYY=RMI (or JMS ...)
In the other case XXX=GWT with YYY=GWT-RPC
The in/out layers on the server to handle the RPC either already exist
or should take little work to adapt.
Since the GWT-RPC allows calls from the GWT client to regular Java
code on the server there should be no issue is calling the same
methods from other UIs or anything else.
You can code this either such that the server code has no idea that it
is responding to UI requests & sending responses to a UI (after all
they are just method calls), or you can have some layer of you code be
(slightly) aware of the UI and have it encode the server response as
the new state of the visual world in some data structure which is
neutral to the UI 'implementation'. I have found that this is possible
to do, again it is just a matter of observing strict boundaries
between Model, View and Controller.
Hope this helps
On Mar 23, 12:27 am, Mike Wannamaker <mwannama...@propertyspot.ca>
wrote:
> 1KDownload
Mike Wannamaker
Yes I would like to communicate GWT/SWING client to the same server
instance.
So right now I have something like this.
public interface Resourcer extends RemoteService
{
StringResource getResourcesFor(String sResourceName);
public static class App
{
private static ResourcerAsync ourInstance = null;
public static synchronized ResourcerAsync getInstance()
{
if(ourInstance == null)
{
ourInstance = (ResourcerAsync)GWT.create(Resourcer.class);
((ServiceDefTarget)ourInstance).setServiceEntryPoint(GWT.getModuleBaseURL()
+ "GwtUI_Resourcer");
}
return ourInstance;
}
}
}
I call StringResource sRes = App.getInstance.getResourceFor("",
myJSCallBack); I'd like to be able to do the same thing in my Swing
app, use the existing code, where GWT.getModuleBaseURL() would be
preconfigured at startup and from my Swing app I could make the same
call but provide a different callback for my swing application,
StringResource sRes = App.getInstance.getResourceFor("",
mySwingCallBack);. This would allow me to use my existing GWT-RPC
interfaces and not have to create new ones. But this code gets compiled
to Javascript.
I agree that I should be able to do it, but I think I need the proper
serialization of method calls and returned objects in order for this to
work properly. Just wondering if anyone had done this, or if GWT
supports it natively out of the box.
IE:
GWT Client (browser) -> GWT-RPC on server -> backend business logic.
SWING Client -> GWT-RPC on server -> backend business logic.
Thanks Mike
> --------------------------------
> Spam/Virus scanning by CanIt Pro
>
> For more information see
> http://www.kgbinternet.com/SpamFilter.htm
>
> To control your spam filter, log in at
> http://filter.kgbinternet.com
>
>
>
mP
to the GWT service. Your GWT service should be a simple bridge that
delegates to the actual service implementation. Your service could
also be exposed via rmi so that the GWT client talks GWT RPC whilst
the Swing app talks RMI to the rmi server.
GWT --> GWT RPC --> GWT RPC Servlet ->
----
> Service --> etc
SWING -> ---------------------RMI -------------------->
On Mar 25, 11:11 am, Mike Wannamaker <mwannama...@propertyspot.ca>
> 1KDownload
Mike Wannamaker
Yes my GWT service is just a bridge to the business logic and I know I
could use RMI, or CORBA or WebServices or ...
But I already have a GWT-RPC over HTTP, why should I need another
interface? Clients don't normally like to open up extra ports on their
network just for the RMI App and besides port 80 is already open.
I'd really like to have my java client, use the GWT.create(...) method
and have it return a version of of object that when the method invoked,
serializes the request to GWT-RPC, sets up an appropriate mechanism for
the response and deserialize the response into my java object and make
the callback to my callback handler.
I'd even be happy for the GWT classes that can serialize the request and
deserialize the response objects correctly.
If anyone has done this I'd sure appreciate a response.
Mike Wannamaker
George Georgovassilis
That are all valid points for having a java version of the client RPC
code, I'll add one: unit testing.
On Mar 26, 6:06 am, Mike Wannamaker <mwannama...@propertyspot.ca>
> 1KDownload
walden
available. Java already has a transparent remote object mechanism,
and the only thing you're missing is that you want to tunnel the RMI
protocol through HTTP. JBoss already does that. Done.
Walden
On Mar 26, 1:06 am, Mike Wannamaker <mwannama...@propertyspot.ca>
> 1KDownload- Hide quoted text -
>
> - Show quoted text -
Mike Wannamaker
can serialize the java object in the correct format to do HTTP request
and same for deserializing an HTTP response into a java object.
Mike Wannamaker
Conzar
1) GWT_Client -[RPC]-> GWT_Servlet -[RMI]-> Java_Server
2) Java_Client -[RMI]-> Java-Server
The problem here is that with GWT, you have a wasted extra step that
requires the developer to maintain yet another layer between the
client and server. So the question is remains, is there a way to get
rid of the GWT_Servlet and directly access the RMIRegistry from the
GWT_Client? So this is what I want:
1) GWT_Client -[RMI]->Java_Server
2) Java_Client -[RMI]->Java_Server
As you can see, the network interface is the same for both clients.
I think Mike is asking this though:
1) GWT_Client -[RPC]->Java_Server
2) Java_Client -[RPC]->Java_Server
Its the same idea ... either case, having an extra network layer makes
maintaining the code more difficult .... also I don't think having a
"simple network layer" is the answer. If you have a complicated app
you more often then not have to pass data structures that are more
complex then primitives. I mean, we could code in assembly and
attempt to do networking that way ... but the whole point of Object
Oriented programming is abstraction with objects ... if u can't pass
an object over the network, then use C or assembly.
On Mar 26, 9:13 am, Mike Wannamaker <mwannama...@propertyspot.ca>
> 1KDownload