Windows Service

  • Thread starter Thread starter Nicholas Paldino [.NET/C# MVP]
  • Start date Start date
N

Nicholas Paldino [.NET/C# MVP]

Moty,

If your windows service already exists, then you have to use whatever
communications mechanism it exposes, don't you? Or are you going to add to
the current service?

You say you still have windows 98 clients, which leads me to believe
that you have clients outside of the network that the machine that the
service is on. If this is the case, I'd expose a web service and then have
that connect to the service.

If you are on an internal network, then you could use tcp, byt why use
wse2 if you are going to use tcp? I mean, why not just use remoting? Or do
you have a need for cross-platform access? If so, then just expose a web
service which connects to your service, then everyone can connect to it.

Hope this helps.
 
Hello,

Can anyone please help me finding a good way to develop a c# winforms
application client for a pre-developed windows service?

Should I use wse2 with tcp protocol? Bu I still have win98 clients. mmm..
Please help.

Thanks,
Moty.
 
Moty Michaely said:
I have a windows service that needs to handle a queue for sending
emails. I don't really know a way of handling such a queue besides
MSMQ or a database
Click to expand...

There are many ways to handle it. The first question then is - do you want to use MSMQ or something
else?
Remoting is one way but someone told me it's a dead-end and wse2 is
the best way of dealing with these kind of things even in intranet
areas.
Click to expand...

Remoting itself isnt dead end. What they might have been referring to is Indigo which will replace it.
But Indigo isnt released yet, so you either use remoting and port later, or wait.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/
 
Nocholas, Thanks for the rapuid reply.

...."communications mechanism it exposes"...
What do you mean by that?

I have a windows service that needs to handle a queue for sending emails. I
don't really know a way of handling such a queue besides MSMQ or a database
:)..

Second. I need a client application which gets the queue and lets the user
the ability to query each item in the queue.

Remoting is one way but someone told me it's a dead-end and wse2 is the best
way of dealing with these kind of things even in intranet areas.

Any idea?

Nicholas Paldino said:
Moty,

If your windows service already exists, then you have to use whatever
communications mechanism it exposes, don't you? Or are you going to add
to the current service?

You say you still have windows 98 clients, which leads me to believe
that you have clients outside of the network that the machine that the
service is on. If this is the case, I'd expose a web service and then
have that connect to the service.

If you are on an internal network, then you could use tcp, byt why use
wse2 if you are going to use tcp? I mean, why not just use remoting? Or
do you have a need for cross-platform access? If so, then just expose a
web service which connects to your service, then everyone can connect to
it.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Moty Michaely said:
Hello,

Can anyone please help me finding a good way to develop a c# winforms
application client for a pre-developed windows service?

Should I use wse2 with tcp protocol? Bu I still have win98 clients. mmm..
Please help.

Thanks,
Moty.
Click to expand...
Click to expand...
 
Actually, I would say remoting is a dead end. The only reason to use
remoting now is if you need the extensibility mechanism exposed through the
channel intercepts. Other than that, remoting doesn't a good number of
services to offer. Authentication, authorization are two examples that come
to mind.

It's been stated publically by people at MS that Enterprise Service
components will offer the easiest migration path to Indigo (it should be as
simple in some cases as just changing some attributes, assuming you follow
best practices).
 
Moty,

I'm amazed that a technology that less than 3 years ago was said to be the
Second Coming is now a "dead end". Not to put to fine a point on it, that's
horseshit.

Remoting is a performant, extensible platform for IPC. I would use it
without hesitation anytime you have a .NET application at both ends of the
connection, complete control over the network / installation / configuration
at both ends, and don't anticipate that changing in the foreseeable future.
For example, I use remoting extensively (binary over TCP/IP) to orchestrate
a bunch of worker machines on the same subnet performing various automated
tasks.

When communicating between clients and servers over the Internet to
locations you have no control over, or that operate on different platforms
than .NET) then you are generally stuck with Web Services over HTTP with
bulky XML payloads -- but you have a highly interoperable and flexible
standard, and it's arguably easier to implement and consume web services
than remoting. Although in my experience once you get over the config
issues remoting is no big deal to work with.

