1. Software Engineering and Architecture
Broker Pattern Architectural Pattern for Remote Method Invocation

2. Henrik Bærbak Christensen
Broker
Broker
Complex pattern
Three levels
Domain level
Marshalling level
IPC level
Two mirrored ‘sides’
Client side
Server side
Let’s have a look at each…
Henrik Bærbak Christensen

3. The ‘Side’ Perspective
Client side
Henrik Bærbak Christensen

4. The ‘Side’ Perspective
Server side
Henrik Bærbak Christensen

5. Henrik Bærbak Christensen
Dynamics (Client)
Henrik Bærbak Christensen

6. Henrik Bærbak Christensen
Dynamics (Server)
Henrik Bærbak Christensen

7. Henrik Bærbak Christensen
Domain Level
Domain level represents the actual Role
Henrik Bærbak Christensen

8. Henrik Bærbak Christensen
Marshalling Level
Encapsulate translation to/from bits and objects
Henrik Bærbak Christensen

9. Henrik Bærbak Christensen
IPC Level
Interprocess Communication
Encapsulate low-level OS/Network communication
Henrik Bærbak Christensen

10. Henrik Bærbak Christensen
Relating to   
Broker pattern and    ?
Yes, yes, and yes
 Encapsulate what varies
We would like to vary marshalling format: Requestor+Invoker
We would like to vary IPC method : RequestHandler
 Object composition
We delegate to the requestor. We delegate to the RequestHandl.
However, the roles bleed into each other somewhat
Often RequestHandlers need additional marshalling/demarshalling
REST and HTTP solves multiple aspects => natural ‘bleeding’
Henrik Bærbak Christensen

11. In Practice
How Does It Look Then…

12. Henrik Bærbak Christensen
TeleMed Proxy
ClientProxy = Proxy calls
Note: location is hardcoded in TeleMed (only one server) so no need for that parameter.
Henrik Bærbak Christensen

13. Henrik Bærbak Christensen
Identity of Methods
Remember: We can only send byte arrays = Strings
Need to Marshall method names as well.
”Mangling” = Concatenate class name and method name
Henrik Bærbak Christensen

14. Henrik Bærbak Christensen
Requestor
General Implementation!
Use JSON and the GSON library
Generic return type is pretty helpful…
And Object… = arrays of mixed types are really nasty that required some googling to find out how.
Henrik Bærbak Christensen

15. Henrik Bærbak Christensen
Request Handlers
Let us skip them for the moment…
Basically they are responsible for the send/receive pairs
Broker Library code base come with two variants:
Socket: Raw Java TCP/IP network implementations
HTTP: Use as a raw transport (URI Tunneling)
Henrik Bærbak Christensen

16. Henrik Bærbak Christensen
Invoker
Basically you need a large switch on each method name to do the ‘upcall’, and extract the relevant parameters for the method
For multi-object system, you need something more complex. Stay tuned – we will look at it next week...
Henrik Bærbak Christensen

17. Henrik Bærbak Christensen
TeleMed Servant
Servant = Domain implementation
Henrik Bærbak Christensen

18. Henrik Bærbak Christensen
Summary
The flow
Henrik Bærbak Christensen

19. Henrik Bærbak Christensen
Summary
Framework !
Only
ClientProxy
Invoker
Are TeleMed specific!
Henrik Bærbak Christensen

20. Henrik Bærbak Christensen
Limitations
No Name Service / Registry required for TeleMed
Hardcoded which machine the servant object resides on
Use DNS as kind of registry, I used ‘localhost’ here
More RPC than RMI
Remote Procedure Call on ‘single type object’, not on multiple objects
Only Value types can be passed, not Reference types
No object references ever pass a network border
Asymmetric
Client-server protocol, no ‘callback’ from server possible
I.e. The Observer pattern can not be implemented
Henrik Bærbak Christensen

21. Henrik Bærbak Christensen
Limitations?
Are these severe limitations? Actually, not really
All web service architectures obey them
They are RPC !
Only value types are passed !
Callbacks are not part of standard web programming
We cannot make an Observer Pattern!
(But lots of tricks to implement it still
COMET, WebSockets, ‘long calls’, polling)
And they are pretty successful 
Henrik Bærbak Christensen

