Windows services are applications that conform to the interface of the Windows Service Control Manager (SCM). ACM is the part of Windows that is responsible for managing Windows services.
Windows services are quite distinct from regular Windows applications. One of most apparent distinctions is that Windows applications usually lack GUI. In addition, Windows services typically run in the background and run in their own process with a specific user identity.
Windows services must be installed in the Windows services database before they can be used. The Windows services database is a part of the Windows Registry. It is recommended, however, that you should not directly modify the database but modify the database through the SCM instead.
You can easily create Windows services by using the functionality provided by the System.ServiceProcess.ServiceBase class.
The System.ServiceProcess.ServiceProcessInstaller and the System.ServiceProcess.ServiceInstaller classes provide the functionality for the custom installation of Windows service applications.
In order for installation tools such as installutil.exe to install an assembly, the assembly must have a class derived from System.Configuration.Install.Installer . If any custom installers (such as Windows service installers) need to be installed, they are added to the Installers collection of the Installer class.
Several tools are available for monitoring and controlling Windows services. Some notable tools are the Services MMC snap-in, Visual Studio .NET Server Explorer, the net.exe command-line utility, and the Service Control command-line utility (sc.exe).
Some programs might also need to monitor Windows services programmatically. The FCL provides the System.ServiceProcess.ServiceController class to programmatically control the Windows services.
The ServiceController.GetServices() method is used to enumerate installed services on a computer. You can use the Start() , Stop() , Pause() , and Continue() methods to change the status of a Windows service. The WaitforStatus() synchronous method is useful when you would like the current thread to pause execution and wait for the Windows service to enter in the specified state.
When the SCM sends a start message to a Windows service, first the Main() method of the Windows service application is executed. This method creates one or more instances of the Windows services and passes them to the Run() method of the ServiceBase class. This method provides the references of Windows service objects to the SCM. SCM uses these references to communicate with the Windows service.
The Service Control utility (sc.exe) is distributed as a part of Windows XP and later operating systems and as a part of Win32 SDK and the .NET Framework SDK. This utility is the most powerful tool to control and configure Windows services.
Instead of providing a new version of component services, Microsoft .NET Framework relies on the COM+ component services that ship as a part of Windows 2000, Windows XP, and the Windows .NET servers.
COM+ component services provide several features for increasing the security, reliability, availability, efficiency, and scalability of an enterprise application as part of the operating system infrastructure.
A distributed application might use different types of applications such as a Windows application, Windows service, Web application, Web service, Remoting server, and so on to consume a serviced component.
Classes that want to use COM+ component services must derive from the System.EnterpriseServices.ServicedComponent class.
To use COM+ services in your program, you need not write a lot of code. Instead, you use declarative attributes to specify whether a class should receive particular services.
The declarative attributes applied to a class are stored in the COM+ catalog as part of the assembly registration process. At runtime, COM+ can read the COM+ catalog to determine what services a component should receive and provide those services.
COM+ uses interception to provide various runtime services. Interception is a mechanism that allows COM+ to capture calls to any object and execute its own code before passing the call to the object.
COM+ creates different contexts for objects that have different runtime requirements. A proxy is used to provide interception services between the objects in different contexts.
The COM+ object pooling service allows you to maintain already created instances of a component that are ready to be used by any client that requests the component.
To use the object pooling service, a class must override the CanBePooled() method of the ServicedComponent class. In addition, you need to apply the ObjectPooling attribute on the class or configure the component via the Component Services administrative tool to use object pooling.
The COM+ Just in Time activation service allows you to minimize the period of time an object lives and consumes resources on the server.
You can enable the just-in-time activation service declaratively in your programs by using the JustInTimeActivation attribute or administratively via the Component services administrative tool. You must, however, indicate to COM+ whether an object should be deactivated after a method call by setting the done bit to true.
The COM+ object construction service allows you to specify initialization information for a serviced component. It is possible to use the Component Services administrative tool and configure the initialization information for a component to change the way a component behaves.
A transaction is a series of operations performed as a single unit. A transaction is successful only when all the operations in that transaction succeed.
The outcome of a transaction depends on the status of the abort bit that is maintained in the context of a transaction and the consistent and done bits, which are maintained in each context.
You can use the methods of the ContextUtil class to change the status of the consistent and done bits programmatically.
The AutoComplete attribute automatically calls the ContextUtil.SetComplete() method if a method completes successfully; otherwise , ContextUtil.SetAbort() is called to abort the transaction.
A queued component is a serviced component that can be invoked and executed asynchronously. With the help of a queued component, you can make your application available even when some of its components are not.
COM+ does not understand .NET and therefore cannot directly provide services to the .NET component. Instead, a .NET component must be exposed as a COM component using an assembly registration process.
To enable the communication between COM and .NET components, the .NET Framework generates a COM Callable Wrapper (CCW). The CCW enables communication between the calling COM code and the managed code and handles conversion between the data types and other messages between the COM types and the .NET types.
If configuration at the method level is required, a class must implement an interface with those methods.
Depending on the ClassInterface attribute to automatically generate class interfaces is bad because it leads to versioning problems. You should set the ClassInterface attribute for a class to the ClassInterfaceType.None value and create your own interface explicitly.
An assembly must be signed with a strong name before the assembly can be registered into the COM+ catalog.
A serviced component is generally shared by several client applications. Therefore, the most recommended place to install a serviced component assembly is the Global Assembly Cache (GAC) because it ensures that the CLR is always capable of locating an assembly.
Administrators can use the Component Services administrative tool to configure COM+ applications at runtime. Using this tool, they can change certain behaviors of a COM+ application without needing to recompile the application.
An Application domain, or AppDomain , is the smallest execution unit for a .NET application. The CLR enables several application domains to run within a single Windows process.
Distributed Applications enable communication between objects that run in different application domains and processes.
The System.Net , System.Runtime.Remoting , and System.Web.Services namespaces enable .NET Framework to support distributed application development.
.NET remoting enables objects in different application domains to talk to each other even when they are separated by applications, computers, or the network.
The process of packaging and sending method calls among objects across the application boundaries via serialization and deserialization is called marshalling.
Marshal- by-value (MBV) and Marshal-by-reference (MBR) are the two types of remotable objects. MBV objects are copied to the client application domain from the server application domain, whereas only a reference to the MBR objects is maintained in the client application domain. A proxy object is created at the client side to interact with the MBR objects.
MBR remotable objects can be activated in two modes: Server-activated mode and Client-activated mode.
Server-activated objects (SAO) are those remote objects whose lifetime is directly controlled by the server.
You can activate SAOs in two ways: SingleCall (object is created for each client request) and Singleton (object is created once on the server and is shared by all clients ).
The SingleCall activation mode provides the maximum scalability because it does not maintain any state and the object lives for the shortest duration possible.
Client-Activated Objects (CAOs) are created for each client when the client requests to create a remote object. These objects maintain state for each client with which they are associated.
The leased-based lifetime process determines how long the Singleton SAO and CAO should exist.
A channel is an object that transports messages across remoting boundaries such as application domains, processes, and computers. The .NET Framework provides implementations for HTTP and TCP channels to enable the communication of messages over the HTTP and TCP protocols, respectively.
A channel has two end points. A channel at the receiving end, the server, listens for messages at a specified port number from a specific protocol; a channel object at the sending end, the client, sends messages through the specified protocol at the specified port number.
Formatters are objects used to serialize and deserialize data into messages before they are transmitted over a channel. You can format messages in SOAP or the binary format with the help of the SoapFormatter and BinaryFormatter classes in the FCL.
The default formatter to transport messages to and from the remote objects is the SOAP formatter for the HTTP channel and is the binary formatter for the TCP channel.
You should create a server channel that listens on a given port number and register the channel with the remoting framework before you register the remotable class.
The type of channel registered by the client must be compatible with the type of channel used by the server for receiving messages.
You do not specify a port number when you register the client channel. The port number is instead specified at the time of registering the remote class in the client's domain.
To register SAO objects, you call the RemotingConfiguration.RegisterWellKnownServiceType() method on the server side and the RemotingConfiguration.RegisterWellKnownClientType() method on the client side.
To register CAO objects, you call the RemotingConfiguration.RegisterActivatedServiceType() method on the server side and the RemotingConfiguration.RegisterActivatedClientType() method on the client side.
You can only instantiate Server-Activated Objects at the client side using their default constructor, whereas you can instantiate Client-Activated Objects using any of the object's constructors.
The .NET Framework allows you to store remoting configuration details in an XML-based configuration file instead of the code file. This causes any changes in the configuration file to be automatically picked up rather than recompiling the code files.
To configure remoting configuration details from configuration files, you should call the RemotingConfiguration.Configure() method and pass the name of the configuration file.
You can distribute the interface assembly to the client instead of the implementation assembly by creating an interface that defines the contract and exposes the member definitions to the client. The remotable class should implement this interface.
You can use the soapsuds tool to automatically generate the interface class for the remotable object instead of manually defining the interface. However, the soapsuds tool only works when the HTTP channel is used for communication.
To create an interface that allows creating client-activated remote objects, you should create an additional interface that declares as many different methods as there are constructors in the remotable class. Each of these methods should be able to create the remote object in a way defined by its corresponding constructor.
You can invoke a method asynchronously by calling the BeginInvoke() method on the delegate of that method.
You can automatically get a notification when an asynchronous method ends. However, you must first create another delegate object (of AsyncCallback type) that refers to the callback method that you need to execute when the remote method ends. Then you should pass the delegate to the callback method as an argument to the BeginInvoke() method.
You can choose to run the remoting host as a console application, as a Windows service, or as an IIS application.
You can use IIS as an activation agent only when the underlying communication is in the HTTP channel. Using IIS as an activation agent eliminates the need to write a separate server program that listens on a unique port number. (IIS uses port 80.)
When creating IIS hosted remote objects, you cannot specify constructor parameters; therefore, activating CAO is not possible using IIS.
To create a remotable class, inherit the remotable class from the MarshalByRefObject class.
A remotable class is usually connected with the remoting framework through a separate server program. The server program listens to the client request on a specified channel and instantiates the remote object or invokes calls on it as required.
Web services provide you with the means to create objects and invoke their methods even though your only connection to the server is via the Internet.
Communication with Web services is via XML messages transported by the HTTP protocol.
Because they communicate over HTTP, Web services are typically not blocked by firewalls.
The Simple Object Access Protocol (SOAP) encapsulates object-oriented messages between Web service clients and servers.
The Universal Description, Discovery, and Integration protocol (UDDI) allows you to find Web services by connecting to a directory.
The Web Services Description Language (WSDL) lets you retrieve information on the classes and methods that are supported by a particular Web service.
Properties of the WebMethod attribute let you control such things as the cache duration, session state, and transactions of the Web Method.
You should be cautious about using session state in a Web service. Session state can tie up server resources for an extended period of time. If you use session state with a popular Web service, you will apply heavy demands to RAM on your Web server.
A SOAP extension allows you to intercept SOAP messages at all stages of processing: before and after serialization and before and after deserialization.
SOAP extensions are classes derived from the base SoapExtension class.
SOAP extensions can run on a Web services client, server, or both.
The GetInitializer method is called once when the SOAP extension is first loaded.
The Initialize method is called once for each call to a Web method being monitored by the SOAP extension.
The ChainStream method allows you to intercept the actual SOAP message stream.
The ProcessMessage method is called with the actual SOAP requests and responses.
By default, calls to a Web method are synchronous and block the client program until the SOAP response is returned.
Proxies generated by wsdl.exe also allow you to make asynchronous calls to a Web service.
One way to make an asynchronous Web Method call is to supply a delegate function that the .NET Framework will call back when the SOAP response is ready.
Another way to make an asynchronous Web Method call is to use a WaitHandle object to wait for one or more calls to complete.
Asynchronous Web method calls can be aborted by calling the Abort method of an appropriate WebClientAsyncResult object.
SOAP messages can be formatted in a variety of ways. You can use literal or encoded parameter formatting, document or RPC-style body formatting, and wrapped or bare parameters.
The .NET Framework allows you to dictate the format of SOAP messages through applying attributes to the Web service or Web method at both the server and the proxy class.
The XmlElement attribute allows you to specify the name and other details of a parameter in a SOAP message.
Visual Studio .NET includes an ASP.NET Web Service template that you can use to build your own Web services.
To make a class available via a Web service, you mark the class with the WebService attribute.
To make a method available via a Web service, you mark the method with the WebMethod attribute.
To test a Web service, run the project in the Visual Studio .NET IDE.
You can generate proxy classes for a Web service manually by using the Web Services Description Language tool.
You can generate proxy classes for a Web service automatically by setting a Web reference to point to the Web service.
You can test and debug a Web service without a client application by using one of several SOAP proxy tools.
The most important security decision you must make with a Windows service is which security account should be used to run the service. You can choose between the LocalSystem account or a user account on Windows 2000. On Windows XP, the LocalService and NetworkService accounts provide additional flexibility.
Because Web services are hosted by ASP.NET, they have the entire spectrum of IIS authentication, authorization, and security features available to them.
You can use IIS to control access to a Web service, and then use declarative or imperative security to control the access of the Web service to resources.
WS-Security is a new specification for a set of SOAP headers to handle authentication, encryption, and signing directly in SOAP messages.
Remoting servers that require secure hosting are best run in the ASP.NET process. Remoting servers that require additional speed but less security can be run in a Windows service host instead.
You can configure security for serviced components by applying attributes within the code for the components and then specifying COM+ roles with the Component Services tool.
Using COM components from .NET managed code requires the creation of an RCW.
You can create an RCW for a COM component by using the Type Library Importer tool or by directly referencing the COM component from your .NET code.
To use COM components that you did not create, you should obtain a PIA from the creator of the component.
RCWs impose a performance penalty on COM code.
You can use the .NET Framework platform invoke facility to call functions from Windows libraries, including the Windows API.
You should use the StringBuilder object for a Windows API call that expects a string buffer to be modified by the function.