windows-xp/Source/XPSP1/NT/inetsrv/iis/config/info/urt configuration system re...

<HTML>

<HEAD>
<TITLE>
URT Configuration System Requirements
</TITLE>
</HEAD>

<BODY LANG=EN-US LINK=blue VLINK=maroon>

<a name="top"></a>
<H1>URT Configuration System Requirements</H1>

<em>
<b>Specification</b><br>
Universal Runtime<br>
<font color=red>Microsoft Confidential</font>
</em>

<p>

<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="100%">
 <tr>
  <td>Author</td>
  <td><a href="mailto:vanvan">Van Van</a></td>
 </tr>
 <tr>
  <td>Area</td>
  <td>Configuration System</td>
 </tr>
 <tr>
  <td>SubArea</td>
  <td>Requirements</td>
 </tr>
 <tr>
  <td>Program Management</td>
  <td><a href="mailto:markush">Markus Horstmann</a></td>
 </tr>
 <tr>
  <td>Development</td>
  <td><a href="mailto:rcraig">Robert Craig</a></td>
 </tr>
 <tr>
  <td>Test</td>
  <td><a href="mailto:mikefan">Michael Fanning</a></td>
 </tr>
 <tr>
  <td>Reviewers</td>
  <td>
    <a href="mailto:boydm">Boyd Multerer</a>;
    <a href="mailto:rcraig">Robert Craig</a>;
    <a href="mailto:billdev">Bill Devlin</a>
  </td>
 </tr>
 <tr>
  <td>Current Version</td>
  <td>
   0.3 : 9/12/99 : added two (2) runtime requirements per StevenPr - VanVan<br>
  </td>
 </tr>
 <tr>
  <td>Version History</td>
  <td>
   0.2 : 9/2/99 : added general requirements - VanVan<br>
   0.1 : 8/17/99 : file created - VanVan<br>
  </td>
 </tr>
 <tr>
  <td>Status</td>
  <td><b>In Progress</b></td>
 </tr>
</TABLE>

<p>

<hr size=2 width="100%" align=center>

<a name="TOC"></a>
<!-- TABLE OF CONTENTS -->

<TABLE BORDER=0 CELLPADDING=0 WIDTH="100%">
 <tr>
  <td><a href="#Overview">Overview</a></td>
  <td></td>
 </tr>
 <tr>
  <td><a href="#Justification">Justification</a></td>
  <td></td>
 </tr>
 <tr>
  <td><a href="#General Requirements">General Requirements</a></td>
  <td></td>
 </tr>
 <tr>
  <td>Groups</td>
  <td>
   <a href="#AppSrv">Application Server</a><br>
   <a href="#Ducttape">Duct Tape</a><br>
   <a href="#Runtime">Runtime</a><br>
   <a href="#XSP">XSP</a><br>
 </tr>
</TABLE>

<hr size=2 width="100%" align=center>

<p>

<h2><a name="Overview">Overview</a></h2>
<p>
As we move forward in planning for and designing the Configuration
System for URT 1.0, it is critical that we understand who our customers
are and what their individual requirements are.  This document will
serve as a repository for the individual requirements from each team
and will be updated as requirements are gathered and consolidated.  We
will be discussing the issues with each requirement and prioritizing
them as well.  <em>Please note that this document is specifically
implementation independent.  Implementation details will be covered in
the design specification.</em>
<p>
This document will eventually be merged with the final design
specification when that becomes available.
<p>

<hr size=2 width="100%" align=center>

<p>

<h2><a name="Justification">Justification</a></h2>

<p>
Without a list of requirements in hand, it is difficult, if not
impossible to build a system that will satisfy every groups needs.  The
goal of the URT Configuration Team is to provide a unified Configuration
System for the entire URT.  In order to do so, our first step is to
collect and reflect on all the requirements as we understand them.  If
you find any information here to be inaccurate or incorrect, please feel
free to contact <a href="mailto:vanvan">Van Van</a>.
<p>

