able/windows-nt
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
windows-nt/Source/XPSP1/NT/inetsrv/iis/config/info/urt configuration system requirements.htm

603 lines
20 KiB
HTML
Raw Normal View History

Add source files
2020-09-26 03:20:57 -05:00
<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>
Reference in a new issue Copy permalink