Best pattern for client/server communication?

[eibaan]

I created a POJO model class which server and client share for my
RemoteService. This works great as long as I do not want to add other
methods. I'd love to add more business logic, but this logic is only
useful for the client. Later, I might also have the case that I need
methods only for the client.

Can I somehow annotate methods to be server-only or client-only? Can I
somehow split the class definition between client and server? Or
should I use different classes on the server and the client side? The
server side objects would probably then clone the client version from
there state and I'd need a mechanism to resync the server state if I
get back a modified client side object via the RemoteService.

What's the best pattern here? The shared class is simple but can it be
used in "real" production code? Do I really need to create data
transfer objects with all that dreaded boilerplate code?

Any ideas or pointers to common pattern would be helpful.

Thanks
Stefan

[Kwhit]

I don't have a boilerplate pattern available as I'm still
experimenting myself. There seems to be two schools of thought:

1/ Try and reuse classes on both server and client sides which means
exporting server logic to clients and vice versa

2/ Separating client and server logic and evolving the two separately

At first I tried to do the former but I didn't like it: it's just not
clean IMHO.

What I'm trying to do now is focus on the service interface offered by
the server to the client. Using Google App Engine helps this
discipline. I define the service interface in terms of actions:
'Create new user', 'Transfer X from account x to account y', 'Get
Employee details'. I'm at the frustrating phase that there's a lot of
similar objects on both sides of the fence. But, over time, I'm seeing
these diverge and evolve differently solving their own use cases
without the restraint of trying to maintain a one-size-fits-all
approach.

In many of my core server-side and persistent objects: Employee,
Account, etc., I have/had a method: EmployeeVo Employee.toVo(): i.e.
to value object (as opposed to toString()). But, as my use cases
become more refined I find that things evolve to having a Person
object with toUserVo(), toEmployee() and toCustomerVo() methods that
create client side objects that are shipped out to log in, update
employee details or have a customer select a shipping address.

I love these types of problems - that's what makes programming so much
fun.

[hazy1]

I typically share as much as possible. If it has to be different then
subclass for the server-side only stuff and don't compile the subclass
on the client.

[David Peterson]

My approach is basically along the lines of #2. However, taking it a
step further, my rule is essentially to remove all operational code
from data objects completely. So, no 'save()' methods, etc on the
actual object. Instead, you would call a 'save( myObject )' method on
the service instead. That way, you can easily share the data objects
on both server and client, and all business logic sits on the server
side.

David