<hr size=2 width="100%" align=center>

<p>

<h2><a name="General Requirements">General Requirements</a></h2>

The following requirements were accepted as a group as the general
requirements of the URT Configuration System.  This is (again)
irrespective of implementation and group.

<ul>
 <li>There is a need for generic (pre-defined) objects in the config
 system</li>
 <li>There is also a need for outputting strongly typed (custom) objects
 from the configuration system</li>
 <li>There is a need for generic (base) config factories that performs
 common merging logic (something that covers the 80% - 90% case)</li>
 <li>There is a need for a layer (layered approach) on top of the base
 config factories which enable third parties to hook in their custom
 merge logic</li>
</ul>
<p>
The following are more concrete requirements by the URT as a whole in no
particular order:
<ul>
 <li>XML File based - Specifically for the HTTP Host</li>
 <li>The Stores return data in a consistent format regardless of storage
 container</li>
 <li>The system supports directives</li>
 <li>Directives are expressed in the form of XML</li>
 <li>The system supports hierachical containment and inheritence</li>
 <li>Configuration Consumers recieve objects</li>
 <li>System is Extensible in these fashions
  <ul>
   <li>Stores</li>
   <li>Config Factories/Config Property based merging rules</li>
   <li>Application Hosts</li>
  </ul>
 </li>
 <li>Runs on all URT Platforms
  <ul>
   <li>Win2K (Server and Workstation)</li>
   <li>NT4 (Server and Workstation)</li>
   <li>Win9x (exact flavors to be determined)</li>
   <li>Ultimately WinCE - Not for prerelease</li>
  </ul>
 </li>
 <li>Supports all known application hosts
  <ul>
   <li>HTTP</li>
   <li>EXE</li>
   <li>IE Hosted Apps</li>
   <li>VBS - not in pre-release</li>
  </ul>
 </li>
 <li>Supports secure store of secrets</li>
 <li>Allows securing of configuration system</li>
 <li>Supports change notification of configuration files</li>
 <li>Object Caching in the configuration system</li>
</ul>
<p>

<hr size=2 width="100%" align=center>

<p>

<h2>Individual Group Requirements</h2>

<p>
The following are (listed by the individual groups) the list of
requirements as we understand them so far.  You can go to specific areas
of this document by using the <a href="#TOC">Table Of Contents</a> at
the beginning of this document.
<p>

<hr size=2 width="100%" align=center>

<p>

<h3><a name="AppSrv">Application Server (Administration/UI)</a></h3>

<p>
The following list of Application Server requirements stem from an
administration/management/UI standpoint.
<ul>
 <li>The configuration system must be able to be queried along several
  different axes and return sets of data/applications.</li>
 <li>The configuration system must be able to service requests for
  machine-wide data and must be designed to handle administration of
  heterogeneous clusters.</li>
 <li>There must be a single point of access to the configuration data
  that the Administration toolset can access. This point must also be
  able to query and return application data as well as system data.</li>
 <li>Administration must be doable when any particular application's
  process pool is offline or disabled.</li>
 <li>The administration tools must be able to build models of the
  structure of the system from metadata alone. This is the same reason
  reflection works the way it does in the runtime. Very meta.</li>
 <li>Changes to a set of properties returned from a query to the config
  system must be accepted by the config system and applied back out to
  the original data sources. If there is inheritance and directives
  roll-up, then this must be accounted for.</li>
 <li>Changes to a set of properties returned from a query or multiple
  queries must be written out in the scope of a transaction. It is totally
  bad if we don't do this and we don't have any excuses as it is
  old technology and it works.</li>
 <li>It must be understandable. The admin tools can probably deal with a
  limited amount of inheritance or roll-up, but anything more is going
  to be impossible to deal with. If this thing works but requires a
  master's degree to operate, we will not succeed.</li>
 <li>
  <b>Locking Mechanism</b>:  In any distributed environment, the chance
  of two entities modifying configuration information is non-trivial.
  There must be mechanisms in place that prevents, or at least, makes it
  difficult to "overwrite" other users settings without knowing it.  The
  actual locking mechanism, pessimistic vs. optimistic, can be discussed
  at a later time.
 </li>
