Client-Server-Kommunikation
mit dem Command Pattern
p.g.taboada | pgt technology scouting GmbH
Papick G. Taboada
pgt technology scouting GmbH!
http://pgt.de
Orientation in Objects GmbH!
http://oio.de
http://gwtreferencelist.appspot.com
‣ Client-Server communication
‣ Command pattern	

‣ Versioning 	

‣ Batching, Caching	

‣ Scaling
!
eb t
w en
sic pm
las elo
c v
de

Server

Browser

user action
e

ons
html resp
full

user action
po
l html res
ful

nse
...



eb ent
w
IA pm
R lo
ve
de

Server

Browser
first reques

t
e

l respons
full htm

event
event
event

data reque

st

dat...
Honor the A in

JAX

does
‣ Javascript it	

 not block !

Get over

‣ Latency is not a myth	

‣ Results must not arrive in...
BUILDING A GENERIC FRAMEWORK FOR	

MARSHALLING/ UNSMARSHALLING DATA SUCKS

MARSHALLING / UNMARSHALLING 	

IN JAVASCRIPT IS SLOW
DON‘T BIND YOU
NEXT 3 YEARS OF
WORK 

AGAINST SOME
COMMUNICATION
PROTOCOLL

LOADING TOO MUCH
DATA WILL ALWAYS
HURT

‣ Client-Server communication	

‣ Command pattern
‣ Versioning 	

‣ Batching, Caching	

‣ Scaling
GWT-RPC
is a good
solution if
handled
with care

GWT-RPC
binds many
methods
into one
interface

