Development Question Regarding Windows Services

>Hello, I'm performing some research to determine the feasibility of
>developing a Windows Service (see
>http://en.wikipedia.org/wiki/Windows_Service for the specific
>definition of "service" to which I'm referring) to perform a particular
>task. I'm having some trouble determining if a service's
>functionality can be accessed in a non-I/O manner (such as avoiding
>Sockets, reading and writing a temp file, etc).
>
>Basically, I'd like to call a method on a running service, and have it
>return an object (similar to a factory's getInstance method). All I've
>been able to find so far is that a service can implement the
>"OnCustomCommand" method, which only provides one-way communication
>from the caller to the service, allowing an integer argument to be
>specified.
>
>A potential solution that I'm currently noodling over is to retrieve an
>instance of the service via the ServiceController class, and cast the
>resulting object to the specific class of the service which I write.
>Unfortunately, I can't test this today, as I have to wait until the
>network admin enables the security settings to allow me to install a
>service (and that won't be until tomorrow).
>
>A good analogy to what I'm trying to do is to imagine a Database
>Connection Pool as a windows service. When the machine starts up,
><i>n</iconnections are created and held as available. At some point,
>an application needing database connectivity requests an available
>connection from the connection pool, which will then provide one to the
>application. Ideally, I'd like to avoid using remoting, as it involves
>a lot of serialization (if I understand its behavior correctly), and
>performance is critical.
>
>Thanks in advance,
>Rob

The ServiceController stuff should usually only be used to actually
control the service, start and stop it and such. To actually
communicate with your service use custom methods. I usually use .NET
Remoting but you can also use TCP sockets, named pipes, or any of the
other Windows inter-process communication mechanisms.
>
Usually when developing a windows service it's good do think of the
windows service part of it as being an add-on. You develop your core
functionality within a dlll and it works totally on it's own. Then
you can built a windows service project that hosts this dll. You can
also use the dll directly from other projects (easier development) and
can create console application wrappers (again, easier development).
>
HTH,
>
Sam
>
>
------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
>
>
>
On 3 Jan 2007 16:02:11 -0800, rkausch@gmail.com wrote:
>

>Hi Sam, thanks for the reply.
>
>Your comments on the ServiceController cleared things up greatly, it
>makes sense that a controller controls the service (duh!). Do you know
>of any performance bottlenecks associated with service communication
>via remoting (I have examined it a bit, and since the connections are
>to be on the same box, it'll probably use an IpcChannel for the
>remoting).
>
>I completely agree with the 'bolt-on' approach you describe.
>Unfortunately, some people (ahem, Mr. System Architect) don't quite see
>eye to eye on this one, and we're stuck implementing their wonderful
>visions. Basically, he's visualizing the 'connection pool' (for lack
>of a better term) part of the application as the 'bolt-on' part, not
>part of the core functionality. Looks like I have a bit of social
>engineering to do ;)
>
>Thanks again!
>Rob
>