Windows Service

[Moty Michaely]

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.

[Nicholas Paldino [.NET/C# MVP]]

Re: Windows Service

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]
- mvp@spam.guard. caspershouse.co m

"Moty Michaely" <moty@speedocs. co.il> wrote in message
news:OYtvGoadFH A.1684@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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.
>[/color]

[Moty Michaely]

Re: Windows Service

Nocholas, Thanks for the rapuid reply.

...."communicat ions 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 [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
message news:ex1AmradFH A.3040@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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]
> - mvp@spam.guard. caspershouse.co m
>
> "Moty Michaely" <moty@speedocs. co.il> wrote in message
> news:OYtvGoadFH A.1684@TK2MSFTN GP09.phx.gbl...[color=green]
>> 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.
>>[/color]
>
>[/color]

[Chad Z. Hower aka Kudzu]

Re: Windows Service

"Moty Michaely" <moty@speedocs. co.il> wrote in
news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl:[color=blue]
> 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[/color]

There are many ways to handle it. The first question then is - do you want to use MSMQ or something
else?
[color=blue]
> 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.[/color]

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/
"Programmin g is an art form that fights back"

Develop ASP.NET applications easier and in less time:

http://www.atozed.com/IntraWeb/

[Nicholas Paldino [.NET/C# MVP]]

Re: Windows Service

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]
- mvp@spam.guard. caspershouse.co m


"Chad Z. Hower aka Kudzu" <cpub@hower.org > wrote in message
news:Xns967BC3A A439Ccpubhowero rg@127.0.0.1...[color=blue]
> "Moty Michaely" <moty@speedocs. co.il> wrote in
> news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl:[color=green]
>> 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[/color]
>
> There are many ways to handle it. The first question then is - do you want
> to use MSMQ or something
> else?
>[color=green]
>> 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.[/color]
>
> 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/
> "Programmin g is an art form that fights back"
>
> Develop ASP.NET applications easier and in less time:
> http://www.atozed.com/IntraWeb/[/color]

[Bob Grommes]

Re: Windows Service

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

"Moty Michaely" <moty@speedocs. co.il> wrote in message
news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl...
[color=blue]
> 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.[/color]

[Richard F. Chauvet]

Re: Windows Service

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
ProcessServiceM odel 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.

--
Richard Chauvet


"Bob Grommes" wrote:
[color=blue]
> 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
>
> "Moty Michaely" <moty@speedocs. co.il> wrote in message
> news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl...
>[color=green]
> > 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.[/color]
>
>
>[/color]

[Bob Grommes]

Re: Windows Service

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

"Richard F. Chauvet" <RichardFChauve t@discussions.m icrosoft.com> wrote in
message news:EFFC7BE2-A2F9-4799-A5DA-28B593A83B63@mi crosoft.com...[color=blue]
> 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
> ProcessServiceM odel 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.
>
> --
> Richard Chauvet
>
>
> "Bob Grommes" wrote:
>[color=green]
>> 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
>>
>> "Moty Michaely" <moty@speedocs. co.il> wrote in message
>> news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl...
>>[color=darkred]
>> > 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.[/color]
>>
>>
>>[/color][/color]

[Moty Michaely]

Re: Windows Service

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 [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
message news:uwFvzYbdFH A.3280@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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]
> - mvp@spam.guard. caspershouse.co m
>
>
> "Chad Z. Hower aka Kudzu" <cpub@hower.org > wrote in message
> news:Xns967BC3A A439Ccpubhowero rg@127.0.0.1...[color=green]
>> "Moty Michaely" <moty@speedocs. co.il> wrote in
>> news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl:[color=darkred]
>>> 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[/color]
>>
>> There are many ways to handle it. The first question then is - do you
>> want to use MSMQ or something
>> else?
>>[color=darkred]
>>> 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.[/color]
>>
>> 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/
>> "Programmin g is an art form that fights back"
>>
>> Develop ASP.NET applications easier and in less time:
>> http://www.atozed.com/IntraWeb/[/color]
>
>[/color]

[Moty Michaely]

Re: Windows Service

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 -

"Bob Grommes" <bob@bobgrommes .com> wrote in message
news:OyeGkabdFH A.3328@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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
>
> "Moty Michaely" <moty@speedocs. co.il> wrote in message
> news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl...
>[color=green]
>> 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.[/color]
>
>[/color]

[jabailo@texeme.com]

Re: Windows Service

Moty Michaely wrote:

[color=blue]
> 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.
>[/color]

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.


--
Texeme Textcasting Technology

http://www.texeme.com

[Moty Michaely]

Re: Windows Service

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 [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
message news:uwFvzYbdFH A.3280@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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]
> - mvp@spam.guard. caspershouse.co m
>
>
> "Chad Z. Hower aka Kudzu" <cpub@hower.org > wrote in message
> news:Xns967BC3A A439Ccpubhowero rg@127.0.0.1...[color=green]
>> "Moty Michaely" <moty@speedocs. co.il> wrote in
>> news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl:[color=darkred]
>>> 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[/color]
>>
>> There are many ways to handle it. The first question then is - do you
>> want to use MSMQ or something
>> else?
>>[color=darkred]
>>> 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.[/color]
>>
>> 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/
>> "Programmin g is an art form that fights back"
>>
>> Develop ASP.NET applications easier and in less time:
>> http://www.atozed.com/IntraWeb/[/color]
>
>[/color]

[Moty Michaely]

Re: Windows Service

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 -

"Bob Grommes" <bob@bobgrommes .com> wrote in message
news:OyeGkabdFH A.3328@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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
>
> "Moty Michaely" <moty@speedocs. co.il> wrote in message
> news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl...
>[color=green]
>> 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.[/color]
>
>[/color]

[jabailo@texeme.com]

Re: Windows Service

Moty Michaely wrote:

[color=blue]
> 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.
>[/color]

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.


--
Texeme Textcasting Technology

http://www.texeme.com

[Dan Kelley]

Re: Windows Service

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

"Moty Michaely" wrote:
[color=blue]
> 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 -
>
> "Bob Grommes" <bob@bobgrommes .com> wrote in message
> news:OyeGkabdFH A.3328@TK2MSFTN GP09.phx.gbl...[color=green]
> > 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
> >
> > "Moty Michaely" <moty@speedocs. co.il> wrote in message
> > news:OyHMIwadFH A.1276@tk2msftn gp13.phx.gbl...
> >[color=darkred]
> >> 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.[/color]
> >
> >[/color]
>
>
>[/color]