Please note: This material is no longer current and appears online for archival purposes only. Use the search and navigation tools above to locate more up-to-date materials, if they exist.

UPenn DC Task Force: Scope of Activities

The DC Task Force will propose an architecture for Penn's distributed computing environment for the next two to five years.

Different types of network or distributed computing

With one exception, the Task Force distinguishes between:

• Penn's current, de facto, network of computing devices,
• the Open Software Foundation's (OSF) "Distributed Computing Environment" or "DCE", and
• a lower-case "distributed computing environment" or "dce".

in the following ways:

• The current network of computing devices is extremely limited in its integration of resources, because integrating them is difficult, especially for any large number of non-identical machines serving heterogeneous needs of a diverse user population.
• The OSF DCE is a specific set of technologies and products that we anticipate using to support our future computing environment, given their current set of features.
• The dce is an extensible, open set of systems, tools, applications, users, etc. using the networked computing and communications environment in relative ease, i.e., with significantly fewer and lower artificial technological barriers to the use of extensive, heterogeneous, and diverse network computing facilities.

The dce and DCE are interrelated in an interesting fashion. First of all, dce is a superset of DCE. Second, where components of our dce can rely on DCE, they should do so, or they risk being part of only our network of computing devices. And third, as DCE provides the foundational services required to provide reliable services at scale, it is difficult to imagine components of our scalable dce that do not rely on DCE.

In other words, the OSF/DCE is seen as the only viable, long-term foundation on which we can choose to build our dce, as it provides an open, widely supported set of tools and services for scalable network computing. While components of the dce might not need to rest on the DCE foundation, at this time, it is difficult to imagine any other source being able to provide a comparably reliable and scaleable foundation within our planning period.

On the other hand, we anticipate near-term requirements for specific dce services that could and probably will be supported by OSF DCE as vendors incorporate the OSF versions in their products. As we make us of such "interim" solutions, we must take care to minimize future conversion problems.

The single exception to our distinction between the upper and lower case DCE and dce is in the name of our Task Force, wherein we use DCE, but take the larger dce as our charge.

The "dce" Architecture

The dce architecture is a blueprint to be used in acquiring the hardware, software and services that comprise a dce. The architecture will define such items as:

