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**************@tk2msftngp13.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**************@tk2msftngp13.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#*************@TK2MSFTNGP11.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.com> wrote in message
news:OZ**************@TK2MSFTNGP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************@unisys.nospam.com> wrote in message
news:O#*************@TK2MSFTNGP11.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********************@comcast.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.com> wrote in message
news:OZ**************@TK2MSFTNGP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************@unisys.nospam.com> wrote in message
news:O#*************@TK2MSFTNGP11.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********************@comcast.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.com> wrote in message
news:OZ**************@TK2MSFTNGP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************@unisys.nospam.com> wrote in message
news:O#*************@TK2MSFTNGP11.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]

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.com> wrote in message
news:%2****************@TK2MSFTNGP09.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********************@comcast.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.com> wrote in message
news:OZ**************@TK2MSFTNGP11.phx.gbl...

Why not just use remoting?

"Michael Riggio" <mi************@unisys.nospam.com> wrote in message
news:O#*************@TK2MSFTNGP11.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
>
>
>

[Michael Riggio]

Simpler in the fact that what's in System.Web.Hosting doesn't include the
tcp listening objects that are really needed. Cassini provides wrapper
classes that allow an application to do exactly what I want, its just a
shame MS didn't add these classes to the framework to begin with, that's
all.

"Jason DeFontes" <ja***@defontes.com> wrote in message
news:Oz**************@TK2MSFTNGP09.phx.gbl...

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**************@tk2msftngp13.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

[Michael Riggio]

I suppose a little background information is needed to describe my
situation. We have a windows service that constantly maintains a bunch of
objects in the background. We would like to expose these objects through a
web service. We're able to use COM to get access to the objects in the
windows service, but when we introduce the web service it means that we'll
be taking a performance hit when crossing process boundaries. I was hoping
that a solution similar to that provided by Cassini would eliminate the
costs of going cross process because the web service and windows service
would be under the same process, but I don't think it will (based on my
initial tests). We have a singleton object in the windows service that is
the main entry point to all the other objects and is created when the
windows service starts. When the web service (implemented inside the
windows service) attempts to access the singleton all the initialization
code gets executed again (as if the singleton was not created yet).

Does anyone have any other suggestions before I give up on this :)

Thanks!
"DM McGowan II" <no****@nospam.net> wrote in message
news:cr********************@comcast.com...

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.com> wrote in message
news:%2****************@TK2MSFTNGP09.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********************@comcast.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.com> wrote in message news:OZ**************@TK2MSFTNGP11.phx.gbl...
> Why not just use remoting?
>
> "Michael Riggio" <mi************@unisys.nospam.com> wrote in message
> news:O#*************@TK2MSFTNGP11.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
> >
> >
> >
>
>

[Jason DeFontes]

Are you giving up because you couldn't get it to work, or because you
think it isn't worth the trouble? I was talking out of my ass when I
suggested Cassini in the first place, so now I'm curious to know if it
was a dead end.

In my opinion, given the huge overhead inherent in the web service to
begin with, crossing a process boundary to get a COM object is a drop in
the bucket. Better off running the web service on top of IIS were you
can manage it more easily.

-Jason

Michael Riggio wrote:

I suppose a little background information is needed to describe my
situation. We have a windows service that constantly maintains a bunch of
objects in the background. We would like to expose these objects through a
web service. We're able to use COM to get access to the objects in the
windows service, but when we introduce the web service it means that we'll
be taking a performance hit when crossing process boundaries. I was hoping
that a solution similar to that provided by Cassini would eliminate the
costs of going cross process because the web service and windows service
would be under the same process, but I don't think it will (based on my
initial tests). We have a singleton object in the windows service that is
the main entry point to all the other objects and is created when the
windows service starts. When the web service (implemented inside the
windows service) attempts to access the singleton all the initialization
code gets executed again (as if the singleton was not created yet).

Does anyone have any other suggestions before I give up on this :)

Thanks!
"DM McGowan II" <no****@nospam.net> wrote in message
news:cr********************@comcast.com...

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.com> wrote in message
news:%2****************@TK2MSFTNGP09.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********************@comcast.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.com> wrote in
message
news:OZ**************@TK2MSFTNGP11.phx.gbl.. .

>Why not just use remoting?
>
>"Michael Riggio" <mi************@unisys.nospam.com> wrote in message
>news:O#*************@TK2MSFTNGP11.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
>>
>>
>>
>
>