|
From: Andrew D. <and...@hs...> - 2004-09-03 04:23:35
|
> . Eric, thanks for your informative response. But I am confused; I keep reading your post in one of two ways. > The interface between the platform (e.g.: Windows) and your service only > provides for a few simple actions. Generally these are Start/Stop, > Pause/Resume and Install/Uninstall. If you have a single class that > implements these interfaces (for the platform) and calls a corresponding > class in your service to provide these actions, then you have > effectively created a single service launcher that can, by using a > specialized .conf file, operate for all of your services. 1. To me, this implies that the ServiceInterface implementation is generic, and is seperate from the stand alone application (SAA). > If you implement a single WrapperListener that calls into an implemented > interface in your service, and you provide the details for this > interaction in your .conf file (in my implementation it is a single > parameter to my service class), then the reflection is performed only > once for your service. And it is performed only when the service > initializes itself. .... > Now I can take my service wrapper, implement my ServiceInterface with > the commands necessary to operate my application, and I can take any app > that I have and run it either as a standalone application, or as a > service. 2. When I read the above, it seems each SAA actually implements the ServiceInterface itself. Which of these is correct, if any? For either of these options, it seems that unlike integration option 1 (service instantiates itself using main), a reference to the SAA is required. Because the service arguments are delivered from the .conf as by the commmand line, using reflection for instantiation is difficult. So to easily create an instance of the SAA, it seems best that I always provide a "String[] args" constructor. Am I on the right track? I still feel like I am missing something obvious here, or I have just got this all wrong... |