Indigo is not out of development yet so it's not an option for the vast
majority of today's projects. Remoting may ultimately be deprecated in
favor or Indigo and may or may not find an ongoing niche of its own, but it
will be supported for a long time to come (a good decade or two is my guess)
even if it drops dead immediately upon Indigo's release, because there are
already a lot of released systems that use it, and for many if not most of
those there will be no compelling reason to rearchitect them with Indigo
since they work just fine as-is.

--Bob
 
Indigo now offers web services the choice of protocol with a few simple
changes in the web.config file. If you want to use biniary over TCP/IP - its
yours. You get the speed of binary thru the transport protocol AND you get
all the ohter bells and whistles that indigo has to offer. Take Indigo out
for a ride with the beta1 release of Avalon and Indgo for the VS2005 Beta 2.
It is very cool and while not everything is available - there is enough
available in the beta 1 to keep you busy. Check it out, its cool. Look at the
examples in the WINFX SDK under the Indigo Samples to see the how easy it
will be to do binary under Indigo versus HTML/XML. But for Beta 1 you may
need to install the WinFX SDK, first, then uninstall it but keep a copy of it
from your program files, then install the beta1 for Indigo and Avalon. the
WinFX has problems with the beta 1 of Indigo and you have to use the Indigo
beta1 without WinfX installed. WinFX will put the classes for
ProcessServiceModel driectly into the framework classes, and with just the
Beta1 of Indigo these are used as extensions, uabale but no yet seen directly
in the framework calsses and its documentation. So hold WinFX out for awhile
until MS has a new version that does not break the Indigo compiles. But
install it first just to get all the Indigo samples and documentation so you
will know HOW to USE the beta1 release of Indigo.

After you have played with this and gone thru the samples you will begin to
think that this is a much more dynamic way of making a binary over TCP/IP
work than remoting. There is no bulky XML overhead unless you decide to put
it there. So you have the old ASMX web service XML style or the Binary style,
whatever you choose, but they are both done with one common API interface. I
think you'll like it.

Later.
 
Hi Richard,

I don't doubt that Indigo may well prove to be my default RPC technology
once it's released, but that is still months away (and as you point out,
still a little wild and wooly to play with at this point) so for anything
with a release time frame prior to Indigo's release, I'd be reluctant to
commit. These technologies need to stabilize and get a bit of a track
record. And, Indigo is quite different from Remoting, so that doesn't make
me terribly eager to rip out all my Remoting code and rewrite it, given that
it's all stable and working fine. Nor do I think Microsoft is suggesting
that we might do that (if only because it would make them look a little
foolish this soon after all the .NET Remoting fanfare -- that's a mighty
young technology to be killing off).

I also didn't suggest that Indigo saddles you with XML -- my quibble there
is with Web Services, and it's not necessarily even a quibble, because XML
is a necessary "lowest common denominator" when talking between disparate
systems ... and quite often, good enough even if not always as compact and
economical as one might wish. It's just that if you don't need cross
platform support, you might as well use TCP/IP over binary, and right now,
Remoting's the ticket for that.

By the way ... while I have perused some of the recent articles on Indigo, I
haven't caught what its final release schedule might be. Is its rollout
tied to the CLR 2.0 / VS 2005 release at all, or is it tied strictly to
Longhorn? If the latter, can we expect somewhat stable support for Indigo
in CLR 2.0 with some kind of follow on maintenance update when Indigo's
production bits are ready?

--Bob
 
Moty Michaely wrote:

Remoting is one way but someone told me it's a dead-end and wse2 is the
best way of dealing with these kind of things even in intranet areas.
Click to expand...

Boy, did that guy ever steer you the wrong way.

Have you actually looked at what WSE 2.0 entails?

Do you want all your clients to have to run a web service in order to do
callbacks?

Right now I'm working with the remoting chat sample code...it has remoted
events...do you know how powerful that is? To be able to broadcast events
back to clients on a wide area network? Tell me how to do that with Web
services? Or with WSE 2.0 without having the client run a web service?

Mastering remoting is a key factor for me this year because I think it can
blow the doors off of anything that XML web services offers...I can write
games with it, I can do real time data islands updates. Remoting is the
real thing, XML web methods are tinkertoys for tots.
 
Hey all, thanks again for your replies.

I am sure saying remoting is a dead end they meant Indigo (WSE 2/3). I would
surely use wse2 if my clients were not win98 machines since wse2 is not
supported on win98/me.

Anyway, using remoting is not a good practice as they all say in MS. Using a
web service is the best way doing it even if it's being used in a LAN
environment. (Say that in some day you would want to move the service one
tier ahead?).

