[要約] RFC 2768は、ミドルウェアに関するワークショップの報告書であり、ネットワークポリシーとサービスに焦点を当てています。このRFCの目的は、ミドルウェアの役割と機能についての理解を深め、ネットワークポリシーとサービスの設計と実装に役立つ情報を提供することです。
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.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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, 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.
1998年12月にアドホックミドルウェアワークショップが国際高等インターネット研究センターで開催されました。このワークショップは、ノースウェスタン大学の先進インターネット研究センター（ICAIR）、IBM、および国立科学財団（NSF）のシスコが組織し、後援しました。。ワークショップの目標は、新しい機能に活用できる既存のミドルウェアサービスを特定し、研究開発を必要とする追加のミドルウェアサービスを特定することでした。ワークショップの参加者は、一般的なミドルウェアの定義について議論し、アプリケーションの観点を調べ、ミドルウェアサービスに関連する基礎となるネットワーク輸送機能の詳細を調べ、その後、ミドルウェアコンポーネントのさまざまな特定の例をカバーしました。これらには、API、認証、承認、会計（AAA）の問題、ポリシーフレームワーク、ディレクトリ、リソース管理、ネットワーク情報の発見と検索サービス、サービスの質、セキュリティ、および運用ツールが含まれます。ミドルウェアR＆Dのより組織化されたフレームワークの必要性が認識され、さらなる作業が必要な特定のトピックのリストが特定されました。
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 and CIM/DEN-LDAP mapping work, being done in the DMTF. (The recently constituted Grid Forum is also pursuing relevant activities.)
このドキュメントでは、「ミドルウェア」という用語とその要件と範囲について説明します。その目的は、コラボレーションベースと高性能分散コンピューティングアプリケーションの両方の開発者と、ネットワークインフラストラクチャの開発者間のコミュニケーションを促進することです。一般的に、高度なネットワークでは、ミドルウェアは、アプリケーションと基礎となるパケット転送とルーティングインフラの両方の間にあるサービスとその他のリソースで構成されていますが、現在、それらのドメインを定義する正確な境界線にコンセンサスは存在しません。このドキュメントは、既存の標準努力のコンテキスト内で開発されています。その結果、このドキュメントは、特にIETFおよびデスクトップ管理タスクフォース（DMTF）内で、ミドルウェア関連標準アクティビティの現在のステータスのフレームワーク内のミドルウェアコアコンポーネントを定義します。IETFの想定される役割は、ミドルウェアインフラストラクチャをサポートするために使用できる基礎となるプロトコルを定義する作業をリードすることです。これに関連して、DMTFで行われている高度なXMLおよびCIM/DEN-LDAPマッピング作業と同様に、情報モデリング作業を活用します。（最近構成されたグリッドフォーラムも関連する活動を追求しています。）
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.
このドキュメントは、1998年12月4〜5日に開催されたアドホックミドルウェアワークショップの製品です。このワークショップは、ノースウェスタン大学の高度なインターネット研究センター（ICAIR）、IBM、および国立科学財団（NSF）のシスコが組織および後援しました。。ワークショップの目標は、ミドルウェアという用語とその要件を、高度なネットワークインフラストラクチャと分散アプリケーションに関する要件を定義することでした。これらの定義により、高度なアプリケーション環境をサポートするだけでなく、他のミドルウェアサービスの基礎を提供するために、コアミドルウェアコンポーネントのセットがその後指定されます。
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.
このドキュメントは、単なるインターネットプロトコルよりも大きな問題に焦点を当てていますが、ここで説明する概念と問題は、「ネットワークはコンピューターです」の実装段階に移行するにつれてネットワークとプロトコルが進化する必要がある方法に非常に関連しています。。したがって、このドキュメントは、IETF、DMTF、Internet2、Next Generation Internet（NGI）、Advanced Computational Infrastructure（PACI）のNSFパートナーシップ、21世紀（IT2）プログラムの省庁間情報技術、グリッドフォーラム、世界中の省庁間情報技術に提供されます。Webコンソーシアム、およびその検討のための他のコミュニティ。
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には、コンテキストフレームワークを示します。セクション2では、ミドルウェアを定義しています。セクション3では、アプリケーションの要件について説明します。後続のセクションでは、アプリケーションとミドルウェアの開業医によって定義されているミドルウェアの要件と機能について説明します。これらのセクションでは、必要な輸送インフラストラクチャ、管理ポリシーと管理、模範的なコアミドルウェアコンポーネント、プロビジョニングの問題、ネットワーク環境と実装の問題、および研究分野についても説明します。
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 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.
ミドルウェアは、大規模なサービスセットを含むように定義できます。たとえば、分散ネットワーク環境に基づいて共通のアプリケーションセットをサポートするために必要なサービスに最初に焦点を当てることを選択しました。ワークショップのコンセンサスは、すべてのアプリケーションがそれらを必要とするという意味で、ミドルウェアサービスのコアセットが実際にはなかったということでした。このコンセンサスは、アプリケーションドメイン固有のミドルウェアの重要性や、カスタマイズされたアプローチの決定に必要な柔軟性を低下させません。多くのコミュニティ（Internet2、NGI、その他の高度なインターネット選挙区など）は、独自の一般的なミドルウェアサービスとツールを決定する場合があります。ただし、可能な限り相互運用性を求めて努力する必要があります。このワークショップのトピックは、特定のタイプのアプリケーションとは異なるミドルウェア自体の性質と範囲についての議論を奨励するために選ばれました。したがって、多くの関連するミドルウェアのトピックは議論されませんでした。
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.
焦点を提供するのに役立ったワークショップのもう1つのコンセンサスは、ミドルウェアが階層的または階層化されたものとして概念化される可能性があるが、そのようなアプローチは役に立たず、実際に以前の努力で問題があり、非生産的であったことでした。
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.
ワークショップの重要な目標は、NGIやInternet2によって開発および追求されているような高度なアプリケーション環境をサポートするために最先端を進めるために必要なミドルウェアまたはネットワーク関連の研究または開発を特定することでした。その結果、議論は、そのような進歩の最大限の機会を持っていた分野に焦点を当てました。
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 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).
ワークショップの参加者はミドルウェアの存在に同意しましたが、ミドルウェアの定義がそれを定義しようとしている人の主観的な視点に依存していることをすぐに明らかにしました。おそらく、昨日のミドルウェア（ドメイン名サービス、公開キーインフラストラクチャ、イベントサービス）が明日の基本的なネットワークインフラストラクチャになる可能性があるため、質問がいつ尋ねられたかにさえ依存していました。アプリケーション環境ユーザーとプログラマーは、API以下のすべてをミドルウェアと見なしています。ネットワーキングの達人は、IPの上にあるものをミドルウェアとして見ています。これらの両極端の間のアプリケーション、ツール、およびメカニズムに取り組んでいる人は、TCPとAPIの間のどこかと見なされ、さらにミドルウェアをアプリケーション固有のミドルウェア、汎用ミドルウェア、およびリソース固有の低ミドルウェアにさらに分類します。ポイントは、ミドルウェアが「ネットワーク」を超えて、ネットワークが接続するコンピューティング、ストレージ、およびその他のリソースに拡張することが多いことを繰り返し述べました。たとえば、ビデオサービングアプリケーションでは、ネットワークだけでなく、ビデオストリームの提供と処理に必要なアーカイブやコンピューター向けにも、リソースの発見と割り当てサービスにアクセスします。一般的なセット理論と大まかなコンセンサスの適用を通じて、ミドルウェアは、アプリケーション環境の下（つまり、アプリケーションレベルAPIの下）の下に、トランスポート（つまり、TCP/IP上）レイヤーセットの上にあるサービスとして大まかに特徴付けます。
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 linked high performance computers nation-wide over high performance networks such that the resulting environment functioned as a single high performance environment. As a consequence of that experiment, the researchers involved re-emphasized the fact that effective high performance distributed computing required distributed common computing and networking resources, including libraries and utilities for resource discovery, scheduling and monitoring, process creation, communication and data transport.
ミドルウェアの最も初期の概念化のいくつかは、1970年代後半から1980年代初頭の分散操作研究で発生し、SC95のI-Wayプロジェクトによってさらに進歩しました。I-Wayは、結果として得られる環境が単一の高性能環境として機能するように、高性能ネットワーク上で全国的に高性能コンピューターをリンクしました。その実験の結果として、研究者は、リソースの発見、スケジューリングと監視、プロセスの作成、コミュニケーション、データ輸送のためのライブラリやユーティリティなど、効果的な高性能分散コンピューティングが分散する共通のコンピューティングとネットワーキングリソースを必要とするという事実を再強調しました。
Subsequent research and development through the Globus project of such middleware resources demonstrated that their capabilities for optimizing advanced application performance in distributed domains.
このようなミドルウェアリソースのGlobusプロジェクトを通じて、その後の研究開発は、分散ドメインでの高度なアプリケーションパフォーマンスを最適化する能力を実証しました。
In May 1997, a Next Generation Internet (NGI) workshop on NGI research areas resulted in a publication, "Research Challenges for the Next Generation Internet", which yields the following description of middleware. "Middleware can be viewed as a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment". This definition could further be refined to include persistent services, such as those found within an operating system, distributed operating environments (e.g., JAVA/JINI), the network infrastructure (e.g., DNS), and transient capabilities (e.g., run time support and libraries) required to support client software on systems and hosts.
1997年5月、NGIの研究分野に関する次世代のインターネット（NGI）ワークショップにより、「次世代インターネットの研究課題」という出版物が出版され、ミドルウェアの以下の説明が得られました。「ミドルウェアは、ネットワーク化された環境でよく機能するために多くのアプリケーションが一般的に必要とするサービスと機能の再利用可能で拡張可能なセットと見なすことができます」。この定義は、オペレーティングシステム内で見つかったサービス、分散オペレーティング環境（Java/Jiniなど）、ネットワークインフラストラクチャ（DNSなど）、および一時的な機能（ランタイムサポートやランタイムサポートなど）などの永続的なサービスを含めるように洗練される可能性があります。ライブラリ）システムとホストでクライアントソフトウェアをサポートする必要があります。
In summary, there are many views of what is middleware. The consensus of many at the workshop was that given the dynamic morphing nature of middleware, it was more important to identify some core middleware services and start working on them than it was to come to a consensus on a dictionary-like definition of the term.
要約すると、ミドルウェアとは何ですか？ワークショップでの多くのコンセンサスは、ミドルウェアの動的なモーフィングの性質を考えると、いくつかのコアミドルウェアサービスを特定し、その用語の辞書のような定義に関するコンセンサスになるよりもそれらに取り組み始めることがより重要だったということでした。
Systems involving strong middleware components to support networked information discovery have also been active research areas since at least the late 1980s. For example, consider Archie or the Harvest project, to cite two examples. One could easily argue that the site logs used by Archie or the broker system and harvest agents were an important middleware tool, and additional work in this area is urgently needed in order to improve the efficiency and scope of web-based indexing services.
ネットワーク化された情報発見をサポートするための強力なミドルウェアコンポーネントを含むシステムは、少なくとも1980年代後半から活動的な研究分野でもあります。たとえば、2つの例を引用するために、ArchieまたはHarvestプロジェクトを検討してください。Archieまたはブローカーシステムと収穫エージェントが使用するサイトログは重要なミドルウェアツールであり、Webベースのインデックス作成サービスの効率と範囲を改善するために、この分野での追加作業が緊急に必要であると主張することができます。
"As long ago" as 1994, the Internet Architecture Board held a workshop on "Information Infrastructure for the Internet" reported in RFC 1862, which in many ways covered similar issues. Although its recommendations were summarized as follows:
1994年の「昔」のインターネットアーキテクチャボードは、RFC 1862で報告された「インターネットの情報インフラストラクチャ」に関するワークショップを開催しました。その推奨事項は次のように要約されましたが、
- increased focus on a general caching and replication architecture - a rapid deployment of name resolution services, and - the articulation of a common security architecture for information applications."
- 一般的なキャッシュおよび複製アーキテクチャに焦点を当てています - 名前解像度サービスの迅速な展開、および情報アプリケーションの一般的なセキュリティアーキテクチャの明確化。」
it is clear that this work is far from done.
この作業が行われていないことは明らかです。
Finally, this workshop noted that there is a close linkage between middleware as a set of standards and protocols and the infrastructure needed to make the middleware meaningful. For example, the DNS protocol would be of limited significance without the system of DNS servers, and indeed the administrative infrastructure of name registry; NTP, in order to be useful, requires the existence of time servers; newer middleware services such as naming, public key registries and certificate authorities, will require even more extensive server and administrative infrastructure in order to become both useful and usable services.
最後に、このワークショップは、一連の標準とプロトコルとしてミドルウェアの間に密接な関係があり、ミドルウェアを意味のあるものにするために必要なインフラストラクチャがあることに注目しました。たとえば、DNSプロトコルは、DNSサーバーのシステム、および実際には名前レジストリの管理インフラストラクチャがなければ重要な意味があります。NTPは、有用であるためには、時間サーバーの存在が必要です。命名、公開キーレジストリ、証明書当局などの新しいミドルウェアサービスには、有用で使用可能なサービスの両方になるために、さらに広範なサーバーと管理インフラストラクチャが必要になります。
From an applications perspective, the network is just another type of resource that it needs to use and manage. The set of middleware services and requirements necessary to support advanced applications are defined by a vision that includes and combines applications in areas such as: distributed computing, distributed data bases, advanced video services, teleimmersion (i.e., a capability for providing a compelling real-life experience in a virtual environment based for example on CAVE technologies), extensions with haptics, electronic commerce, distance education, interactive collaborative research, high-rate instrumentation (60 MByte/s and above sustained), including use of online scientific facilities (e.g. microscopes, telescopes, etc.), effectively managing large amounts of data, computation and information Grids, adaptable and morphing network infrastructure, proxies and agents, and electronic persistent presence (EPP). Many of these applications are "bleeding edge" with respect to currently deployed applications on the commodity Internet and hence have unique requirements. Just as the Web was an advanced application in the early 1990s, many of the application areas defined above will not become commonplace in the immediate future. However, they all possess the capability to change the way the network is used as well as our definition of infrastructure, much as the Web and Mosaic changed it in the early 90s. A notable recent trend in networks is the increasing amount of HTTP, voice, and video traffic, and it was noted that voice and video particularly need some form of QoS and associated middleware to manage it.
アプリケーションの観点から見ると、ネットワークは、使用および管理する必要がある別のタイプのリソースにすぎません。高度なアプリケーションをサポートするために必要なミドルウェアサービスと要件のセットは、分散コンピューティング、分散データベース、高度なビデオサービス、テレイムムーション（つまり、魅力的なリアルなリアルなものを提供する機能を含むアプリケーションを含むビジョンによって定義されます。洞窟技術に基づいた仮想環境でのライフエクスペリエンス、ハプティックスとの拡張、電子商取引、遠隔教育、インタラクティブコラボレーション研究、高レートの計装（60 mbyte/s以上）、オンライン科学施設の使用（例：顕微鏡、望遠鏡など）、大量のデータ、計算および情報グリッド、適応性とモーフィングネットワークインフラストラクチャ、プロキシとエージェント、および電子永続的存在（EPP）を効果的に管理します。これらのアプリケーションの多くは、現在展開されているアプリケーションに関して「エッジを出血させている」ため、独自の要件があります。1990年代初頭にWebが高度なアプリケーションであったように、上記のアプリケーション領域の多くは、近い将来には一般的ではありません。ただし、WebとMosaicが90年代前半に変更したように、それらはすべて、ネットワークの使用方法とインフラストラクチャの定義を変更する機能を備えています。ネットワークの最近の顕著な傾向は、HTTP、音声、ビデオトラフィックの量の増加であり、音声とビデオが特に何らかの形のQosとそれを管理するために関連するミドルウェアが必要であることが注目されました。
A quick review of the requirements for teleimmersion highlight the requirement for multiple concurrent logical network channels, each with its own latency, jitter, burst, and bandwidth QoS; yet all being coordinated through a single middleware interface to the application. For security and efficiency those using online instruments require the ability to steer the devices and change parameters as a direct result of real-time analysis performed on the data as it is received from the instruments. Therefore, network requirements encompass high bandwidth, low latency, and security, which must all be coordinated through middleware. Large databases, archives, and digital libraries are becoming a mainstay for researchers and industry. The requirements they will place on the network and on middleware will be extensive, including support of authentication, authorization, access management, quality of service, networked information discovery and retrieval tools, naming and service location, to name only a few. They also require middleware to support collection building and self-describing data. Distributed computing environments (e.g., Globus, Condor, Legion, etc.) are quickly evolving into the computing and information Grids of the future. These Grids not only require adaptive and manageable network services but also require a sophisticated set of secure middleware capabilities to provide easy-to-use APIs to the application.
テレマーションの要件を簡単にレビューすると、それぞれが独自のレイテンシ、ジッター、バースト、帯域幅のQosを備えた複数の同時の論理ネットワークチャネルの要件を強調しています。しかし、すべてはアプリケーションへの単一のミドルウェアインターフェイスを通じて調整されています。セキュリティと効率のために、オンライン機器を使用している人は、機器から受信したデータに対して実行されるリアルタイム分析の直接的な結果として、デバイスを操縦し、パラメーターを変更する機能を必要とします。したがって、ネットワークの要件には、高い帯域幅、低遅延、セキュリティが含まれます。これらはすべてミドルウェアを通じて調整する必要があります。大規模なデータベース、アーカイブ、デジタルライブラリは、研究者と業界の主力になりつつあります。ネットワークおよびミドルウェアに配置する要件は、認証、承認、アクセス管理、サービスの品質、ネットワーク情報の発見と検索ツール、命名およびサービスの場所など、わずかにわずかに名前を付けることなど、広範囲になります。また、コレクションの構築と自己記述データをサポートするためにミドルウェアが必要です。分散コンピューティング環境（グローブ、コンドル、レギオンなど）は、将来のコンピューティングと情報グリッドに急速に進化しています。これらのグリッドは、適応性のある管理可能なネットワークサービスを必要とするだけでなく、アプリケーションに使いやすいAPIを提供するために、洗練された安全なミドルウェア機能のセットも必要です。
Many application practitioners were adamant that they also required the capability for "pass through" services. This refers to the ability to bypass the middleware and directly access the underlying infrastructure such as the operating system or network), even though they were eager to make use of middleware services and see more of it developed to support their own applications. In addition, authentication and access control, as well as security, are required for all of the applications mentioned above, albeit at different levels.
多くのアプリケーションの開業医は、「パススルー」サービスの機能も必要とすることを断言しました。これは、ミドルウェアサービスやネットワークなどの基礎となるインフラストラクチャにミドルウェアをバイパスし、基礎となるインフラストラクチャに直接アクセスする機能を指します。さらに、異なるレベルではあるが、上記のすべてのアプリケーションには、認証とアクセス制御、およびセキュリティが必要です。
In an attempt to describe middleware and discuss pertinent issues relating to its development and deployment, an exemplary set of services were selected for discussion. These services were chosen to stimulate discussion and not as an attempt to define an exclusive set of middleware services. Also, it is the intent of this effort not to duplicate existing IETF efforts or those of other standards bodies (e.g., the DMTF), but rather to leverage those efforts, and indeed to highlight areas where work was already advanced to a stage that might be approaching deployment.
ミドルウェアを説明し、その開発と展開に関連する関連する問題について議論するために、模範的な一連のサービスが議論のために選択されました。これらのサービスは、ミドルウェアサービスの独占セットを定義する試みとしてではなく、議論を刺激するために選択されました。また、既存のIETFの取り組みや他の標準団体（例：DMTF）の努力を複製するのではなく、それらの努力を活用し、実際に作業が既に進歩している領域を強調するために、既存の努力を活用することは、この努力の意図です。展開に近づいています。
Applications require the ability to explicitly request resources based on their immediate usage needs. These requests have associated network management controls and network resource implications; however, fulfillment of these requests may require multiple intermediate steps. Given the preliminary state of middleware definition, there currently is no common framework, much less a method, for an application to signal its need for a set of desired network services, including quality and priority of service as well as attendant resource requirements. However, given the utility of middleware, especially with regard to optimization for advanced applications, preliminary models for both quality and priority of service and resource management exist and continue to evolve. however, without an agreed-to framework for standards in this area, there is the risk of multiple competing standards that may further delay the deployment of a middleware-rich infrastructure. This framework should probably include signaling methods, access/admission controls, and a series of defined services and resources. In addition, it should include service levels, priority considerations, scheduling, a Service-Level-Agreement (SLA) function, and a feedback mechanism for notifying applications or systems when performance is below the SLA specification or when an application violates the SLA. Any such mechanism implies capabilities for: 1) an interaction with some type of policy implementation and enforcement, 2) dynamic assessment of available network resources, 3) policy monitoring, 4) service guarantees, 5) conflict resolution, and 6) restitution for lack of performance.
アプリケーションでは、当面の使用ニーズに基づいてリソースを明示的に要求する機能が必要です。これらの要求には、ネットワーク管理コントロールとネットワークリソースへの影響が関連付けられています。ただし、これらの要求の履行には、複数の中間ステップが必要になる場合があります。ミドルウェアの定義の予備状態を考えると、現在、サービスの品質と優先順位、および付随するリソース要件を含む一連の望ましいネットワークサービスの必要性を示すアプリケーションのための一般的なフレームワークはありません。ただし、特に高度なアプリケーションの最適化に関しては、ミドルウェアの有用性を考えると、サービスとリソース管理の品質と優先度の両方の予備モデルが存在し、進化し続けています。ただし、この分野の標準の合意されたフレームワークがなければ、ミドルウェアが豊富なインフラストラクチャの展開をさらに遅らせる可能性のある複数の競合する基準のリスクがあります。このフレームワークには、おそらくシグナリング方法、アクセス/入場制御、一連の定義されたサービスとリソースが含まれる必要があります。さらに、サービスレベル、優先順位の考慮事項、スケジューリング、サービスレベルアグリーメント（SLA）関数、およびパフォーマンスがSLA仕様を下回っている場合、またはアプリケーションがSLAに違反したときにアプリケーションまたはシステムを通知するためのフィードバックメカニズムを含める必要があります。このようなメカニズムは、次の能力を意味します。1）何らかのタイプのポリシーの実装と執行との相互作用、2）利用可能なネットワークリソースの動的評価、3）ポリシー監視、4）サービス保証、5）紛争解決、6）欠如のための賠償パフォーマンスの。
Application programmers are concerned with minimizing the interfaces that they must learn to access middleware services. Thus the unification of common services behind a single API is of great interest to middleware users. Examples of common APIs that may be achievable are:
アプリケーションプログラマーは、ミドルウェアサービスにアクセスすることを学ばなければならないインターフェイスの最小化に関心があります。したがって、単一のAPIの背後にある一般的なサービスの統一は、ミドルウェアユーザーにとって非常に興味深いものです。達成可能な一般的なAPIの例は次のとおりです。
* Environmental discovery interface, whether for discovering hardware resources, network status and capabilities, data sets, applications, remote services, or user information. * Remote execution interface, whether for distributed metacomputing applications, or for access to a digital library presentation service, or a Java analysis service. * Data management interface, whether for manipulating data within distributed caches, or replication of data between file systems, or archival storage of data.
* 環境発見インターフェース、ハードウェアリソース、ネットワークステータスと機能、データセット、アプリケーション、リモートサービス、ユーザー情報の発見など。*リモート実行インターフェイス、分散メタコンピューティングアプリケーション用であろうと、デジタルライブラリプレゼンテーションサービスへのアクセス、またはJava分析サービス。*データ管理インターフェイス、分散キャッシュ内のデータを操作する場合、またはファイルシステム間のデータの複製、またはデータのアーカイブストレージ。
* Process management interface, whether for composing data movement with remote execution, or for linking together multiple processing steps.
* プロセス管理インターフェイス、リモート実行でデータの動きを構成する場合でも、複数の処理手順をリンクする場合。
The IETF AAA (authentication, authorization, and accounting) effort is but one of many IETF security initiatives. It depends heavily on a Public key infrastructure, which is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model).
IETF AAA（認証、承認、会計）の取り組みは、多くのIETFセキュリティイニシアチブの1つにすぎません。これは、さまざまな信頼/階層環境とさまざまな使用環境をサポートするフレームワークを提供することを目的とした公開キーインフラストラクチャに大きく依存しています（RFC1422はそのようなモデルの例です）。
The IETF AAA working group has recently been formed. IETF AAA working group efforts are focused on many issues pertaining to middleware, including defining processes for access/admission control and identification (process for determining a unique entity), authentication (process for validating that identity), authorization (process for determining an eligibility for resource requests/utilization) and accounting (at least to the degree that resource utilization is recorded). To some degree, AAA provides for addressing certain levels of security, but only at a preliminary level. Currently, AAA protocols exist, although not as an integrated model or standard. One consideration for AAA is to provide for various levels of granularity. Even if we don't yet have an integrated model, it is currently possible to provide for basic AAA mechanisms that can be used as a basis to support SLAs. Any type of AAA implementation requires a policy management framework, to which it must be linked. Currently, a well-formulated linking mechanism has not been defined.
IETF AAAワーキンググループが最近形成されました。IETF AAAワーキンググループの取り組みは、アクセス/入場制御と識別のプロセスを定義する（一意のエンティティを決定するプロセス）、認証（そのアイデンティティを検証するプロセス）、許可（適格性を決定するためのプロセスなど、ミドルウェアに関連する多くの問題に焦点を当てています。リソースの要求/利用）および会計（少なくともリソース利用が記録される程度）。ある程度、AAAは特定のレベルのセキュリティに対処することを規定していますが、予備レベルでのみ。現在、AAAプロトコルは存在しますが、統合モデルまたは標準としてではありません。AAAの考慮事項の1つは、さまざまなレベルの粒度を提供することです。まだ統合されたモデルがない場合でも、現在、SLAをサポートするための基礎として使用できる基本的なAAAメカニズムを提供することが可能です。あらゆるタイプのAAA実装には、リンクする必要があるポリシー管理フレームワークが必要です。現在、よく形成されたリンクメカニズムは定義されていません。
Middleware AAA requirements are also driven by the distributed interoperation that can occur between middleware services. The distribution of application support across multiple autonomous systems will require self-consistent third-party mechanisms for authentication as well as data movement. Conceptually, an application may need access to data that is under control of a remote collection, to support the execution of a procedure at a third site.
ミドルウェアAAA要件は、ミドルウェアサービス間で発生する可能性のある分散間操作によっても駆動されます。複数の自律システムにわたるアプリケーションサポートの分布には、データの動きと同様に、認証のための自己整合性のサードパーティメカニズムが必要です。概念的には、アプリケーションでは、3番目のサイトでの手順の実行をサポートするために、リモートコレクションの制御下にあるデータへのアクセスが必要になる場合があります。
The data flow needs to be directly from the collection to the execution platform for efficiency. At the same time, the procedure will need access permission to the data set while it is acting on behalf of the requestor. How the authentication is done between the remote procedure and the remote data collection entities raises significant issues related to transitivity of trust, and will require establishment of a trust policy for third-party mechanisms. This is exacerbated when a collection of entities, such as is required for visualization applications, is involved.
データフローは、効率のためにコレクションから実行プラットフォームまで直接行う必要があります。同時に、この手順では、リクエスターに代わって動作している間、データセットへのアクセス許可が必要です。リモートプロシージャとリモートデータ収集エンティティの間で認証が行われる方法は、信頼の交換性に関連する重大な問題を引き起こし、サードパーティのメカニズムのための信頼ポリシーの確立が必要になります。これは、視覚化アプリケーションに必要なエンティティのコレクションが関与している場合に悪化します。
The IETF Policy Framework working group is addressing a policy framework definition language, a policy architecture model, policy terminology and, specifically, a policy model that can be used for signaled as well as provisioned QoS. The policy meta-model links high-level business requirements, such as those that can be specified in an SLA, to low-level device implementation mechanisms, ranging from specific access control and management of services, objects and other resources to configuration of mechanisms necessary to provide a given service.
IETFポリシーフレームワークワーキンググループは、ポリシーフレームワークの定義言語、ポリシーアーキテクチャモデル、ポリシー用語、特に指示に使用できるポリシーモデルとプロビジョニングQOに取り組んでいます。ポリシーメタモデルは、SLAで指定できる高レベルのビジネス要件を、特定のアクセス制御とサービス、オブジェクト、その他のリソースの管理から必要なメカニズムの構成に至るまで、低レベルのデバイス実装メカニズムにリンクします。特定のサービスを提供します。
Polices are an integral component of all middleware services, and will be found within most middleware services in one form or another. Policies are often represented as an "if condition then action" tuple. Policies can be both complex and numerous; therefore, policy management services must be able to identify and resolve policy conflicts. They also need to support both static (i.e. loaded at boot time via a configuration file) and dynamic (i.e. the configuration of a policy enforcing device may change based on an event) modes.
ポリシーはすべてのミドルウェアサービスの不可欠なコンポーネントであり、ほとんどのミドルウェアサービスに何らかの形で見つかります。多くの場合、ポリシーは「If条件、アクション」タプルとして表されます。ポリシーは複雑で多数の両方である可能性があります。したがって、ポリシー管理サービスは、ポリシーの競合を特定して解決できる必要があります。また、静的（構成ファイルを介して起動時にロードされる）と動的（つまり、ポリシー強制デバイスの構成がイベントに基づいて変更される可能性がある）モードの両方をサポートする必要があります。
A generalized policy management architecture (as suggested by the IETF policy architecture draft) includes a policy management service, a dedicated policy repository, at least one policy decision point (PDP), and at least one policy enforcement point (PEP). The policy management service supports the specification, editing, and administration of policy, through a graphical user interface as well as programmatically. The policy repository provides storage and retrieval of policies as well as policy components. These policy components contain definitional information, and may be used to build more complex policies, or may be used as part of the policy decision and/or enforcement process. The PDP (e.g. resource manager, such as a bandwidth broker or an intra-domain policy server) is responsible for handling events and making decisions based on those events (e.g., at time x do y) and updating the PEP configuration appropriately. In addition, it may be responsible for providing the initial configuration of the PEP. The PEP (e.g., router, firewall or host) enforces policy based on the "if condition then action" rule sets it has received from the PDP.
一般化されたポリシー管理アーキテクチャ（IETFポリシーアーキテクチャドラフトで示唆されているように）には、ポリシー管理サービス、専用のポリシーリポジトリ、少なくとも1つのポリシー決定ポイント（PDP）、および少なくとも1つのポリシー執行ポイント（PEP）が含まれます。ポリシー管理サービスは、グラフィカルユーザーインターフェイスとプログラムでの仕様、編集、および管理をサポートしています。ポリシーリポジトリは、ポリシーコンポーネントだけでなく、ポリシーのストレージと取得を提供します。これらのポリシーコンポーネントには定義情報が含まれており、より複雑なポリシーを構築するために使用される場合があります。または、ポリシー決定および/または執行プロセスの一部として使用される場合があります。PDP（例：帯域幅のブローカーやドメイン内ポリシーサーバーなどのリソースマネージャー）は、イベントの処理とこれらのイベント（たとえば、時間x y）に基づいて決定を下し、PEP構成を適切に更新する責任を負います。さらに、PEPの初期構成を提供する責任がある場合があります。PEP（例えば、ルーター、ファイアウォール、またはホスト）は、「条件の場合、アクション」ルールがPDPから受信したセットに基づいてポリシーを実施します。
Policy information may be communicated from the PDP to the PEP through a variety of protocols, such as COPS or DIAMETER. A proxy may be used to translate information contained in these protocols to forms that devices can consume (e.g., command line interface commands or SNMP sets). Additional information, contained in Policy Information Bases (PIBs), may also be used to translate from an intermediate specification to specific functions and capabilities of a device. For example, a policy may specify "if source IP address is 198.10.20.132, then remark traffic with a DSCP of 5". The PIB would be used to translate the device-specific meaning of the conditioning specified by the DiffServ code point of 5 (e.g., a specific set of queue and threshold settings).
ポリシー情報は、警官や直径などのさまざまなプロトコルを介して、PDPからPEPに伝えることができます。プロキシを使用して、これらのプロトコルに含まれる情報を翻訳して、デバイスが消費できる形式（コマンドラインインターフェイスコマンドまたはSNMPセットなど）を形成できます。ポリシー情報ベース（PIB）に含まれる追加情報は、中間仕様からデバイスの特定の機能と機能に変換するためにも使用できます。たとえば、ポリシーは「ソースIPアドレスが198.10.20.132の場合、5のDSCPでトラフィックを照らす」を指定する場合があります。PIBは、5のDiffServコードポイント（例えば、キューとしきい値設定の特定のセット）で指定された条件付けのデバイス固有の意味を変換するために使用されます。
Policy requires AAA functions, not only for access control, but also to establish the trust relationships that will enable distributed policy interactions. PDPs may require the requesting end systems and applications to be authenticated before the PDP will honor any requests. The PDP and PEP must be authenticated to each other to reduce the probability of spoofing. This will be true whichever protocol is utilized for supporting communications between these entities. Audit trails are essential for all of these transactions. In addition, trust management policies will need to be developed as well as the supporting middleware mechanisms to enable inter-domain policy negotiation.
ポリシーには、アクセス制御だけでなく、分散ポリシーの相互作用を可能にする信頼関係を確立するためにも、AAA機能が必要です。PDPは、PDPがリクエストを尊重する前に、リクエストエンドシステムとアプリケーションを認証する必要がある場合があります。PDPとPEPは、スプーフィングの可能性を減らすために互いに認証されなければなりません。これは、これらのエンティティ間の通信をサポートするために使用されるプロトコルのいずれかが真実になります。監査証跡は、これらすべてのトランザクションに不可欠です。さらに、信頼管理ポリシーと、ドメイン間のポリシー交渉を可能にするためのサポートミドルウェアメカニズムを開発する必要があります。
Ultimately, many policy processes link entities to resources, And therefore require interactions with entity identification mechanisms, resource identification mechanisms, and allocation mechanisms. The distributed computing community has already started efforts developing policy definition languages and systems. Globus uses its Resource Services Language (RSL) to define the resources and policies associated with them. Condor uses a matchmaking bidding technique to match those providing and those acquiring services. Similarly, the IETF has several policy definition languages in varying stages of development, including RPSL, RPCL, SPSL, PFDL, PAX, and Keynote. Ultimately, these efforts should be merged into a single specification (or at least a smaller group of specifications) to enable distributed computing applications to be able to effectively communicate and utilize network resources and services.
最終的に、多くのポリシープロセスがエンティティをリソースにリンクするため、エンティティ識別メカニズム、リソース識別メカニズム、および割り当てメカニズムとの相互作用が必要です。分散コンピューティングコミュニティは、すでにポリシー定義言語とシステムの開発努力を開始しています。Globusは、リソースサービス言語（RSL）を使用して、それらに関連するリソースとポリシーを定義します。コンドルは、マッチメイキング入札手法を使用して、提供するものと取得サービスを獲得するものに一致させます。同様に、IETFには、RPSL、RPCL、SPSL、PFDL、PAX、および基調講演など、さまざまな開発段階にいくつかのポリシー定義言語があります。最終的に、これらの取り組みは、分散コンピューティングアプリケーションがネットワークリソースとサービスを効果的に通信および利用できるようにするために、単一の仕様（または少なくとも小規模な仕様のグループ）に統合する必要があります。
Directories play a crucial role in policy systems. Directories are ideally suited for storing and retrieving policy information, due to their exceptionally high read rates, ability to intelligently replicate all or part of their information, per-attribute access control, and use of containment. To this end, the IETF Policy Framework working group (in conjunction with the DMTF) is developing a core information model and LDAP schema that can be used to represent policy information that applications can use. This core model is used to provide common representation and structure of policy information. Applications can then subclass all or part of the classes in this core schema to meet their own specific needs, while retaining the ability to communicate and interoperate with each other.
ディレクトリは、政策システムで重要な役割を果たします。ディレクトリは、非常に高い読み取りレート、情報のすべてまたは一部をインテリジェントに複製する能力、魅力ごとのアクセス制御、および封じ込めの使用により、ポリシー情報の保存と取得に理想的に適しています。この目的のために、IETFポリシーフレームワークワーキンググループ（DMTFと併せて）は、アプリケーションが使用できるポリシー情報を表すために使用できるコア情報モデルとLDAPスキーマを開発しています。このコアモデルは、ポリシー情報の共通の表現と構造を提供するために使用されます。アプリケーションは、このコアスキーマのクラスのすべてまたは一部を、独自の特定のニーズを満たし、相互に通信して相互運用する能力を保持することができます。
Directories are critical resource components that provide support to many other elements in the middleware environment, especially policy. As network-based environment evolves, it will no longer be viable to encode policy information directly into each individual application. The prevailing model in use today is for each application to store its view of a device's data (e.g., configuration) in its own private data store.These data include relevant information concerning network resources and services as well as clients wanting to use those resources (e.g., people, processes, and applications). The same resource (or aspects of that resource, such as its physical vs. logical characteristics) may be represented in several data stores. Even if the device is modeled the same way in each data store, each application only has access to its own data. This leads to duplication of data and data synchronization problems.
ディレクトリは、ミドルウェア環境の他の多くの要素、特にポリシーをサポートする重要なリソースコンポーネントです。ネットワークベースの環境が進化するにつれて、個々のアプリケーションにポリシー情報を直接エンコードすることはもはや実行可能ではありません。今日使用されている一般的なモデルは、各アプリケーションが独自のプライベートデータストアにデバイスのデータ（たとえば、構成）のビューを保存するためのものです。これらのデータには、ネットワークリソースとサービスに関する関連情報、およびそれらのリソースを使用したいクライアント（たとえば、人、プロセス、アプリケーション）。同じリソース（またはそのリソースの側面、その物理的特性と論理的特性など）は、いくつかのデータストアで表される場合があります。デバイスが各データストアで同じ方法でモデル化されている場合でも、各アプリケーションは独自のデータにのみアクセスできます。これにより、データとデータの同期の問題が重複します。
The promise of technologies like CIM and DEN is to enable each application to store data describing the resources that they manage in a single directory using a common format and access protocol. This results in the data describing the resource being represented only once. Defining a logically centralized common repository, where resources and services are represented in a common way, enables applications of different types to utilize and share information about resources and services that they use.
CIMやDENなどのテクノロジーの約束は、各アプリケーションが共通の形式とアクセスプロトコルを使用して単一のディレクトリで管理するリソースを説明するデータを保存できるようにすることです。これにより、リソースが1回だけ表示されることを説明するデータが表示されます。リソースとサービスが共通の方法で表される論理的に集中化された共通リポジトリを定義することにより、さまざまなタイプのアプリケーションが使用しているリソースとサービスに関する情報を利用および共有できるようにします。
Not only does this solve the data duplication and synchronization problems, it also provides inherent extensibility in describing the characteristics of an object - a single entity can be represented by multiple directory objects, each representing a different aspect of the entity. Different applications can be responsible for managing the different objects that together make up a higher-level object, even if the applications themselves can not communicate with each other. This enables these applications to effectively share and reuse data. This provides significant benefits for users and applications. In the short term, users and applications will benefit from having all of the data in one place. In the long term, users and applications will be able to take advantage of data managed by other applications.
これにより、データの複製と同期の問題が解決するだけでなく、オブジェクトの特性を記述する際の固有の拡張性も提供します。単一のエンティティは、それぞれがエンティティの異なる側面を表す複数のディレクトリオブジェクトで表現できます。さまざまなアプリケーションが、アプリケーション自体が相互に通信できなくても、高レベルのオブジェクトを構成するさまざまなオブジェクトを管理する責任があります。これにより、これらのアプリケーションがデータを効果的に共有および再利用できるようになります。これにより、ユーザーとアプリケーションに大きなメリットが提供されます。短期的には、ユーザーとアプリケーションは、すべてのデータを1か所に配置することで恩恵を受けます。長期的には、ユーザーとアプリケーションは他のアプリケーションによって管理されているデータを活用することができます。
Directories are key to supporting advanced network-based application environments. Directory purists say that the directory is not middleware; rather, it is a dumb storage device that is made into an intelligent repository by encapsulating it within middleware. Although a directory associates attributes with objects, what makes it different from a database are four key things:
ディレクトリは、高度なネットワークベースのアプリケーション環境をサポートするための鍵です。ディレクトリの純粋主義者は、ディレクトリはミドルウェアではないと言います。むしろ、それはミドルウェア内でカプセル化することによりインテリジェントリポジトリにする愚かなストレージデバイスです。ディレクトリはオブジェクトに属性を関連付けていますが、データベースと違うのは4つの重要なことです。
- directory objects are essentially independent of each other, whereas database objects are related to each other (sometimes in very complex ways) - directories organize their information using the notion of containment, which is not naturally implemented in databases - directory objects can have specific access controls assigned to an object and even attributes of an object - directories, unlike databases, are optimized to perform a high number of reads vs. writes.
- ディレクトリオブジェクトは本質的に互いに独立していますが、データベースオブジェクトは互いに関連しています（時には非常に複雑な方法で） - ディレクトリは封じ込めの概念を使用して情報を整理します。オブジェクトに割り当てられ、オブジェクトの属性 - ディレクトリは、データベースとは異なり、多くの読み取りと書き込みを実行するように最適化されています。
Directories use a common core schema, supporting a common set of syntaxes and matching rules, that defines the characteristics of their data. This enables a common access protocol to be used to store and retrieve data.
ディレクトリは、データの特性を定義する共通の構文と一致するルールのセットをサポートする共通コアスキーマを使用します。これにより、一般的なアクセスプロトコルを使用してデータを保存および取得できます。
Containment can be used for many purposes, including associating roles with objects. This is critical in order to support a real world environment, where people and elements may assume different roles based on time or other context.Containment may also be used to provide different naming scopes for a given set of data.
封じ込めは、役割をオブジェクトに関連付けるなど、多くの目的に使用できます。これは、人と要素が時間やその他のコンテキストに基づいて異なる役割を引き受ける可能性のある現実世界環境をサポートするために重要です。また、特定のデータセットに異なる命名スコープを提供するために、コンテンメントを使用することもできます。
Directories use attribute inheritance - subclasses inherit the attributes of their superclasses. This enables one to define generalized access control at a container (e.g., a group) and then refine the access control on an individual basis for objects that are inside that container (e.g., different objects have different access privileges).
ディレクトリ使用属性継承を使用 - サブクラスはスーパークラスの属性を継承します。これにより、コンテナで一般化されたアクセス制御を定義し（グループ）、そのコンテナ内にあるオブジェクトの個別ベースでアクセス制御を改良することができます（たとえば、異なるオブジェクトには異なるアクセス権限があります）。
Currently, directories are used mostly to represent people, servers, printers, and other similar objects. CIM, DEN, and other similar efforts have encouraged directories to be used to contain common objects in a managed environment. For networked applications, this enables clients of the network (e.g., users and applications) to be bound to services available in the network in a transparent manner. The "Grid" community is making extensive use of directory services for this purpose, using them to maintain information about the structure and state of not only networks but also computers, storage systems, software, and people. The DMTF is using directories to contain CIM and DEN information, which enables a common information model to be applied to objects in a managed environment. The IETF is using directories for many different purposes, not the least of which is to contain common policy information for users and applications of an environment, as well as services and configuration information of network devices.
現在、ディレクトリは、主に人、サーバー、プリンター、およびその他の類似のオブジェクトを表すために使用されています。CIM、den、およびその他の同様の努力により、ディレクトリが管理された環境に共通のオブジェクトを含めるために使用されるように奨励されています。ネットワーク化されたアプリケーションの場合、ネットワークのクライアント（ユーザーやアプリケーションなど）が透明な方法でネットワークで利用可能なサービスに縛られることができます。「グリッド」コミュニティは、この目的のためにディレクトリサービスを広範囲に使用しており、ネットワークだけでなくコンピューター、ストレージシステム、ソフトウェア、および人々の構造と状態に関する情報を維持するために使用しています。DMTFは、ディレクトリを使用してCIMおよびden情報を含むため、一般的な情報モデルを管理した環境のオブジェクトに適用できます。IETFは、多くの異なる目的でディレクトリを使用していますが、少なくともユーザーの一般的なポリシー情報と環境のアプリケーション、およびネットワークデバイスのサービスと構成情報を含めることです。
CIM and DEN are conceptual information models for describing the management of entities ranging from network elements to protocols to hosts and services. CIM and DEN are platform- and technology-independent. DEN is an extension of CIM that, among other things, describes how to map CIM data into a form usable by LDAP.
CIMとDENは、ネットワーク要素からプロトコル、ホストやサービスに至るまでのエンティティの管理を説明するための概念情報モデルです。CIMとDENは、プラットフォームおよびテクノロジーに依存しません。DENは、とりわけ、CIMデータをLDAPで使用可能なフォームにマッピングする方法を説明するCIMの拡張です。
The CIM Specification describes the meta schema, information model, language, naming, and mapping techniques to other management models, such as SNMP MIBs and DMTF MIFs. DEN provides a good start on a model that addresses the management of the network and its elements; DEN is an extension of CIM to include the management of networks as a whole and not just the individual elements. DEN addresses the requirements for abstracting a complex entity, such as a router, into multiple components that can be used to manage individual aspects of that complex entity. The DEN information model, like CIM, incorporates both static and dynamic information. DEN provides a mapping to directories for the storage and retrieval of data. DEN will also rely heavily on the use of AAA services in order to maintain the integrity of the directory and its policies as well as to manage the distribution of policies among the policy repositories, PDPs and PEPs. Resource managers and applications will also rely heavily on directories for the storage of policy and security information necessary for the management and allocation of resources.
CIM仕様では、SNMP MIBSやDMTF MIFなどの他の管理モデルに対するメタスキーマ、情報モデル、言語、命名、マッピング手法について説明します。デンは、ネットワークの管理とその要素に対処するモデルの良いスタートを提供します。DENは、個々の要素だけでなく、ネットワーク全体の管理を含めるCIMの拡張です。DENは、ルーターなどの複雑なエンティティを、その複雑なエンティティの個々の側面を管理するために使用できる複数のコンポーネントに抽象化するための要件に対処します。CIMのようなDEN情報モデルには、静的情報と動的情報の両方が組み込まれています。デンは、データのストレージと検索のためにディレクトリにマッピングを提供します。デンはまた、ディレクトリとそのポリシーの完全性を維持し、ポリシーリポジトリ、PDP、およびPEPS間のポリシーの分布を管理するために、AAAサービスの使用に大きく依存します。リソースマネージャーとアプリケーションは、管理とリソースの配分に必要なポリシーおよびセキュリティ情報の保存について、ディレクトリに大きく依存します。
Since much of the information associated with a person, agent or element is stored in a directory, and access to that information will be controlled with appropriate security mechanisms, many voiced the need for a single user/process sign on.
個人、エージェント、または要素に関連付けられた情報の多くはディレクトリに保存され、その情報へのアクセスは適切なセキュリティメカニズムで制御されるため、多くのユーザー/プロセスサインの必要性が多くなりました。
Future advanced applications (e.g., NGI, Internet2, PACI, Grids) may require a variety of PDPs to manage a variety of resource types (i.e., QOS, security, etc.). In this case, a general model would have to be developed that defines the protocols and mechanisms used by cooperating resource managers (i.e., PDPs) of different domains and different genres of resource (i.e., network, security, storage, proxy agents, online facility, etc.). For policies to be implemented in a coherent fashion, it is necessary to have a mechanism that discovers and tracks resources and utilization.
将来の高度なアプリケーション（NGI、Internet2、PACI、グリッドなど）には、さまざまなリソースタイプ（QO、セキュリティなど）を管理するためにさまざまなPDPが必要になる場合があります。この場合、さまざまなドメインとさまざまなジャンルのリソース（すなわち、ネットワーク、セキュリティ、ストレージ、プロキシエージェント、オンライン施設の協力リソースマネージャー（すなわち、PDP）が使用するプロトコルとメカニズムを定義する一般的なモデルを開発する必要があります。、など）。ポリシーを一貫した方法で実装するには、リソースと利用を発見および追跡するメカニズムを持つ必要があります。
There is an architectural issue of central importance, which has most recently surfaced in the directory area. Many applications, and many middleware components, need what is essentially a highly scalable, distributed database service. In other words, people want to take the best of what directories and databases have to offer. This would result in a distributed, replicated database that can use containment to effectively organize and scope its information. It would be able to have exceptional read response time, and also offer transactional and relational integrity. It would support simple and complex queries. Such a service has never been defined as a middleware component; the complexities involved in specifying and implementing such a service are certainly formidable. However, in the absence of such a general service, many middleware components have attempted to use the closest service available, which is deployed - historically first using DNS, and more recently, directory services.
中心的な重要性の建築上の問題があり、最近ではディレクトリエリアで浮上しています。多くのアプリケーション、および多くのミドルウェアコンポーネントには、基本的に非常にスケーラブルな分散データベースサービスが必要です。言い換えれば、人々はディレクトリやデータベースが提供するものを最大限に活用したいと考えています。これにより、封じ込めを使用して情報を効果的に整理して範囲することができる、分散した複製されたデータベースが生じます。例外的な読み取り応答時間を持つことができ、トランザクションおよびリレーショナルの完全性も提供できます。シンプルで複雑なクエリをサポートします。このようなサービスは、ミドルウェアコンポーネントとして定義されていません。このようなサービスの指定と実装に伴う複雑さは、確かに手ごわいです。ただし、このような一般的なサービスがない場合、多くのミドルウェアコンポーネントは、展開されている最も近いサービスを使用しようとしました。これは、歴史的に最初にDNSを使用し、最近ではディレクトリサービスを使用しています。
It will be important to clarify the limitations of the appropriate use of directory services, and to consider whether a more general data storage and retrieval service may be required, or whether directory services can be seamlessly integrated (from the point-of-view of the applications using them) with other forms of storage and retrieval (such as relational databases) in order to provide an integrated directory service with these capabilities.
ディレクトリサービスの適切な使用の制限を明確にし、より一般的なデータストレージと検索サービスが必要かどうか、またはディレクトリサービスをシームレスに統合できるかどうかを検討することが重要です（の視点からディレクトリサービスをシームレスに統合できるかどうかが重要です。これらの機能を備えた統合ディレクトリサービスを提供するために、他の形式のストレージおよび検索（リレーショナルデータベースなど）を使用してそれらを使用するアプリケーション）。
Policy implementation processes need to be linked to Resource Managers in a more sophisticated way than those that currently exist. Such processes must be dynamic, and able to reflect changes in their environment (e.g., adjust the quality of service provided to an application based on environmental changes, such as congestion or new users with higher priorities logging onto the system). We need to determine how different types of resource managers learn about one another and locate each other - as well as deal with associated cross-domain security issues. Another aspect of this problem is developing a resource definition language that can describe the individual elements of the resource being utilized, whether that is a network, processor, agent, memory or storage. This will require developing an appropriate metadata representation and underlying meta schema that can be applied to multiple resource types.
ポリシーの実装プロセスは、現在存在するものよりも洗練された方法でリソースマネージャーにリンクする必要があります。このようなプロセスは動的であり、環境の変化を反映することができなければなりません（たとえば、環境の変化に基づいて提供されるアプリケーションに提供されるサービスの品質を、システムにログインするより高い優先順位を持つ新規ユーザーなど）。さまざまな種類のリソースマネージャーが互いにどのように学習し、お互いを見つけるかを判断し、関連するドメインのセキュリティの問題に対処する必要があります。この問題のもう1つの側面は、それがネットワーク、プロセッサ、エージェント、メモリ、またはストレージであろうと、利用されているリソースの個々の要素を説明できるリソース定義言語を開発することです。これには、複数のリソースタイプに適用できる適切なメタデータ表現と基礎となるメタスキーマを開発する必要があります。
Some models of resource managers are currently being used to provide for the management of distributed computing and Grid environments (e.g., Condor, Globus, and Legion). These resource managers provide languages, clients, and servers to support accessing various types of distributed computing resources (e.g. processors, memory, storage and network access). There is a broad interest in the distributed and parallel computing communities in developing an automated access control architecture, using policies, to support the evolving IETF differentiated services architecture. However, this work has not yet been incorporated into any IETF working group charter. The term "bandwidth broker" has been used to refer to the agents that will implement this functionality through network resource management, policy control, and automated edge device configuration. The IETF Policy Framework working group is currently working on a policy architecture framework, information model, and policy definition language that is targeted initially at policy management within a single domain. However, this work is fundamental in defining inter-domain policy management issues, such as those that are required in implementing a network resource manager / bandwidth broker. Many resource managers being deployed today rely on directory services for storing policy information as well as X.509 for certificate-based authentication and authorization to these resources. Middleware will be required to translate the needs of distributed and parallel computing applications within and across different policy domains. It is crucial that a standard means for representing and using resource management be developed.
現在、リソースマネージャーの一部のモデルは、分散コンピューティングおよびグリッド環境（コンドル、グローブス、レギオンなど）の管理を提供するために使用されています。これらのリソースマネージャーは、言語、クライアント、およびサーバーを提供して、さまざまな種類の分散コンピューティングリソース（プロセッサ、メモリ、ストレージ、ネットワークアクセスなど）へのアクセスをサポートします。進化するIETF差別化されたサービスアーキテクチャをサポートするために、ポリシーを使用して、自動アクセス制御アーキテクチャの開発において、分散型および並列コンピューティングコミュニティに幅広い関心があります。ただし、この作業はまだIETFワーキンググループチャーターに組み込まれていません。「帯域幅ブローカー」という用語は、ネットワークリソース管理、ポリシー制御、および自動エッジデバイス構成を通じてこの機能を実装するエージェントを指すために使用されています。IETFポリシーフレームワークワーキンググループは現在、単一のドメイン内のポリシー管理を最初に対象とするポリシーアーキテクチャフレームワーク、情報モデル、およびポリシー定義言語に取り組んでいます。ただし、この作業は、ネットワークリソースマネージャー /帯域幅ブローカーの実装に必要なものなど、ドメイン間のポリシー管理の問題を定義する上で基本的です。今日展開されている多くのリソースマネージャーは、ポリシー情報を保存するためのディレクトリサービスと、これらのリソースに対する証明書ベースの認証と承認のためにX.509に依存しています。ミドルウェアは、さまざまなポリシードメイン内および並列コンピューティングアプリケーションのニーズを変換するために必要です。リソース管理を表現および使用するための標準手段を開発することが重要です。
Advance reservation of resources, as well as dynamic requests for resources, is a crucial aspect of any resource management system. Advance reservations are more of a policy issue than a provisioning issue; however, the mechanisms for exchanging and propagating such requests between resource managers located within different administrative domains is a currently unsolved problem that needs to be addressed. In addition, it is important to address the issue of possible deadlock and/or the inefficient use of resources (i.e., the time period between a request, or set of requests, being initiated and honored and resources being allocated). There is also a need for rendezvous management in resource allocation services, where an application must gather resource reservations involving multiple sites and services.
リソースの事前予約と、リソースの動的な要求は、あらゆるリソース管理システムの重要な側面です。事前予約は、プロビジョニングの問題というよりもポリシーの問題です。ただし、異なる管理ドメイン内にあるリソースマネージャー間のそのような要求を交換して伝播するメカニズムは、現在対処する必要がある現在の未解決の問題です。さらに、デッドロックの可能性のある問題および/またはリソースの非効率的な使用の問題（つまり、リクエストまたはリクエストのセット間の期間、開始および尊重され、リソースが割り当てられる）に対処することが重要です。また、複数のサイトとサービスを含むリソース予約を収集する必要があるリソース割り当てサービスには、Rendezvous管理が必要です。
A mesh of cooperating resource managers, which interact with each other using standards based protocols (e.g. COPS), could be the model for a resource management infrastructure. Each of these may manage different sets of resources. For example, one may be a bandwidth broker that only manages network bandwidth, while another may be a general-purpose resource manager that manages security, IP address allocation, storage, processors, agents, and other network resources. There are already plans for middleware resource managers that not only allocate the resources but also manage the composition of a group of services that may include security services, billing services, shaping of multimedia composite images, etc.). Another form of resource manager may provide mapping between a set of related services (i.e., mapping an IP based RSVP request to an ATM SVC, as was demonstrated in a pilot project on the vBNS).
標準ベースのプロトコル（COPなど）を使用して相互に対話する協力リソースマネージャーのメッシュは、リソース管理インフラストラクチャのモデルになる可能性があります。これらのそれぞれは、異なるリソースセットを管理する場合があります。たとえば、1つはネットワーク帯域幅のみを管理する帯域幅のブローカーである可能性がありますが、もう1つはセキュリティ、IPアドレス割り当て、ストレージ、プロセッサ、エージェント、その他のネットワークリソースを管理する汎用リソースマネージャーです。リソースを割り当てるだけでなく、セキュリティサービス、請求サービス、マルチメディアコンポジット画像の形成などを含むサービスグループの構成を管理するミドルウェアリソースマネージャーの計画がすでにあります。別の形式のリソースマネージャーは、関連サービスのセット間のマッピングを提供する場合があります（つまり、VBNSのパイロットプロジェクトで実証されたように、IPベースのRSVP要求をATM SVCにマッピングします）。
Resource managers depend on the use of locator services to find other resource managers as well as to locate the AAA server(s) for the requestor and the associated directories containing applicable policy information. They may also need to query the network to determine if a policy request for bandwidth can be satisfied. It is essential that these (and other) different uses of resource management be integrated to provide an end-to-end service for applications and users alike.
リソースマネージャーは、ロケーターサービスの使用に依存して、他のリソースマネージャーを見つけるだけでなく、リクエスターのAAAサーバーと適用されるポリシー情報を含む関連ディレクトリを見つけます。また、帯域幅のポリシー要求が満たされるかどうかを判断するために、ネットワークを照会する必要がある場合があります。これらの（および他の）リソース管理の異なる使用を統合して、アプリケーションとユーザーに同様にエンドツーエンドサービスを提供することが不可欠です。
There are a wide range of middleware services broadly related to the discovery and retrieval of networked information. Because such a broad range of applications (and not just high-performance, distributed, or parallel applications) requires these services, this area is under very active development and new requirements are constantly emerging.
ネットワーク化された情報の発見と検索に広く関連する幅広いミドルウェアサービスがあります。このような幅広いアプリケーション（高性能、分散、または並列アプリケーションだけでなく）がこれらのサービスを必要とするため、この領域は非常に積極的な開発の下にあり、新しい要件は絶えず出現しています。
Perhaps the most basic service in this area is persistent naming and location services (and infrastructure) that can resolve names to locations (i.e., URLs). The IETF has done considerable work in defining a syntax for Uniform Resource Identifiers (URIs), which are intended to be persistent name spaces administered by a wide range of agencies. URIs are resolved to URLs using resolver services; there are a number of different proposals for such resolver services, and some implementations exist such as the CNRI Handler Service. Many organizations are beginning to establish and manage URI namespaces, notably the publishing community with their Digital Object Identifier (DOI). however, there are many unresolved questions, such as how to most effectively deal with the situation where the resource named by a URI exists in multiple places on the network (e.g., find the "closest" mirror in terms of network connectivity and resource availability). There is a need for an extensive set of infrastructure around resolvers, including how resources are registered and identifiers are assigned, the ongoing management of data about the current location of resources that are identified by a specific URI, and the operation of sets of resolvers for various name spaces. Finally, given a URI, one needs to locate the resolver services that are connected with that namespace; the IETF has done initial work on resolution service location for URI namespaces.
おそらく、この分野で最も基本的なサービスは、名前を場所（つまりURL）に解決できる永続的な命名とロケーションサービス（およびインフラストラクチャ）です。IETFは、幅広い機関が管理する永続的な名前スペースであることを目的とした、均一なリソース識別子（URI）の構文を定義する上でかなりの作業を行ってきました。URISは、Resolver Servicesを使用してURLに解決されます。このようなリゾルバーサービスにはさまざまな提案があり、CNRIハンドラーサービスなど、いくつかの実装が存在します。多くの組織がURIの名前空間を確立および管理し始めています。特に、デジタルオブジェクト識別子（DOI）を備えた出版コミュニティがあります。ただし、URIによって指定されたリソースがネットワーク上の複数の場所に存在する状況を最も効果的に扱う方法など、多くの未解決の質問があります（たとえば、ネットワークの接続とリソースの可用性の観点から「最も近い」ミラーを見つけます）。リソースの登録方法と識別子の割り当て方法、特定のURIによって識別されるリソースの現在の場所に関するデータの継続的な管理、リソースバーのセットの操作など、リソースの周りに広範なインフラストラクチャセットが必要です。さまざまな名前スペース。最後に、URIを考えると、その名前空間に接続されているリゾルバーサービスを見つける必要があります。IETFは、URI名の解像度サービスの場所に関する最初の作業を行っています。
URIs are intended to be processed primarily by machines; they are not intended to necessarily be easy to remember, though they are intended to be robust under transcription (not sensitive to whitespace, for example). More recently, the IETF has begun work on defining requirements for human friendly identifier systems that might be used to register and resolve mnemonic names.
URIは、主に機械で処理されることを目的としています。それらは必ずしも覚えやすいことを意図していませんが、転写下で堅牢であることを目的としています（たとえば、空白に敏感ではありません）。最近では、IETFは、ニーモニック名の登録と解決に使用される可能性のある人間に優しい識別子システムの要件の定義に関する作業を開始しました。
Another set of issues revolves around various types of metadata - descriptive, ratings, provenance, rights management, and the like, that may be associated with objects on the network. The Resource Description Framework (RDF) from the Worldwide Web Consortium (W3C) provides a syntax for attaching such descriptions to network objects and for encoding the descriptions; additional middleware work is needed to locate metadata associated with objects that may be stored in repositories, and to retrieve such metadata. Validation of metadata is a key issue, and both IETF and W3C are working on XML canonicalization algorithms that can be used in conjunction with public key infrastructure to sign metadata assertions. However, such an approach implies a complex set of trust relationships and hierarchies that will need to be managed, and policies that will need to be specified for the use of these trust relationships in retrieval.
別の一連の問題は、ネットワーク上のオブジェクトに関連付けられる可能性のある、説明、評価、出所、権利管理など、さまざまな種類のメタデータを中心に展開します。Worldwide Webコンソーシアム（W3C）のリソース説明フレームワーク（RDF）は、そのような説明をネットワークオブジェクトに添付し、説明をエンコードする構文を提供します。リポジトリに保存される可能性のあるオブジェクトに関連付けられたメタデータを特定し、そのようなメタデータを取得するには、追加のミドルウェア作業が必要です。メタデータの検証は重要な問題であり、IETFとW3Cの両方が、メタデータアサーションに署名するために公開キーインフラストラクチャと組み合わせて使用できるXML Canonicalization Algorithmsで作業しています。ただし、このようなアプローチは、管理する必要がある複雑な信頼関係と階層のセットと、検索でこれらの信頼関係を使用するために指定する必要があるポリシーを意味します。
There is specific work going on in defining various types of metadata for applications such as rights management; ultimately this will imply the development of middleware services. It will also impact the use of directory, database, and similar services in the storage, access, and retrieval of this information. Similarly, there will be a need for services to connect descriptive metadata and identifiers (URNs).
権利管理などのアプリケーション用のさまざまな種類のメタデータを定義する際には、特定の作業が行われています。最終的に、これはミドルウェアサービスの開発を意味します。また、この情報のストレージ、アクセス、および取得におけるディレクトリ、データベース、および同様のサービスの使用にも影響します。同様に、記述メタデータと識別子（URN）を接続するサービスが必要になります。
(See also the NSF/ERCIM report on metadata research issues at http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.html http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.ps http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.pdf
（http://www.ercim.org/publication/ws-proceedings/eu-nsf/metadata.html http://www.ercim.org/publication/ws-のメタデータ研究問題に関するNSF/ERCIMレポートも参照してください。Proceedings/eu-nsf/metadata.ps http://www.ercim.org/publication/ws-proceedings/eu-nsf/metadata.pdf
Finally, there is a need for a set of middleware services which build upon the research work already integrated into services such as Archie and Harvest. These services permit the efficient extraction of metadata about the contents of network information objects and services without necessarily retrieving and inspecting those services. This includes the ability to dispatch "indexing agents" or "knowbots" that can run at a site to compute such indexing, under appropriate security and authentication constraints. In addition, a set of "push-based" broker services which aggregate, filter and collect metadata from multiple sites and provide them to interested applications are also required. Such services can provide a massive performance, quality, comprehensiveness and timeliness improvement for today's webcrawler-based indexing services.
最後に、ArchieやHarvestなどのサービスに既に統合された研究作業に基づいたミドルウェアサービスのセットが必要です。これらのサービスにより、必ずしもそれらのサービスを取得および検査することなく、ネットワーク情報オブジェクトとサービスの内容に関するメタデータを効率的に抽出することができます。これには、適切なセキュリティと認証の制約の下で、このようなインデックス作成を計算するためにサイトで実行できる「インデックスイングント」または「知識ボット」を派遣する機能が含まれます。さらに、複数のサイトからメタデータを集約、フィルタリング、収集し、興味のあるアプリケーションに提供する「プッシュベースの」ブローカーサービスのセットも必要です。このようなサービスは、今日のWebCrawlerベースのインデックスサービスに、大規模なパフォーマンス、品質、包括性、適時性の改善を提供できます。
As noted earlier, applications may need to explicitly request resources available in the network to meet their requirements for certain types of communication, or in order to provide service with an appropriate guarantee of one or metrics, such as bandwidth, jitter, latency, and loss. One type of request that has been the focus of much effort recently is for services beyond best effort, particularly with respect to services running over IP. This is particularly important for the advanced applications noted previously (e.g., visualization and teleimmersion) as well as the emerging importance of voice and video, especially voice and video operating with lower bandwidth or voice and video co-mingled with data. One perspective on this issue is to consider the effect of multiple drops in a single RTT, which is catastrophic for TCP applications but may be of no special significance for real-time traffic. Providing for improved services can be accomplished through a variety of quality of service (QoS) and class of service (CoS) mechanisms. The first IETF model was the Integrated Services (IntServ) model, which used RSVP as the signaling mechanism. Since this model requires state in every router for every session and to manage the traffic flows, it is generally recognized to have scaling limits. However, it is very appropriate for certain situations.
前述のように、アプリケーションは、特定の種類の通信の要件を満たすために、または帯域幅、ジッター、待ち時間、損失などの1つまたはメトリックの適切な保証をサービスに提供するために、ネットワークで利用可能なリソースを明示的に要求する必要がある場合があります。。最近の努力の焦点であったリクエストの1つのタイプは、特にIPを介して実行されるサービスに関して、最善の努力を超えたサービスのためです。これは、以前に記載されている高度なアプリケーション（視覚化やテレイマーションなど）や、音声とビデオの新たな重要性、特に帯域幅や音声とビデオとデータと共同混合されて動作する音声とビデオの新たな重要性にとって特に重要です。この問題に関する1つの見方は、単一のRTTでの複数のドロップの影響を考慮することです。これは、TCPアプリケーションでは壊滅的ですが、リアルタイムトラフィックにとって特別な意味がない場合があります。改善されたサービスを提供することは、さまざまな品質のサービス（QoS）およびサービスのクラス（COS）メカニズムを通じて達成できます。最初のIETFモデルは、RSVPをシグナル伝達メカニズムとして使用した統合サービス（INTSERV）モデルでした。このモデルは、すべてのセッションのすべてのルーターの状態を必要とし、トラフィックフローを管理するために、通常、スケーリング制限があることが認識されています。ただし、特定の状況には非常に適しています。
Differentiated Services, or DiffServ, grew out of a reaction against the perceived scalability problems with the IETF IntServ model. DiffServ is an architecture for implementing scalable service differentiation in the Internet. Scalability is achieved by aggregating traffic through the use of IP-layer packet marking. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. These simple PHBs are combined with a much larger number of policing policies enforced at the network edge to provide a broad and flexible range of services, without requiring state or complex forwarding decisions to be performed in the core and distribution layers.
差別化されたサービス、またはdiffservは、IETF IntServモデルの知覚されたスケーラビリティの問題に対する反応から生じました。DiffServは、インターネットにスケーラブルなサービス差別化を実装するためのアーキテクチャです。スケーラビリティは、IPレイヤーパケットマーキングを使用してトラフィックを集約することにより達成されます。パケットは、パスに沿ってノードで特定のホップ前転送動作を受信するように分類され、マークされています。洗練された分類、マーキング、ポリシング、および形成操作は、ネットワーク境界またはホストでのみ実装する必要があります。ネットワークリソースは、差別化されたサービス対応ネットワークへのエントリ時にトラフィックがマークされ、条件付けられている方法と、そのネットワーク内にそのトラフィックがどのように転送されるかを支配するサービスプロビジョニングポリシーによってトラフィックストリームに割り当てられます。これらの単純なPHBは、ネットワークエッジで強制されたはるかに多くのポリシングポリシーと組み合わされて、コアおよび配布層で実行される状態または複雑な転送決定を必要とせずに、広範かつ柔軟なサービスを提供します。
Recently, the idea of "tunneling" RSVP over a DiffServ-capable network has generated significant interest. This attempts to combine the best features of both IntServ and DiffServ while mitigating the disadvantages of each. This in turn has led the IETF to study ways to ensure that Differv and Inteserv can not only coexist, but are also interoperable.
最近、DiffServ対応ネットワークを介した「トンネリング」RSVPのアイデアは、大きな関心を生み出しました。これは、それぞれの欠点を軽減しながら、IntServとDiffservの両方の最良の機能を組み合わせようとします。これにより、IETFは、differvとinteservが共存するだけでなく、相互運用可能であることを確認する方法を研究するようになりました。
The practical realization of either or both architectures depends on many middleware components, some of which are described in this document. The workshop discussion mainly focused on DiffServ mechanisms and on what effect such mechanisms would have on middleware and its ability to monitor and manage the network infrastructure for the benefit of the applications. Both IntServ and DiffServ only fully make sense if linked to a policy mechanism. This mechanism must be able to make policy decisions, detect and resolve conflicts in policies, and enforce and monitor policies.
いずれかまたは両方のアーキテクチャの実際の実現は、多くのミドルウェアコンポーネントに依存します。その一部は、このドキュメントで説明されています。ワークショップの議論は、主にDiffServメカニズムと、そのようなメカニズムがミドルウェアに与える影響と、アプリケーションの利益のためにネットワークインフラストラクチャを監視および管理する能力に焦点を当てていました。IntServとDiffservの両方が、ポリシーメカニズムにリンクされている場合にのみ完全に意味があります。このメカニズムは、ポリシーの決定を下し、ポリシーの競合を検出および解決し、ポリシーを実施および監視できる必要があります。
Workshop participants almost unanimously agreed that they also required a scalable inter-domain resource manager (e.g., a bandwidth broker). Currently, if an RSVP session is run, each router along a path becomes involved, with flow policing at each hop. Bandwidth Broker models include the bandwidth broker, a policy decision point (which makes admission control and policy decisions) and the policy enforcement points (i.e., edge routers) which provide for policing at the first hop and for remarking aggregate flows so that subsequent routers need only deal with the aggregate flows.
ワークショップの参加者は、スケーラブルなドメイン間リソースマネージャー（帯域幅のブローカーなど）も必要とすることにほぼ全会一致で同意しました。現在、RSVPセッションが実行されている場合、パスに沿った各ルーターが関与し、各ホップでフローポリシングが行われます。帯域幅のブローカーモデルには、帯域幅のブローカー、ポリシー決定ポイント（入場管理とポリシーの決定を下す）、およびポリシー執行ポイント（すなわち、エッジルーター）が含まれます。骨材の流れのみを扱います。
IETF protocols that could be used to implement a Bandwidth Broker model (e.g., COPS, Diameter, and others) were also discussed. The Diameter protocol is interesting in this context, because it provides set up mechanisms for basic network resource allocations and reallocations, as well as optional allocations.- All of these can be used for various types of bandwidth broker implementations, including those directed at QoS, using RSVP type information. Diameter currently does not provide path information, but instead relies on network pathway information established at ingress and egress nodes. However, the status of Diameter is still open in the IETF.
帯域幅ブローカーモデル（COP、直径など）の実装に使用できるIETFプロトコルについても説明しました。このコンテキストでは、直径のプロトコルは興味深いです。これは、基本的なネットワークリソースの割り当てとリアルコンテストのセットアップメカニズム、およびオプションの割り当てを提供するためです。これらはすべて、QoSに向けられたものを含むさまざまな種類の帯域幅ブローカーの実装に使用できます。RSVPタイプ情報の使用。直径は現在、パス情報を提供していませんが、IngressおよびEgressノードで確立されたネットワーク経路情報に依存しています。ただし、IETFでは直径のステータスがまだ開いています。
COPS was initially developed as a mechanism for establishing RSVP policy within a domain and remains intra-domain centric. It is a useful intra-domain mechanism for allocating bandwidth resources within a policy context. Work is now being conducted to use COPS for establishing policy associated with a DiffServ-capable network. COPS is designed to facilitate communication between the PDP and the PEP, carrying policy decisions and other information.
COPSは当初、ドメイン内でRSVPポリシーを確立するメカニズムとして開発され、ドメイン内の中心のままでした。これは、ポリシーコンテキスト内で帯域幅リソースを割り当てるための有用なドメイン内メカニズムです。現在、diffserv対応ネットワークに関連するポリシーを確立するためにCOPを使用するための作業が行われています。COPSは、PDPとPEPの間のコミュニケーションを促進し、政策決定やその他の情報を運ぶように設計されています。
To implement any type of Bandwidth Broker model, it is necessary to establish a mechanism for policy exchanges. The Internet2's Qbone working group is currently working to define a prototype inter-domain bandwidth broker signaling protocol. This work is being coordinated with IETF efforts.
あらゆるタイプの帯域幅ブローカーモデルを実装するには、ポリシー交換のメカニズムを確立する必要があります。Internet2のQboneワーキンググループは現在、プロトタイプ間帯域幅ブローカーシグナリングプロトコルの定義に取り組んでいます。この作業は、IETFの取り組みと調整されています。
Another mechanism is required for traffic shaping and SLA policing and enforcement. One mechanism is fair queuing in its various forms, which has been described as TDM emulation without the time and space components. Techniques have been used for several years for fair queuing for low speed lines. For DS-3 with 40 byte packets and OC-3c speeds with 200-byte packets, weighted fair queuing uses a deficit round-robin algorithm that allows it to scale. It is capable of flow discrimination based on stochastically hashing the flows. An additional expansion of this technique is to preface this technique with class indicators. Currently, classification techniques are based on IP precedence. However, classification will soon be achieved in many routers using Diffserv code points (DSCPs) to specify the type of conditioning to be applied. The complete requirements of policing for DiffServ implementations, e.g., via bandwidth brokers, have not yet been fully explored or defined.
トラフィックの形成とSLAポリシングと施行には、別のメカニズムが必要です。1つのメカニズムは、時間とスペースのコンポーネントなしでTDMエミュレーションとして説明されているさまざまな形式での公正なキューイングです。テクニックは、低速線の公正なキューイングに数年間使用されてきました。40バイトパケットと200バイトのパケットを備えたOC-3C速度を備えたDS-3の場合、重み付けされた公正キューイングは、スケーリングできる赤字ラウンドロビンアルゴリズムを使用します。流れを確率的にハッシュすることに基づいて、流れの識別が可能です。この手法の追加の拡張は、この手法をクラスインジケーターで序文に序文で描写することです。現在、分類手法はIPの優先順位に基づいています。ただし、DiffServコードポイント（DSCPS）を使用して多くのルーターで分類が達成され、適用される条件付けの種類を指定します。Diffservの実装のためのポリシングの完全な要件、たとえば、帯域幅ブローカーを介したものは、まだ完全に調査または定義されていません。
Network monitoring capabilities (i.e., querying the network for state information on a micro and macro level) that support middleware and application services were identified as a core requirement. In fact, a network instrumentation and measurement infrastructure, upon which a set of intelligent network management middleware services can be built, is absolutely critical.
ミドルウェアおよびアプリケーションサービスをサポートするネットワーク監視機能（つまり、マイクロレベルとマクロレベルに関する状態情報のネットワークをクエリする）がコア要件として識別されました。実際、一連のインテリジェントなネットワーク管理ミドルウェアサービスを構築できるネットワーク計装および測定インフラストラクチャが絶対に重要です。
Current mechanisms (e.g. ICMP, SNMP) were not deemed robust enough for middleware and applications developers to determine the state of the network, or to verify that they were receiving the specific type of treatment they had requested. This was judged especially true of a network providing QoS or CoS. Indeed, it is not at all clear that SNMP, for example, is even the right architectural model for middleware to use to enable applications to determine the state of the network. Other capabilities, such as OcxMon, RTFM, new MIBs, and active measurement techniques (e.g., IPPM one-way delay metrics) need to be made available to middleware services and applications.
現在のメカニズム（ICMP、SNMPなど）は、ミドルウェアやアプリケーションの開発者がネットワークの状態を決定したり、要求した特定のタイプの治療を受けていることを確認するのに十分な堅牢性とは見なされませんでした。これは、Qosまたはcosを提供するネットワークについて特に真実であると判断されました。実際、たとえば、SNMPが、アプリケーションがネットワークの状態を決定できるように使用できるミドルウェアにとって適切なアーキテクチャモデルでさえあることはまったく明確ではありません。OCXMON、RTFM、新しいMIBS、アクティブ測定技術（IPPM一元配置遅延メトリックなど）などのその他の機能を、ミドルウェアサービスやアプリケーションで利用できるようにする必要があります。
The provisioning of differentiated services takes the Internet one step away from its "dumb" best effort status. As the complexity of the network increases (e.g. VPNs, QoS, CoS, VoIP, etc.), more attention must be paid to providing the end-user/customer or network administrator with the tools they require to securely and dynamically manage an adaptable network infrastructure. Differentiated services means that theoretically some traffic gets better service than other traffic; subsequently, one can expect to pay for better service, which means that accounting and billing services will be one of the important middleware core components that others will rely upon. The model and protocols necessary to accomplish this are not developed yet.
差別化されたサービスのプロビジョニングは、インターネットを「愚かな」最高の努力ステータスから一歩離れています。ネットワークの複雑さが増加するにつれて（VPN、QOS、COS、VoIPなど）、適応性のあるネットワークを安全かつ動的に管理するために必要なツールをエンドユーザー/顧客またはネットワーク管理者に提供することにより、さらに注意を払う必要があります。インフラストラクチャー。差別化されたサービスとは、理論的には一部のトラフィックが他のトラフィックよりも優れたサービスを得ることを意味します。その後、より良いサービスを支払うことを期待できます。つまり、会計および請求サービスは、他の人が依存する重要なミドルウェアコアコンポーネントの1つになることを意味します。これを達成するために必要なモデルとプロトコルはまだ開発されていません。
The IETF's AAA working group is focusing on the requirements for supporting authentication, authorization, accounting, and auditing of access to and services provided by network resource managers (e.g., bandwidth brokers). These processes constitute an important security infrastructure that will be relied upon by middleware and applications. However, these components are only basic security components. A public key infrastructure (PKI) was identified as a crucial security service infrastructure component. For example, the PKI will be required to support the transitivity of authentication, authorization, and access control and, where appropriate, accounting and billing. It was noted that, except for issues dealing with group security and possibly more efficient and simple management, there are no real technical challenges preventing the wide scale deployment of a PKI support structure at this time. Instead, the main obstacles to overcome are mostly political and economic in nature. However, additional middleware may be required to better facilitate a PKI. That being said, some people believe that we do have some large technical security challenges, revocation lists and security with respect to changing group memberships being two examples.
IETFのAAAワーキンググループは、ネットワークリソースマネージャー（帯域幅ブローカーなど）が提供する認証、承認、会計、およびサービスの監査と監査をサポートするための要件に焦点を当てています。これらのプロセスは、ミドルウェアやアプリケーションに依存する重要なセキュリティインフラストラクチャを構成します。ただし、これらのコンポーネントは基本的なセキュリティコンポーネントのみです。公開キーインフラストラクチャ（PKI）は、重要なセキュリティサービスインフラストラクチャコンポーネントとして特定されました。たとえば、PKIは、認証、承認、アクセス制御の推移性、および必要に応じて会計と請求をサポートする必要があります。グループのセキュリティを扱う問題と、より効率的で簡単な管理を扱う問題を除き、現時点でPKIサポート構造の大規模な展開を妨げる実際の技術的課題はないことに注意しました。代わりに、克服すべき主な障害は、ほとんどが政治的および経済的であることです。ただし、PKIをより促進するには、追加のミドルウェアが必要になる場合があります。そうは言っても、一部の人々は、グループメンバーシップの変化に関して、いくつかの大きな技術的セキュリティの課題、取り消しリスト、セキュリティが2つの例であると考えています。
Middleware and security support is also required for newer applications (e.g., proxy agents that would act on a process or application's behalf and gather the necessary certificates for access and using resources). A particularly difficult example is remote collaboration. Accessing a particular resource may require a user and/or application to gather certificates from more than one policy-controlling agent. It is also true that an entity may have various identities that are dependent on the task they are performing (usage or role based) or the context of the application. In order for the PKI to become truly functional on a ubiquitous level, there needs to exist a set of independent signing authorities that can vouch for the top-level certificate authorities.
新しいアプリケーションには、ミドルウェアとセキュリティサポートも必要です（たとえば、プロセスまたはアプリケーションに代わって行動し、リソースにアクセスして使用するために必要な証明書を収集するプロキシエージェント）。特に難しい例は、リモートコラボレーションです。特定のリソースにアクセスするには、複数のポリシー制御エージェントから証明書を収集するには、ユーザーおよび/またはアプリケーションが必要になる場合があります。また、エンティティが実行しているタスク（使用またはロールベース）またはアプリケーションのコンテキストに依存するさまざまなアイデンティティを持つこともあります。PKIがユビキタスレベルで真に機能するためには、トップレベルの証明書当局を保証できる独立した署名当局のセットが存在する必要があります。
There are also higher-level middleware services which will build on public key infrastructure, notary services and provenance verification. As we move from a relatively dumb network (e.g. best effort IP) to an Internet with embedded intelligence (e.g., DiffServ, IntServ, bandwidth brokers, directory-enabled networks, etc.), the secure exchange of information will become even more important. In addition, as we start to provide differentiated services, accounting and statistics gathering will become much more important. We also need to provide for the integrity and security of collecting, analyzing, and transporting network management and monitoring information. And the issues of data privacy and integrity, along with addressing denial of service and non-repudiation, cannot be ignored.
また、公開キーインフラストラクチャ、公証サービス、および起源の検証に基づいて構築される高レベルのミドルウェアサービスもあります。比較的馬鹿げたネットワーク（ベストエフェクションIPなど）から、インテリジェンスが組み込まれたインターネット（Diffserv、intserv、帯域幅のブローカー、ディレクトリ対応ネットワークなど）に移行すると、安全な情報交換がさらに重要になります。さらに、差別化されたサービスの提供を開始すると、会計と統計の収集がより重要になります。また、ネットワーク管理と監視情報の収集、分析、輸送の整合性とセキュリティを提供する必要があります。また、データのプライバシーと誠実さの問題は、サービスの拒否と非控除に対処することとともに、無視することはできません。
Network management capabilities were identified as being paramount to the success of middleware deployment, and subsequently to the success of the application. Many of the issues addressed here are not part of standard NOC operations. In a more complex world of QoS, CoS, and micro prioritization, reactions to network failures must be handled differently than current procedures. Allocations are more dynamic, especially additions, deletions, and changes with additional sets of requirements, such as priorities and new types of inter-domain interactions. These will inevitably increase the complexity of network management.
ネットワーク管理機能は、ミドルウェアの展開の成功に最重要であると特定され、その後アプリケーションの成功に至りました。ここで取り上げられている問題の多くは、標準的なNOC操作の一部ではありません。QoS、COS、およびミクロの優先順位付けのより複雑な世界では、ネットワーク障害に対する反応は、現在の手順とは異なる方法で処理する必要があります。割り当ては、より動的であり、特に追加、削除、および優先順位や新しいタイプのドメイン間相互作用などの追加の要件セットを備えた変更が行われます。これらは必然的にネットワーク管理の複雑さを高めます。
There are many microscopic and macroscopic network management projects focusing on making both active and passive network statistics and information available to end-users. Current visual debugging and analysis capabilities (e.g., those developed by NLANR/CAIDA) are crucial tools for network administrators and designers for understanding their networks. In addition, current network management techniques and mechanisms, which were designed for network designers and managers, need to be adapted to provide a dynamic and relevant set of information to the middleware or application service software. This will allow the programs to dynamically adapt to the changing state of the network infrastructure while ensuring the integrity and security of the network and other resources.
エンドユーザーが利用できるアクティブおよびパッシブネットワークの両方の統計と情報の両方を作成することに焦点を当てた、多くの顕微鏡および巨視的なネットワーク管理プロジェクトがあります。現在の視覚的なデバッグおよび分析機能（たとえば、NLANR/CAIDAによって開発された機能）は、ネットワークを理解するためのネットワーク管理者と設計者にとって重要なツールです。さらに、ネットワーク設計者とマネージャー向けに設計された現在のネットワーク管理手法とメカニズムは、ミドルウェアまたはアプリケーションサービスソフトウェアに動的で関連する情報セットを提供するために適応する必要があります。これにより、プログラムはネットワークインフラストラクチャの変化する状態に動的に適応しながら、ネットワークおよびその他のリソースの整合性とセキュリティを確保できます。
Another aspect of network management that has not received the necessary attention, is the need for modeling and analysis tools for network and middleware designers. CIM and DEN show great promise in providing a common framework for modeling the management of network elements and services as well as users, applications, and other resources of the network. Undoubtedly, middleware designers will place new requirements on CIM and DEN that will cause these approaches to evolve.
必要な注意を受けていないネットワーク管理のもう1つの側面は、ネットワークおよびミドルウェアデザイナーのモデリングおよび分析ツールの必要性です。CIMとデンは、ネットワーク要素とサービスの管理をモデル化するための共通のフレームワーク、およびユーザー、アプリケーション、およびネットワークのその他のリソースを提供するための共通のフレームワークを提供することに大きな期待を示しています。間違いなく、ミドルウェアの設計者は、これらのアプローチを進化させるCIMとDENに新しい要件を掲載します。
IP multicast - that is, the routing and forwarding of mutlicast packets in an IP-based network, is in the view of the workshop part of the basic network infrastructure. The Internet Group Multicast Protocol, which manages the joining and leaving of multicast groups, could also be considered a basic network service. However, there is a tremendous need for middleware services to make multicast useable for various applications, much like TCP played a key role in making IP applications useable. Specifically, one might reasonably want middleware services to provide authenticated control of multicast services. Examples of these services include the creation and joining of multicast groups, multicast address management, multicast channel directories (there has already been considerable work in this area), various forms of reliable multicast services (this has been an IRTF research area), and to secure multicast groups through various cryptographic strategies. In addition, because of the large impact that multicast can have on a network, multicast management middleware services, particularly in conjunction with QoS, will be needed, as will services to link together multicasting within various networks that do not directly interchange multicast routing information. It should be noted, however, that several security issues with multicast, especially groups with dynamic membership policies, still need to be resolved.
IPマルチキャスト - つまり、IPベースのネットワークでのMutlicastパケットのルーティングと転送は、基本的なネットワークインフラストラクチャのワークショップ部分を見ることです。マルチキャストグループの参加と退去を管理するインターネットグループマルチキャストプロトコルも、基本的なネットワークサービスと見なすことができます。ただし、TCPがIPアプリケーションを使用可能にする上で重要な役割を果たしたように、さまざまなアプリケーションでマルチキャストを使用できるようにするためのミドルウェアサービスには非常に必要です。具体的には、ミドルウェアサービスがマルチキャストサービスの認証された制御を提供することを合理的に望むかもしれません。これらのサービスの例には、マルチキャストグループの作成と参加、マルチキャストアドレス管理、マルチキャストチャンネルディレクトリ（この分野ではすでにかなりの作業があります）、さまざまな形式の信頼できるマルチキャストサービス（これはIRTF研究分野です）、およびさまざまな暗号化戦略を通じてマルチキャストグループを保護します。さらに、マルチキャストがネットワークに与える大きな影響のため、特にQoSと連携してマルチキャスト管理ミドルウェアサービスが必要になります。これは、マルチキャストルーティング情報を直接交換しないさまざまなネットワーク内のマルチリキャストをリンクするサービスと同様に、必要になります。ただし、マルチキャストに関するいくつかのセキュリティ問題、特に動的なメンバーシップポリシーを持つグループは、まだ解決する必要があることに注意してください。
Java was chosen as an example of a heterogeneous runtime support system for the sake of discussion as to whether it could be qualified as a development language particularly suitable for the development of middleware. The consensus was that the Java language and compilers are important in the current distributed model of the Internet and for the support of middleware (i.e., middleware written using Java). Also, a virtual Java machine located on a system can be considered middleware as much as any operating system or network operating systems would be considered middleware. Jini middleware technology not only defines a set of protocols for discovery, join, and lookup, but also a leasing and transaction mechanism to provide resilience in a dynamic networked environment. Java and Jini will be dependent on a functioning PKI, especially for signed applets. That being said, there are security concerns with both Java and Jini that need to be addressed, such as allowing the downloading of applets and servlets.
Javaは、ミドルウェアの開発に特に適した開発言語として資格があるかどうかについて、議論のために、不均一なランタイムサポートシステムの例として選ばれました。コンセンサスは、Java言語とコンパイラがインターネットの現在の分散モデルで、およびミドルウェア（つまり、Javaを使用して書かれたミドルウェア）のサポートに重要であるということでした。また、システムにある仮想Javaマシンは、オペレーティングシステムやネットワークオペレーティングシステムがミドルウェアと見なされるのと同じくらいミドルウェアと見なすことができます。Jini Middlewareテクノロジーは、発見、参加、および検索のための一連のプロトコルを定義するだけでなく、動的なネットワーク環境で回復力を提供するリースおよびトランザクションメカニズムも定義します。JavaとJiniは、特に署名されたアプレットの機能PKIに依存します。そうは言っても、アプレットやサーブレットのダウンロードを許可するなど、対処する必要があるJavaとJiniの両方にセキュリティ上の懸念があります。
This document is a report of a workshop in which security was a common theme, as can be seen by the references to security through out the document; but the workshop did not reach any specific recommendations for new security-related terminology.
このドキュメントは、セキュリティが共通のテーマであるワークショップのレポートです。しかし、ワークショップは、新しいセキュリティ関連の用語に関する具体的な推奨事項には達しませんでした。
Middleware may have components and services that only exist in the persistent infrastructure, but it will also have components that enable and support end-to-end (i.e. application to application or host to host) interaction across multiple autonomous administrative domains. A set of core persistent middleware services is required to support the development of a richer set of middleware services which can be aggregated or upon which applications will be based (e.g., an onion or layered model). This set of core middleware services will help applications leverage the services and capabilities of the underlying network infrastructure, along with enabling applications to adjust in changes to the network. The particular set of such services utilized by an application or process will be a function of the requirements of the application field or affinity group (e.g., network management or high energy physics applications) wishing to utilize the network or distributed data/computation infrastructure. This document discusses some of the basic and core middleware services, which include, but are not limited to: directories, name/address resolution services, security services (i.e., authentication, authorization, accounting, and access control), network management, network monitoring, time servers, and accounting. Network level capabilities, such as multicast and DiffServ, are not classified as middleware; rather, they are enabling infrastructure services upon which middleware will be built or which middleware may use and manage. A second level of important middleware services, which builds upon these core set of services, may include accounting/billing, resource managers, single sign-on services, globally unique names, metadata servers, and locators.
ミドルウェアには、永続的なインフラストラクチャにのみ存在するコンポーネントとサービスがありますが、複数の自律管理ドメインにわたってエンドツーエンド（つまり、アプリケーションまたはホストへのアプリケーションまたはホストへのアプリケーションまたはホストへのアプリケーションまたはホストへのアプリケーション）相互作用を可能にしてサポートするコンポーネントがあります。一連のコア永続的なミドルウェアサービスは、集約できる、またはどのアプリケーションのベースになるか（たとえば、オニオンや層状モデル）の豊富なミドルウェアサービスの開発をサポートするために必要です。この一連のコアミドルウェアサービスは、アプリケーションが基礎となるネットワークインフラストラクチャのサービスと機能を活用し、アプリケーションがネットワークの変更を調整できるようにするのに役立ちます。アプリケーションまたはプロセスで利用されるこのようなサービスの特定のセットは、ネットワークまたは分散データ/計算インフラストラクチャの利用を希望するアプリケーションフィールドまたはアフィニティグループ（ネットワーク管理または高エネルギー物理学アプリケーションなど）の要件の関数となります。このドキュメントでは、ディレクトリ、名前/アドレス解決サービス、セキュリティサービス（つまり、認証、承認、会計、アクセス制御）、ネットワーク管理、ネットワーク監視を含むがこれらに限定されない基本およびコアミドルウェアサービスの一部について説明します。、時間サーバー、および会計。マルチキャストやdiffservなどのネットワークレベルの機能は、ミドルウェアとして分類されていません。むしろ、ミドルウェアが構築されるか、ミドルウェアが使用および管理できるインフラストラクチャサービスを可能にしています。これらのコアセットのサービスに基づいた第2レベルの重要なミドルウェアサービスには、会計/請求、リソースマネージャー、シングルサインオンサービス、グローバルに一意の名前、メタデータサーバー、ロケーターが含まれます。
A recognized goal is to provide a set of middleware services that enable access to and management of the underlying network infrastructure and support applications wishing to make use of that network-based infrastructure. It appears necessary to agree to a framework of services for the support, provisioning and operations, and management of the network. Today, we have piecemeal activities already being pursued in various standards organizations. These include efforts in the IETF and DMTF (e.g., AAA, Policy Framework, DiffServ, DEN, CIM, etc.), as well as in the advanced application environments (e.g., Grid Forum, the PACIs, NGI, Internet2, etc.). Both of these efforts require the integration and management of many infrastructure components, not just networks; however, we have no overall framework that pulls all of these together, or a mechanism to coordinate all of these activities. We are just embarking on the development of a rich plan of middleware services. Consequently, we have a lot of work yet to be done. For instance, as we move into an electronic persistent presence (EPP) environment where multiple instances of an identity or person (or even their proxy agents) are supported, we will require enhanced locator and brokering services. The directory (e.g., DNS or X.500) and locator services of today may not be appropriate for this task.
認識されている目標は、そのネットワークベースのインフラストラクチャを利用したい基礎となるネットワークインフラストラクチャへのアクセスと管理およびサポートアプリケーションを可能にするミドルウェアサービスのセットを提供することです。ネットワークのサポート、プロビジョニングおよび運用、および管理のためのサービスのフレームワークに同意する必要があるようです。今日、私たちはすでにさまざまな標準組織で追求されている断片的な活動があります。これらには、IETFおよびDMTF（AAA、ポリシーフレームワーク、Diffserv、den、CIMなど）、および高度なアプリケーション環境（グリッドフォーラム、Pacis、NGI、Internet2など）の努力が含まれます。。これらの取り組みには、ネットワークだけでなく、多くのインフラストラクチャコンポーネントの統合と管理が必要です。ただし、これらすべてをまとめる全体的なフレームワークや、これらすべてのアクティビティを調整するメカニズムはありません。ミドルウェアサービスの豊富な計画の開発に着手しています。その結果、まだ多くの作業が行われていません。たとえば、アイデンティティまたは個人（またはプロキシエージェント）の複数のインスタンスがサポートされている電子永続的な存在（EPP）環境に移行すると、強化されたロケーターとブローカーサービスが必要になります。このタスクには、今日のディレクトリ（DNSまたはX.500など）とロケーターサービスが適切ではない場合があります。
One goal of the workshop was to identify research and development areas in middleware that federal agencies and industry may choose to support. The workshop highlighted a few areas that may benefit from additional R&D support. These areas include, but are not limited to:
ワークショップの目標の1つは、連邦政府機関や業界がサポートすることを選択できるミドルウェアの研究開発分野を特定することでした。ワークショップは、追加のR＆Dサポートの恩恵を受ける可能性のあるいくつかの分野を強調しました。これらの領域には、以下が含まれますが、これらに限定されません。
- inter-domain resource management architecture and protocols (e.g., inter-domain bandwidth brokers) - resource languages that describe and enable the management of a wide variety of resources (e.g., networks, data bases, storage, online facilities, etc. - avoiding deadlock and ensuring efficiency with resource managers - network management tools and APIs that provide macroscopic and microscopic real-time infrastructure - information to middleware services and applications (not just MIBs and SNMP access) - domain and inter-domain accounting and billing - monitoring and verification services of contracted infrastructure services - enhanced locators that can locate resources and resource managers
- ドメイン間のリソース管理アーキテクチャとプロトコル（例：ドメイン間帯域幅ブローカーなど） - さまざまなリソースの管理を説明および可能にするリソース言語（ネットワーク、データベース、保管、オンライン施設など - デッドロックの回避リソースマネージャーとの効率の確保 - 巨視的および顕微鏡的リアルタイムインフラストラクチャを提供するネットワーク管理ツールとAPI-ミドルウェアサービスとアプリケーション（MIBSおよびSNMPアクセスだけでなく）への情報 - ドメインおよびドメイン間会計と請求 - 監視および検証サービス契約されたインフラストラクチャサービスの範囲 - リソースとリソースマネージャーを見つけることができる強化されたロケーター
- cross administrative policy negotiation and authentication - middleware bypass (i.e. access to raw system or network resources metadata (i.e., data that is used to describe data found in directories or exchanged between services such as resource managers, PDPs, PEPs, directories, accounting and billing services, etc.) - middleware support for mobile or nomadic use - support for availability of resources (i.e. replication and load balancing
- クロス管理ポリシーの交渉と認証 - ミドルウェアバイパス（つまり、生システムまたはネットワークリソースメタデータへのアクセス（つまり、ディレクトリ、PDP、PEP、ディレクトリ、会計、請求などのサービス間でディレクトリで見つかったデータまたは交換されたデータに使用されるデータが使用されます。サービスなど） - モバイルまたは遊牧民の使用のミドルウェアサポート - リソースの可用性のためのサポート（つまり、複製と負荷分散
This workshop was just one small step in identifying relevant middleware topics, technologies and players. Even though this workshop did not arrive at a consensual definition of middleware, it did identify the need for additional work. Specifically, further work is needed to identify and qualify middleware services for specific affinity groups (e.g. Internet2, Education, the PACIs, Grids, etc.) as well as to define a macroscopic framework that incorporates the middleware work of the IETF, DMTF and other relevant organizations such as the Grid Forum.
このワークショップは、関連するミドルウェアのトピック、テクノロジー、プレーヤーを特定するための1つの小さなステップでした。このワークショップはミドルウェアの合意に基づいた定義に到達しませんでしたが、追加の作業の必要性を特定しました。具体的には、特定のアフィニティグループ（例：Internet2、教育、PACIS、グリッドなど）のミドルウェアサービスを特定して資格を取得し、IETF、DMTF、その他のミドルウェア作業を組み込んだ巨視的なフレームワークを定義するために、さらなる作業が必要です。グリッドフォーラムなどの関連組織。
Deb Agarwal <deba@george.lbl.gov>, Bob Aiken <raiken@cisco.com>, Guy
Almes <almes@internet2.edu>, Chase Bailey <chase@cisco.com>, Fred
Baker <fred@cisco.com>, Pete Beckman <beckman@lanl.gov>, Javad
Boroumand <jborouma@nsf.gov>, Scott Bradner <sob@harvard.edu>, George
Brett <ghbrett@mindspring.com>, Rich Carlson <racarlson@anl.gov>,
Brian Carpenter <bcarpent@uk.ibm.com>, Charlie Catlett
<catlett@ncsa.uiuc.edu>, Bill Cheng <wtcheng@us.ibm.com>, Kim Claffy
<kc@caida.org>, Bill Decker <Wdecker@nsf.gov>, Christine Falsetti
<cfalsetti@arc.nasa.gov>, Ian Foster <foster@mcs.anl.gov>, Andrew
Grimshaw <grimshaw@cs.virginia.edu>, Ed Grossman
<egrossma@ncsa.uiuc.edu>, Ted Hanss <ted@internet2.edu>, Ron Hutchins
<ron@oit.gatech.edu>, Larry Jackson <jackson@ncsa.uiuc.edu>, Bill
Johnston <Wejohnston@lbl.gov>, Juerg von Kaenel <jvk@us.ibm.com>,
Miron Livny <miron@cs.wisc.edu>, Cliff Lynch <cliff@cni.org>, Joel
Mambretti <j-mambretti@nwu.edu>, Reagan Moore <moore@sdsc.edu>, Klara
Nahstedt <klara@cs.uiuc.edu>, Mike Nelson <mrn@us.ibm.com>, Bill
Nitzberg <nitzberg@nas.nasa.gov>, Hilarie Orman <ho@darpa.mil>, John
Schnizlein <jschnizl@cisco.com>, Rick Stevens <stevens@mcs.anl.gov>,
John Strassner <johns@cisco.com>, Ben Teitelbaum <ben@advanced.org>,
George Vanecek <g.vanecek@att.com>, Ken Klingenstein
<Ken.Klingenstein@Colorado.EDU>, Arvind Krishna
<akrishna@us.ibm.com>, Dilip Kandlur <kandlur@us.ibm.com
Please see http://www.mcs.anl.gov/middleware98 for copies of the slides presented at the workshop as well as a list of related URLs on applications, middleware and network services.
ワークショップで提示されたスライドのコピーと、アプリケーション、ミドルウェア、ネットワークサービスの関連URLのリストについては、http：//www.mcs.anl.gov/middleware98を参照してください。
Editor: Bob Aiken EMail: raiken@cisco.com
編集者：Bob Aikenメール：raiken@cisco.com
Authors:
著者：
Bob Aiken Cisco Systems, Inc. 6519 Debold Rd. Sabillasville, Md. 21780 USA
Bob Aiken Cisco Systems、Inc。6519 Debold Rd。メリーランド州サビラスビル21780 USA
Phone: +1 301 271 2919
EMail: raiken@cisco.com
John Strassner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
John Strassner Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
Phone: +1 408 527 1069
EMail: johns@cisco.com
Brian E. Carpenter IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire SO21 2JN, UK
ブライアンE.カーペンターIBMイギリス研究所MP 185、ハズリーパークウィンチェスター、ハンプシャーSO21 2JN、英国
EMail: brian@hursley.ibm.com
Ian Foster Argonne National Laboratory The University of Chicago Argonne, IL 60439 USA
Ian Foster Argonne National Laboratoryシカゴ大学アルゴンヌ、イリノイ州60439 USA
Phone: +1 630 252 4619 EMail: foster@mcs.anl.gov Clifford Lynch Coalition for Networked Information 21 Dupont Circle Washington, DC 20036
電話：1 630 252 4619メール：foster@mcs.anl.gov Clifford Lynch Coalition for Networked Information 21 Dupont Circle Washington、DC 20036
Phone: +1 202 296 5098
EMail: cliff@cni.org
Joe Mambretti International Center for Advanced Internet Research 1890 Maple, Suite 150 Northwestern University, Evanston, Illinois 60201
ジョー・マンブレッティ国際高等インターネット研究センター1890メープル、スイート150ノースウェスタン大学、イリノイ州エヴァンストン60201
Phone: +1 847 467 3911
EMail: j-mambretti@nwu.edu
Reagan Moore University of California, San Diego NPACI/SDSC, MC 0505 9500 Gilman Drive La Jolla, CA 92093-0505 USA
レーガンムーアカリフォルニア大学、サンディエゴNPACI/SDSC、MC 0505 9500ギルマンドライブラホーヤ、カリフォルニア92093-0505 USA
EMail: moore@sdsc.edu
Benjamin Teitelbaum Advanced Networks & Services, Inc.
Benjamin Teitelbaum Advanced Networks＆Services、Inc。
EMail: ben@internet2.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。