| OSF DCE SIG | S. Blount (DEC) | |
| Request For Comments: 14.0 | September 1992 |
THIS IS A HISTORICAL DOCUMENT. The Requirements Survey reported in this DCE-RFC was conducted by the SIG nearly a year ago, in the 4th quarter of 1991. Consequently, some of the information contained herein has been outdated by events of the intervening year -- for example, the Requirements described here have undergone a continuing series of improvements, and are themselves in the process of being published as independent subject-matter-specific DCE-RFC's. But since the Survey marked a major milestone in the SIG's deliberations, it has been decided to re-publish the original Survey without significantly updating it. Some reformatting and minor editing have been required by the DCE-RFC process itself; some other changes between the original Survey and this version are indicated in the footnotes (no footnotes were present in the original version) -- but apart from these modifications, this DCE-RFC consists of the Requirements Survey in its ORIGINAL FORM.
This document is intended to provide a mechanism for the DCE SIG and other OSF members to give their individual opinions to OSF relating to the importance of priorities of some proposed enhancements to DCE 1.0.
The DCE SIG has identified a number of proposals for enhancements and extensions to the functionality that is currently in DCE 1.0. Some of these proposals are very limited in scope (and time required to implement them). Others are more oriented to future technology, and would likely not be possible to be included in DCE until at least 2.0. OSF has asked the SIG to provide input as to the relative importance of a number of these proposals, with particular emphasis on those projects which could be implemented in the DCE 1.1 timeframe (approximate availability in late calendar 1992 or early 1993).\*(f!
Note that the estimated release dates quoted in this paper have changed since this survey was made. This fact MUST be taken into consideration when interpreting the results of the survey, because some of the respondents to the survey undoubtedly had absolute dates in mind, not DCE release numbers.
The data which is gathered with this questionnaire will be made available freely to all members of the SIG, or any member of OSF who requests it. OSF will use this data to determine which features should be included in DCE 1.1 (or possibly 1.2) and which ones should be planned for a future release of DCE. It is important to note that this is NOT your last chance to provide input to OSF, particularly for releases beyond 1.1. The planning for DCE 2.0 will not even begin for some time, and so the SIG will be actively working with OSF to make sure that our views about the contents and requirements for DCE 2.0 are made clear. The most important purpose of this poll is to gain some specific direction for OSF in terms of the contents of DCE 1.1, and a possible follow-on release, DCE 1.2 (target is approximately late 1993).
The data for this survey needs to be collected fairly quickly, in order for OSF to plan the contents of DCE 1.1 Therefore,
An attempt has been made in the survey form to gather some very basic information about the company submitting the response, in order to be able to collect data on the priorities assigned by different types of firms (ISVs, end-users, vendors, etc). Please supply this information, as it make our responses more meaningful to OSF.
Section 2 of this document contains the list of these projects, and space for you to indicate your relative priority ranking of each one.\*(f! The
And, in this printing, Section 2 also contains the RESULTS of the survey.first column ("DCE 1.1") should contain either "A", "B", "C", or "D". reflecting your view of how important each of these proposals is in the DCE 1.1 timeframe (approximately late 1992 or early 1993). Note that some features which don't make the 1.1 deadlines might be included in a possible 1.2, which would follow by about 6-9 months. The second column (DCE 2.0) should contain your priority ranking for this project in the DCE 2.0 timeframe (approximately calendar 1994).
NOTE: a non-vote (a blank or "N/A" in the entry) will be interpreted as a "don't care" vote. This is important because it will provide OSF with an indication of the relative amount of interest in that specific issue.
The approximate meanings of each are:
As you can see, you might submit different priorities for the different DCE releases. So, you might state that a project is a "C" priority for 1.1, but "A" for 2.0. Also, it is clear that some of these projects could not possibly be implemented before 2.0 (Object-orientation is the obvious example), but we decided for completeness to include them in the survey anyway, and let you include this notion of feasibility in the priority that you give it.
Please try to avoid giving many projects a high priority. This only dilutes the effectiveness of the feedback for OSF.
The DCE SIG has divided many of these proposals into a small list of sub-items. You may believe that some of these sub-items are important, but others aren't. It is possible to submit priorities for both the major item, and the individual sub-bullets within each item. You have complete freedom for expressing your views, and the data will be collected and reported. If you would like to offer separate priorities on an item which is not sub-divided, then please use the comment sheet to make your specific comments. They will be passed directly to OSF.\*(f!
These complete results were indeed forwarded to OSF, but in order to keep the size of this DCE-RFC within reasonable bounds they are not included here.
Section 3 contains a list of each project, and a brief description of each one. The description may contain a pointer to another document, which is available from the author (contact me if you don't know the author).
It is VERY DESIREABLE for the responses for each company to be collected and resolved before submittal. To facilitate this, the SIG membership agreed that a single individual would be the focal point for the responses from several of the member companies. The following list contains the names of these individuals who are assigned to collect the responses within their company, and to submit a single response. If you work for any of these companies, please submit your response to the person named:\*(f!
In the final tally, completed forms were actually received from the following 23 organizations: Aggregate Computing, Apple, ARCO, Bellcore, Boeing, Bull, CERN, Citicorp, Cray, U.S. Dept. of Defense (Ft. Meade), DEC, HAL, HP, Hitachi, IBM, ICL, Institute Mihajlo Pupin (Yugoslavia), SNI, Sematech, Tandem, Transarc, U. Mass, U. Mich.
The original survey form contained underlined blanks in which respondents could indicate their votes. In the present version, those blanks have been replaced with 4 comma-separated numbers ("a,b,c,d") indicating the total number of votes for "A", "B", "C", "D" respectively received for each item; the number of remaining votes consisted of blanks and "N/A"'s, so need not be indicated explicitly here. For ordered rankings of the survey results, see the Appendix.
Instructions:
Please fill in this form, and send it (BY NOV 8, 1991) to:
Sumner Blount (blount@took.enet.dec.com)
550 King St.
Littleton, MA 01460
Electronic response is preferred, but please be careful that your
answers line up in the correct columns (use spaces, not tabs).
Name: _______________________________________________________________
Phone: ______________________________________________________________
Company: ____________________________________________________________
Are you a DCE SIG member?: ____
Are you a: (pick only one please)
System Vendor?: ____ ISV?: ____ End-user?: ____ Other?: ____
Project Priority Priority
------- for DCE 1.1 for DCE 2.0
----------- -----------
1. Improve DCE Performance 9,7,5,0 14,5,0,0
2. DCE Code Cleanup 6,7,3,0 7,4,4,0
a. Licensing Issues 3,7,3,1 6,3,1,1
b. Software Dev. Issues 4,7,6,0 8,1,2,0
c. Standards Compliance 4,9,6,0 9,7,2,0
3. Internationalization (I18N) of DCE 3,3,8,0 5,8,1,0
a. Follow I18N Standards 8,4,1,1 12,1,1,0
b. Influence I18N Standards 0,6,2,2 1,5,4,1
c. Code Set Independence 3,4,2,1 5,3,2,0
d. Support EBCDIC encodings 3,0,5,1 3,4,3,0
e. Universal Character Set 1,3,7,0 2,5,3,0
f. Portable Characters 5,2,3,1 5,4,2,0
g. Architecture for identification of 1,3,7,1 2,7,3,0
character data
h. Tools for identification of character 1,1,6,0 1,5,3,0
data
i. DCE should support standard locales 5,1,4,1 5,2,3,0
j. User-defined locales must be permitted 1,0,4,3 1,3,3,0
k. Homogeneous Interoperability 9,0,3,0 7,4,0,0
l. Regional Heterogeneous Interop 1,6,2,1 3,7,1,0
m. World-Wide Heterogeneous Interop 1,1,5,1 2,4,3,0
4. Integration of DCE into OSF/1 5,7,3,1 8,4,3,1
a. Authenticating NFS translator 7,7,5,0 8,5,3,0
b. Consistent locking 4,6,3,1 8,2,2,1
c. Performance trace points 5,5,6,0 6,5,1,0
d. RPC support for both sockets & streams 4,4,5,2 5,8,0,1
framework
e. VFS integration 8,3,3,1 8,3,0,0
f. ACLs convergence and POSIX compliant 8,7,3,0 11,4,0,0
g. Diskless implementation 3,0,7,1 4,3,3,1
h. Dynamic loading of DCE kernel pieces 3,5,5,1 4,6,1,0
i. Distribute all OSF/1 filesystems 5,2,6,1 8,5,3,0
j. Configurable Authentication Mechanism 3,7,4,2 6,6,3,0
k. Common interface for name service 4,9,3,1 8,6,0,0
integration
l. Security operation with respect to 0,5,8,0 5,6,3,0
privileges
m. Time synchronization 1,8,8,0 5,6,4,0
n. Name service management 0,7,8,0 4,9,0,0
o. Kerberized TCP/IP commands 4,8,4,2 7,6,4,0
p. Integrate OSF/1 system commands with 3,8,3,1 4,7,2,0
DCE security
5. Integration of DME and DCE (N/A) 19,2,0,0
6. Enhanced Naming Capabilities 2,6,6,0 8,6,1,0
a. Seamless XDS API to Cds and X.500 5,6,3,0 8,6,1,0
b. Support for X.500 Schema semantics 0,5,3,4 3,5,4,2
within the CDS
c. Support X.500 style typed names 3,0,6,3 3,3,5,3
within the CDS
d. Single naming interface across all 2,6,3,2 10,4,0,1
name exporters
e. Single client protocol for access 3,4,6,2 8,3,5,1
f. Access to Cell Name Service entries 0,1,10,1 1,8,5,1
from non-DCE X.500 implementations
g. Access to X.500 using DCE identity 4,4,5,1 8,3,4,0
h. Writeable browser 1,4,4,4 5,4,5,2
i. Single consistent browser across 0,3,9,2 6,4,4,1
all name exporters
j. Allow CDS server to export multiple 1,6,5,1 2,5,4,1
name service interfaces
k. DME integration for management (N/A) 13,5,1,0
operations
l. Add support for hierarchical cells 6,3,2,1 6,6,1,1
m. Internationalization enhancements 0,1,7,3 1,1,8,1
n. Code cleanup 9,4,3,0 10,3,0,0
o. Fix CDS EBCDIC/ASCII Inter- 5,1,5,1 6,3,2,1
operability Problems
p. Administrative improvements 5,4,6,0 8,3,1,1
q. Support for 1992 X.500 Standard 1,5,7,0 8,7,0,0
7. Better PC Integration 6,2,6,2 7,6,0,1
a. Indicate timeframe for each DCE service:
Remote Procedure Call 7,5,2,0 8,4,0,0
Naming Service 3,8,2,1 8,4,0,1
Time Service 1,4,7,1 3,5,4,1
Security Service 4,4,5,1 5,6,1,1
Threads Service 5,1,5,0 4,4,2,1
Distributed File System 2,4,5,2 5,7,3,1
Diskless Support 2,1,9,1 4,6,3,0
b. DCE integration for the following LAN protocols:
Novell 10,4,3,0 9,3,1,0
Banyan 1,2,7,0 2,3,6,0
LAN Manager 6,3,3,0 5,4,1,0
AppleTalk 2,7,5,0 8,3,3,0
8. Dist. Application Development Tools 3,7,7,4 11,5,1,4
9. Enhanced Security Capabilities 3,8,4,0 7,7,0,0
a. Security mechanism-independent 4,6,8,1 12,4,2,0
protocol-independent API
b. Integration of management 0,3,8,3 6,3,5,1
infrastructure with secure mail
c. Auditing 4,6,4,0 7,6,2,1
d. Mandatory security 2,1,8,2 2,6,3,1
e. Hierarchical trust 6,1,7,1 8,5,1,2
f. Delegation 2,12,3,0 14,1,1,0
g. Global groups 3,3,6,2 7,3,3,1
h. Prevention of password guessing 4,9,3,0 11,2,0,0
attacks
i. Integration with operating system 3,5,6,1 5,5,1,0
j. Balance need for online trust 0,3,6,3 4,5,0,3
k. Other (specify on comment page) _______ _______
10. Object-Orientation Extensions (N/A) 8,8,4,0
11. Support for TP 6,2,3,1 8,3,1,1
a. Level 1 features 6,2,5,0 9,3,2,0
b. Level 2 features (N/A) 7,2,5,1
12. Serviceability Enhancements: 6,7,2,0 10,3,0,0
a. Error Data Capture 6,6,2,0 11,3,0,0
b. Enhanced Error Notification 6,7,1,0 12,2,0,0
c. Enhanced Tracing 5,8,2,0 12,2,0,0
d. Improved Externals 4,7,4,0 9,4,1,1
13. Resource Management: 1,3,7,3 6,4,1,1
a. Resource Information service 3,2,8,2 7,6,2,1
b. Decision-making Support I/faces 2,3,9,2 5,7,2,2
c. Binding Applications 0,5,8,3 6,9,0,2
d. Service Instantiation 1,4,5,3 3,7,3,1
e. Resource Management applications 0,3,8,3 4,7,4,2
f. Distributed Processing Service 1,3,7,3 4,7,4,1
g. Transparent Remote Processing 0,3,5,4 5,3,4,5
14. File Systems Enhancements: 5,4,5,0 6,7,2,1
a. Full POSIX 1003.1 Support 8,5,4,0 12,3,0,0
b. Better Integration with OSF/1 5,4,2,1 9,0,3,1
c. Property List Control 4,4,5,0 5,7,1,0
d. Performance Improvements 7,6,5,0 12,4,1,0
e. Security Enhancements 2,6,7,0 8,9,0,0
f. Fileset Management Enhancements 1,6,7,0 6,7,1,0
for the DCE Executive
g. 1003.4 Support 3,4,6,2 7,5,3,0
15. More Reference Platforms 5,3,5,3 6,5,2,5
16. Miscellaneous Proposals:
a. AFS Control 0,2,11,2 3,5,5,1
b. DTS clock training 1,0,8,1 2,3,8,0
c. Thread improvements in X.500 3,3,5,2 6,2,3,2
d. Use POSIX time 5,5,4,0 7,3,2,1
e. Full kernel RPC 2,4,5,1 7,4,2,0
f. Security operation viz. 1,1,10,0 5,5,2,1
privileges
17. Message Queueing 1,3,4,6 6,5,4,3
18. (Your project here) _______ _______
COMMENTS
--------
You may add any comments or clarifications you wish
about your input on the specific items.
A thorough performance evaluation of the entire DCE is needed before recommending specific enhancements. Performance enhancements will then be based on data collected from the analysis to correct bottlenecks and, for critical areas, performance deficiencies.
This item involves DCE product release issues. It breaks down into the following categories:
For the current status of the SIG's internationalization requirements, see [RFC 13.0].
The following items have been derived from the various discussions at the last three DCE I18N SIG meetings. For background information, refer to the document "Internationalization in the OSF DCE: A Framework" dated 5/22/91. The current DCE 1.1 priorities are indicated for those items which the SIG could agree on a TENTATIVE priority (H(igh), M(ed), L(ow)). Items with no agreed on priorities are indicated with a 'U'.
DCE I18N requirements (with tentative 1.1 priority):
The DCE shall follow formal standards (ISO C, POSIX, and XPG) in providing the following functionality: messaging, international character data processing, local conventions, and collation. The recommended OSF prioritization of standards shall be applied in cases of conflicting standards.
OSF should coordinate members' participation in standards groups meetings, as well as directly participate themselves, seeking to influence internationalization standards in ways favorable to the success of OSF DCE. In particular, these areas are of concern to the DCE: Data tagging, Large character sets, Wide-character processing, Locale naming, Distributed and non-global locales.
DCE should be able to handle a wide variety of code sets and encoding methods, at a very minimum the single and multibyte ASCII supersets supported by OSF 1.1. DCE components will be required to support interfaces capable of being called with different code sets. It should be possible to compile DCE components into a single object that can support various code sets, both within the workstation and on the network.
EBCDIC encodings should be supported (includes single and multibyte). In the multibyte case, User-Defined Characters (GAIJI) should be supported.
OSF should support a single, universal codeset which may be used by any DCE component or application for the transmission of any desired characters. An example of this may be the merged ISO 10646 -- UNICODE definition.
OSF should identify, publish, implement, and promote the use of a collection of "portable characters" which may be used by any DCE application, anywhere in the world, regardless of the local codeset in use. (NOTE: This is intended to imply that the ASCII name "ABC" is portable to an EBCDIC system, which further implies that "portable character" data is identifiable in some way so that the necessary conversions can be done. This doesn't necessarily further imply tagged data, since "portable characters" could be implemented as a unique IDL type if desired.)
OSF should specify an architecture for allowing DCE components and applications to identify character data with (at least) the identity of the codeset of the data. This identification could be granular, such as by string, character, node, or filesystem. The definition of granularity should be specified per component.
Tools should be provided for DCE services to implement the architecture for character data identification. These should implement such tasks as adding and extracting character data identification information.
DCE should support standard locales, if available from these groups: ISO (highest priority), POSIX, X/OPEN. If none of these group has created standard locales, OSF should provide its own definitions.
In a distributed environment, it must be possible for user-defined locales to be available on both a client and its associated server. This may require manual replication on the part of a system administrator.
The DCE must be able to support networks in which clients and servers all work in the same, arbitrary, codeset, chosen at runtime.
The DCE must be able to support networks in which clients and servers are working in different codesets, provided that these different codesets are substantially or entirely interconvertible (i.e., ASCII and U.S. EBCDIC, or SJIS and UJIS). (NOTE: This will depend on either a tagged data type or a universal codeset, so it would be inconsistent to prioritize it above BOTH of those items.)
The DCE must be able to support networks in which clients and servers work in different codesets which cannot be interconverted. (NOTE: This implies some useful "fallback" behavior, not a miracle. It will probably depend on the existence of "portable characters", and so should be prioritized accordingly.)
This items involves closer integration of the DCE facilities with comparable ones within OSF/1. The following is a list of such possible projects which has been authored jointly by the OSF/1 and the DCE SIG. Many of these items could easily be included elsewhere in this document ... for example, there are many file system and security issues listed below. But, they are listed here since there is, in general, work required both in DCE and in OSF/1 in order to implement these enhancements.
The dates listed below are the estimates and opinions of the joint OSF/1 and DCE SIG working groups.
OSF/1 DCE environment:
OSF should supply sample NFS translator code to enable vendors to provide full NFS access to DFS. This requirement allows a NFS client authenticated access to files in DFS. Changes to the NFS server are necessary to map NFS credentials to DFS. The current DCE 1.0 NFS translator allows access only to public files.
OSF should supply a mechanism for each file system to honor each other locks. This includes local file system, NFS, and DFS. The current OSF NFS offering does not support locking.
OSF should supply an API and a set of tools to capture performance measurements information for debug and tracing capabilities. This interface is essential to support the Managed Object Definition of OSF/1 to capture performance data. Note: this is probably not just DCE specific, but all OSF offerings could use the benefit of a well-defined API and tools for performance.
RPC (user and kernel space) should support both a sockets and streams framework. The socket API does not currently provide access to any protocol stack which has been implemented using a streams infrastructure. Therefore, if a vendor chooses to implement the OSI protocol stack using a streams framework, RPC could not use that protocol stack. There are several different options to solve this problem -- one being a OSF/1 solution and one being a DCE solution.
DCE DFS uses an enhanced Virtual File System Interface (VFS+) to insure consistency between requests for remote files (from file server systems) and requests for local files present in the physical file systems on the system. To guarantee consistency, all exported DFS file system (file system available in the uniform file space) share the same access mechanism. The VFS+ interface guarantees that local file system requests generate the same access tokens as files located on a remote file server system. The VFS+ interface is an extension of the virtual file system interface found in most of the UNIX kernels. The VFS+ interface extends the VFS interface in several ways:
The VFS+ interface supports operations on DFS filesets and aggregates, including creating new filesets within an aggregate, putting those filesets online, taking existing filesets offline and iterating through files in a fileset and enumerating filesets.
OSF should supply a single ACL mechanism for all OSF/1 objects, including DCE objects. The mechanism should be POSIX compliant. Migration for users should be a high consideration from the existing ACLs implementation in both of the offerings today.
OSF should supply an OSF/1 DCE diskless implementation as a competitive offering. The OSF/DCE diskless implementation today is not a complete implementation; it is a set of pieces that a vendor could put work into and produce a diskless implementation.
DCE kernel pieces should be dynamically loadable/configurable. This dynamic capability exists in OSF/1 today, but is not being used for for DCE port to the OSF/1 platform. The DCE should exploit this capability. The current kernel pieces are time, RPC, and DFS.
It should be possible to distribute all OSF/1 filesystems, including Secure UFS, using DFS. For those familiar with NFS and the exportfs command, the functionality (not implementation) requested is similar. Using DFS, a user should be able to see files (directories, filesystems) from other filesystems that have been exported into the DFS tree. This requires that the extended vnode operations (present in DCE today) be supported in each of the filesystems to be exported.
Provide the ability to configure a system for different combinations of local (c2, bsd), remote, and vendor supplied (such as NIS) security using a single set of binary images for security mechanism specific utilities such as login, su, and passwd.
Information may be stored in some combination of local and remote databases. For example, host names may be stored locally in /etc/hosts, or in a remote database served by BIND or X.500 or some vendor supplied name service. Access to this type of information is provided through existing interfaces such as gethostbyname(). It should be possible for the system manager to configure the order in which databases are searched for information. In addition, the PasswdETC component of DCE distributes the equivalent of the local system /etc/passwd and /etc/group globally for the cell. The DCE should be used to globally distribute other administrative databases such as mail aliases or other /etc/* files.
OSF/1 supports privileges today as a compilation option for the NCSC B1 and upwards levels. The user acquires privileges at login time. It defines the user's access to object, commands, system calls, and other resources at runtime. These privileges are discreet from the unix uids and gids which are associated with users/processes. Auditing implies that privileges are to be compiled in. When privileges are active in the operating system and DCE user registry is the authentication method, this privilege information must be returned at login time so the user can do useful work in the system. OSF needs to solve this problem. Compatibility with existing registry/ticket protocol is essential for 2 reasons: (1) some systems may implement as part of the base operating system, i.e., always present, and (2) registry protocol doesn't store this type of information today. In a heterogeneous environment not all hosts may implement privileges.
Only one daemon should be allowed to synchronize the clock when both TCP/IP and DCE are present on a host. DCE provides dtsd; TCP/IP provides timed. OSF TCP/IP provides a time daemon timed and its control program timedc to synchronize time in the local area network. It uses the Time Synchronization Protocol (TSP), is built on UDP, and is based on a master-slave scheme. Only one method/protocol of synchronizing time should be run on any given node. This means that dtsd or timed can run, but not at the same time. DTS should be the preferred mechanism in a mixed DCE, TCP/IP environment.
OSF should provide a recommendation of what should be maintained when more than one name space is in use. In the name spaces that exist today such as bind and NIS, the same objects can be defined and maintained in both spaces. Examples of these objects are mail addresses, host names, host addresses, users, passwords. With DCE, two additional namespaces are introduced, they are cell and X500. The goal is to provide only one copy so maintenance is minimal. The current OSF/1 offering does not support NIS.
DCE uses Kerberos V5 protocol. Existing TCP/IP commands from some vendors use Kerberos V4. OSF presently does not support kerberized TCP/IP commands. V4 and V5 are incompatible. DCE supports KDC and the user registry. Kerberized TCP/IP typically uses the MIT kerberos admin model. The two models are not the same. Also not all of Kerberos V5 is included by DCE, plus DCE has added extensions. Modifications need to be made to the TCP/IP commands commands and Berkeley "r" commands) such that tickets are obtained to use these services for authenticated and authorized usage. The DCE security component includes version of Kerberos V5 that has tracked the MIT implementation, but is not exactly the same. It is based on MIT's beta1 distribution with a number of bug fixes and other changes (including more recent protocol changes for V5). Many of the bug fixes have been or will be shared with MIT -- but not all of the enhancements. The database and replication implementation is entirely different as are the management interfaces and tools.
The DCE security component includes substantially more than Kerberos. A DCE site cannot run with a vanilla Kerberos implementation from MIT -- it must run with the OSF DCE implementation. Applications linked against the MIT beta1 code, however, can run in a DCE cell (read "realm") unchanged. It is the intent to preserve compatibility for "off the shelf" MIT Kerberos applications but cannot guarantee that this will remain true after DCE has shipped and MIT continues to evolve their implementation. More protocol changes are not expected -- but it is possible that the format of certain local files like the credential cache could change thereby breaking interoperability.
Portions of the MIT package are not included in the DCE code. These portions include: the database code, MIT admin tools, gssapi, sample applications, Kerberos 4 compatibility API. In addition binary versions of the DCE will generally not expose the MIT V5 API -- though source licensees are free to make this available.
OSF should integrate DCE security more fully in an OSF/1 system, such as for basic operating system and filesystem commands/libs. Some commands need only to be re-linked and re-tested with threaded libs, others need modifications to work with the DCE user registry (such as the getpw* routines).
This proposal involves integrating the DME and the DCE technologies in such a way that all of the DCE components are managed in a consistent way, using the integrated DME facility. This would solve the problem of the multiple and often different management facilities that the DCE currently has.
This proposal DOES NOT involve the use of, and integration of, the DCE technologies into the DME offering. This will be considered as part of the work of the DME team.
The exact details of how these two technologies would be integrated will be determined over the next few months, as the DME technologies become more widely known.
Some early ideas are:
For the current status of the SIG's naming requirements, see [RFC 4.0].
Programmers use XDS for accessing the DCE Directory Services as a single service. The fact that there are different directory service implementations (X.500 and CDS) behind the XDS interface should be fully transparent to the programmers. They should be able to perform all the functions supported through XDS interface irrespective of the fact that the target operation will actually be performed in CDS or X.500. In DCE 1.0, this is not the case. The following is a list of functions/capabilities that are not available to programmers when target operation is to be performed by CDS rather than GDS.
All of the discrepancies are visible to and must be dealt with by the application programmer using XDS. More significantly, these differences will impact the portability of XDS compliant applications onto the DCE XDS API because functions which are assumed to be supported by the XDS are in fact not supported for some subset of the name space.
GDS ensures the integrity of the Directory Information Database (DIB) by enforcing a set of rules and constraints (defined in the directory schema concerning the structure of DIT, object class definitions, attribute types and their syntaxes, etc., which are used to represent information in DIB. Every directory entry stored in GDS contains an object class attribute which defines a set of mandatory and optional attributes, naming attributes for the entry and the type of its parent entry etc. Any attempt to modify an entry that would violate the entry's object class or modify the DIT in such a way as to violate the appropriate structure rules fails.
CDS does not have such a schema concept; however, it does define a class attribute which can be used to specify the class of each object entry. For each value of the class attribute, users can define a set of class-specific attributes that can/should belong to that class. However, such information is not stored in CDS and it is left to the users to describe, publish, and inform other users about the characteristics of that object class. In other words, CDS has no knowledge of the object classes and thus cannot enforce any of the rules mentioned above for the class-specific attributes in the object entries. For example, CDS cannot prevent an XDS programmer (assuming he has appropriate access rights) to delete mandatory attribute RPC_TOWER from an object entry of type "RPC_Entry" which contains the bindings exported by RPC Server. The outcome of this deletion is that the server will become unreachable from all clients.
In DCE 1.0, the CDS supports passing X.500 style typed names (<attribute type> = <attribute value>) as the cell name portion of a global name. However, the CDS implementation does not support the concept of matching rules that X.500 defines for comparing two names, nor does it support the semantics implied by attribute based naming. Within the scope of the CDS, names are treated as labels rather than Attribute Value Assertions. This requirement would extend the CDS to provide support for the full semantics of X.500 attribute based naming.
This item represents a proposed architectural change to the current DCE Directory/Naming structure which would enable the development of generic, cross resource manager (and object class) tools and applications. One example of such a application is a generic name space browser which could display, browse (navigate), and manipulate names and attributes across all resource managers exporting names into the global namespace.
In the DCE 1.0 architecture, each resource manager which exports names and attributes into the global namespace must define its own specialized interfaces and protocols for mapping names onto locations, functionality and attributes. Additionally, each resource manager client must implement a "junction" between the CDS and the set of names exported by its servers. These junctions allow the resource manager clients to resolve the GDS and CDS portions of a global name using the XDS or CDS APIs, and then switch to their own protocol to resolve the rest of the name. Since these junctions are specific to each resource manager, there is no single interface through which basic naming functions are provided against all names in the global namespace. As a result, truly generic, cross resource manager applications cannot be easily supported because they must understand and use the specific interfaces for each resource manager they wish to support. Whenever a new name exporting resource manager is developed, all of the cross resource manager applications must be updated to utilize that resource manager's specific naming interfaces.
In order to enable the development of truly generic, cross resource manager tools and applications, the following architectural modifications/additions to the current DCE Naming architecture are proposed.
As part of the protocol definition, the architecture should define the minimum set of functionality that MUST be supported by a resource manager in order for it to be integrated into the global namespace and be accessible through the common system level programming interface.
The current DCE implementation requires two protocol stacks in the client workstation in order to support the XDS programming interface. When a CDS name is passed to XDS, it calls the CDS Clerk which uses its RPC based protocol to communication with CDS servers to resolve the name. When an X.500 name is passed to XDS, it calls the X.500 DUA and accompanying OSI protocol stack (layers 5, 6, and 7) to communicate with DSAs to resolve the name. Requiring both of these protocol stacks, both of which are fairly large, to reside in every workstation imposes a significant drain on system resources. This is particularly painful in low-end workstation configurations where memory and swap space are at a premium.
Therefore, since RPC is already required on every workstation in order to support the other DCE services, this item proposes modifying the XDS implementation to run over an RPC based protocol and provide access to X.500 via RPC to DAP/DSP protocol gateways.
In DCE 1.0, programs using the DCE XDS API can access names both in any standard X.500 namespace as well as names residing in the CDS. This is accomplished via the switch mechanism supported by the specific DCE XDS implementation. Non-DCE X.500 implementations do not have this capability and therefore cannot provide their users with access to names which reside in a Cell namespace. Since the XDS is a standard API, this limits the portability of applications written to XDS which require access to information residing only within a CDS.
This requirement would allow non-DCE X.500 implementations of XDS using X.500 standard DAP and DSP protocols to access and manipulate entries in the CDS subject to access controls.
Currently in DCE, when a user tries to access a resource with a global name, he may be asked to enter an X.500 userid and password information before his local DUA will be able to proceed with trying to resolve the name. This characteristic is a result of the different authentication mechanisms used by the Cell based DCE services and the X.500 Directory Service. This requirement asks for modifications to the DCE X.500 server implementation such that DCE X.500 servers can be configured to participate in the DCE authentication mechanism. This change would simplify the administrative work involved with using X.500 as the GDS since they would no longer have to define and maintain multiple definitions and passwords for each user. Further, users would no longer have to deal with remembering and maintaining separate passwords for X.500 and DCE.
Note: While this proposal would eliminate the problem of logging onto each server within a given enterprise or installation that used all DCE X.500 servers, it will not (can not) solve the general case problem because the X.500 standard does not specify the same authentication mechanism as is used by DCE. Therefore, a non-DCE X.500 server which uses a different authentication scheme will still require administration of a separate user definition than that defined for DCE services.
The current CDS browser only provides the capability to graphically display and navigate through a Cell name space and its entries. Changes to the namespace or the contents of entries must be made using the text-based CDS Control Program. This requirement proposes the enhancement of the CDS browser to support all of the CDS functionality through the graphical interface.
The CDS Browser currently supports only browsing and navigating through Cell namespaces. The user/administrator must use other non-graphical tools when accessing resources in other namespaces supported by the DCE (i.e., X.500, DFS, Registry). This requirement proposes enhancing the CDS browser or providing a new generic namespace browser which allows display, navigation and basic attribute manipulation functionality across the entire global namespace.
Note: Providing a truly generic and extensible namespace browser basically is dependent on the implementation of a "Single naming interface across all name exporters" requirement. However, browser which encompasses only the resource managers shipped with DCE is possible without it.
While DCE provides a new, highly functional and integrated set of directory services, there are several existing name services which will continue to exist in parallel with the DCE. For example, the Internet Domain Name Service (DNS) is and will continue to be heavily used by both DCE and non-DCE workstations by e-mail and other existing applications. In an environment where users want to run applications which make use of these existing name services as well as DCE function, the administrator will be required to maintain and keep in synch multiple name service databases containing the same or similar information. For example, in an environment where both DNS and DCE are used, each host must have an entry in both the DCE CDS and DNS. If the host's IP address is changed, both the CDS and DNS databases must be updated to reflect the change.
This requirement proposes enhancing the CDS servers to support queries against its databases using multiple name service protocols (Internet DNS, NIS, etc.). In this environment, a host would be defined once to the CDS with all of the attributes required by both DCE based and DNS based applications. DCE clients would access the attributes using DCE interfaces and protocols and would be able to take advantage of the full functionality of the DCE. The CDS server would also export the DNS protocols so that DNS based applications, could use existing interfaces to access the same information.
There are several components of the CDS implementation which provide "management" capabilities as they are defined by the OSF DME selection. This requirement proposes modifying these components of the CDS to integrate them with the appropriate DME services. In particular,
Hierarchical cells are cells whose root directory is cataloged in another CDS server. Nesting can be quite deep, but ultimately, the tree should be rooted (cataloged) in the Global Namespace. The advantage of this is that cell administrators do not have to allocate names in the Global Namespace and hierarchical cells for the basis for hierarchical trust agreements. For example, assume that DEC is composed of a set of hierarchical cells. The name of the uppermost cell in the hierarchy is /.../dec.com. The lkg cell, named /.../dec.com/lkg, is rooted in /.../dec.com as is /.../dec.com/zko. We assume that the administrators of the lkg and zko cells have exchanged keys with the administrator of dec.com. Because of hierarchical trust, the administrators of lkg and zko do not have to exchange keys among themselves to allow lkg users to read zko files and vice versa. Since they both trust a common ancestor, they automatically trust one another.
In addition to the general Internationalization requirements for DCE, this item proposes a naming specific enhancement to the DCE Naming architecture to allow users to define names for entries in multiple languages so that users accessing those entries can do so via their natural language. For example, a directory in the CDS named /.:/colors in US English could be assigned an alternate name /.:/colores which would be used when being viewed by a Spanish speaking user.
General code cleanup of the CDS source tree.
String names for CDS in cds_types.idl are defined as an array of bytes. This causes problems running in a world where an RPC call is sent to a machine that does not use an ASCII character set. These arrays need to be defined as an array of type char so that when the RPC call is received on an EBCDIC machine, the character translations are done correctly.
These improvements would be geared towards simplifying the administrative tasks associated with maintaining an operational CDS. Such enhancements would include:
Whereas in DCE 1.0 the replication site for each newly created directory must be explicitly specified, this enhancement would allow the administrator to explicitly specify the replication sites for a subtree of directories only once (for the root directory of the subtree) and all subsequently created directories in the subtree would automatically be replicated to the same sites.
Need to upgrade the DCE Directory Service to support the 1992 X.500 standards when it is approved. Some of the major additions to the X.500 standards in 1992 include:
Implementation of the 1992 standards will allow OSF DCE Directory Service to interoperate fully with other non-DCE X.500 Directory Services that are compliant with the 1992 standards.
PC integration with DCE can provide:
However, significant tradeoffs must be considered in deciding what level of integration should be implemented. Three levels of integration are:
This requires the client to use whatever security is available in its LAN protocol. Sometimes this means that the client will be passing passwords in the clear over the network.
Since the user interface does not reflect the capabilities provided by DCE, the client machine offers only a subset of the possible services available.
System administrators must update all the PC's which will be clients.
This will require additional education to instruct the PC users on how to use the additional utilities.
System administrators must update all the PC's which will be clients.
Other issues include:
This is an outline of distributed application development tools that would be used by the distributed application developer to develop distributed applications that run on DCE.
Tools used by the distributed application tester are not covered.
A distributed symbolic debugger would include the following properties.
Given that the vast majority of today's application designers are skilled in designing single threaded, standalone applications, tools are required to assist the application designer when designing and coding distributed applications.
The Program Design Aid consists of two sections, one section looks at the program code and the other looks at the DCE system.
Static analysis is concerned with a program's perceived execution based on source code. Static analysis is useful for distributed systems since it can be performed independent of the target environment, so results are applicable to a range of implementation configurations.
Using the program static analyzer the developer will be able to find:
The DCE System Analyzer would assist in predicting distributed application behavior, performance, and capacity needs with regards to
The DCE System Analyzer would also allow an application conversion simulation prior to having completed all specifications for components of the conversion. It would also make use of libraries of existing code during the prototype task.
The underlying network that the application is being distributed on needs to be understood in order to determine where tasks and data that make up the application program should be placed in the network.
The decision on where to place tasks would be based on the following criteria.
Language extensions (to C, Fortran, Cobol and other commercially significant languages) permit the operations of DCE to be expressed directly in programming language statements which are checked by the compiler. This permits the power of DCE to be expressed more simply, and reduces the "iteration time" involved in making a change and learning whether or not it is correct.
Programs in the extended languages should, when compiled, be fully interoperable with DCE programs written without the aid of the language extensions, and such extensions should always be a perfect superset of the (ANSI or ISO) standardized languages which they extend.
Integrating DCE operations into the language should allow many current thread library operations, RPC binding operations, directory operations, and program-starting operations (e.g., 'rexec') to be expressed more simply and naturally and to be checked for correctness by compilers. If properly designed, these extensions may also reduce the number of specialized data types (such as RPC handles and context handles) which must be maintained. Integrating the IDL into programming languages reduces the number of distinct technologies, source files, and program build steps with which a programmer and his other tools must interact.
For the current status of the SIG's security requirements, see [RFC 8.0].
The following are selected items from the list of DCE Security Requirements prepared by the DCE Security Working Group, that have been proposed as candidates for highest priority. The group has not yet settled on a final list, however.
Provide an API that permits authentication and communications security functions to be invoked by applications that use protocols other than RPC to communicate, while continuing to shield these applications from details of the security mechanisms.
Integrate DCE user registration and certification functions with those needed for the public key variant of Internet Privacy-Enhanced Mail.
Enhance DCE auditing capabilities.
Security labels in OSF/1 and their enforcement are now lost on communications between systems.
DCE currently requires n^2 keying between cells; that is, each cell's PasswdEtc server must be manually registered as a principal in every other cell. Hierarchical trust permits inter-cell security using a hierarchical scheme requiring only a small (constant) number of registrations for each new cell.
Delegation is the ability for a server to make a remote access (to another server) and authenticate itself as an authorized delegate for the original client who authenticated to the server.
DCE groups can currently only name principals registered in the cell in which the group is defined.
It is currently possible for an attacker to masquerade as a legitimate user and obtain from the PasswdEtc server information allowing the attacker to mount a dictionary attack against the user's password without auditing or other constraints.
OSF/1 does not recognize the incoming credentials obtained by a server process during the authentication of client to server. There is no mechanism for the client's identity to be used by the server's operating system for enforcing an access control decision made by the server process. There is no integration between OSF/1 ACLs and DCE ACLs.
DCE requires highly trusted security (PasswdEtc) servers to be online, suitably replicated, and highly available so that all clients and servers can access them at authentication time. Use of public key techniques offers the potential for placing all trusted entities responsible for maintaining the integrity of authentication in offline systems that need not be replicated or highly available, thereby making them easier to protect and possibly reducing administration costs.
(Note: this enhancement could not be implemented prior to the DCE 2.0 timeframe.)
The world of object oriented systems is both a very important and confusing issue to DCE. Important, in that it provides an excellent model to express the concepts for distributed computing systems (such as DCE) and thus provides an improved application programmer model. Confusing, in that there are many implementations that exist (or are proposed), all of which exhibit different object models and facilities tailored to a particular task for which the system was designed. Today DCE provides rudimentary object oriented support onto communications between clients and servers in a distributed environment. This working group has been set up to determine how DCE can be extended to provide a richer set of object oriented functionality that can support many different object models.
The main objective of the Object Oriented Technologies working group is to define the requirements for extensions to existing DCE services and new DCE services to support object oriented environments over DCE. These services and extensions will form an infrastructure (termed Object Support Infrastructure) that can support many different object models. The specification of a specific object model over DCE is NOT an objective of this group.
This working group will approach this problem by examining the system requirements for existing and proposed object oriented systems. These requirements will be compared and contrasted with that already provided by DCE to determine the extensions and new services required.
The output of this group will comprise of a document detailing the requirements to support object oriented environment over DCE and provide a technical description of proposed extensions and new services for DCE (No Specific technologies will be recommended at this stage). This document will be offered to OSF as input to a future RFT process.
The distributed transaction processing (DTP) requirements defined by the Reliability Working Group have been divided into Level 1 and Level 2 DTP requirements. The Level 1 DTP requirements specify the core services needed to provide basic DTP support on the OSF DCE and should be considered for inclusion in the OSF DCE in the 1.X timeframe.
The Level 2 DTP requirements specify enhanced DTP functionality that could be layered on top of the Level 1 DTP Support. The Level 2 DTP requirements are dependent on the Level 1 DTP requirements and are considered to be candidates for inclusion in the OSF DCE in the 2.0 timeframe.
Commercial applications, such as banking, financial, airline and manufacturing represent a substantial portion of the computing industry. For DCE to be successful in the commercial marketplace, it must address their requirements for building distributed transaction processing systems (DTP). Transaction integrity is important to commercial applications which cannot afford any data loss or data inconsistency. As applications become more distributed and the number of points of failure increase, transaction integrity becomes even more important.
Large systems developers, working with existing non-distributed technology, have come to depend on the transaction integrity provided by existing environmental software layers. For example, non-distributed transaction integrity is provided by all major database management systems and transaction processing monitors, such as, CICS on MVS, and TMX, Intact and ACMS on VMS. Large commercial systems in the key industries will not be able to give up the transaction protection they currently have and move to heterogeneous distributed computing until support for DTP is available.
The following requirements specify the core requirements needed to support DTP applications spanning heterogeneous systems that include transaction managers and resource managers that are compliant with either the X/Open XA or the DCE transactional RPC protocol.
The following requirements specify enhanced DTP functionality that could be layered on top of the Level 1 DTP Support. The Level 2 DTP requirements are dependent on the DTP services specified in the Level 1 DTP requirements.
Serviceability refers to those elements of a software product that aid/facilitate the diagnosing, repairing and possibly the early warning of problems ("failures").
A document has been circulated that describes in detail suggestions to improve/increase the usability, scaleability, distributed capabilities, diagnostic capabilities, customizability and integratability (with the host platform) of existing serviceability features within DCE components. The Serviceability workgroup will be issuing an updated copy before the official ballot. We welcome any and all comments on this paper (contact hubbard@torolab5.vnet.ibm.com for a copy).
These enhancements are intended to reduce service costs, aid in the overall problem management of a DCE system and alleviate many of the difficulties associated with the servicing of a heterogeneous network. As well, they present DCE vendors the opportunity to offer value add features to their DCE implementation (by exploiting hooks implanted in the base code) and to provide network-wide problem management and service offerings.
There is a strong affiliation of these enhancements with both DME and OSF/1. Both will play a part in improving the serviceability of DCE. However, many improvements can still be made to the existing DCE code base.
The 4 major areas of serviceability enhancements are:
The following sections subdivide the above areas to aid in balloting. A suggested rollout of these functional items (based on anticipated degree of difficulty, benefits and availability of DME) is included in the Serviceability Enhancements paper and is open for discussion by members of the DCE SIG and OSF.
For the current status of the SIG's Resource Management Workgroup, see [RFC 16.0].
A service is required which collects and maintains information about system resources that can be used in making intelligent decisions in support of a number of management applications (e.g., load balancing, service reconfiguration) The information maintained by this service is generally dynamic in nature. A standard set of API's to this service are required.
A set of interfaces are required which allow resource management applications to "query" the resource information service (and other information services such as directory services). These interfaces must allow policies and conditions to be specified. This well defined API is expected to be used by resource management applications as well as system management applications to set default policies and conditions.
Intelligent location brokering must be incorporated into "binding" applications such as RPC, such that RPC can transparently choose service locations using system status information. Other binding applications include an object request broker, a distributed processing service, etc.
A service is required which will allow RPC servers to be instantiated when conditions are met. This service is functionally analogous to "inetd" for dynamically invoking RPC services based on system information.
A number of management applications can be provided which build on the above resource management services. These include:
A service is required for doing efficient, authenticated remote execution in a heterogeneous environment. This service should be made intelligent by incorporating the above mentioned decision making support interfaces for choosing execution locations. A well defined set of programming interfaces should be provided for use by resource management applications.
A set of operating system enhancements is required to support full UNIX posix process semantics over the network. These operating system enhancements would support executing a process over the network including its full UNIX semantics (open file descriptors, shared memory, etc.)
Enhancements to include support for full POSIX 1003.1 interfaces and semantics, including network named pipes (fifos) and controlling terminals.
Enhancements to integrate DCE VFS extensions; dynamic loading of DFS, LFS; multiprocessor safe DFS, LFS; support for export of OSF/1 file systems via NFS and DFS (including SUFS w/ACLs); LFS support for boot, quotas; common backup scheme for all file systems.
Exporting property list interface for DFS and LFS to permit support of extended file properties such as B1/CMW security attributes, record attributes; requires additional management, and coexistence of multiple properties (i.e., records and MAC labels).
Improved read and write performance for DFS (LAN, WAN vs. NFS) and LFS (over "competitive" UFS) review of future scaling requirements (i.e., sizes greater 2 gigabytes).
Support for full C2 capabilities, including audit; support for B1/CMW file labels (Sensitivity, Integrity, Information, ...); support for requirements as defined by OSF Security Sig and the DCE SIG Security Working Group; consideration for future POSIX 1003.6 requirements.
Support for extended file set operations in the DCE Executive environment: ability to use other ACL based file systems (i.e., SUFS), ability to support minimal cloning operations (such as to support common on-line backup).
Investigation leading to future support for memory mapped files, asynchronous I/O as defined by 1003.4.
The widespread success of DCE will be limited by the amount of effort required to port it to other systems. A richer set of reference platforms can greatly facilitate the porting process. The following are desirable for future releases of DCE. `*' indicate items which should be possible for inclusion in release 1.1.
A set of functions that provide new, more flexible access control choices to system administrators and application writers. AFS Control features:
One of the uses of these features may be by a system administrator to:
AFS control provides an additional dimension to DCE access control mechanisms. Its features also enhance the usefulness of traditional license enforcement products.
Design and implement new functionality to dynamically adjust the free-running frequency of a system's clock (i.e., train the clock). This new functionality will reduce the actual error (difference between clock and UTC) as well as the skew (difference between clocks). This will be achieved by observing the historical behaviour of the clock (i.e., whether is has been fast or slow relative to UTC) and correcting it accordingly, similar to the mechanism used by NTP. The key distinction will be preserving the DTS property of correctness.
This involves making the DUA and DSA thread safe, and adding threads to the DSA.
OSF/1 currently implements the POSIX time zone definition. DCE Time currently adds its own rules and time zone package which is not POSIX compliant. Since the OSF direction is to use standards where standards exist, DCE Time should be modified to use the POSIX definition.
The state of support for kernel RPC today is:
The requirement is to support a full kernel RPC, i.e., a set of kernel RPC services and APIs as in the user space version of RPC (not the subset that is supported today).
OSF/1 supports privileges today as a compilation option for the NCSC B1 and upwards levels. The user acquires privileges at login time. It defines the user's access to object, commands, system calls, and other resources at runtime. These privileges are discreet from the unix uids and gids which are associated with users/processes. Auditing implies that privileges are to be compiled in. When privileges are active in the operating system and DCE user registry is the authentication method, this privilege information must be returned at login time so the user can do useful work in the system. OSF needs to solve this problem. Compatibility with existing registry/ticket protocol is essential.
Message queueing is a technique used for program-to-program communication. It can be used within any application where programs communicate with each other. This communication is done by the programs sending messages to each other via queues. The messages contain application data, which is being passed from one part of the application to another.
Message queueing has certain important characteristics that distinguish it from some other methods of program-to-program communication:
Message queueing is naturally asynchronous; program A sends a message to program B, but program B need not be there to receive it. The message is not lost. Instead, it is retained by the message queueing service, for program B to process when B starts execution, which might be immediately, but could equally well be some considerable time later.
Program A may or may not expect a reply from B, but A need not suspend execution waiting for B to reply; instead, A can perform other work, and then process the reply from B when it arrives later. Program A can even terminate before the reply arrives; the reply is not lost -- it is retained by the message queueing service, for A to retrieve when it next executes.
As well as message queueing being used for asynchronous communication between programs, it can also be used in a synchronous manner. In the example above, having sent a message to program B, program A could wait for a reply from B before continuing with its execution.
Message queueing can be used between any two programs, irrespective of whether those programs are executing within one machine, or in different nodes within a network.
If program A wishes to communicate with program B it does not need to know if B executes within the same node as A, or in some other node. The programming statements that would be necessary for program A to send a message to program B, where A and B execute within the one node, would be identical to those that would be required if program B were in a different node from A. In fact, program B can be moved (by the network administrator) from one node to a different node without affecting the execution of program A.
Message queueing does not expose the network protocol to application programs. Instead, program A puts messages to the message-queueing service, and program B gets messages from the message-queueing service. The mechanism by which the message is transmitted from A's message-queueing service to B's message-queueing service is completely hidden from the program. This simplifies application programming considerably.
Similarly, message queueing has no concept of connections between programs -- it can be implemented on a connectionless network, where it is not necessary for two programs to establish a mutual connection before they can communicate. The fact that connections may have to be established between the two message-queueing services does not manifest itself at the application program level.
On large networks, this can reduce both the network start-up time, and the amount of human effort required to control and administer the network.
Message queueing is a natural way of exploiting parallelism. Instead of program A performing all parts of a task sequentially, the task (if suitable) can be split into several smaller and independent activities. These activities could be executed by separate programs, running on the same or different nodes, all executing in parallel. Program A could cause these programs to start execution by sending messages to the appropriate queues; the programs would each perform their designed function and would send their results back to A as messages.
The characteristics described above are of particular benefit to distributed applications, especially those designed to operate on large networks.
This section lists the approximate ordered rankings of results for the 16 top-level (coarsest-granularity) items in the survey.
Various attempts have been made in the past to consolidate the raw votes (reported above) into a single number, but no such scheme has been completely satisfactory. So the technique used to generate the lists below is a compromise: (1) list items in the order determined by the formula "3*a+2*b+1*c-2*d" (in the case of ties, list the ones having the most "A" votes first); but (2) display their raw "a,b,c,d" votes instead of the single number given by the formula. Bear in mind also that the coarse granularity of the top-level items can be misleading because some finer-granularity subitems could be construed as being more important than some of the top-level items (e.g., consider the Delegation subitem of the Enhanced Security Capabilities top-level item). It is for reasons such as these that the rankings below are considered to be only "approximate", and of somewhat limited ("broad brush stroke") value.
Improve DCE Performance 9,7,5,0 DCE Code Cleanup 6,7,3,0 Serviceability Enhancements 6,7,2,0 Integration of DCE into OSF/1 5,7,3,1 Enhanced Security Capabilities 3,8,4,0 File Systems Enhancements 5,4,5,0 Better PC Integration 6,2,6,2 Enhanced Naming Capabilities 2,6,6,0 Support for TP 6,2,3,1 Internationalization (I18N) of DCE 3,3,8,0 Dist. Application Development Tools 3,7,7,4 More Reference Platforms 5,3,5,3 Resource Management 1,3,7,3 Message Queueing 1,3,4,6 Integration of DME and DCE (N/A) Object-Orientation Extensions (N/A)
Integration of DME and DCE 19,2,0,0 Improve DCE Performance 14,5,0,0 Object-Orientation Extensions 8,8,4,0 Enhanced Naming Capabilities 8,6,1,0 Dist. Application Development Tools 11,5,1,4 Serviceability Enhancements 10,3,0,0 Enhanced Security Capabilities 7,7,0,0 Integration of DCE into OSF/1 8,4,3,1 DCE Code Cleanup 7,4,4,0 File Systems Enhancements 6,7,2,1 Internationalization (I18N) of DCE 5,8,1,0 Better PC Integration 7,6,0,1 Support for TP 8,3,1,1 Message Queueing 6,5,4,3 Resource Management 6,4,1,1 More Reference Platforms 6,5,2,5
| Sumner Blount | Internet email: blount@tuxedo.enet.dec.com | |
| Digital Equipment Corporation | Telephone: +1-508-486-5966 | |
| 550 King St. | ||
| Littleton, MA 01748 | ||
| USA |