I recently embarked on some Spring "re-training" (I haven't looked at it in a few years and it was time to get my skills up to scratch again). Since the last time I looked at Spring, I have worked on a couple of rich (thick) client projects where it was almost impossible to find people with both server skills and GUI skills (the market is quite good at the moment and people like me with all those skills get snapped up very quickly ). Anyway, since it is hard to find strong GUI programmers who also know how to deploy an app server and start it, it becomes desirable to be able to run the services inside the same JVM as the GUI programmer is developing in. There is then no wasted time due to EJB configurations and all the crap that comes with server development. About 18 months ago, I got around the problem by quickly implementing a clever service locator. It worked brilliantly, the only real problem being that we had a few bugs because people had developed code which worked when services were local but not when they were remote. The effort in fixing those bugs was however minimal. On my current project, we are using a proprietary framework based on Inversion of Control and Dependency Injection. Based upon its configuration, a client can call services locally or remotely too. If calling services remotely, they are invoked inside a stateless session bean which uses reflection and proxies…