Advertisement

Abstract

Recall the earlier example on.NET remoting, in which we created a console application that hosts the remoting objects. To make the remoting objects available to access from clients, we must first start the console application. This is perfectly all right during development. It is no trouble at all to take the extra step to start the hosting application for the remoting objects. That is not the case when we deploy the application in a production environment. Users expect your remoting objects to be up and running after they turn on the machine. If you used the same console applications to host your remoting object, the system administrator would have to log on the machine and start each console application one by one in order for the remoting object to work, and they would have to repeat this process each time the machine reboots. Even after the console applications are started, they can be accidentally turned off by closing the console window. Running your application on the console also has security implications. When the administrator logs on the machine and starts your applications, you application will be running under the identity of the administrator. Some administrators prefer to use the local administrator account, while others prefer the domain administrator account. So your application may have either too little or too much privilege with respect to what it actually needs.

Keywords

Service Application Configuration File Business Logic User Account Main Thread 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Copyright information

© Xin Chen 2004

Authors and Affiliations

  • Xin Chen
    • 1
  1. 1.Xtremework, Inc.USA

Personalised recommendations