Development Question Regarding Windows Services

[rkausch]

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</i> connections 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

 

[Samuel R. Neff]

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.

 

[rkausch]

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

 

[Samuel R. Neff]

We developed an app for a client that insisted on physical separation
so the entire web UI ran on one box and communicated with a windows
service on another box via remoting. Our testing showed that the
overhead due to remoting was under 10ms per call.

And a Mr. System Architect that doesn't understand separating code
into modules and plugging things together is hilarious. Sorry to hear
that.. just remember...