• A common, University-wide username space and mechanisms for maintaining it;
• A cell structure for the University of Pennsylvania, including the DCE "Secure Core" -- Security Service (Kerberos-based authentication services), CDS (a cell directory service), DTS or NTP (either DCE's Distributed Time Service, or the Network Time Protocol) -- components;
• Kerberos authentication services standards other than OSF/DCE's to support pressing requirements and pilot projects
• An implementation of the OSF DCE's Distributed File System (DFS);
• Linkages to major LAN file services or Network Operating Systems (NOS), specifically NFS, Novell NetWare, and AppleShare;
• Network information security, including network-wide authentication services;
• Technologies for managing large numbers of heterogeneous computer systems;
• Standards for various types of secure remote procedure calls;
• Connection to the emerging world-wide, Internet DCE;

Assumptions about the Task Force's Scope

The architecture effort recognizes the following assumptions about the scope of its activities:

• Like other IT Architectures, the DCE will not define every component at the same level of detail. Because technologies for authentication and file services are already relatively mature, the architecture's definition of them will be more complete than its definitions of authorization and management facilities, and user tools and resources. While parts of these other areas will be well-defined, they are on the whole more open-ended and less mature.
• The DCE architecture will include models for both the lower layer networking protocols (e.g., transports, RPCs, and threads), and the services that use those layers to provide functionality (e.g., authentication, authorization, file services, and user tools). Other efforts will coordinate with the DCE Task Force and provide important inputs (e.g., Cornerstone, Access 2000, the Network Architecture Task Force, other client/server strategies, and the Email Task Force), including specifying the desktop hardware and operating systems that can play in Penn's DCE. From these models will flow the standards and supported product lists to be adopted campus-wide.
• The components of OSF/DCE are evolving at different rates.

UPenn DCE Task Force: Architecture Planning Assumptions

Note: Assumptions imply "where appropriate" unless explicitly stated otherwise.

General

• The planning period is immediate to five years. Different components of the architecture, however, will likely become available and mature at different times and rates, have different life cycles, and therefore different depreciation and replacement schedules. Implicit in this is continuous, on-going, and incremental development and deployment of our dce.
• Penn will require a state-of-the art means of effectively sharing and managing network resources both internally and externally in order to retain its position as a first rate research university.
• The development of standards will be a major University initiative in the '94-'95 fiscal year.
• Operational deployment of Penn's DCE will begin roughly during the summer of 1996.
• Standards will be deployed and maintained University-wide. Compliance with standards is necessary to achieve business objectives.
• The community of those that support and use the network effort both centrally and distributed around the campus must be able to adjust to extremely rapid change in skills, operational requirements, and user procedures. Investments in technical training for staff will be required.

Cost

• The planning effort will attempt to develop the right solutions for Penn while recognizing the challenge the University will face in funding its full life cycle implementation.
• Non-compliant and old networking technologies that cannot participate in a distributed computing environment will be costly to replace. Similarly, some technologies that provide functionally inferior subsets of a distributed computing environment will be costly to displace.
• Funding is a continuous, on-going requirement as these technologies will be evolving for many years to come. However, the dce's focus on delivering economies of scale and specialization should result in significant cost savings and cost avoidance.

Standards

• Open-standards-based solutions supporting Penn's heterogeneous computing environment will be preferred to proprietary ones for several reasons:
  • our desire to have the largest possible pool of system vendors to choose from, to spur competition and help save money, and to allow people to choose special computing systems to meet special, even esoteric requirements, especially in the pursuit of academic objectives,
  • to gain the greatest flexibility in using our dce, partly by having access to the largest number of open interfaces to different levels of the dce, and
  • to reap the economic benefits that follow from the reduced learning costs and greater selection in selecting products and services of open-systems, and therefore lowering the total cost of ownership.
• OSF's DCE will be the foundation for our enterprise-wide distributed computing environment, although we may elect to use only portions of current and future versions of OSF DCE. Other options are not, and will not become viable during the planning period.
• Transarc Corporation's AFS, which is derived from CMU's Andrew File System, will cease to be a viable alternative within 12-18 months, i.e., before our target date for operational deployment of dce.
• The fewer standards that can be selected to solve a particular problem the better.
• Users will expect functionality at least equivalent to those provided by prevailing applications, even if prevailing applications do not adhere to standards.
• Standards will be deployed, enforced, and maintained University-wide. Enforcement methods need to be negotiated ahead of time and established to assure adherence with critical standards. The dce will need to interact at some level with systems that do not adhere to standards.
• Interim standards may be required or useful in order to provide desireable functionality in the short term as standards evolve.
• dce standards will need to be compelling in and of themselves, and well communicated as well. (i.e., you can't sell a bad standard, but even a good standard won't sell without thoughtful and thorough communication).
• Legacy network computing devices and functions that are part of the current architecture will have to be accommodated for a limited time.

Applications

• Commercial versions of certain components of system software and applications, and the foundational DCE Secure Core and DFS, will be required to achieve sufficient quality and robustness for operational deployment.
• Public domain / Internet-wide user applications (building on the commercial foundations) will contribute significantly to the choice of enterprise-wide network applications.
• Applications deployed will be a mixture of purchased packaged solutions and custom-developed solutions. Only customization of purchased packages (e.g., help desk or DCE management applications) that is explicitly supported by the vendor for a package's useful life will be allowed. Packages from one or more vendors must be integrated with one another.
• In-house customization of software (public domain or commercial) will be permitted only after an assessment of lifecycle costs, risks, benefits, and resource requirements is performed to insure that the customized software can be adequately supported.
• DCE is an important building block for the client/server applications that will be deployed during the planning period to maximize the utilization of powerful desktop computers, and provide seamless access to network resources.
• Faculty, staff, and students will all become major users of the dce during the planning period.
• The dce will need to serve alumni during the planning period.
• All dorms will be wired by the end of the planning period.
• Penn's dce needs to be sufficient scalable as to support to all faculty, students, and staff by the end of the planning period.
• Telecommuting will become increasingly important.
• The dce must be available 24 hour a day, 365 days a year.
• Application and users needs will determine where public domain, freeware, shareware, and commercial software are most appropriate and preferred.
• Future applications will run cooperatively across multiple server hosts.
• New "killer apps" will increase demands on the dce in unpredictable ways.
• The Internet will become substantially commercialized by the end of the planning period, requiring tighter access controls, and more robust authentication.
• Penn will use the Internet for commercial services/uses by the end of the planning period.
• Administrative users value consistent, reliable services and are by-and-large not as interested in new services as academic users. Academic users often expect new, experimental services to be as reliable as standard offerings.

Infrastructure

• The Internet is Penn's wide-area network. Therefore, the TCP/IP suite of protocols will continue to be the enterprise-wide protocols of choice for our enterprise-wide dce.
• The infrastructure, which includes work group environments, must provide robust and reliable dce connectivity both on- and off-campus, perhaps with different levels of performance.
• The DCE architecture will support the use of graphical user interfaces (GUIs). GUIs will often be preferred for both system management and end-user tools.
• Unix (versions to be determined) will be the preferred application server and data server operating system.
• MS-Windows, MacOS, and Unix/Motif systems will be the preferred DCE clients.
• "Network computing" workgroup servers used for file and/or print services that run proprietary network operating systems (e.g. Netware, Windows-NT, and AppleShare) will have difficulty joining the dce, but will eventually be able to participate at some level. Apple's AppleShare, Novell's NetWare, and MicroSoft's Windows NT are likely to join the TCP/IP and DCE-based dce before the dce is able to welcome them via AppleTalk, IPX/SPX, or NetBeui protocols.
• Operating systems tied to a single vendor's hardware platform are not desirable for servers.

Organization

• The IT organizations (central and distributed) must be able to adjust to changing skills and operations requirements. Investments in training will be required.
• New levels of interorganizational trust, coordination, and cooperation will be required to deploy a pervasive, widely-used dce.
• IT organizations on campus will choose to support a number of dce-compliant applications on a variety of hardware and software platforms. Some of these applications, hardware and software will not be supported by other organizations.

Please note: This material is no longer current and appears online for archival purposes only. Use the search and navigation tools above to locate more up-to-date materials, if they exist.