I am not sure about the MSMQ.

My example of what I am trying to develop is a Print Spooler (A windows
service) and a queue viewer lioke the printer properties.

Again, any ideas? :)

Thanks alot,
- Moty -

Nicholas Paldino said:
Actually, I would say remoting is a dead end. The only reason to use
remoting now is if you need the extensibility mechanism exposed through
the channel intercepts. Other than that, remoting doesn't a good number
of services to offer. Authentication, authorization are two examples that
come to mind.

It's been stated publically by people at MS that Enterprise Service
components will offer the easiest migration path to Indigo (it should be
as simple in some cases as just changing some attributes, assuming you
follow best practices).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Chad Z. Hower aka Kudzu said:
There are many ways to handle it. The first question then is - do you
want to use MSMQ or something
else?


Remoting itself isnt dead end. What they might have been referring to is
Indigo which will replace it.
But Indigo isnt released yet, so you either use remoting and port later,
or wait.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/
Click to expand...
Click to expand...
 
Hey Bob,

I must argue with that :).

I really think remoting has lots of disadvantages. Security is one of them.
Since XML is still not Binary, remoting is the best way doing this kind of
things, but if the 2 applications replace small amounts of data, textual xml
and Web services enhancements doe's a great work with messaging technuiqes.

Since I am in the middle of my project planning, I don't have to rearchitect
any of the ideas. That's why I am asking you, the experts about the ways of
dealing with this kind of project.

Thanks again,

- Moty -
 
I am curious about the security issue. Ingo Rammer, among others, recommends
hosting your remoted services in IIS. I agree with Bob 100%. If you have 2
..Net clients that need to communicate to each other, I would always choose a
remoting solution. Host remoted objects in IIS and use the binary formatter.
I would love to see any MS documents that say you should use web services in
preference to remoting when you do have 2 .Net clients communicating to each
other.

When Indigo arrives, by all means I would use that.

Dan
 
=?Utf-8?B?UmljaGFyZCBGLiBDaGF1dmV0?=
Indigo now offers web services the choice of protocol with a few
simple changes in the web.config file. If you want to use biniary over
TCP/IP - its yours. You get the speed of binary thru the transport
Click to expand...

Indigo is very cool - but its not released yet and many people have deadlines now. :) So its worth
checking out, but not everyone can wait for it to be released and must choose something now.
Personally I stick with webservices even though they are less efficient than remoting. If I need
something more effcient, I usually revert to a TCP server without RPC of remoting etc.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/
 
Moty Michaely said:
Using a web service is the best way doing it even if it's being used
in a LAN environment. (Say that in some day you would want to move the
service one tier ahead?).
Click to expand...

There are many opinions, but my opininion is this as well. Just use webservices, even locally. The
performance overhead is higher, but you can put a serious load on them before hitting any limits, and
they scale.
I am not sure about the MSMQ.
Click to expand...

MSMQ is a whole other system.
My example of what I am trying to develop is a Print Spooler (A
windows service) and a queue viewer lioke the printer properties.
Click to expand...

MSMQ, or Webservices. Webservices are easier to deploy and setup IMO, but it depends on if you
need MSMQ features or not.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!
http://www.atozed.com/IntraWeb/
 
Moty Michaely said:
I really think remoting has lots of disadvantages. Security is one of
them. Since XML is still not Binary, remoting is the best way doing
this kind of things, but if the 2 applications replace small amounts
Click to expand...

Remoting is a decent 1.0, but as I said in other messages I've long ago shied away from it because of
its many limitations, especially with regards to upgarding interfaces.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/
 
Thanks chad for all your replies.

I'll stick to the web service idea but is there any way of dealing with some
kind of queues? I need my service to handle a queue and the clients to be
able watiching the queue and canceling jobs from it.

???

-Moty-
 
Moty Michaely said:
I'll stick to the web service idea but is there any way of dealing
with some kind of queues? I need my service to handle a queue and the
clients to be able watiching the queue and canceling jobs from it.
Click to expand...

If the queue is internal, FCL has many objects. You can use other clietns to query the active queue
with a web method, and add another method to cancel.

If the clients will have a high level of intergration with the queue, MSMQ would be a better option.
However your case is simplistic and really can go either way depending on your needs, etc.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/
 
Back
Top