rfc2768.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,205 行 · 第 1/5 页

Network Working Group                                          B. Aiken
Request for Comments: 2768                                 J. Strassner
Category: Informational                                   Cisco Systems
                                                           B. Carpenter
                                                                    IBM
                                                              I. Foster
                                            Argonne National Laboratory
                                                               C. Lynch
                                    Coalition for Networked Information
                                                           J. Mambretti
                                                                  ICAIR
                                                               R. Moore
                                                                   UCSD
                                                          B. Teitelbaum
                                     Advanced Networks & Services, Inc.
                                                          February 2000


                     Network Policy and Services:
                 A Report of a Workshop on Middleware

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   An ad hoc middleware workshop was held at the International Center
   for Advanced Internet Research in December 1998.  The Workshop was
   organized and sponsored by Cisco, Northwestern University's
   International Center for Advanced Internet Research (iCAIR), IBM, and
   the National Science Foundation (NSF). The goal of the workshop was
   to identify existing middleware services that could be leveraged for
   new capabilities as well as identifying additional middleware
   services requiring research and development.  The workshop
   participants discussed the definition of middleware in general,
   examined the applications perspective, detailed underlying network
   transport capabilities relevant to middleware services, and then
   covered various specific examples of middleware components. These
   included APIs, authentication, authorization, and accounting (AAA)
   issues, policy framework, directories, resource management, networked
   information discovery and retrieval services, quality of service,



Aiken, et al.                Informational                      [Page 1]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   security, and operational tools.  The need for a more organized
   framework for middleware R&D was recognized, and a list of specific
   topics needing further work was identified.

Table of Contents

   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   1.0   Contextual Framework . . . . . . . . . . . . . . . . . . . .  3
   2.0   What is Middleware?  . . . . . . . . . . . . . . . . . . . .  4
   3.0   Application Perspective  . . . . . . . . . . . . . . . . . .  6
   4.0   Exemplary Components . . . . . . . . . . . . . . . . . . . .  7
   5.0   Application Programming Interfaces and Signaling . . . . . .  8
   6.0   IETF AAA . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.0   Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.0   Directories  . . . . . . . . . . . . . . . . . . . . . . . . 12
   9.0   Resource Management  . . . . . . . . . . . . . . . . . . . . 15
   10.0  Networked Information Discovery and Retrieval Services . . . 17
   11.0  Network QOS  . . . . . . . . . . . . . . . . . . . . . . . . 18
   12.0  Authentication, authorization, and access management . . . . 21
   13.0  Network Management, Performance, and Operations  . . . . . . 22
   14.0  Middleware to support multicast applications . . . . . . . . 23
   15.0  Java and Jini TM . . . . . . . . . . . . . . . . . . . . . . 24
   16.0  Security Considerations  . . . . . . . . . . . . . . . . . . 24
   17.0  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   18.0  Participants . . . . . . . . . . . . . . . . . . . . . . . . 26
   19.0  URLs/references  . . . . . . . . . . . . . . . . . . . . . . 27
   20.0  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
   21.0  Full Copyright Statement . . . . . . . . . . . . . . . . . . 29

Introduction

   This document describes the term "middleware" as well as its
   requirements and scope. Its purpose is to facilitate communication
   between developers of both collaboration based and high-performance
   distributed computing applications and developers of the network
   infrastructure. Generally, in advanced networks, middleware consists
   of services and other resources located between both the applications
   and the underlying packet forwarding and routing infrastructure,
   although no consensus currently exists on the precise lines of
   demarcation that would define those domains. This document is being
   developed within the context of existing standards efforts.
   Consequently, this document defines middleware core components within
   the framework of the current status of middleware-related standards
   activities, especially within the IETF and the Desktop Management
   Task Force (DMTF). The envisioned role of the IETF is to lead the
   work in defining the underlying protocols that could be used to
   support a middleware infrastructure. In this context, we will
   leverage the information modeling work, as well as the advanced XML



