|
From: EXT-Smith, E. M <eri...@bo...> - 2004-09-02 12:23:32
|
Andrew, >> The alternative is to create an interface that all my service classes >> must implement, so that a generic WrapperListener implementor can=20 >> provide a controlled startup and shutdown. This can be implemented >> using the current API, but does not seem as flexible. On the contrary, IMHO this is an extremely flexible way to do what you are asking. Consider this... 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. >>=20 >> What I want to avoid is having to create a WrapperListener implementation >> for each service class I create. Not having to use reflection would also be nice... 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. I put together a simple WrapperListener in about 100 lines (including javadocs) that does this for all of our services. This let me build my services as follows: +- - - - - - - - - - - - - - - + | +-----+ +-----------------+ | +------------------+ +----------------+ | JSW |<>| WrapperListener |<->| ServiceInterface |<->| Standalone App | | +-----+ +-----------------+ | +------------------+ +----------------+ +- - - - - - - - - - - - - - - + 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. All of this by implementing one interface, distributing it in its own jar, adding a parameter in my .conf file, and if necessary an installation program (InstallAnywhere/InstallShield/MSI/etc...). This has allowed my team to put together multiple services for license services, file services, logging services, etc... without each developer requiring specific knowledge of service development or configuration. They only need to know ServiceInterface and how their application works. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Eric M. Smith Harpoon Technologies Office : (314) 233-4204 |