A client asked me to create a layer in their SOA app which would allow them to do the following;
1. Log calls to a service with their analytics software
2. Measure the response time of a service
3. Track service call timeouts and repeat the call as needed
Creating a ServiceProxy seemed like a natural choice.
For those in a hurry - my big lesson was: when assembling a dynamic call and passing params you must use ‘.apply’.
Works: ’service[serviceCall].apply( null, params );’
Broke: ’service[serviceCall]( params );’
On with the progam…
The existing ’service’ files make calls to backend services, via Proxy’s, and process the response received from the server. For example, LoginService contains a login( username, password ) function- - which passes the params as part of a call to FlickrProxy.login( username, password ) .
LoginService listens for a success/failure from FlickrProxy and processes the response accordingly.
Entere the ServiceProxy… who sits between the LoginService and the FlickrProxy.
LoginService.login(username, password) now calls ServiceProxy.makeCall( params ) which ultimately calls FlickrProxy.login(username, password). ServiceProxy.makeCall() is the perfect place to submit data to analytics and start timers immediately before or after making the call to FlickrProxy.
When a response is received from the FlickrProxy, the ServiceProxy stops timers and can submits more analytics data before/after passing the response back to LoginService.handleLogin().
In your LoginService you will now listen for events from ServiceProxy instead of FlickrProxy.
That’s the gist. Not rocket science, I know, but I had fun considering the architectural options and assembling the dynamic calls to service proxies.
Here is a hacked together (non-client specific) version of a ServiceProxy filled with comments.
If I have time I will put together a sample app using the ServiceProxy.
more posts at http://toddrothe.com
