Communication between a Windows Service and a UI Front End

[JB]

Hi All,

I have a VB.NET application that constantly executes queries through
ODBC connections. The application consists of a simple Form type UI
where the query parameters can be edited, and a simple scheduler that
executes the queries.
The application works fine as "standalone" but it now needs to be
installed on a server and left running permanently even when no user
is logged on.
I think a Windows Service would be perfect for this, but I read
everywhere that Windows Services shouldn't have a UI. That makes sense
to me and I'd have no problem splitting the application between a
Front End (form based to edit the parameters) and a back end (doing
the actual execution of the queries).
What I'm wondering now is what would be the simplest way to achieve
this? I've been looking into .NET Remoting (MSDN examples and various
groups), but it seems far too complex for what I need. I need the
split applications to behave just like one single application, they
will always be on the same machine (even same directory), etc.
Can anybody give me any direction on that and/or point me to examples
of Windows Service / UI communication.

Thanks a lot
JB

 

[ShaneO]

.... What I'm wondering now is what would be the simplest way to achieve
this?
Can anybody give me any direction on that and/or point me to examples
of Windows Service / UI communication.

Thanks a lot
JB

I have a Service that sits on various Servers. My Service only requires
to function once every 30 mins. Before it performs its task, it checks
a configuration file ("ini" file) which is stored on the local machine.

The ini file can be modified by a separate program which a User launches
when they're logged-in.

This might not suit your requirements, but it might give you an idea of
a way to address your problem.

Regards,

ShaneO

There are 10 kinds of people - Those who understand Binary and those who
don't.

 

[Michel Posseth [MCP]]

You could store the values in a database and thus comunicate through the
database with your service ( periodic check intervall ) or
with sql 2005 you could use notification services ( so the service wakes up
when a task is added to the db ) .

And yes Remoting would be suitable , and is not as difficult / complex as
you might think

regards

Michel

 

[JB]

You could store the values in a database and thus comunicate through the
database with your service ( periodic check intervall ) or
with sql 2005 you could use notification services ( so the service wakes up
when a task is added to the db ) .

And yes Remoting would be suitable , and is not as difficult / complex as
you might think

regards

Michel

Hi All,

Thanks for your suggestions, it helped. I think I will go for an
hybrid solution.
Save an Xml file picked up by the service, and for a UI refresh,
implement a few Remoting function to interogate the service on its
current state.

Regards
JB

 

[Guest]

I have a Service that sits on various Servers. My Service only requires
to function once every 30 mins. Before it performs its task, it checks
a configuration file ("ini" file) which is stored on the local machine.

The ini file can be modified by a separate program which a User launches
when they're logged-in.

Wow, yuck - you should really be using remoting!

 

[Guest]

Thanks for your suggestions, it helped. I think I will go for an
hybrid solution.
Save an Xml file picked up by the service, and for a UI refresh,
implement a few Remoting function to interogate the service on its
current state.

Why not implement the UI functions as a remoting function too? That'll save
you the hassle of writing out to disk + allow network users to access the
service too!

 

[JB]

Why not implement the UI functions as a remoting function too? That'll save
you the hassle of writing out to disk + allow network users to access the
service too!

Hi Spam Catcher,

You're right, it would certainly be more "elegant" to use remoting for
the whole thing, but the truth is, I'm worried it would require too
much of rewriting to implement. And as I couldn't find any good sample
code out there (other than the basic MSDN one) I'd rather go for
something simpler that I can maybe improve in the future.

Regards
JB

 

[ShaneO]

Wow, yuck - you should really be using remoting!

I certainly wouldn't agree with using remoting. In this case the
settings are usually only configured during installation and never need
to be changed, however if they ever did, I would argue that using the
method I am using follows the KISS principle and doesn't use
high-falutin' solutions just for the heck of it.

It's funny, Remoting wasn't being used by anyone only a short while ago,
and now every man and his dog seems to be jumping onto the bandwagon!
(I guess that's how fads are created)


ShaneO

There are 10 kinds of people - Those who understand Binary and those who
don't.

 

[Guest]

I certainly wouldn't agree with using remoting. In this case the
settings are usually only configured during installation and never need
to be changed, however if they ever did, I would argue that using the
method I am using follows the KISS principle and doesn't use
high-falutin' solutions just for the heck of it.

I guess I over-reacted a bit, your method is definately KISS!

I've seen some apps use the registry to pass information back and forth.

.NET's service controller class also has the ability to execute a
custom command and pass in parameter

It's funny, Remoting wasn't being used by anyone only a short while ago,
and now every man and his dog seems to be jumping onto the bandwagon!
(I guess that's how fads are created)

Remoting has been around since .NET 1.0, which is >5 years old. These
days applications need to be run remotely or on several PCs at once
which mean that some sort of network interface needs to be implemented.
As such .NET remoting is typically the easiest and most robust method
available.

I tend to stay away from data integration methods (i.e. using an INI,
Database, etc) because users could modify the INI file and fudge data. I
always liked the ideas of separate tiers rather than tieing everything
together through a common data layer.

Just my preference I guess

 

[Phill W.]

It's funny, Remoting wasn't being used by anyone only a short while ago,
and now every man and his dog seems to be jumping onto the bandwagon!

I suspect that's largely because we're all having to turn out Windows
Services to get 'round Vista's security .. er .. "enhancements" and
there's no other, easy way of adding a client-process callable API to a
..Net-written Windows Service ...
"he said, earnestly hoping that /someone/ would disagree and suggest
something far, far better" ;-)

Regards,
Phill W.