Call Logistics:

1. DCE and the IT DialTone

The following is a draft of a proposal to the Architecture Board of The Open Group. It is a statement of how DCE will relate to the IT DialTone and, consequently, how the DCE Program Group will be treated in the future.

The Program Groups of the Open Group have until the end of June (that is, until the July meetings) to define their relation to the IT DialTone initiative. This draft proposal will, after discussion with the DCE Forum, be presented to the Architecture Board at its April meeting.

This presentation is intended to get a first reaction from the AB, so that if there are adjustments that might be needed, the DCE program will have three months to work on them.

Please read this as a proposal, and feel free to comment on it in any way you deem appropriate.

Thanks,
Eliot

The Open Group is in the process of realigning its operations around a new mission. The new corporate mission is embodied in a new architecture for ubiquitously available Information Technology called the IT DialTone architecture The IT DialTone initiative will provide an architecture against which standards may be evaluated. Standards which conform to the requirements of the IT DialTone architecture will be included in The Open Group's Standards Information Base. Products that conform to those standards will be considered IT DialTone products.

The IT DialTone initiative is NOT intended to create either standards or products. It will operate mainly by identifying appropriate standards and products developed by others. This does not preclude The Open Group from creating standards or products, but it is not the primary mechanism for populating the IT DialTone Standards Information Base.

