mirror of https://github.com/tongzx/nt5src
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
602 lines
20 KiB
602 lines
20 KiB
<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>
|