Tech Off Post

Single Post Permalink

View Thread: Future Suggestions for Windows Services
  • User profile image

    While it is true that I could come up with certain solutions on my own, my strategy to deal with these problems would differ from the strategies (if any) used by other developers and vendors and that could cause a confusing experience for the end user. Also, the majority of third party services also run under the local system account.


    Services are really popular now for firewalls, antivirus software, database engines, etc. My current service application that I’m working on is conference software that allows users to chat with one another through multiple interfaces (telnet, specialized GUI client software, and the Web). Running as a service has a lot of advantages: (1) it can be controlled via the service controller locally or remotely from another computer, (2) it has built in failsafe if the server should go down (you can give services instructions on whether to restart or reboot the machine or whatever), (3) it can run when no user is logged onto the machine and users logging on and off don’t disrupt the server at all.


    My service application has multiple services in it (which is one reason a tabbed view might be cool, and maybe a tree node view for service applications so you can see all the services that belong to them them), such as the interface for telnet, the interface for smart clients, and the interface that exports Web services. It also has an NNTP service for newsgroups. I’m not the worst offender though. Oracle has like 10+ services.


    With all the attention services are receiving today, I thought maybe the service controller would be organized more like the Global Assembly Cache in .NET which is pretty well guarded against naming and versioning conflicts with strong naming.


    As for SQL Server, Exchange, or BizTalk, I’m not sure. They’re not core services and they’re not third party either. Maybe you should be able to create different sections like you can in the event log.