|
|
|
|
The New DCE Review the Forum discussion of this draft |
The relation between DCE and the IT DialTone Architecture Draft for review by the DCE Program Group and the Architecture Board |
||
Introduction 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 Architecture Board and Program Groups 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.
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 "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. Each of these environments is specifically designed to meet a particular set of usage, business, and/or operational goals or objectives. 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, and for diversely constructed environments within an enterprise to be mutually accessible and interoperable. |
|
A look back at where DCE came from. Was the process more successful in the early days? |
The Origin of DCE DCE began as an effort to identify technologies that could be used to 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 "RFTs," 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. |
||
This section defines the target market for DCE by characterizing the organizations that have already adopted DCE. What aspects of "Enterprise Computing" particularly demand DCE? |
The Users of DCE It is significant that most adopters of DCE are organizations with a long heritage of centralized enterprise computing. They have chosen DCE as a platform on which to build applications that address mission-critical and differentiating applications that are core to the operation of their enterprises. Typically, DCE is deployed in centrally administered and controlled contexts that would in the past have been implemented as "glass house" data centers. These contexts usually support the operation of many diverse but interdependent applications. In most cases, the applications and their systems include several generations of the organization’s technology initiatives, and represent a substantial investment. These business applications are typically transactional in nature – that is, they repeatedly perform distinct but similar units of work. (This description includes database and file system access as well as multiphase transactions.) They often have stringent capacity, latency, or throughput requirements. A key feature of DCE that 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 or per data element authentication and authorization services. The ability to carry credentials through multiple tiers of client server architectures is another key feature when interdependent services are assembled into complex business systems. |
||
How has the definition of DCE evolved so far? How should it evolve into the future? |
The Evolution of DCE 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 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 is a framework that will guarantee consistent performance and operation of any "DCE" elements they choose to adopt. Users’ understanding of the role of DCE in the enterprise IT environment 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 or for 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. Users want the benefits of this robust and operable infrastructure to be carried "upward" to all overlying applications deployed in the environment. This upward extension of the benefits of DCE infrastructure must extend through and to any overlying application, not just those specifically designed using DCE RPC. |
||
|
The Future of DCE in the IT DialTone 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 will provide IT DialTone API’s so that IT DialTone applications 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, recovery, 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-appropriate 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 (or have traditionally built) 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. |