22. Henrik Bærbak Christensen
Limitations?
Web architectures impose limitations that make perfect architectural sense
If you have callback, you cannot scale-out
That is, increase power by adding more servers / load balancing
Exercise: why not?
Hint: Consider WoW clients to be notified if one tree in the world is chopped down…
If you have real remote object references you will get callbacks
remoteServer.addCustomer(localCustomerObject)
On remote server, the ‘localCustomerObject’ is now remote!
Pure client-server + value passing saves the day!
Henrik Bærbak Christensen

23. Marshalling Robustness
Jon Postel
Scenario:
Change the marshalling format for messages
Redeploy the server
Bang! All deployed clients fail to talk to server!
Henrik Bærbak Christensen

24. Henrik Bærbak Christensen
Robustness
Key point
Include a version identity in the marshalling format !
The demarshalling must ‘taste’ it and next decide on the full demarshalling
I.e. parse the ‘raw byte array’ for the version identity
Select the proper demarshalling algorithm to use
JSON and XML are very flexible formats!
You can add new attributes, but older algorithms can still pick out those attributes that they know the semantics of
Gson can demarshall ‘half’ objects
Henrik Bærbak Christensen

25. Deployment
In the code bases distributed, the client and server side classes are pooled into one big source tree
src and src-lib
In real deployments you need to split’em
Server: Server side specific classes
Core: Core domain interfaces and PODOs
Client: Client side specific classes
The client side deployment (Core + Client)
The server side deployment (Core + Server)
Simply easier in our teaching
Henrik Bærbak Christensen

26. The Process?
How did I get there?

27. Henrik Bærbak Christensen
Developing it
All well – you see the final picture but how was it painted?
Challenge: TDD of a distributed system?
I cannot (easily) automate that a server needs to be running on some remote machine, can I?
(well we can, but that is another course…)
Henrik Bærbak Christensen

28. Henrik Bærbak Christensen
Exercise
Which level hinders TDD???
And you know how to deal with it, right?!?
What is the answer???
Henrik Bærbak Christensen

29. Henrik Bærbak Christensen
Principle 1+2+Doubles
It is the IPC Level that hinders TDD
But
Programmed to an interface
Object compose a Test Double into place instead!!!
A Fake Object IPC
Henrik Bærbak Christensen

30. LocalMethodCall ClientRequestHandler
Faking the IPC
No need to start server. No concurrency.
All aspects (except IPC) can be TDD’ed
LocalMethodCall ClientRequestHandler
Henrik Bærbak Christensen

31. @Before Binding the Broker / Coupling the delegates together That is
Link proxy to requestor, requestor to CRH double, CRH to invoker, and the Invoker to the servant object
The only test double!
Rest are production code!
Henrik Bærbak Christensen

32. Henrik Bærbak Christensen
Make a Test Case
Call client proxy, assert something stored in XDS
Henrik Bærbak Christensen

33. The IPC Level
Talking network’ish

34. Henrik Bærbak Christensen
Choosing IPC
The most fundamental level
Sockets
More modern approach
URI Tunneling using HTTP web servers
Next lesson in next week
ReST based
Henrik Bærbak Christensen

35. Henrik Bærbak Christensen
Rule #1
Find stuff on the internet 
Jakob Jenkov has fine tutorials on socket server programming
Single thread
Multi thread
Thread pooled
Question of concurrency
Single thread Only one call at the time
Multi thread Unlimited => Memory exhausted!
Thread pool N threads = Best of both worlds
Henrik Bærbak Christensen

36. Client Request Handler
Socket = ”file”
Not tied to disk, but remote computer…
The old HTTP protocol
Create socket
Send request
Read reply
Close socket
Inefficient but reliable
Henrik Bærbak Christensen

37. Server Request Handler
Jenkov single thread
Accept incoming socket
Read request
Call invoker
Send reply
Close socket
Henrik Bærbak Christensen

38. Henrik Bærbak Christensen
Summary
Henrik Bærbak Christensen