A web service inside a windows service?

[Michael Riggio]

Is there a way to have a windows service instantiate a class that is a web
service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[Jason DeFontes]

I don't think a web service is internally capable of doing all the work.
I.e., it doesn't have the socket listening/request queuing code, it just
knows how to handle a request once one is handed to it. It still needs
to be hosted by some kind of web server, normally IIS, but you may be
able to modify the Cassini server to create something that could be
fully self-contained within a windows service:

http://www.asp.net/Default.aspx?tabindex=7&tabid=41

-Jason

Michael Riggio wrote:

Is there a way to have a windows service instantiate a class that is a web
service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[Michael Riggio]

This is a great start, thanks for the information!! Cassini seems pretty
straight forward (I'm stepping through the debugger), though it would be
really cool if it was a bit more simpler such that anyone can roll out their
own solution with relative ease.

Thanks!
"Jason DeFontes" <ja***@defontes .com> wrote in message
news:uM******** ******@tk2msftn gp13.phx.gbl...

I don't think a web service is internally capable of doing all the work.
I.e., it doesn't have the socket listening/request queuing code, it just
knows how to handle a request once one is handed to it. It still needs
to be hosted by some kind of web server, normally IIS, but you may be
able to modify the Cassini server to create something that could be
fully self-contained within a windows service:

http://www.asp.net/Default.aspx?tabindex=7&tabid=41

-Jason

Michael Riggio wrote:

Is there a way to have a windows service instantiate a class that is a web service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[Jason DeFontes]

Well, I'm not sure how much simpler you'd want it to be. Start IIS, drop
web service in wwwroot, go home. You're the one that wants to run it
from inside a Windows service, when it wasn't designed to work that way.
Your pain is self-inflicted.

Best of luck,

-Jason

Michael Riggio wrote:

This is a great start, thanks for the information!! Cassini seems pretty
straight forward (I'm stepping through the debugger), though it would be
really cool if it was a bit more simpler such that anyone can roll out their
own solution with relative ease.

Thanks!
"Jason DeFontes" <ja***@defontes .com> wrote in message
news:uM******** ******@tk2msftn gp13.phx.gbl...

I don't think a web service is internally capable of doing all the work.
I.e., it doesn't have the socket listening/request queuing code, it just
knows how to handle a request once one is handed to it. It still needs
to be hosted by some kind of web server, normally IIS, but you may be
able to modify the Cassini server to create something that could be
fully self-contained within a windows service:

http://www.asp.net/Default.aspx?tabindex=7&tabid=41

-Jason

Michael Riggio wrote:

Is there a way to have a windows service instantiate a class that is a
web
service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[Ray Cassick \(Home\)]

Why not just use remoting?

"Michael Riggio" <mi************ @unisys.nospam. com> wrote in message
news:O#******** *****@TK2MSFTNG P11.phx.gbl...

Is there a way to have a windows service instantiate a class that is a web
service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[DM McGowan II]

Isn't Remoting a different solution to that provided by Web Services? WS can
accept any SOAP client but Remoting requires (IIRC) .NET on the client.

"Ray Cassick (Home)" <rc************ @enterprocity.c om> wrote in message
news:OZ******** ******@TK2MSFTN GP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************ @unisys.nospam. com> wrote in message
news:O#******** *****@TK2MSFTNG P11.phx.gbl...

Is there a way to have a windows service instantiate a class that is a web service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[DalePres]

Web Services are implementations of remoting. They are wrappers around the
remoting classes but they use the same remoting classes you would use are
used by web services.

Which is also the answer to your question. Your Windows service can
absolutely consume web services. Just remember that Windows services often
do not have a user account and if your web service is on a different server,
and doesn't have anonymous access allowed, you will get access denied unless
you assign a domain account for your Windows service to run under.

Dale

"DM McGowan II" <no****@nospam. net> wrote in message
news:up******** ************@co mcast.com...

Isn't Remoting a different solution to that provided by Web Services? WS can accept any SOAP client but Remoting requires (IIRC) .NET on the client.

"Ray Cassick (Home)" <rc************ @enterprocity.c om> wrote in message
news:OZ******** ******@TK2MSFTN GP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************ @unisys.nospam. com> wrote in message
news:O#******** *****@TK2MSFTNG P11.phx.gbl...

Is there a way to have a windows service instantiate a class that is a web service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[Ray Cassick \(Home\)]

Web services are really just a remoted service hosted within IIS. They use
IIS as a transport (HTTP CHannel) and to manage the connections. Other than
that there is really very little difference. The major difference is that
web services are only allowed to use the SOAP Format for communications
while remoting can use either SOAP or a binary formatter.

You can write a remoted service, telkl it to use the SOAP formatter and the
HTTP channel and it is baisicaly a web service.

Personally, unless you are planning to exspose the service externally
(outside the enterprise) use remoting with the binary formatter. Faster,
less connecton overhead and IMHO a bit more secure because you don;t need a
machine running IIS to host it. You can just write a windows service.

Here is *some* links that show the differecnes:

http://www.developer.com/net/net/art...1087_2201701_1

http://dotnetjunkies.com/WebLog/chri...1/31/6385.aspx
"DM McGowan II" <no****@nospam. net> wrote in message
news:up******** ************@co mcast.com...

Isn't Remoting a different solution to that provided by Web Services? WS can accept any SOAP client but Remoting requires (IIRC) .NET on the client.

"Ray Cassick (Home)" <rc************ @enterprocity.c om> wrote in message
news:OZ******** ******@TK2MSFTN GP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************ @unisys.nospam. com> wrote in message
news:O#******** *****@TK2MSFTNG P11.phx.gbl...

Is there a way to have a windows service instantiate a class that is a web service, which will then be accessible to clients via HTTP?

Thanks,

-Mike

[Sami Vaaraniemi]

"Ray Cassick (Home)" <rc************ @enterprocity.c om> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Web services are really just a remoted service hosted within IIS. They use
IIS as a transport (HTTP CHannel) and to manage the connections. Other than that there is really very little difference. The major difference is that
web services are only allowed to use the SOAP Format for communications
while remoting can use either SOAP or a binary formatter.

You can write a remoted service, telkl it to use the SOAP formatter and the HTTP channel and it is baisicaly a web service.

There are some fundamental differences between .NET remoting and Web
services,
so I would not go as far as calling Web services just another way of doing
remoting.

One big difference is that with remoting the end points share types. Both
remoting
parties typically have a copy of an assembly that contains the shared types.
..NET remoting
infrastructure serilizes and deserializes instances of these types while
they are on the wire.

Web services and their consumers, on the other hand, exchange XML messages.
These
messages can be mapped to and from objects in the end points, but the
difference is that
the Web service and the consumer typically do not have a shared assembly
containing the
types.

This is a big difference because it has implications on e.g., how the
communication
endpoints can evolve over time. Another difference is that Web services are
more
message-oriented than based on the notion of calling methods remotely.

Web services also provide security (WS-Security) and other infrastructure
that .NET
remoting does not provide. This functionality is already available with Web
Services
Enhancements (WSE). With remoting, you'd have to implement most of that
stuff on
your own.

Regards,
Sami

[DM McGowan II]

I researched this recently then created a small benchmark to compare the
performance of Remoting SOAP to Remoting Binary.

Firstly, Remoting SOAP is not 100% compatible with Web Service SOAP and
there is more overhead in the case where you can coax it to work. This is
documented in numerous articles on the Web.

Next, I found Remoting SOAP to be a minimum of 5 times slower than Remoting
Binary so I agree that within the enterprise, binary is the best option
unless the design can't afford to have all clients tied to the .NET
Architecture which would put you back in Web Services. True Web Services not
Remoting pseudo web services.

Overall I'd say that Michael is right to start with the Cassini source and
design a solution from there.

"Ray Cassick (Home)" <rc************ @enterprocity.c om> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Web services are really just a remoted service hosted within IIS. They use
IIS as a transport (HTTP CHannel) and to manage the connections. Other than that there is really very little difference. The major difference is that
web services are only allowed to use the SOAP Format for communications
while remoting can use either SOAP or a binary formatter.

You can write a remoted service, telkl it to use the SOAP formatter and the HTTP channel and it is baisicaly a web service.

Personally, unless you are planning to exspose the service externally
(outside the enterprise) use remoting with the binary formatter. Faster,
less connecton overhead and IMHO a bit more secure because you don;t need a machine running IIS to host it. You can just write a windows service.

Here is *some* links that show the differecnes:

http://www.developer.com/net/net/art...1087_2201701_1

http://dotnetjunkies.com/WebLog/chri...1/31/6385.aspx
"DM McGowan II" <no****@nospam. net> wrote in message
news:up******** ************@co mcast.com...

Isn't Remoting a different solution to that provided by Web Services? WS

can

accept any SOAP client but Remoting requires (IIRC) .NET on the client.

"Ray Cassick (Home)" <rc************ @enterprocity.c om> wrote in message
news:OZ******** ******@TK2MSFTN GP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************ @unisys.nospam. com> wrote in message
news:O#******** *****@TK2MSFTNG P11.phx.gbl...
> Is there a way to have a windows service instantiate a class that is

a web

> service, which will then be accessible to clients via HTTP?
>
> Thanks,
>
> -Mike
>
>
>