Best practice to implement Command Pattern RPC on server?

[Herme Garcia]

Hi,

After listening carefully Google IO's session from Ray Ryan about
"Best Practices For Architecting Your GWT App" :

http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkitBestPractices.html

He suggests a command pattern implementation for RPC calling (see
slides 21-25) they are using in Wave.

But, how to implements the service interface for multiple rpc
methods ?

this is the Ray's sample interface :

interface ContactsService extends RemoteService {
<T extends Response> T execute(Action<T> action);
}

How?, ¿one class per rpc method?, ¿redirect using instanceof?, ... any
better idea?

Best Regards

Herme

[Eric]

On Jun 25, 5:12 pm, Herme Garcia <hgar...@peoplecall.com> wrote:
> Hi,
>
> After listening carefully Google IO's session from Ray Ryan about
> "Best Practices For Architecting Your GWT App" :
>

> http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkit...

>
> He suggests a command pattern implementation for RPC calling (see
> slides 21-25) they are using in Wave.

Ray,

If you're reading this, can you tell us if the full code for your
contact
manager is available anywhere? Also, the second of the "Contact
DIsplay UI"
slides has the line

currentContactId = currentContactId;

[ClusterCougar]

I thought I posted this last night, but I don't see it. Apologies if
this is a dupe.

I've tried to implement the command pattern using generics, but have
some hangups. You can see my code at

http://code.google.com/p/gwt-command-pattern/

Hangups:

1) Too many parameters. It's just not pretty
2) I have to parameterize the RPCServiceAsync at the class level,
whereas I would like to parameterize at the method level. This is a
constraint of the compiler.
3) All my server-side code actually resides on the client side,
because of the aggressive nature of the GWT compiler. I would add my
voice again asking for a simple annotation or annotations like

on a class: @GWTIgnoreReference(ServerSideClass.class)
and/or a method: @GWTIgnoreMethod

I think there are many justifiable use cases for this type of thing,
and I can't think of any way it would decrease user experience. Does
anyone know if this is a planned feature? Any comments/suggestions on
how to remediate the problems above that I don't know of? Ray Ryan,
are you listening?

Thanks,

On Jun 25, 4:07 pm, Eric <erjab...@gmail.com> wrote:
> On Jun 25, 5:12 pm, Herme Garcia <hgar...@peoplecall.com> wrote:
>
> > Hi,
>
> > After listening carefully Google IO's session from Ray Ryan about
> > "Best Practices For Architecting Your GWT App" :
>
> >http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkit...
>

