Dotnet Application Services

Applications must be a Set of Services
Applications can no longer be allowed to contain large masses of compiled executable code. Applications must be broken down into a number of smaller individual services that are easier to create and easier to maintain. Individual services should be developed and maintained by smaller groups of people. Services are not the same as executables, or components, or DLL's. Services should be answers to submitted requests. Services should be returned as data. Our best suggestion is to develop services as a number of server-side HTML and/or XML pages.
Services must not be Purpose Built
Our history is full of applications that were purpose built for a single task. Many of these applications died before they were introduced, because they could not manage new changes in the requirements. This is a terrible waste of money and time. We (and the people that pay for our applications) want to create flexible applications that are so generalized that they can gracefully support future changes. Future - not even thought about - changes should easily hook into our application without crumbling or destroying it. Our best suggestion is to create flexible standard services that can be used to serve a lot of different requests.
Services must be easy to Create and Edit
Services should not be coded if it can be avoided. If a service has to be coded, our best suggestion is to use scripts. Services should never be compiled into executables. That makes services too hard to access and to edit. Any pre-compiled component used in an application will threaten the possibility of creating an application that can move, scale and gracefully support future extensions or changes. Services should be created and modified by editing their properties and methods, not by changing their executable code. Our best suggestion is to use an XML editor to create and edit services, and to use a standard service engine to provide services by executing the service description. The service descriptions should be stored in a data store like a database or in an XML/HTML file.
Services and data must be Self Describing
Application clients must be able to query a server for a service and to ask for the current server functions. Clients and servers must also be able to exchange data in a way so that both understand each element in the data. Our best suggestion is to use an XML based information vocabulary with a DTD (Document Type Definition) to exchange server functions, and to use XML to exchange data.