A web service inside a windows service?

  • Thread starter Thread starter Michael Riggio
  • Start date Start date
M

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
 
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
 
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!
 
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
 
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.
 
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
 
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/article.php/11087_2201701_1

http://dotnetjunkies.com/WebLog/chris.taylor/archive/2004/01/31/6385.aspx
 
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.
 
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.
 
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!
 
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
 
Back
Top