</ul>
<p>

<hr size=2 width="100%" align=center>

<p>

<h3><a name="Ducttape">Duct Tape</a></h3>

Ducttape's requirements are similiar to those from other teams.  They
are listed here in no particular order:

<ul>
 <li>Text based (preferably XML)</li>
 <li>Support schema as defined by the Ducttape team (spec to be found at
  <a href="http://ericdew2k/specs/configstoredata.htm">http://ericdew2k/specs/configstoredata.htm</a>) 
  such as APPPOOL, WEB SITE, and APPLICATION
 </li>
 <li>There shouldn't be any file size limitation on the config data.
  Performance may be a trade off</li>
 <li>No GUIDs or like in object definition.  Human readability and
   editability is key</li>
</ul>
<p>

<hr size=2 width="100%" align=center>

<p>

<h3><a name="Runtime">Runtime (aka Lightning)</a></h3>

<p>
The following is the list of requirements by the Runtime team in no
specific order:

<ul>
 <li>
  Efficient, production implementation of APIs/infrastructure in URT 1.0
  release timeframe. Pre-release quality in November, sufficient to
  allow the runtime to retain its beta quality goals.
  <br>
  <font color=red><em><b>
   ISSUE:  What are these performance/quality goals?
  </b></em></font>
 </li>
 <li>
  Publish perf goals, measure against perf with each milestone.
 </li>
 <li>
  Production UI in URT 1.0 release, more than just XML/text file
  edit. Alpha-quality, but fully-functional UI, in November.
 </li>
 <li>Get in URT integration build starting immediately.</li>
 <li>
  Publish feature plan / schedule for each milestone, including being
  very clear what dependencies you have, e.g., xml parser, platforms,
  other services.
 </li>
 <li>
  Equivalent administration feature set on client and server with
  equal emphasis on both.
 </li>
 <li>
  Support for runtime administration schema including assembly and
  assembly locale, processor, OS, ref, ref locale, ref processor, ref
  OS; and file, comtype, manifest resource, and execution location.<br>
  <font color=red><em><b>
   ISSUE:  Are there any file caching requirements?
  </b></em></font>
 </li>
 <li>
  Must support various change notification scenarios.  In some cases,
  running code wants to be immediately notified when a config file
  changes.  In other scenarios, the running code wants to take a
  snapshot of the config data at startup and be unaffected by changes.
  For the runtime in particular, these snapshots must be maintained per
  app domain.<br>
  <font color=red><em><b>
   ISSUE:  Are these the only two scenarios or are there more?
  </b></em></font>
 </li>
 <li>
  Run on NT4, W2K, Win9x.<br>
  <font color=red><em><b>
   ISSUE:  What about alpha, terminal server, and WinCE?  Dates?
  </b></em></font>
 </li>
 <li>
  Must be consistent config model for:
  <ul>
   <li>Installed client executable</li>
   <li>Code download through a browser</li>
   <li>Web apps (XSP application)</li>
  </ul>
 </li>
 <li>
  Support configuration retrieval from XML and Secure store
 </li>
 <li>
  Security requirements for the runtime
  <ul>
   <li>
    Machine security policy based on groups with associated
    permissions to be granted; groups include named publishers for
    signed code (e.g. "Microsoft Corp" for AuthentiCode signature), web
    site origin of code (e.g. "www.microsoft.com"), zone of origin of
    code (e.g. Internet, intranet, etc.), and strong name
    (e.g. cryptographically unspoofable namespace for code)
   </li>
   <li>
    Permissions associated with groups will be sets of permissions
    defined by name, either pre-defined defaults we supply or XML
    description of permissions in a file that may be authored/modified
    by admin/users.
   </li>
   <li>
    Need a flag to turn on/off security globally (probably a handful of
    flags for "debugging" purposes)
   </li>
   <li>
    Configuration based on user and machine.  For example, in a large
    enterprise all clients will have some kind of basic policy -
    e.g. don't run unmanaged code downloads from the outside, etc. -
    that apply to all users and should be replicated to all client
    machines; however, developers within the enterprise, say, may be
    allowed to run unmanaged code, yet perhaps "normal workers" would
    only be allowed to run managed code.  That is - the security policy
    in effect on a client is different depending on who logs in (dev or
    worker); the machine policy is universal but depending on the user
    there may be further restrictions or possibly overrides (whatever
    merge logic is) applicable.  In an enterprise, admin needs to be
    able to "lock down" machine settings against tampering by local
    user.  Rely on OS user login. 
   </li>
   <li>
    Hierarchical restrictions for site hosting.  An ISP has a box they
    host hundreds of independent sites - a.com b.com and c.com all run
    on one NT box unbeknownst to each other.  For a b and c to admin
    their "very own" virtual machines they login separately and would
    want security policy that keeps their code from interacting.  So the
    ISP "real machine admin" is top boss and hands out pieces of the
    system to a b and c; each site in turn has admin rights on their
    "virtual machine" within their various areas.  Obviously, admin b
    can only config their own stuff and further can only give out
    security permissions within the constraints the ISP admin has set.
    For example, b.com may have all of C:\B folder but may want to
    further restrict file access to C:\B\TEMP for certain code, yet we
    can't allow b.com admin to hand out C:\C folder access (that's
    c.com's area of course).
    <br>
     Model should be general but implementation may limit hierarchy to
     depth of just two levels to reduce complexity and testing effort
     (two levels supports the ISP hosting of sites nicely, or in an
     enterprise the machine admin - ITG here - versus site owners like
     various departments within the org).
   </li>
   <li>
    The store itself must also be secure.  All security/policy and
    probably just about all other config settings will need to be
    secure, esp. in the ISP hosting example above we don't want a.com
    being able to even see much less alter any of b.com's settings.
   </li>
   <li>
    Provide for some sort of tamper-detection.  The next level would be
    tamper-detection plus obscuring anyone but the admin from seeing
    config info; next level would be preventing any read or write access
    (we would like that higer level, but could live with the minimum for
    November I think)  Protection will ultimately be as good as base OS
    security protection can support, which will vary by platform. 
   </li>
   <li>
    Only authorized admin can change config.
    <br>
    <font color=red><em><b>
    ISSUE:  How do we define who can be an admin?  Do we need access
    roles for config/policy?
    </b></em></font>
   </li>
  </ul>
 </li>
 <li>
  The configuration store must be able to be backed-up and restored
  given the appropriate permissions.
  <br>
  <font color=red><em><b>
   ISSUE:  How do you backup a secure config?
  </b></em></font>
 </li>
 <li>
  By the third week in August, the runtime needs the following:
  <ul>
   <li>Be ported to Win9x</li>
   <li>Handle stores provided by the runtime (XML file based on the file
   name of the application)</li>
   <li>Have a default validation/merge layer that can be used by the
   runtime</li>
   <li>Provide API's for retrieving the merged configuration<br>
    <font color=red><em><b>
     ISSUE:  Are the interfaces managed, native, or both?<br>
     ISSUE:  What are the merge scenarios?
    </b></em></font>
 </li>
   <li>Minimal impact when there are no relevant stores</li>
   <li>Support a download.  This is basically the same as the shell. The
   IE host will be responsible for making the store available to the
   configuration system.</li>
  </ul>
 </li>
 <li>
  Must support the storage and retreival of user defined objects.  Both
  our security and context features support the capability for customers
  to build their own configurable objects.  For example, I could define
  a custom permission that controls access to a dedicated hardware
  device.
 </li>
</ul>

<hr size=2 width="100%" align=center>

<p>

<h3><a name="XSP">XSP</a></h3>

<p>
These are the requirements of XSP in no particular order:

<ul>
 <li>
  Configuration directives are associated with nodes in a
  hierarchy. Nodes in the hierarchy represent machines, sites,
  applications, directories, files, set of directories matching a regex
  and sets of files matching a regex. 
 </li>
 <li>
  The configuration for a child node is computed by merging the parent
  node's configuration and the child node's configuration
  directives. The directives can take any form. Examples include simple
  name-value pairs, imperative commands (add/remove script mapping) or
  scripts (url rewriting). The merge semantics are also open ended.
  Examples include union and intersection. 
  <br>
  <font color=red><em><b>
   ISSUE:  Can you specify the child's config info at the parent?
  </b></em></font>
 </li>
 <li>
  Store configuration directives in human readable text files. This
  allows the website developer to use the same set of tools for website
  content and configuration files.  These tools include Notepad, XCOPY,
  FTP, source code control systems, diff and so on.  Note that GUIDs and
  excessive use of IDREFs fall outside the realm of human readability.
 </li>
 <li>
  Optimize data access for multiple reads in the same application
  domain.
 </li>
 <li>
  Cache data in memory using types determined by the developer. This
  helps with performance and it helps to discourage the creation of
  custom configuration caches.
 </li>
 <li>
  The cost of reading and parsing one or more text files when loading
  configuration information for the first time in an application domain
  is acceptable. The cost is small compared to the cost of serving out a
  handful of dynamic pages.
 </li>
 <li>
  Use the same update semantics for content and configuration
  information. If content changes are picked up immediately after a file
  change, then configuration changes should be picked up immediately
  after a file change. Although transacted update of configuration is
  desirable, it only makes sense if all aspects of an application or web
  site are updated in the same transaction.
 </li>
 <li>
  Support the edit-save-test cycle that is so popular with ASP
  developers. In this mode of operation, the developer makes changes a
  file in an editor, saves the changes to disk and refreshes the browser
  to see the changes. Any errors are reported back to browser through
  the HTTP response.
 </li>
 <li>
  Handle ISP scenarios where the site administrator's only access to
  the machine is through FTP. The configuration does not require a
  "kick". 
 </li>
 <li>
  Handle configuration files dribbling in through FTP over a slow
  link. Cooking the configuration information on every change as they
  occur might have undesirable performance characteristics. 
 </li>
 <li>
  Allow application and component developers to define new types of
  configuration information and merge semantics.  
 </li>
 <li>
  Do not require site-wide administrative control when extending the
  configuration system.
 </li>
 <li>
  Build XSP using the public extensibility mechanism to ensure that the
  extensibility model is complete and robust.
 </li>
 <li>
  Minimize the number of data access APIs the developer needs to learn
  to extend the configuration system. For one reason or another,
  developers will probably learn XML-DOM and XDO. All configuration data
  manipulation should be through one of these APIs or through object
  access.
 </li>
 <li>
  Minimize the number of data representations that the developer must
  understand to extend the configuration system. At a minimum, the
  developer must understand two representations of the data: the in
  memory representation and the configuration file representation. If
  any intermediate data representations are used, then they should be
  hidden from the user. 
 </li>
 <li>
  Execute application or component supplied configuration extensions in
  the host application's application domain. This ensures that the
  configuration extension is loaded from the correct location and that
  the extension runs in the correct security context. 
 </li>
 <li>
  Fire change notification events. This allows XSP, components and
  applications to remove dependent information from caches.
 </li>
 <li>
  Use XSP's file change notification system. We don't need more than one
  file change notification system running in the process.
  <br>
  <font color=red><em><b>
   ISSUE:  Need more investigation in the XSP file change notification
   system.
  </b></em></font>
 </li>
</ul>

<hr size=2 width="100%" align=center>

</BODY>

</HTML>