[Wrapper-user] RE: Integration methods; something different?

[EXT-Smith, E. M <eri...@bo...>]

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