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.
著作権（C）インターネット協会（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.
アドホックミドルウェアのワークショップは、ワークショップが組織され、シスコ、高度なインターネットリサーチのためのノースウェスタン大学の国際センター（iCAIR）、IBM、および国立科学財団（NSF）が主催した1998年12月に高度なインターネットリサーチのための国際センターで開催されました。ワークショップの目標は、新しい機能だけでなく、研究開発を必要とする追加のミドルウェアサービスを識別するために活用することができ、既存のミドルウェアサービスを同定することでした。ワークショップの参加者は、一般に、ミドルウェアの定義を議論し、サービスをミドルウェアに関連する詳細な基礎となるネットワークトランスポート機能をアプリケーションの視点を検討し、次にミドルウェア・コンポーネントの様々な具体例をカバー。これらは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.
この文書では、ワークショップを組織し、シスコ、高度なインターネットリサーチのためのノースウェスタン大学の国際センター（iCAIR）、IBM、および国立科学財団（NSF）が主催して12月4-5 1998年に開催されたアドホックミドルウェアワークショップの製品です。ワークショップの目的は、高度なネットワークインフラストラクチャ上だけでなく、分散アプリケーションに長期的なミドルウェアとその要件を定義することでした。これらの定義は、その後、高度なアプリケーション環境を支援するだけでなく、他のミドルウェアサービスのための基礎を提供するための両方、指定するコア・ミドルウェア・コンポーネントの集合を可能にします。
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、インターネット2、次世代インターネット（NGI）、高度な計算インフラストラクチャのためのNSFパートナーシップ（PACI）、省庁間の情報技術21世紀のための（IT2）プログラム、グリッド・フォーラム、世界的に提供されますその検討のためのウェブコンソーシアム、および他のコミュニティ。
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.
ミドルウェアは、サービスの大規模なセットを包含するように定義することができます。例えば、我々は、分散ネットワーク環境に基づいてアプリケーションの共通セットをサポートするために必要なサービスに最初に焦点を当てることにしました。ワークショップのコンセンサスは、すべてのアプリケーションがそれらを必要とするという意味でミドルウェアサービスのないコアセットは本当にありませんでしたということでした。このコンセンサスは、アプリケーションドメイン固有のミドルウェア、またはカスタマイズされたアプローチを決定する際に必要な柔軟性の重要性を減少させません。多くのコミュニティ（例えば、インターネット2、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.
フォーカスを提供助けたワークショップのもう一つのコンセンサスは、ミドルウェアは、階層的、または階層として概念化することができるが、このようなアプローチは役に立ちませんでした、ということでした、そして実際に問題とそれ以前の努力で非生産的でした。
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上で何を参照してください。これらの2つの両極端の間のアプリケーション、ツール、およびメカニズムに働く人々は、アプリケーション固有の上位ミドルウェア、汎用的なミドルミドルウェア、およびリソース固有の下のミドルウェアへのいくつかのさらに分類するミドルウェアで、どこかのようにTCPとAPIの間にそれを参照してください。ポイントは、ミドルウェアは、多くの場合、ネットワークが接続されている「ネットワーク」コンピューティング、ストレージへの、および他のリソースを超えて延びていることが繰り返し行われました。例えば、ビデオサービス提供アプリケーションは、ネットワークのためにも役立つとビデオストリームを処理するために必要なアーカイブおよびコンピュータ用だけでなく、資源の発見と割り当てサービスにアクセスすることになるでしょう。一般的な集合論とラフコンセンサスのアプリケーションを介して、我々は、概ねサービスの輸送（すなわち、上のTCP / IP）層セット上になく（すなわち、アプリケーションレベルのAPI以下）アプリケーション環境下に見られるサービスとしてミドルウェアを特徴付けます。
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年代初頭の分散オペレーティング研究で発祥し、さらにSC'95で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.
そのようなミドルウェア・リソースのグローバスプロジェクトを通じて、その後の研究開発がためにその機能を分散ドメインで高度なアプリケーションのパフォーマンスを最適化することを実証しました。
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つの例を引用することは、アーチーや収穫プロジェクトを検討してください。一つは、簡単にアーチーまたはブローカーシステムと収穫エージェントによって使用されるサイトのログは重要なミドルウェアツールだった、この分野での追加作業を緊急にウェブベースのインデックスサービスの効率性と範囲を改善するために必要であることを主張することができます。
"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.
アプリケーションの観点から、ネットワークはそれを使用して管理する必要があるリソースのちょうど別のタイプです。分散コンピューティング、分散型データベース、高度なビデオサービス、teleimmersion（すなわち、説得力のある実を提供するための機能：高度なアプリケーションをサポートするために必要なミドルウェアサービスと一連の要件は、次のような分野での応用が含まれており、組み合わせたビジョンによって定義されていますオンライン科学的施設の利用など、生活CAVE技術上の例えばベースの仮想環境での経験）、ハプティクスと拡張機能、電子商取引、遠隔教育、対話型の共同研究、高レートの計測（60メガバイト/秒および持続以上）、（たとえば、顕微鏡、望遠鏡、等）、有効データ、計算および情報グリッド、適応及びモーフィングネットワークインフラストラクチャ、およびプロキシエージェント、電子永続的な存在（EPP）を大量に管理します。これらのアプリケーションの多くは、商品の現在インターネット上にデプロイされたアプリケーションに関して、「エッジを出血」、したがって、独自の要件を持っています。 Webは1990年代初めに、高度なアプリケーションだったのと同様に、上記で定義された応用分野の多くは、近い将来には一般的になっていないだろう。しかし、彼らはすべての多くのウェブとして、ネットワークインフラストラクチャの私達の定義と同様に使用される方法を変更する機能を有し、モザイクは、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.
teleimmersionための要件のクイックレビューは、独自の遅延、ジッタ、バースト、および帯域幅のQoSと、それぞれ、複数の同時論理的なネットワークチャネルのための要件を強調表示します。まだ全ては、アプリケーションへの単一のミドルウェア・インタフェースを介して調整されています。セキュリティと効率のためにオンラインの楽器を使用して、それらは、デバイスを操縦し、それが楽器から受信されるデータに対して実行リアルタイム分析の直接の結果として、パラメータを変更する機能を必要とします。そのため、ネットワークの要件は、すべてのミドルウェアを通じて調整されなければならない高帯域幅、低遅延、およびセキュリティを、包含する。大規模なデータベース、アーカイブ、およびデジタルライブラリは、研究者や業界のための主力になっています。彼らはネットワーク上およびミドルウェアに配置されます要件は、ほんの数に名前を付けるために、認証、許可、アクセス管理、サービスの品質、ネットワーク化された情報の発見と検索ツール、ネーミングおよびサービスの場所のサポートを含む、広範囲になります。彼らはまた、コレクションの構築と自己記述型データをサポートするためのミドルウェアが必要です。分散コンピューティング環境（例えば、Globusのは、コンドル、軍団、等）を素早く将来のコンピューティングおよび情報グリッドに進化しています。これらのグリッドは、適応と管理しやすいネットワークサービスを必要とするだけでなく、アプリケーションに簡単に使用できる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に違反未満である場合、アプリケーションまたはシステムに通知するためのフィードバック機構を含むべきです。利用可能なネットワークリソース、不足するため3）ポリシーの監視、4）サービス保証、5）紛争解決、および6）反発1）ポリシーの実装及び実施のある種の相互作用、2）動的評価：任意のそのような機構はのための能力を意味しますパフォーマンスの。
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セキュリティの取り組みの一つに過ぎません。これは、（RFC1422は、1つのそのようなモデルの一例である）信託/階層環境の範囲や使用環境の範囲をサポートするフレームワークを提供することを意図している公開鍵インフラストラクチャ、に大きく依存します。
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のための一つの考慮事項は、粒度のさまざまなレベルを提供することです。我々はまだ統合モデルを持っていない場合でも、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ポリシーフレームワークワーキンググループは、具体的には、ポリシーフレームワーク定義言語、ポリシー・アーキテクチャ・モデル、ポリシー用語と、シグナリングならびにプロビジョニングQoSのために使用することができるポリシーモデルに取り組んでいます。ポリシーメタモデルは、サービス、オブジェクトおよびその他のリソースの特定のアクセス制御管理の必要な機構の構成に至るまで、低レベルのデバイスの実装機構に、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.
ポリシーは、すべてのミドルウェアサービスの不可欠な構成要素であり、一つの形態または別で最もミドルウェアサービス内で発見されます。ポリシーは、多くの場合、「条件であれば、その後のアクション」タプルとして表現されています。ポリシーは複雑で、数多くの両方にすることができます。そのため、ポリシー管理サービスは、ポリシーの競合を特定し、解決できなければなりません。彼らはまた、静的（すなわち、コンフィギュレーションファイルを介して、起動時にロードされる）および動的（すなわち、デバイスを強制ポリシーの設定は、イベントに基づいて変更することができる）の両方のモードをサポートする必要があります。
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).
ポリシー情報は、COPSまたはDIAMETERなどのプロトコルの様々なを通じてPEPとPDPから通信されてもよいです。プロキシは、デバイス（例えば、コマンドライン・インタフェース・コマンドまたは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.
最終的には、多くの政策プロセスがリソースへのエンティティをリンクするので、エンティティ識別メカニズム、リソース識別メカニズム、および割り当てメカニズムとの相互作用を必要とします。分散コンピューティングコミュニティは、すでにポリシー定義言語とシステムの開発努力を開始しました。グローバスは、それらに関連付けられているリソースやポリシーを定義するために、そのリソースサービス言語（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.
ディレクトリはミドルウェア環境における他の多くの要素、特に政策へのサポートを提供し、重要なリソースコンポーネントです。ネットワークベースの環境が進化するにつれて、もはや、個々のアプリケーションに直接ポリシー情報を符号化するために実行可能になることはありません。今日は、独自のプライベートデータstore.Theseデータでデバイスのデータのビュー（例えば、コンフィギュレーション）を格納するために、各アプリケーション用で使用されている現行モデルは、（ネットワークリソースとサービスだけでなく、それらの資源を使用したいクライアントに関する適切な情報が含ま例えば、人、プロセス、およびアプリケーション）。同じリソース（または、その物理的対論理的な特性として、そのリソースの態様は、）いくつかのデータストアに表すことができます。デバイスは、各データストアに同じようにモデル化されている場合でも、各アプリケーションは、独自のデータへのアクセス権を持っています。これは、データとデータの同期の問題の重複につながります。
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ような技術の約束は、それらが共通のフォーマットおよびアクセス・プロトコルを使用して単一のディレクトリに管理するリソースを記述するデータを格納するために各アプリケーションを可能にすることです。これは、一度だけ示されているリソースを記述するデータが得られます。リソースとサービスが一般的な方法で表現されている論理的に集中管理共通リポジトリを定義する、さまざまなタイプのアプリケーションは、彼らが使用するリソースやサービスについての情報を利用して共有することができます。
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.
のみならず、これはデータの重複や同期の問題を解決ず、それはまた、オブジェクトの特性を説明する際に固有の拡張性を提供する - 単一のエンティティは、各エンティティの異なる態様を表す、複数のディレクトリ・オブジェクトで表すことができます。異なるアプリケーションはアプリケーション自体が相互に通信できない場合でも、一緒に上位レベルのオブジェクトを構成するさまざまなオブジェクトを管理するための責任を負うことができます。これは、これらのアプリケーションが効果的にデータを共有し、再利用することができます。これは、ユーザーやアプリケーションのための重要な利点を提供します。短期的には、ユーザーやアプリケーションは、一箇所ですべてのデータを持っていることから恩恵を受ける。長期的には、ユーザーやアプリケーションが他のアプリケーションによって管理されるデータを利用することができます。
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.
コンテは、オブジェクトと役割を関連付けるなど、多くの目的に使用することができます。これは、人々との要素は、データのセットに対して異なる命名スコープを提供するために使用することができる時間や他のcontext.Containmentに基づいて異なる役割を引き受けることが現実世界の環境をサポートするために重要です。
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).
ディレクトリは、属性の継承を使用する - サブクラスは、スーパークラスの属性を継承します。これは、（例えば、異なるオブジェクトが異なるアクセス権限を持っている）、容器（例えば、グループ）で一般アクセス制御を定義し、そのコンテナ内にあるオブジェクトに対して個別にアクセス制御を改善するために1つを可能にします。
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は、とりわけ、LDAPによって使用可能な形式にCIMデータをマッピングする方法について説明し、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 MIBとDMTF MIFファイルなど、他の管理モデル、に対してメタスキーマ、情報モデル、言語、ネーミング、およびマッピング技術を説明します。 DENは、ネットワークとその要素の管理に取り組むモデルに良いスタートを提供します。 DENは、全体としてのネットワークだけでなく、個々の要素の管理を含むようにCIMの拡張です。 DENは、複合エンティティの個々の態様を管理するために使用することができる複数のコンポーネントに、ルータなどの、複雑なエンティティを抽象化するための要件に対処します。 DEN情報モデルは、CIMのように、静的および動的の両方の情報が組み込まれています。 DENは、データの記憶及び検索のためのディレクトリへのマッピングを提供します。 DENは、ディレクトリとその政策の整合性を維持するだけでなく、ポリシーリポジトリ、プラズマディスプレイパネルとのPEP間の政策の配布を管理するために、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は、インターネット2、PACI、グリッド）リソースタイプ（すなわち、QOS、セキュリティ、等）の様々な管理するための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.
ポリシーの実装プロセスは、現在存在しているものよりもより洗練された方法でリソース・マネージャにリンクする必要があります。そのようなプロセスは、（例えば、そのようなシステムにログオンし、より高い優先度の輻輳や新規ユーザのような環境変化に基づいてアプリケーションに提供されるサービスの品質を調整する）、ダイナミック、およびそれらの環境の変化を反映することができなければなりません。だけでなく、関連するクロスドメインセキュリティ問題に対処 - 私たちは、お互いについて学び、お互いを見つけるどのように異なるのリソースマネージャのタイプを決定する必要があります。この問題の別の局面は、ネットワーク、プロセッサ、エージェント、メモリまたは記憶装置であるか否かを、利用されているリソースの個々の要素を記述することができるリソース定義言語を開発しています。これは、複数のリソースタイプに適用することができ、適切なメタデータ表現とその下にあるメタスキーマの開発が必要になります。
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.
資源の事前予約、ならびにリソースの動的な要求は、任意のリソース管理システムの重要な態様です。事前予約は、プロビジョニングの問題よりも政策課題のより多くのです。しかし、異なる管理ドメイン内に位置するリソース・マネージャとの間のこのような要求を交換し、増殖させるためのメカニズムが対処する必要は現在未解決の問題です。また、可能なデッドロックおよび/または資源の非効率的な使用（すなわち、要求、または要求のセットの間の期間は、開始され、光栄とリソースが割り当てられている）の問題に対処することが重要です。アプリケーションが複数のサイトやサービスに関わるリソース予約を収集する必要があり、リソース割当サービスにおけるランデブー管理の必要性もあります。
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).
プロトコル（例えば、COPS）ベース使用して互いに規格と相互作用するリソースマネージャを、協働のメッシュは、リソース管理インフラストラクチャのモデルとすることができます。これらのそれぞれは、リソースの異なるセットを管理することができます。別のセキュリティ、IPアドレス割り当て、ストレージ、プロセッサ、薬剤、およびその他のネットワークリソースを管理する汎用リソース・マネージャであり得るが、例えば、一方が、唯一のネットワーク帯域幅を管理帯域ブローカーであってもよいです。すでにリソースを割り当てるだけでなく）など、マルチメディア合成画像の成形、セキュリティサービス、課金サービスを含むことができ、サービスのグループの構成を管理するだけでなく、ミドルウェア・リソース・マネージャーのための計画があります。リソース・マネージャの別の形態は、関連するサービスのセットとの間のマッピングを提供してもよい（すなわち、ATM SVCのIPベースのRSVP要求をマッピングし、vBNS上のパイロット・プロジェクトで実証されたように）。
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）、の構文を定義するには、かなりの作業を行っています。 URIはリゾルバサービスを使用してURLに解決されています。そこにこのようなレゾルバサービスに対する異なる提案の数であり、そしていくつかの実装は、CNRIハンドラサービスとして存在します。多くの組織では、デジタルオブジェクト識別子（DOI）とURI名前空間、特に出版コミュニティを確立し、管理するために始めています。しかし、そのような最も効果的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.
記述、評価、出所、著作権管理、など、ネットワーク上のオブジェクトに関連付けすることができる - 問題の別のセットは、様々な種類のメタデータを中心に展開します。ワールドワイドウェブコンソーシアム（W3C）からリソース記述フレームワーク（RDF）は、オブジェクトをネットワークにそのような記述を取り付けるため、説明を符号化するための構文を提供します。追加のミドルウェア作業がリポジトリに格納することができ、そのようなメタデータを取得するために、オブジェクトに関連付けられたメタデータを検索するために必要とされています。メタデータの検証は重要な問題であり、IETFとW3Cの両方は、メタデータのアサーションに署名する公開鍵インフラストラクチャと併せて使用することができるXML正則化アルゴリズムに取り組んでいます。しかし、このようなアプローチは、検索でこれらの信頼関係を使用するように指定する必要があります信頼関係と階層管理する必要があります、およびポリシーの複雑なセットを意味します。
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レポートを参照してください。手続き/ 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.
最後に、すでにそのようアーチーや収穫などのサービスに統合された研究作業の上に構築するミドルウェアサービスのセットが必要です。これらのサービスは、必ずしもそれらのサービスを検索し、検査することなく、ネットワーク情報オブジェクトおよびサービスの内容に関するメタデータの効率的な抽出が可能。これは、適切なセキュリティと認証の制約の下で、そのようなインデックスを計算するためのサイトで実行できる「インデックス剤」または「knowbots」を派遣する機能が含まれています。また、集約「プッシュベースの」ブローカー・サービスのセット、フィルタ、および複数のサイトからメタデータを収集し、興味のあるアプリケーションにそれらを提供も必要です。このようなサービスは、今日のウェブクローラベースのインデックスサービスのための大規模な性能、品質、包括性と適時改善を提供することができます。
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つのまたはメトリックの適切な保証とサービスを提供するために、通信の特定の種類のための彼らの要求を満たすために、ネットワーク内の利用可能なリソースを要求する必要があるかもしれません。最近、多くの努力の焦点となっている要求の一つのタイプは、特にIP上で実行されているサービスに関して、最善の努力を超えたサービスのためのものです。これは前述の高度なアプリケーション（例えば、視覚化及びteleimmersion）、ならびに音声およびビデオ、特に音声及び低い帯域幅または音声とビデオで動作するビデオの出現重要性のために特に重要であるデータと混交。この問題の一つの視点は、TCPアプリケーションのための壊滅的ですが、リアルタイムトラフィックのための特別な重要性のものであってもよい単一RTT、中に複数の液滴の影響を考慮することです。改善されたサービスを提供するサービス品質（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のアイデアは、大きな関心を生成しました。これは、各の欠点を軽減しながらイントサーブおよびDiffServの両方の長所を組み合わせることを試みます。これは、順番にDiffervとInteservが共存できるだけでなく、ことを確実にするための方法を研究するIETFを主導するだけでなく、相互運用性がありました。
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のメカニズムにどのような影響に焦点を当てたワークショップでの議論は、このようなメカニズムは、ミドルウェアやアプリケーションの利益のためにネットワークインフラストラクチャを監視および管理する能力にしています。政策機構にリンクされている場合イントサーブおよび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.
帯域幅ブローカーモデルを実装するために使用することができるIETFプロトコル（例えば、COPS、直径など）も検討しました。それは基本的なネットワークリソースの割り当て及び再割り当てのためのメカニズムを設定、ならびにこれらのすべてallocations.-オプションは、QoSのに向けられたものを含む帯域ブローカーの実装の様々なタイプに使用することができる提供するため、Diameterプロトコルは、この文脈で興味深いですRSVPタイプ情報を使用して。直径は現在、パス情報を提供していませんが、代わりに、入口及び出口ノードにおいて確立されたネットワークの経路情報に依存しています。しかし、直径の状態はまだ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対応のネットワークに関連付けられたポリシーを確立するためにCOPSを使用することが行われています。 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.
帯域幅ブローカーモデルのいずれかのタイプを実装するには、政策の交換のためのメカニズムを確立する必要があります。インターネット2の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エミュレーションとして記載されている様々な形態、で均等化キューイングです。テクニックは、低速回線のための均等化キューイングのために数年前から使用されています。 DS-3 200バイトのパケットと40のバイトのパケットとOC-3cの速度のために、均等化キューイングは、それが拡張することができます不足ラウンドロビンアルゴリズムを使用しています。これは、確率的に流れをハッシュに基づいて、フローの差別が可能です。この技術の追加の拡張は、クラスの指標で、この技術を前置きすることです。現在、分類技術は、IP優先順位に基づいています。しかし、分類はすぐに適用されるコンディショニングのタイプを指定するためのDiffservコードポイント（DSCPを）を使用して、多くのルータに達成されます。 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、新たなMIB、および能動的測定技術（例えば、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を容易にするために必要とすることができます。言われていることを、何人かの人々は、我々は二つの例であるグループメンバーシップを変更することに関して、いくつかの大規模な技術的なセキュリティ上の課題、失効リストとセキュリティを持っていると信じています。
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.
公開鍵インフラストラクチャ、公証人のサービスや出所の検証に構築され、より高いレベルのミドルウェアサービスもあります。我々は組み込みインテリジェンス（例えば、DiffServの、イントサーブ、帯域幅ブローカー、ディレクトリ対応のネットワークなど）でインターネットに比較的ダムネットワーク（例えば、ベストエフォートIP）から移動すると、情報の安全な交換がさらに重要になります。また、我々は差別化サービスを提供し始めとして、会計と統計情報の収集は、はるかに重要になります。我々はまた、収集、分析、およびネットワーク管理を輸送し、監視情報の完全性とセキュリティを提供する必要があります。そして、データのプライバシーと整合性の問題は、サービスと否認防止の否定に取り組むとともに、無視することはできません。
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.
必要な注意を受けていないネットワーク管理の別の態様は、ネットワークやミドルウェア設計者のためのモデリングと解析ツールの必要性です。 CIMとDENは、ネットワーク要素とサービスの管理だけでなく、ユーザー、アプリケーション、およびネットワークの他のリソースをモデル化するための共通のフレームワークを提供する上で大きな期待を示しました。確かに、ミドルウェアの設計者は、これらのアプローチを進化させます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のミドルウェア技術が発見、参加、および検索するだけでなく、動的なネットワーク接続環境で回復力を提供するために、リースおよび取引メカニズムのためのプロトコルのセットを定義していないだけ。 Javaとジニは、特に署名付きアプレットのために、機能の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.
認識の目標は、ネットワークベースのインフラストラクチャを利用することを希望する基盤となるネットワークインフラとサポートのアプリケーションへのアクセスと管理を可能にするミドルウェアサービスのセットを提供することです。ネットワークのサポート、プロビジョニングおよび運用、および管理のためのサービスの枠組みに同意する必要が表示されます。今日、我々はすでに、さまざまな標準化団体で追求されている断片的な活動を持っています。これらは、（例えば、AAA、ポリシーフレームワーク、DiffServの、DEN、CIM）IETFやDMTFで、だけでなく、高度なアプリケーション環境での取り組み（例えば、グリッド・フォーラム、パチス、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 - サービスやアプリケーションをミドルウェアするための情報（だけでなく、MIBと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.
このワークショップでは、関連するミドルウェアのトピック、技術や選手を特定するのにちょうど小さな一歩でした。このワークショップは、ミドルウェアの合意の定義に到着していなかったにもかかわらず、それは追加作業の必要性を識別しました。具体的には、さらに作業が特異的親和性グループのためのミドルウェアサービスを識別し、修飾する必要がある（例えばインターネット2、教育、パチス、グリッドなど）だけでなく、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
デブAgarwalさん<deba@george.lbl.gov>、ボブ・エイケン<raiken@cisco.com>、ガイAlmes <almes@internet2.edu>、チェイス・ベイリー<chase@cisco.com>、フレッド・ベイカー<fred@cisco.com >、ピート・ベックマン<beckman@lanl.gov>、ジャヴァドBoroumand <jborouma@nsf.gov>、スコット・ブラッドナー<sob@harvard.edu>、ジョージ・ブレット<ghbrett@mindspring.com>、リッチカールソン<racarlson@anl.gov >、ブライアン・カーペンター<bcarpent@uk.ibm.com>、チャーリー・キャトレット<catlett@ncsa.uiuc.edu>、ビル・チェン<wtcheng@us.ibm.com>、キムClaffy <kc@caida.org>、ビル・デッカー<Wdecker@nsf.gov>、クリスティンFalsetti <cfalsetti@arc.nasa.gov>、イアン・フォスター<foster@mcs.anl.gov>、アンドリュー・グリムショー<grimshaw@cs.virginia.edu>、エド・グロスマン<egrossma @ NCSA .uiuc.edu>、テッドHanss <ted@internet2.edu>、ロン・ハッチンス<ron@oit.gatech.edu>、ラリー・ジャクソン<jackson@ncsa.uiuc.edu>、ビル・ジョンストン<Wejohnston@lbl.gov>、 JuergフォンKaenel <jvk@us.ibm.com>、マイアン・リビー<miron@cs.wisc.edu>、クリフ・リンチ<cliff@cni.org>、ジョエルMambretti <j-mambretti@nwu.edu>、レーガン・ムーア< moore@sdsc.edu>、クララNahstedt <klara@cs.uiu c.edu>、マイク・ネルソン<mrn@us.ibm.com>、ビルNitzberg <nitzberg@nas.nasa.gov>、ヒラリーオーマン<ho@darpa.mil>、ジョンSchnizlein <jschnizl@cisco.com>、リックスティーブンス<stevens@mcs.anl.gov>、ジョンStrassner <johns@cisco.com>、ベンTeitelbaum <ben@advanced.org>、ジョージVanecek <g.vanecek@att.com>、ケンKlingenstein <Ken.Klingenstein @ Colorado.EDU>、アービンド・クリシュナ<akrishna@us.ibm.com>、ディリップ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
エディタ：ボブ・エイケンEメール：raiken@cisco.com
Authors:
著者：
Bob Aiken Cisco Systems, Inc. 6519 Debold Rd. Sabillasville, Md. 21780 USA
ボブ・エイケンシスコシステムズ株式会社6519 Debold Rdを。 Sabillasville、メリーランド州。 21780 USA
Phone: +1 301 271 2919 EMail: raiken@cisco.com
電話：+1 301 271 2919 Eメール：raiken@cisco.com
John Strassner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ジョンStrassnerシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
Phone: +1 408 527 1069 EMail: johns@cisco.com
電話：+1 408 527 1069 Eメール：johns@cisco.com
Brian E. Carpenter IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire SO21 2JN, UK
ブライアンE.カーペンターIBMイギリス研究所MP 185、Hursleyの公園ウィンチェスター、ハンプシャーSO21 2JN、英国
EMail: brian@hursley.ibm.com
メールアドレス：brian@hursley.ibm.com
Ian Foster Argonne National Laboratory The University of Chicago Argonne, IL 60439 USA
シカゴアルゴンヌのイアン・フォスターアルゴンヌ国立研究所東京大学、IL 60439 USA
Phone: +1 630 252 4619 EMail: foster@mcs.anl.gov
電話：+1 630 252 4619 Eメール：foster@mcs.anl.gov
Clifford Lynch Coalition for Networked Information 21 Dupont Circle Washington, DC 20036
ネットワーク情報21デュポンサークルワシントンD.C. 20036のためのクリフォード・リンチ連合
Phone: +1 202 296 5098 EMail: cliff@cni.org
電話：+1 202 296 5098 Eメール：cliff@cni.org
Joe Mambretti International Center for Advanced Internet Research 1890 Maple, Suite 150 Northwestern University, Evanston, Illinois 60201
高度なインターネットリサーチ1890メープルのためのジョーMambretti国際センター、スイート150ノースウェスタン大学、イリノイ州エバンストン60201
Phone: +1 847 467 3911 EMail: j-mambretti@nwu.edu
電話：+1 847 467 3911 Eメール：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ギルマンドライブラ・ホーヤ、CA 92093-0505 USA
EMail: moore@sdsc.edu
メールアドレス：moore@sdsc.edu
Benjamin Teitelbaum Advanced Networks & Services, Inc.
ベンジャミンTeitelbaum高度なネットワーク＆サービス株式会社
EMail: ben@internet2.edu
メールアドレス：ben@internet2.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。