> > He suggests acommandpatternimplementation for RPC calling (see

[David Peterson]

Hey ClusterCougar,

I think your implementation is over-complicated. On the client side,
just stick to two basic interfaces (and concrete implementations there-
of) - Action and Result (I'm using 'Result' rather than 'Response'
because that is often used in HTTP-related APIs), or in your API,
IProcedure and IReturn. The IAttributes, IRemoteProcedure and other
interfaces are unnecessary.

Then, on the server side, I've got 'ActionHandler' classes, which look
something like this:

public interface ActionHandler<A extends Action<R>, R extends Result>
{
public Class<A> getActionType();

public R execute( A action ) throws Exception;
}

You then register your various ActionHandler instances with your
'RPCService' and it just matches up the action passed in with the
appropriate action handler, calls execute and you're off to the races.

Sorry about the incomplete example - the code itself is tied up in the
app I'm using this in at the moment. I hope to make it a bit more
general down the track.

David

> > > "Best PracticesFor Architecting Your GWT App" :

[ClusterCougar]

Thanks David. That looks like a much better solution. The only reason
I did all those generics was because I was still trying to wrap my
head around the problem. Based on this, I've come up with some ideas
I'm going to try to implement. How do you register your
ActionHandlers?

On Jul 3, 8:55 am, David Peterson <da...@randombits.org> wrote:
> Hey ClusterCougar,
>
> I think your implementation is over-complicated. On the client side,
> just stick to two basic interfaces (and concrete implementations there-
> of) - Action and Result (I'm using 'Result' rather than 'Response'
> because that is often used in HTTP-related APIs), or in your API,
> IProcedure and IReturn. The IAttributes, IRemoteProcedure and other
> interfaces are unnecessary.
>
> Then, on the server side, I've got 'ActionHandler' classes, which look
> something like this:
>
> public interface ActionHandler<A extends Action<R>, R extends Result>
> {
>    public Class<A> getActionType();
>
>    public R execute( A action ) throws Exception;
>
> }
>
> You then register your various ActionHandler instances with your
> 'RPCService' and it just matches up the action passed in with the
> appropriate action handler, calls execute and you're off to the races.
>
> Sorry about the incomplete example - the code itself is tied up in the
> app I'm using this in at the moment. I hope to make it a bit more
> general down the track.
>
> David
>
> On Jun 30, 8:05 pm, ClusterCougar <nwwe...@gmail.com> wrote:
>
>
>
> > I thought I posted this last night, but I don't see it. Apologies if
> > this is a dupe.
>

> > I've tried to implement thecommandpatternusing generics, but have

[David Peterson]

There are a couple of ways to go about it, and I'm not 100% happy with
my current solution as a 'best practice'. It's a bit convoluted,
really. Current I'm using Guice on the server-side, so I bind them to
'ActionHandler.class', and then a post-config step pulls all
ActionHandler bindings and registers them to my ActionHandlerRegistry.

Binding code:

binder.bind( ActionHandler.class ).annotatedWith( Names.named
( type.getName() ) ).to( type ).in(
Singleton.class );

Linking code:

List<Binding<ActionHandler>> bindings = injector
.findBindingsByType( TypeLiteral.get
( ActionHandler.class ) );

for ( Binding<ActionHandler> binding : bindings ) {
actionHandlerRegistry.addHandler( binding.getProvider().get() );
}

A simpler way would be to have an eager singleton which is provided
the actionHandlerRegistry via injection and just adds whatever
handlers you want to it.

David

[David Peterson]

Just a couple of other comments on this general topic.

1. Yes, it's one-class-per RPC method. This is actually a good thing,
since it lets you do item 2, which is:
2. You can add 'undo' to your actions. This is particularly handy if
you build your Action classes using item 3:
3. You can have one action which executes multiple other items. This
means you're using the command pattern on the server side too, not
just from the client side.

When you add them all together, most of your actual functionality is
encapsulated in command/action classes. I use the same service
implementation on the server side as the client side, so there is
really just one shared service now (I call it 'Dispatch') rather than
having various services for different application functions.

But for me, the biggest win is 'undo' - it's essentially like having
transactions for Java code, not just database code. Not quite as
bullet-proof, since some actions can't actually be undone, but a big
step in that direction.

I will see if I can get the code abstracted enough from my app to post
it publicly.

David

[Herme Garcia]

David,

Thank you for your help,

How is "type" related to getActionType method on ActionbHandler
interface?, do you have different services?

Herme

On 4 jul, 03:51, David Peterson <da...@randombits.org> wrote:
> Just a couple of other comments on this general topic.
>
> 1. Yes, it's one-class-per RPC method. This is actually a good thing,
> since it lets you do item 2, which is:
> 2. You can add 'undo' to your actions. This is particularly handy if
> you build your Action classes using item 3:
> 3. You can have one action which executes multiple other items. This

> means you're using thecommandpatternon the server side too, not

> just from the client side.
>
> When you add them all together, most of your actual functionality is

> encapsulated incommand/action classes. I use the same service

[traneHead]

Thanks both to David and ClusterCougar for your efforts!

I've also been struggeling with this for a while now and got something
similar to the command model Ray Ryan described it in the talk.

Your version of it David, with the undo-functionality, sounds very
interessting though. I'd be very interested to see some version of it
if you have the time.

Thanks!

[Jason A. Beranek]

David,

The Apache Shindig project (reference implementation of OpenSocial)
provides another approach for registering ActionHandlers. The Shindig
OpenSocial API code uses a HandlerDispatcher to dispatch Action
handling (as opposed to using the Servlet to do this directly). For
application specific registration, you'd write an Application specific
HandlerDispatcher and inject that Dispatcher into your RPC Servlet.
Your RPC Servlet would then do any initial processing on RPC calls,
and then retrieve the ActionHandler from the dispatcher and handle the
request. In this case, as you build new Actions you simply add a new
Handler (or update a previous one to Handle the new action, as
desired).

I haven't tried implementing this same approach, but I don't see any
issues with it at this point. Note that Shindig goes a bit farther as
their Handlers pass of most processes to a Service Provider Interface
that can be replaced with concrete implementation.

You can find the source I referred to at the Shindig SVN repository
(http://incubator.apache.org/shindig/source-repository.html) in /trunk/
java/social-api/src/main/java/org/apache/shindig/social/.

Cheers,

Jason

[Jason A. Beranek]

All,

Ok, just relooked and apparently the approach I described above was
part of the 0.8 Shindig release, not the current 0.9. The pattern is
still similar, but the implementation is a bit more confusing if you
look at the Shindig code directly. Other than the references above to
the Shindig source locations, the approach for the most part still
stands (the code is just built with more complex dependency
injection).

Respectfully,

Jason

[David Peterson]

Jason: I'll admit I was unable to figure out exactly what Shindig's
approach is, exactly, unfortunately. However there is definitely more
than one way to skin this cat. My current implementation an Action, a
Result and a Handler for each operation. This does result in some
class proliferation, but has the upside of having everything nicely
self-contained.

In my implementation, I actually have a 'Dispatch' class which can be
injected directly, and a separate DispatchServiceServlet which is also
injected the same Dispatch instance and provides access from GWT/RPC.

To hold you over while I get the code sorted, here is a simple example
of what an action/result/handler looks like:

It's just a concrete implementation of ActionHandler. Essentially,
each Action/Result has a single ActionHandler that does the actual
execution on the server side.

getActionType() returns the concrete Action subclass that the handler
supports. For example, a 'Get User' operation might look like this:

public class GetUser implements Action<GetUserResult> {
private String name;

// For serialization
GetUser() {}

public GetUser( String name ) {
this.name = name;
}

public String getName() {
return name;
}
}

public class GetUserResult implements Result {
private User user;

// Serialization
GetUserResult() {}

public GetUserResult( User user ) {
this.user = user;
}

public User getUser() {
return user;
}
}

// This class is server-side only
public GetUserHandler implements ActionHandler<GetUser, GetUserResult>
{
private final UserDAO dao;

@Inject
public GetUserHandler( UserDAO dao ) {
this.dao = dao;
}

public Class<GetUser> getActionType() {
return GetUser.class;
}

public GetUserResult execute( GetUser action ) throws Exception {
return new GetUserResult( dao.getUser( action.getName() ) );
}
}

A very simple example, and the actual 'getting' code is wrapped in the
DAO in this case. It could equally be coded directly in, or hooking up
to a non-DB service. Depends how you want to implement it.

David

[Herme Garcia]

Hi,

I have been playing a while, and I like Dave Peterson's, even with
that class proliferation, I wrote a simple (and incomplete) example
code:

http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pattern-on-server.html

Thanks

[Nathan Wells]

I updated my project to only use the two interfaces as suggested by
David. Instead of using actionhandlers and registering them, I created
an annotation for the IRemoteProcedureCall implementations that
contains the canonical class name of the IProcedure that is to be run
on the server.

I'm very open to suggestions. Let me know what you think :)

http://code.google.com/p/gwt-command-pattern/

On Jul 4, 8:17 am, Herme Garcia <hgar...@peoplecall.com> wrote:
> Hi,
>
> I have been playing a while, and I like Dave Peterson's, even with
> that class proliferation, I wrote a simple (and incomplete) example
> code:
>

> http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat...

[David Peterson]

Hi all,

I extracted the command-related code from my current project and have
posted it here:

http://code.google.com/p/gwt-dispatch/

The original code was working fine, but I haven't had a chance to
test it since it was extracted from the project. It does compile,
although you will currently need Java 1.6 to compile it (even though
it is compiling in 1.5 class/source compatibility mode). There is only
one section of generics-related code that requires 1.6 (you'll figure
it out quickly if you check it out and build with 1.5), so if anyone
can provide a patch I'll be happy to slap it in.

There is also a short example on how to build an action/result/handler
and wire it in via Guice/GIN. That can be had here:

http://code.google.com/p/gwt-dispatch/wiki/GettingStarted

I'll be hooking this library into my current project next week, so
expect to see some minor adjustments and bug fixes, but it should be
fairly stable.

Enjoy!

David Peterson

[martinhansen]

Can someone explain how this is useful? I don't know what a command
pattern is. Why should I use command patterns and not the traditional
way? What is the difference? At first look, this seems to be a lot
more complicated, so I'm a little confused.

[Nathan Wells]

For general information and benefits of the Command Pattern, see this
article:

http://en.wikipedia.org/wiki/Command_pattern

GWT has some additional quirks that would make an abstracted command
pattern nice, but I can see how you could say the added complexity
might detract from those benefits.

On Jul 4, 2:18 pm, martinhansen <martin.hanse...@googlemail.com>
wrote:

[David Peterson]

Yeah, there is some added complexity, however I found myself basically
implementing it in a much more ad-hoc fashion anyway, it's just that
some operations required a 'token' object with multiple parameters, or
returning another token with multiple return values, and some didn't.
This way, it's more consistent, and there is the benefit of undo and
more fine-grained testing.

For this project it was an experiment as much as anything, but from
the experience I generally think there are more benefits than
downsides, even for server-side-only projects. It definitely fits well
with the DI-style of configuration.

Each to their own though - it really is mostly a matter of taste.

David

[David Peterson]

Hi Nathan,

On Jul 5, 2:15 am, Nathan Wells <nwwe...@gmail.com> wrote:
> I updated my project to only use the two interfaces as suggested by
> David. Instead of using actionhandlers and registering them, I created
> an annotation for the IRemoteProcedureCall implementations that
> contains the canonical class name of the IProcedure that is to be run
> on the server.

As you say, one of the downsides of linking the handler to the
concrete implementation is that there may be issues with the GWT
compiler. That said, in general it seems to mostly ignore attributes,
so it may not be an issue.

The other downside for me is that it ties the action interface to a
specific implementation. This makes it more difficult to write mocks
for tests, etc. Having them configured purely on the server-side means
you can replace them with whatever you like on in test scenarios. Or,
if you want to provide alternate implementations (eg. JDO vs
Hibernate), you can have both in your app and just switch between them
by changing your DI configuration.

The downside of my method is that you may forget to actually implement
the handler. Of course, this will generally show up pretty quickly
when you try to actually use it. And I guess it's still quite easy to
forget to supply the annotation anyway...

David

[martinhansen]

Hello David,

I've read your source code and your example. It is very interesting.
But although it's short and simple, I still don't understand it.
Especially "GIN" and "GUICE" confuses me a lot. Can I use your example
without these technologies?

Does anyone know a really simple example? The example in Ray's sheet
is interesting and simple, but incomplete. Where does the actual
action take place in his example, let's say, querying some contact
details from a remote data base? I think this important part is
missing.
The ContactService defines a method called "execute", but where is
this method implemented? Is it implemented automatically by some
mechanism? If yes, how is it done? Is "execute" the only method in the
interface I ever need, e.g. some kind of place holder?

Any help would be greatly appreciated.

[Herme Garcia]

Martin,

For really simple example, look at

http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pattern-on-server.html

This is really simple, far from complete, but you can see how the
pattern works

Herme

On Jul 5, 10:16 am, martinhansen <martin.hanse...@googlemail.com>
wrote:

[David Peterson]

On Jul 5, 6:16 pm, martinhansen <martin.hanse...@googlemail.com>
wrote:

> Hello David,
>
> I've read your source code and your example. It is very interesting.
> But although it's short and simple, I still don't understand it.
> Especially "GIN" and "GUICE" confuses me a lot. Can I use your example
> without these technologies?

You can use the classes directly, but if you can figure out Guice, it
will save you a fair bit of work in the long run. There is a bit of a
learning curve though. The main things you will need to configure if
you want to do it manually:

Server side:

Provide an instance of 'ActionHandlerRegistry' and 'Dispatch' (you can
use 'DefaultDispatch' for a simple implementation) as a singleton:

public class MyManager {
private static final ActionHandlerRegistry REGISTRY;
private static final Dispatch DISPATCH;

public static Dispatch getDispatch() {
if ( DISPATCH == null ) {
REGISTRY = new DefaultActionHandlerRegistry();
DISPATCH = new DefaultDispatch();
REGISTRY.addHandler( new MyCustomHandler() );
REGISTRY.addHandler( new MyOtherHandler() );
}
return DISPATCH;
}
}

You will also need a subclass of 'DispatchServiceServlet'. Eg:

public class MyDispatchServiceServlet extends DispatchServiceServlet {
public MyDispatchServiceServlet() {
super( MyManager.getDispatch() );
}
}

Then hook that up in the appropriate place for your GWT connection.

On the server side, you just need an instance of 'DispatchAsync'.
Again, 'DefaultDispatchAsync' should do the trick. Eg:

private final static DispatchAsync DISPATCH = new DefaultDispatchAsync
();

Provide an accessor for that to your other classes and off you go.

David

[hgarciag]

Martin,

For really simple example you can see here:

http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pattern-on-server.html

At the end, you will need to add some more code, but you can see how
the pattern works (it helped me!)

Herme



On Jul 5, 10:16 am, martinhansen <martin.hanse...@googlemail.com>
wrote:

[martinhansen]

Hello Herme,

your example is very interesting. I downloaded it and changed it to
work with GWT. But I was not successful. When I run my application,
the compiler complains about my client service interface:



[ERROR] Type 'com.isp.gwtpattern.client.rpc.Response' was not
serializable and has no concrete serializable subtypes



The code is as follows:



@RemoteServiceRelativePath( "buchungServlet" )
public interface BuchungService extends RemoteService {

<T extends Response> T execute(Action<T> action);

}

What am I doing wrong here? My interfaces "Action" and "Response" both
implement IsSerializable.


M

On 5 Jul., 11:55, hgarciag <hgarc...@gmail.com> wrote:
> Martin,
>
> For really simple example you can see here:
>

> http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat...

[martinhansen]

Grrrrrrrrr!

I found out why! Grrrrrrrrr!

The Action and Response classes must have an empty default constructor
to be serializable. I've had this error before. Unfortunately, the GWT
compiler error message is anything but helpful in this case. Grrrr.

[martinhansen]

Hello Herme,

now it finally works. I've used your great and simple example and
created a simple GWT application from it to check a user name and a
password. For anyone interested, I've uploaded the sample application.
It's essentially the same, just using GWT.

http://rapidshare.de/files/47769639/GWTPattern.zip.html

On 5 Jul., 11:59, Herme Garcia <hgar...@peoplecall.com> wrote:
> Martin,
>
> For really simple example, look at
>

> http://itsp.typepad.com/voip/2009/07/gwt-implementing-rpc-command-pat...

[David Peterson]

Yeah, that took me a while to figure out too - I do mention that on
the 'Getting Started' example for gwt-dispatch. Better error messages
would definitely be helpful...

David

On Jul 6, 8:17 pm, martinhansen <martin.hanse...@googlemail.com>
wrote:

[jdwy]

Thought I'd point to my command pattern examples:
http://github.com/jdwyah/tocollege.net/tree/f97ed4ff3f31c1c463eb426c34a55de439c601b3/src/main/java/com/apress/progwt/client/domain/commands

I found the command pattern to be just the ticket to deal with XSRF
attacks. In the directory above you can see my AbstractCommand class
and a number of Command subclasses. I ended up creating a
CommandService class as well, which would have different affects on
the client and server (basically it would persist entities when on the
server and just execute logic when on the client).

Cheers,
-Jeff



On Jul 6, 6:17 am, martinhansen <martin.hanse...@googlemail.com>
wrote:

[Nathan Wells]

I think this is mostly directed at David, but if anyone has answers,
I'd welcome them.

In your command pattern implementation or somewhere on this thread
(can't remember where I saw it) you mention that GWT doesn't properly
implement parameterized method calls on the RPC service. Is that true,
or did I misunderstand something? I think you also mentioned that that
is in fact desirable, since you would want one service per procedure
call. Can you explain that a little more? I'm not sure I understood.

Oh, and I updated my annotation to take a Class<?> rather than a
String literal, thanks for the tip.

On Jul 6, 9:06 am, jdwy <jdw...@gmail.com> wrote:
> Thought I'd point to my command pattern examples:http://github.com/jdwyah/tocollege.net/tree/f97ed4ff3f31c1c463eb426c3...

[David Peterson]

Hi Nathan,

On Jul 7, 7:24 am, Nathan Wells <nwwe...@gmail.com> wrote:
> I think this is mostly directed at David, but if anyone has answers,
> I'd welcome them.
>
> In your command pattern implementation or somewhere on this thread
> (can't remember where I saw it) you mention that GWT doesn't properly
> implement parameterized method calls on the RPC service. Is that true,
> or did I misunderstand something? I think you also mentioned that that
> is in fact desirable, since you would want one service per procedure
> call. Can you explain that a little more? I'm not sure I understood.

Essentially, I couldn't get the GWT compiler to work with a service
with the following definition:

public interface DispatchService extends RemoteService {
<A extends Action<R>, R extends Result> R execute( A action )
throws Exception;
}

It was complaining about generic method matching, which I am guessing
means that whatever magic is going on with generators for
RemoteServices doesn't correctly handle having the '<A extends
Action<R>, R extends Result>' parameter generic definition. It works
fine if I just make it:

Result extends ( Action<?> action ) throws Exception;

But I lose the handy type-casting from this one.

Anyway, the workaround I have works ok, it's just a little less
direct. No big deal...

> Oh, and I updated my annotation to take a Class<?> rather than a
> String literal, thanks for the tip.

Ah, ok. Glad it's working :)

David

[pohl]

> Essentially, I couldn't get the GWT compiler to work with a service
> with the following definition:
>
> public interface DispatchService extends RemoteService {
>     <A extends Action<R>, R extends Result> R execute( A action )
> throws Exception;
>
> }

I tried to do the same thing, inspired by Ray Ryan's talk at Google I/
O.

Did you file an issue to track this defect? In my opinion, the
Javascript compiler should do the right thing if it can.

Perhaps this is the same as Issue 2374?

http://code.google.com/p/google-web-toolkit/issues/detail?id=2374

[Peter]

When you run your web app in hosted mode, specify a log level of
SPAM. The gwt compiler will then be more helpful - it will generate
detailed messages about what is wrong with your class. In particular
it will tell you if you're missing a default constructor or if you
forgot to implement IsSerializeable. If you are using the google
eclipse plugin you can change this on the GWT tab of the run
configuration you are using. If you are running it manually you'll
probably have to mess with the debugLevel parameter.

On Jul 6, 5:17 am, martinhansen <martin.hanse...@googlemail.com>
wrote:

[David Peterson]

Yeah, that looks like the same issue.

That said, it probably wouldn't change the design too much if the bug
wasn't there - there are some other reasons to have DispatchAsync as a
separate class anyway, including but not limited making it easier to
inject via Ginjector.

David