Aiken, et al.                Informational                      [Page 2]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   and CIM/DEN-LDAP mapping work, being done in the DMTF. (The recently
   constituted Grid Forum is also pursuing relevant activities.)

   This document also addresses the impact of middleware on Internet
   protocol development. As part of its approach to describing
   middleware, this document has initially focused on the intersections
   among middleware components and application areas that already have
   well defined activities underway.

   This document is a product of an ad hoc Middleware Workshop held on
   December 4-5 1998. The Workshop was organized and sponsored by Cisco,
   Northwestern University's International Center for Advanced Internet
   Research (iCAIR), IBM, and the National Science Foundation (NSF).
   The goal of the workshop was to define the term middleware and its
   requirements on advanced network infrastructures as well as on
   distributed applications. These definitions will enable a set of core
   middleware components to subsequently be specified, both for
   supporting advanced application environments as well as for providing
   a basis for other middleware services.

   Although this document is focused on a greater set of issues than
   just Internet protocols, the concepts and issues put forth here are
   extremely relevant to the way networks and protocols need to evolve
   as we move into the implementation stage of "the network is the
   computer". Therefore, this document is offered to the IETF, DMTF,
   Internet2, Next Generation Internet (NGI), NSF Partnerships for
   Advanced Computational Infrastructure (PACI), the interagency
   Information Technology for the 21st Century (IT2) program, the Grid
   Forum, the Worldwide Web Consortium, and other communities for their
   consideration.

   This document is organized as follows: Section 1 provides a
   contextual framework. Section 2 defines middleware. Section 3
   discusses application requirements. Subsequent sections discuss
   requirements and capabilities for middleware as defined by
   applications and middleware practitioners. These sections will also
   discuss the required underlying transport infrastructure,
   administrative policy and  management, exemplary core middleware
   components, provisioning issues, network environment and
   implementation issues, and research areas.

1.0 Contextual Framework

   Middleware can be defined to encompass a large set of services. For
   example, we chose to focus initially on the services needed to
   support a common set of applications based on a distributed network
   environment.  A consensus of the Workshop was that there was really
   no core set of middleware services in the sense that all applications



Aiken, et al.                Informational                      [Page 3]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   required them.  This consensus does not diminish the importance of
   application domain-specific middleware, or the flexibility needed in
   determining customized approaches. Many communities  (e.g.,
   Internet2, NGI, and other advanced Internet constituencies) may
   decide on their own set of common middleware services and tools;
   however, they should strive for interoperability whenever possible.
   The topics in this workshop were chosen to encourage discussion about
   the nature and scope of middleware per se as distinct from specific
   types of applications; therefore, many relevant middleware topics
   were not discussed.

   Another consensus of the Workshop that helped provide focus was that,
   although middleware could be conceptualized as hierarchical, or
   layered, such an approach was not helpful, and indeed had been
   problematic and unproductive in earlier efforts.

   The better approach would be to consider middleware as an
   unstructured, often orthogonal, collection of components (such as
   resources and services) that could be utilized either individually or
   in various subsets.  This working assumption avoided extensive
   theological modeling discussions, and enables work to proceed on
   various middleware issues independently.

   An important goal of the Workshop was to identify any middleware or
   network-related research or development that would be required to
   advance the state of the art to support advanced application
   environments, such as those being developed and pursued by NGI and
   Internet2.  Consequently, discussion focused on those areas that had
   the maximum opportunity for such advances.

2.0  What is Middleware?

   The Workshop participants agreed on the existence of middleware, but
   quickly made it clear that the definition of middleware was dependent
   on the subjective perspective of those trying to define it. Perhaps
   it was even dependent on when the question was asked, since the
   middleware of yesterday (e.g., Domain Name Service, Public Key
   Infrastructure, and Event Services) may become the fundamental
   network infrastructure of tomorrow.  Application environment users
   and programmers see everything below the API as middleware.
   Networking gurus see anything above IP as middleware. Those working
   on applications, tools, and mechanisms between these two extremes see
   it as somewhere between TCP and the API, with some even further
   classifying middleware into application-specific upper middleware,
   generic middle middleware, and resource-specific lower middleware.
   The point was made repeatedly that middleware often extends beyond
   the "network" into the compute, storage, and other resources that the
   network connects.  For example, a video serving application will want



Aiken, et al.                Informational                      [Page 4]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   to access resource discovery and allocation services not just for
   networks but also for the archives and computers required to serve
   and process the video stream.  Through the application of general set
   theory and rough consensus, we roughly characterize middleware as
   those services found above the transport (i.e., over TCP/IP) layer
   set of services but below the application environment (i.e., below
   application-level APIs).

   Some of the earliest conceptualizations of middleware originated with
   the distributed operating research of the late 1970s and early 1980s,
   and was further advanced by the I-WAY project at SC'95.  The I-WAY