SomeResult someMethodName(...
this will be an object

SomeResult someMethodName(SomeParameter spo)

this will be an object too
the method names bind the requests to the result

SomeResult someMethodName(SomeParameter spo)

typesafety all the way
USING

GENERICS FOR 	

!

TYPESAFETY, 	

!

GET RID OF METHODS 	

!

AND INTERFACES

now we just one interface with one method

<A extends Action<R>, R extends Result> R execute(A action);

typesafety all th...
!

command
pattern
GOF Pattern	

!

commonly used in 	

Rich Clients	

!
someAction

EXECUTE
someResult

someActionHandler
someAction

POJOS

someResult

someActionHandler
client

server

GWT client
someAction

GWT-RPC
someActionHandler

someResult

batching	

caching	

security

caching	

exc...
client

server

Java client
someAction

RMI / HTTPInvoker
someActionHandler

someResult

batching	

caching	

security

ca...
client

server

Mobile client
someAction

JSON-servlet
someActionHandler

someResult

batching	

caching	

security

cachi...
aka DTOs

type safety

Reusable

public class TerminLoadAction
implements Action<DataResult<TerminData>> {

!
!
!

}

publ...
<A extends Action<R>, R extends Result> 	

void execute(A action, AsyncCallback<R> callback)
dispatch.execute(

!

new Ter...
Server side
type safety
handler to
action
mapping

public interface ActionHandler
<A extends Action<R>, R extends Result> ...
Server side
custom
annotation
spring

@ActionHandlerBean
@Transactional
public final class TerminDataLoadHandler
implement...
‣ Client-Server communication	

‣ Command pattern	

‣ Versioning
‣ Batching, Caching	

‣ Scaling
RPC 	

interface 	

hell?
easy way

right way?

public interface SomeNiceService
extends RemoteService {

!
!
!

String someService(String param);
S...
someAction

POJOS

someResult

someActionHandler
different versions can coexist!

someAction
someActionV2

multiple

versions

someActionHandler
someActionHandlerV2

someR...
someAction
someActionV2

multiple

versions

someActionHandler
someActionHandlerV2

someResult
someResultV2

different res...
‣ Client-Server communication 	

‣ Command pattern	

‣ Versioning	

‣ Batching, Caching
‣ Scaling
why batch?
• one batch call is better than
10 single calls	


• less data	

• less roundtrip latency	

• avoid connection
bottleneck	...
someAction1

client

server

someAction2
batchActionHandler
someAction3
someAction1

batchAction

someAction2
batchResult
...
automatic batching?
IDLE

Scheduler.scheduleEntry(…)

GWT code execution

Scheduler.scheduleFinally(…)

browser event loop

Scheduler.schedule...
IDLE

collect commands

GWT code execution

Scheduler.scheduleFinally(…)

cmd 1!
cmd 2!
cmd 3!
cmd …

fire batch command
BATCH EXECUTION ALLOWS FOR FINE GRAINED
COMMANDS AND REUSE

toggleTerminMetadata

reloadDashboardTermine

BooleanResult

DataListResult<Termin>
toggleTerminMetadata

reloadTermin

BooleanResult

DataResult<Termin>
toggleTerminMetadata

loadMonthStats

loadMonthTermine

BooleanResult

DataResult<MonthStats>

DataListResult<Termin>
Caching
• Introduce cacheable interface	

• simple marker interface,	

• or more elaborate version with cache id,
expirati...
Patient 1!

Patient 1 details

!

Patient 2

0101010101010101001010101010101010101010101010101!
01010101010101010010101010...
action 1
action 2

execution 1
execution 2

result 2

result 1

Ops.
Ensure „only last“ result
action 1
action 2

„smart	

dispatch“

action 1
handler

last action is:

action

result 2
resul...
Re-Auth
• If server exception is security exception, try to
reauth and than re-execute commands
‣ Client-Server communication 	

‣ Command pattern	

‣ Versioning 	

‣ Batching, Caching	

‣ Scaling
GWT scaling is easy...
• Every client brings his own CPU power	

• The client does the page rendering	

• GWT provides dif...
WHAT CAN POSSIBLY GO WRONG?
LETS TALK HIGH TRAFFIC...	

HIGH TRAFFIC IS WHEN ONE SERVER IS NOT ENOUGH
HIGH TRAFFIC
PROBLEMS
• Bandwith issues	

• Connection pool bottlenecks	

• Thread pool bottlenecks	

• CPU bottlenecks ca...
NOT REALLY GWT PROBLEMS,	

BUT WHAT CAN WE DO?
avoid „tx
collisions“

TX

TX

TX

TX

TX

TX

TX

TX

TX

5 gleichzeitige Transaktionen
load small
portions of
data, do it
often
TX

TX

TX
TX

TX
TX

TX

TX
TX

TX

TX
TX

TX

TX

TX
IMPLEMENT REAL LOAD BALANCING	

EACH REQUEST GOES TO THE NEXT AVAILABLE SERVER
SCALING HOW-TO
• Don‘t stick a session to a server. 


Why send a user over and over again to a
possible overloaded server...
STATELESS 	

WEBAPP
Webserver
Webserver
Webserver
LB

Webserver
Webserver
Webserver

Session Cache
Session state could contain user
id, client id, session id, user roles
Session Cache

If session cache becomes
bottleneck,...
Thanks!
Client-Server-Kommunikation mit dem Command Pattern
Upcoming SlideShare
Loading in …5
×

Client-Server-Kommunikation mit dem Command Pattern

1,896 views

Published on

Eine Client-Server-Architektur stellt besondere Anforderungen an die Client-Server-Kommunikation. Einerseits wird Sparsamkeit angestrebt, andererseits absolute Flexibilität, Wiederverwendbarkeit und Wartbarkeit. Gerade im GWT-Umfeld fehlen clientseitig eine vollwertige JVM und das Reflection-API. Hinzu kommt noch der teilweise ungewohnte Umgang mit den asynchronen Aufrufen. In diesem Vortrag wird das Command Pattern vorgestellt. Es werden konkrete Lösungsansätze für Batching, Caching, Security und Journaling vorgestellt.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,896
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Client-Server-Kommunikation mit dem Command Pattern

  1. 1. Client-Server-Kommunikation mit dem Command Pattern p.g.taboada | pgt technology scouting GmbH
  2. 2. Papick G. Taboada pgt technology scouting GmbH! http://pgt.de Orientation in Objects GmbH! http://oio.de
  3. 3. http://gwtreferencelist.appspot.com
  4. 4. ‣ Client-Server communication ‣ Command pattern ‣ Versioning ‣ Batching, Caching ‣ Scaling
  5. 5. ! eb t w en sic pm las elo c v de Server Browser user action e ons html resp full user action po l html res ful nse user action po l html res ful nse
  6. 6. 
 eb ent w IA pm R lo ve de Server Browser first reques t e l respons full htm event event event data reque st data event data reque data st
  7. 7. Honor the A in JAX does ‣ Javascript it not block !
 Get over ‣ Latency is not a myth ‣ Results must not arrive in the call order
  8. 8. BUILDING A GENERIC FRAMEWORK FOR MARSHALLING/ UNSMARSHALLING DATA SUCKS

  9. 9. MARSHALLING / UNMARSHALLING IN JAVASCRIPT IS SLOW
  10. 10. DON‘T BIND YOU NEXT 3 YEARS OF WORK 
 AGAINST SOME COMMUNICATION PROTOCOLL

  11. 11. LOADING TOO MUCH DATA WILL ALWAYS HURT

  12. 12. ‣ Client-Server communication ‣ Command pattern ‣ Versioning ‣ Batching, Caching ‣ Scaling
  13. 13. GWT-RPC is a good solution if handled with care GWT-RPC binds many methods into one interface SomeResult someMethodName(SomeParameter spo) Interface Versioning is a monstrous thing
  14. 14. this will be an object SomeResult someMethodName(SomeParameter spo) this will be an object too
  15. 15. the method names bind the requests to the result SomeResult someMethodName(SomeParameter spo) typesafety all the way
  16. 16. USING GENERICS FOR ! TYPESAFETY, ! GET RID OF METHODS ! AND INTERFACES

  17. 17. now we just one interface with one method <A extends Action<R>, R extends Result> R execute(A action); typesafety all the way
  18. 18. ! command pattern GOF Pattern ! commonly used in Rich Clients !
  19. 19. someAction EXECUTE someResult someActionHandler
  20. 20. someAction POJOS someResult someActionHandler
  21. 21. client server GWT client someAction GWT-RPC someActionHandler someResult batching caching security caching exception translation security
  22. 22. client server Java client someAction RMI / HTTPInvoker someActionHandler someResult batching caching security caching exception translation security
  23. 23. client server Mobile client someAction JSON-servlet someActionHandler someResult batching caching security caching exception translation security
  24. 24. aka DTOs type safety Reusable public class TerminLoadAction implements Action<DataResult<TerminData>> { ! ! ! } public class DataResult<DATA extends Data> implements Result { ! private String terminId; public TerminLoadAction(String terminId) { this.terminId = terminId; } ! ! public String getTerminId() { return terminId; } ! ! private DATA data; public DataResult(DATA data) { this.data = data; } public void setData(DATA data) { this.data = data; } public DATA getData() { return data; } } Action Result
  25. 25. <A extends Action<R>, R extends Result> void execute(A action, AsyncCallback<R> callback) dispatch.execute( ! new TerminLoadAction(terminId), new AsyncCallback<DataResult<TerminData>>() { ! @Override public void onFailure(Throwable caught) { } ! ! ! ); @Override public void onSuccess(DataResult<TerminData> result) { } }
  26. 26. Server side type safety handler to action mapping public interface ActionHandler <A extends Action<R>, R extends Result> { ! ! ! ! ! action execution Class<A> getActionType(); R execute( A action, ExecutionContext context) throws DispatchException; ! } declared exception hiearchy Execution context for server side command execution
  27. 27. Server side custom annotation spring @ActionHandlerBean @Transactional public final class TerminDataLoadHandler implements ActionHandler<TerminLoadAction, DataResult<TerminData>> { ! access to backend type safe result ! ! ! ! ! ! ! } @Autowired private TerminDAO terminDao; @Override public DataResult<TerminData> execute( TerminLoadAction action, ExecutionContext context) throws DispatchException { TerminBean termin = … TerminData data = … return new DataResult<TerminData>(data); } @Override public Class<TerminLoadAction> getActionType() { return TerminLoadAction.class; } business logic, etc…
  28. 28. ‣ Client-Server communication ‣ Command pattern ‣ Versioning ‣ Batching, Caching ‣ Scaling
  29. 29. RPC interface hell?
  30. 30. easy way right way? public interface SomeNiceService extends RemoteService { ! ! ! String someService(String param); String someServiceV2(String param); String someServiceV3(String param); } public interface SomeNiceService extends RemoteService { ! ! String someService(String param); } ! public interface SomeNiceServiceV2 extends RemoteService { ! ! String someService(String param); } maintainability? maintainability? ! public interface SomeNiceServiceV3 extends RemoteService { ! ! } String someService(String param);
  31. 31. someAction POJOS someResult someActionHandler
  32. 32. different versions can coexist! someAction someActionV2 multiple
 versions someActionHandler someActionHandlerV2 someResult same result
  33. 33. someAction someActionV2 multiple
 versions someActionHandler someActionHandlerV2 someResult someResultV2 different results
  34. 34. ‣ Client-Server communication ‣ Command pattern ‣ Versioning ‣ Batching, Caching ‣ Scaling
  35. 35. why batch?
  36. 36. • one batch call is better than 10 single calls • less data • less roundtrip latency • avoid connection bottleneck • ensure server side execution order • less roundtrips solving common problems
  37. 37. someAction1 client server someAction2 batchActionHandler someAction3 someAction1 batchAction someAction2 batchResult someAction3 someResult1 someResult2 someResult3 batching can 
 server executes be manual or actions in given order automatic
  38. 38. automatic batching?
  39. 39. IDLE Scheduler.scheduleEntry(…) GWT code execution Scheduler.scheduleFinally(…) browser event loop Scheduler.scheduleDeferred(…)
  40. 40. IDLE collect commands GWT code execution Scheduler.scheduleFinally(…) cmd 1! cmd 2! cmd 3! cmd … fire batch command
  41. 41. BATCH EXECUTION ALLOWS FOR FINE GRAINED COMMANDS AND REUSE

  42. 42. toggleTerminMetadata reloadDashboardTermine BooleanResult DataListResult<Termin>
  43. 43. toggleTerminMetadata reloadTermin BooleanResult DataResult<Termin>
  44. 44. toggleTerminMetadata loadMonthStats loadMonthTermine BooleanResult DataResult<MonthStats> DataListResult<Termin>
  45. 45. Caching • Introduce cacheable interface • simple marker interface, • or more elaborate version with cache id, expiration time, etc… • Implement caching (client or server side)
  46. 46. Patient 1! Patient 1 details ! Patient 2 0101010101010101001010101010101010101010101010101! 0101010101010101001010101010101010101010101010101! 0101010101010101001010101010101010101010101010101! 0101010101010101001010101010101010101010101010101! 0101010101010101001010101010101010101010101010101! 0101010101010101001010101010101010101010101010101! 0101010101010101001010101010101010101010101010101! 0101010101010101001010101010101010101010101010101
  47. 47. action 1 action 2 execution 1 execution 2 result 2 result 1 Ops.
  48. 48. Ensure „only last“ result action 1 action 2 „smart dispatch“ action 1 handler last action is: action result 2 result 1 result 1 check result deliver if last! result
  49. 49. Re-Auth • If server exception is security exception, try to reauth and than re-execute commands
  50. 50. ‣ Client-Server communication ‣ Command pattern ‣ Versioning ‣ Batching, Caching ‣ Scaling
  51. 51. GWT scaling is easy... • Every client brings his own CPU power • The client does the page rendering • GWT provides different ways to reduce number of requests even more • The server must „only“ authenticate the user and provide the data, perform the actions requested by the client
  52. 52. WHAT CAN POSSIBLY GO WRONG?
  53. 53. LETS TALK HIGH TRAFFIC... HIGH TRAFFIC IS WHEN ONE SERVER IS NOT ENOUGH
  54. 54. HIGH TRAFFIC PROBLEMS • Bandwith issues • Connection pool bottlenecks • Thread pool bottlenecks • CPU bottlenecks caused by reflection API calls • High JVM garbage collection CPU usage
  55. 55. NOT REALLY GWT PROBLEMS, BUT WHAT CAN WE DO?
  56. 56. avoid „tx collisions“ TX TX TX TX TX TX TX TX TX 5 gleichzeitige Transaktionen
  57. 57. load small portions of data, do it often TX TX TX TX TX TX TX TX TX TX TX TX TX TX TX
  58. 58. IMPLEMENT REAL LOAD BALANCING EACH REQUEST GOES TO THE NEXT AVAILABLE SERVER
  59. 59. SCALING HOW-TO • Don‘t stick a session to a server. 
 Why send a user over and over again to a possible overloaded server? • Don‘t store anything on the HTTP session. Share session content outside web container • Session replication is expensive and does not scale well • Let the load balancer distribute calls to available servers
  60. 60. STATELESS WEBAPP Webserver Webserver Webserver LB Webserver Webserver Webserver Session Cache
  61. 61. Session state could contain user id, client id, session id, user roles Session Cache If session cache becomes bottleneck, use distributed cache Session Cache Session Cache
  62. 62. Thanks!

×