(For a more detailed description of the IT DialTone Initiative, see the relevant pages in the Open Group's web site.)

The Board of Directors of The Open Group has created the Architecture Board to oversee all technical work of The Open Group, and to create the IT DialTone Architecture. Program Groups are, as of January 1, 1998, created by the Architecture Board. Two types of Program Group will be recognized.

• Strategic Program Groups

• Clear (and defined) link to IT DialTone Strategy

• Voting participation in the Architecture Board

• "Other" Program Groups

• No clear link to IT DialTone Strategy

• No entitlement to participate in the Architecture Board

Allocation of Open Group resources to program groups will be based on this characterization. "Other" Program groups may be limited to using resources that they raise on their own.

"The IT DialTone initiative focuses on the commercial needs of both suppliers and customers for a global, ubiquitous, robust, and easy to use distributed communications infrastructure for the deployment of business applications." It has a number of important elements.

The architecture model itself is represented as a three dimensional object. Viewed from the "front" it is divided into distinct "services," in a partially hierarchical model. Examples of services are communication services, management services, location services, information flow control services, security services, presentation services and so on. Viewed from the "side," the model is divided into "qualities." Qualities is the term used in the IT DialTone effort for what is sometimes referred to as the "ilities." Qualities include manageability, "securability", reliability, scalability, and so on.

The environment in which the IT DialTone Architecture is employed consists of a number of elements or contexts. The major elements are the IT DialTone core infrastructure, and IT DialTone Application Environments. (Non-conforming environments are also recognized, and generally characterized as "legacy.")

An IT DialTone Application Environment is "a standardized environment that enables a business application to exploit the capabilities of the IT DialTone Core Infrastructure." The "Network Computer" and the "Internet Server" are examples of IT DialTone Application Environments.

The IT DialTone initiative is to be driven by business requirements. One of the key insights in this regard is that not all businesses are the same, and that not all parts of a single business have identical requirements. The use of Application Environments as a key architectural element will allow diversely constructed and operated enterprises to be consistently accessible from outside the enterprise.

DCE began as an effort to identify technologies that could be used t address the problems of "distributed computing." (It is worth noting that "distributed computing" at that time meant networked enterprise computing, not global network computing.) The DCE process involved the use of "RFT's," Requests for Technology, by which vendors were requested to supply solutions to specific parts of the distributed computing problem. The OSF selected one appropriate technology for each part of the problem. The parts were then "adapted" to fit appropriately together into an integrated distributed computing environment.

It is significant that most adopters of DCE are organizations with a long heritage of centralized enterprise computing. They have chosen DCE as the platform on which to build applications that address mission critical and differentiating applications that are core to the operation of their enterprises. Typically, it is deployed in "data center" contexts. These contexts support the operation of many diverse but interdependent applications. These applications are typically transactional in nature, often with significant capacity or throughput requirements. A key feature of DCE which attracted these early adopters is the security mechanism inherent in the DCE RPC. It supports not only session-oriented authentication of an end user, but also fine-grained, per-transaction authentication and authorization services that can carry credentials through multiple tiers of client server architectures.

Over its life, DCE has come to be defined as a specific set of core services. This definition is no longer serving DCE well. A key example of the change in view can be seen in the evolving approach to directory services. Until recently, DCE directory services were provided by CDS. CDS was the directory service that defined DCE. In the near future, the LDAP NSI, which was recently added to DCE, will allow DCE to use any of a number of LDAP-compliant directory services, either in addition to or instead of CDS. This is the trend in actual deployment of DCE. As using organizations become more sophisticated in their understanding of distributed computing, both in terms of what it is and what it can do, they increasingly need to be able to deploy DCE in variable configurations to meet the specific needs of the individual enterprise. What they seek from DCE as a framework will be guarantees of consistent performance and operation of any "DCE" elements they choose to adopt.

The understanding of the role of DCE is evolving. The definition of DCE is becoming an "application environment" for mission-critical enterprise computing. This environment is typically used in contexts where a number of high-volume, transactional applications are run centrally, and made available throughout the enterprise. DCE services, both those supplied to the enterprise and those built by the enterprise, are typically distributed and replicated for throughput and reliability. Infrastructure services are "tuned" to allow that distributed, replicated architecture to be correctly operated and administered, so that "clients" experience minimal latency or interruption as the replication and associated recovery and reliability mechanisms are employed.

The DCE Program proposes that DCE be related to the IT DialTone architecture as a specific "Application Environment." The targeted market (user base) for the DCE Application Environment is enterprise computing with a significant component of centralized, mission critical services. The DCE Application environment will be (or become) a complete IT DialTone environment. That is, it wil provide IT DialTone API's so that IT DialTone aplications will be guaranteed to operate correctly. It will also provide a full IT DialTone interface to the IT DialTone core infrastucture, so that clients or other interoperators outside the local environment will be correctly supported.

The DCE Environment will be enhanced in some regards by comparison with a "generic" IT DialTone application environment. It will include standards and defined practices that will help ensure that DCE compliant elements, when deployed in a DCE environment, will be able to achieve the levels of throughput and reliability desired by the target user community. This will include the assurance that DCE compliant elements will not interfere with pre-existing components of the enterprise computing environment. In particular, it will help assure that existing DCE-compliant operational procedures, including administration, security, monitoring, recover, and so forth, will not be compromised by the introduction of a new component.

DCE will continue to define certain core services in a rigorous manner, using either base or reference implementations. However, DCE will extend its scope to include "higher level" services that are less rigorously defined in terms of implementation or functionality. In general, higher level DCE services will be defined or identified by their "qualities," and the manner in which they use underlying DCE services.

To relate DCE to the IT DialTone architecture, we propose to introduce the concept of "quality profile" as an element of business requirements that IT DialTone will address. To meet a particular business's objective, its IT infrastructure must meet the business's needs in the most cost-effective manner. Each of the "qualities" of the IT DialTone architecture can be met to differing degrees at differing costs. The best cost-benefit ratio for a particular business requirement can be characterized as a "quality profile," which identifies the metrics by which the business would evaluate the qualities, and the relative value each of the qualities has to the business. The "quality profile" could be viewed as the third dimension of the architecture model.

DCE, in this context, is the application environment associated with a class of business requirements that value high-throughput, low latency, nearly continuously available centralized applications. It is intended for organizations that typically build environmentally-controlled, raised floor data centers, with back-up or duplicated sites. Such organizations typically have fairly large, tightly disciplined three-shift operations staffs, and carefully defined procedures manuals by which the staff respond to a variety of scheduled and unscheduled events. They support large numbers of employees whose job functions are defined and predictable. These characteristics lead to models of fixed and variable costs that differ from other business models, and, therefore, require specific approaches to IT deployment and architecture.

DCE would be the third defined application environment, after the Network Computer and the Internet Server. It will be IT DialTone in microcosm, allowing significant latitude on the part of implementers and users to meet specific needs. It will be more focused than IT DialTone, incorporating certain characteristics and constraints that are specifically appropriate for the DCE target market, but that might be inappropriate for a "ubiquitous" platform architecture.