"ServiceMgr" provides the means of abstraction of the actual service implementation. The application developer never cares about "how" nor "where" is the service is implemented and executed. It is the responsibility of the "ServiceMgr" to initialize the services properly. The "ServiceMgr" initialization configuration is stored in a property file, which results in maximal flexibility of the service implementation.
At one point, the service is executed locally, even inside the same process (the component executing the service and the service implementation run within the same process) and next, just by small configuration file modification, the same service can be turned into remotely hosted one, accessed across the Internet via SOAP/HTTP, RMI, CORBA or whatever else. Let's imagine, such a huge change of concept, and it can be done without changing one single line of code. One does not even need to restart the server to swap between two distinct service implementations.
Figure 5.2: Interaction Diagram: Service instantiation and initialization
Figure 5.2 shows how the services are instantiated, initialized and registered in the "ServiceMgr".
The following figure 5.3 presents the idea of service implementation abstraction. When one need to execute a service function, the service implementation is obtained from "ServiceMgr". It depends on the "ServiceMgr" initialization, what is the actual implementation of the service returned by "getService" operation. More about this follows in the "voting" example.
Figure 5.3: Interaction Diagram: Service execution