Smart Service Model?

[Blitz Krieg]

Oh Great Gurus... The wisdom of DotNet-dom is needed...

We have several applications in our test lab, that do not need peak
performance, but consistent reporting. We have been using C# and VB
..NET because of the ease of use.

However, each application has a significant percentage of code that is
replicated in each application... true it is assembly based and not a
big deal to include, but there must be a better way. We have our own
custom trace-listener, that has a file-pipe, event-log-pipe,
console-pipe, etc. Not managed on Microsoft's applicable block model,
but similar in concept. Since we always use the same providers we do
not need a plug-able provider model like Microsoft has established.

Now for the real question... If we take our core custom
trace-listener, and convert it from a group of assemblies that is
embedded/linked in each application 'so-to-speak' and convert the
engine that drives the trace-listener to a serivce, what special
consideration should we take into account?

Again, the overhead of the service is not an issue per se for us. Here
are the basic questions we have...

1) If the service has nothing to do, should be pause and resume it as
needed, or stop and start it? I would think pause and resume would
work best, where if the trace message queue is empy we pause, and when
ever we enqueue a message to the trace listener queue we resume it as
needed? Does a thread.sleep command do the same thing as a pause? for
the length of the sleep duration?

2) if the service has something to do, how long do we let the service
process queue items? Is there any advantage to let the service
process, cache every 100 messages, and then resume? Or even if the
queue is not empty, force the service to pause?

I suspect that this idea is similar in concept to those that have an
I/O based service say a TCP listener or something to the same effect?
Any and all suggestions welcome.

[Nick Malik [Microsoft]]

Sounds like you want to head towards service oriented architecture.

I am concerned, however, that what you've described isn't a service. taking
input from an application and displaying some of it on the console isn't
suitable for service code, because the service, by definition, runs in a
different address space (and usually a different user space) and therefore,
doesn't share the desktop. If you just want to install common code, you can
place assemblies in the GAC and your apps can refer to them without
including them in the install.

On the other hand, I agree that an audit and logging service is a shared
module that can easily be extended to a service. As long as your messages
are going to a message store (configurable or not), you have a pathway, and
with a pathway, you can create a service.

OK... so you asked about a windows service. That's surprising to me.

If you use a web service, then all of the work is already done for you. A
web service runs as a service (IIS), listens on a port (any port you want),
manages security (web.config <identity>) and gives you full programmatic
control. If you are concerned about illegal access, then implement WSE (Web
service extensions) that will keep unauthorized apps from posting to your
service. (if you were rolling your own, you'd have to write 100% of this by
yourself).

There is no reason whatsoever to re-invent this wheel.

I have created a number of web services to be used in common by my apps.
This works remarkably well. Something to consider.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Blitz Krieg" <Sc*******@DSLE xtreme.COM> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.com...

Oh Great Gurus... The wisdom of DotNet-dom is needed...

We have several applications in our test lab, that do not need peak
performance, but consistent reporting. We have been using C# and VB
.NET because of the ease of use.

However, each application has a significant percentage of code that is
replicated in each application... true it is assembly based and not a
big deal to include, but there must be a better way. We have our own
custom trace-listener, that has a file-pipe, event-log-pipe,
console-pipe, etc. Not managed on Microsoft's applicable block model,
but similar in concept. Since we always use the same providers we do
not need a plug-able provider model like Microsoft has established.

Now for the real question... If we take our core custom
trace-listener, and convert it from a group of assemblies that is
embedded/linked in each application 'so-to-speak' and convert the
engine that drives the trace-listener to a serivce, what special
consideration should we take into account?

Again, the overhead of the service is not an issue per se for us. Here
are the basic questions we have...

1) If the service has nothing to do, should be pause and resume it as
needed, or stop and start it? I would think pause and resume would
work best, where if the trace message queue is empy we pause, and when
ever we enqueue a message to the trace listener queue we resume it as
needed? Does a thread.sleep command do the same thing as a pause? for
the length of the sleep duration?

2) if the service has something to do, how long do we let the service
process queue items? Is there any advantage to let the service
process, cache every 100 messages, and then resume? Or even if the
queue is not empty, force the service to pause?

I suspect that this idea is similar in concept to those that have an
I/O based service say a TCP listener or something to the same effect?
Any and all suggestions welcome.

[Blitz Krieg]

You points are well taken, in that console is interactive, and not 'as'
supportable for a service per se. However, that point aside, web
services are not an option for us. We have a restrictive enviornment
that does not allow 'web' anything. I could spend hours in
explanation, but it would not change the fact that no web components or
aspects are allowed. Not the first time this issue has been asked of.

As for coding ourselves, we have everything done, but the service shell
its-self because our entire trace-listener engine is already done and
established as sat. assemblies. About the only thing I have not done
is work-up a few .NET remoting examples to get a handle on interprocess
communication locked into my mindset. Of cource, we could also setup a
singleton process that runs a low priority that acts as a clearing
house for trace messages for any given application that may need to
generate a trace message, etc. But such a process, is in point of fact
a service, in all but name.

[Nick Malik [Microsoft]]

well, if you can't go web (sounds like that decision has some painful
history... I won't go there)...
There is nothing wrong with going to remoting. Using the ability to create
a singleton object, you still won't need to run it as a windows service.

The best resource I've found for .Net remoting is a book by Ingo Rammer
called Advanced .Net Remoting. It will have you writing remoting objects
before you are done with chapter 2, with extensive sections on advanced
topics. Truly a fantastic book, and it sounds like it may suit your needs.

If you really need to stay with windows services, and you don't want to go
the remoting path, then I'd recommend using MSMQ. You send a queued audit
message to the logging component and let the logging component figure out
what to do with it. Nice thing about this: if the service isn't running,
nothing is blocked and nothing is lost.

Hope this helps,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Blitz Krieg" <Sc*******@DSLE xtreme.COM> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

You points are well taken, in that console is interactive, and not 'as'
supportable for a service per se. However, that point aside, web
services are not an option for us. We have a restrictive enviornment
that does not allow 'web' anything. I could spend hours in
explanation, but it would not change the fact that no web components or
aspects are allowed. Not the first time this issue has been asked of.

As for coding ourselves, we have everything done, but the service shell
its-self because our entire trace-listener engine is already done and
established as sat. assemblies. About the only thing I have not done
is work-up a few .NET remoting examples to get a handle on interprocess
communication locked into my mindset. Of cource, we could also setup a
singleton process that runs a low priority that acts as a clearing
house for trace messages for any given application that may need to
generate a trace message, etc. But such a process, is in point of fact
a service, in all but name.