RFC2768 日本語訳
2768 Network Policy and Services: A Report of a Workshop onMiddleware. B. Aiken, J. Strassner, B. Carpenter, I. Foster, C.Lynch, J. Mambretti, R. Moore, B. Teitelbaum. February 2000. (Format: TXT=81034 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループB.エーケンの要求をネットワークでつないでください: 2768年のJ.Strassnerカテゴリ: ネットワークでつながれたInformationのMambretti ICAIR R.ムーア・UCSD B.J.タイテルバウムのための情報のシスコシステムズB.大工のIBMのI.フォスター・アルゴンヌ国立研究所のC.リンチの連合はInc.2000年2月にネットワークとサービスを唱えました。
Network Policy and Services:
A Report of a Workshop on Middleware
方針とサービスをネットワークでつないでください: ミドルウェアに関するワークショップのレポート
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The Workshop was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development. The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service,
臨時のミドルウェアワークショップは1998年12月にAdvancedインターネットResearchのための国際センターで開かれました。 Workshopはシスコ、AdvancedインターネットResearchのためのノースウェスタン大学の国際センター(iCAIR)、IBM、および国立科学財団(NSF)によって組織化されて、後援されました。 ワークショップの目標は新しい能力のために利用されて、研究開発を必要とする追加ミドルウェアサービスを特定できた既存のミドルウェアサービスを特定することでした。 講習会参加者は、一般に、ミドルウェアの定義について議論して、アプリケーション見解を調べて、ミドルウェアサービスに関連している基本的なネットワーク輸送能力を詳しく述べて、次に、ミドルウェアの部品の様々な特定の例をカバーしました。 これらの含まれているAPI、認証、承認、および会計(AAA)問題、方針フレームワーク、ディレクトリ(資源管理)は情報発見と検索サービスをネットワークでつなぎました、サービスの質
Aiken, et al. Informational [Page 1] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[1ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
security, and operational tools. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified.
セキュリティ、および操作上のツール。 ミドルウェア研究開発のための、より組織化されたフレームワークの必要性は認識されました、そして、さらなる仕事を必要とする特定の話題のリストは特定されました。
Table of Contents
目次
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Contextual Framework . . . . . . . . . . . . . . . . . . . . 3 2.0 What is Middleware? . . . . . . . . . . . . . . . . . . . . 4 3.0 Application Perspective . . . . . . . . . . . . . . . . . . 6 4.0 Exemplary Components . . . . . . . . . . . . . . . . . . . . 7 5.0 Application Programming Interfaces and Signaling . . . . . . 8 6.0 IETF AAA . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.0 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.0 Directories . . . . . . . . . . . . . . . . . . . . . . . . 12 9.0 Resource Management . . . . . . . . . . . . . . . . . . . . 15 10.0 Networked Information Discovery and Retrieval Services . . . 17 11.0 Network QOS . . . . . . . . . . . . . . . . . . . . . . . . 18 12.0 Authentication, authorization, and access management . . . . 21 13.0 Network Management, Performance, and Operations . . . . . . 22 14.0 Middleware to support multicast applications . . . . . . . . 23 15.0 Java and Jini TM . . . . . . . . . . . . . . . . . . . . . . 24 16.0 Security Considerations . . . . . . . . . . . . . . . . . . 24 17.0 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 18.0 Participants . . . . . . . . . . . . . . . . . . . . . . . . 26 19.0 URLs/references . . . . . . . . . . . . . . . . . . . . . . 27 20.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 21.0 Full Copyright Statement . . . . . . . . . . . . . . . . . . 29
序論. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0Contextual Framework. . . . . . . . . . . . . . . . . . . . 3 2.0WhatはMiddlewareですか? . . . . . . . . . . . . . . . . . . . . 4 3.0 アプリケーション見解. . . . . . . . . . . . . . . . . . 6 4.0の模範的コンポーネント. . . . . . . . . . . . . . . . . . . . 7 5.0アプリケーションプログラミングインターフェースとシグナリング. . . . . . 8 6.0IETF AAA…; 9 7.0 方針. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.0ディレクトリ. . . . . . . . . . . . . . . . . . . . . . . . 12 9.0資源管理. . . . . . . . . . . . . . . . . . . . 15 10.0は情報発見と検索サービスをネットワークでつなぎました; .17 11.0がQOS.18 12.0Authentication、承認、およびアクセス管理をネットワークでつなぐ、サポートマルチキャストアプリケーション. . . . . . . . 23 15.0JavaとジニーTM. . . . . . . . . . . . . . . . . . . . . . 24 16.0Security Considerations. . . . . . . . . . . . . . . . . . 24 17.0Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 24 18.0への.21 13.0Network Management、パフォーマンス、およびOperations.22 14.0Middleware.26 19.0のURL/参照箇所. . . . . . . . . . . . . . . . . . . . . . 27 20.0作者のものが.27 21.0の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 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
このドキュメントはその要件と範囲と同様に「ミドルウェア」という用語について説明します。 目的は基づく共同と高性能分散コンピューティングアプリケーションの両方の開発者とネットワークインフラの開発者とのコミュニケーションを容易にすることです。 一般に、高度なネットワークでは、ミドルウェアはサービス、両方のアプリケーションの間に位置する他のリソース、基本的なパケット推進、およびルーティングインフラストラクチャから成ります、コンセンサスは全く現在、それらのドメインを定義する画定の正確な系列に存在しませんが。 このドキュメントは既存の規格取り組みの文脈の中で開発されています。 その結果、このドキュメントはミドルウェア関連の規格活動の現在の状態のフレームワークの中でミドルウェアコア構成要素を定義します、特にIETFとDesktop Management Task Force(DMTF)の中で。 IETFの思い描かれた役割は使用できた基本的なプロトコルを定義することにおける仕事がミドルウェアインフラストラクチャをサポートするように導くことです。 このような関係においては、私たちは、情報がモデル仕事と、高度なXMLであると利用するつもりです。
Aiken, et al. Informational [Page 2] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[2ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
and CIM/DEN-LDAP mapping work, being done in the DMTF. (The recently constituted Grid Forum is also pursuing relevant activities.)
そして、DMTFでして、仕事を写像するCIM/DEN-LDAP。 (また、最近構成されたGrid Forumは関連活動を追求しています。)
This document also addresses the impact of middleware on Internet protocol development. As part of its approach to describing middleware, this document has initially focused on the intersections among middleware components and application areas that already have well defined activities underway.
また、このドキュメントはインターネットプロトコル開発でのミドルウェアの影響を扱います。 ミドルウェアについて説明することへのアプローチの一部として、このドキュメントは初めは、既に進行中のよく定義された活動を持っているミドルウェアの部品と応用分野で交差点に焦点を合わせました。
This document is a product of an ad hoc Middleware Workshop held on December 4-5 1998. The Workshop was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to define the term middleware and its requirements on advanced network infrastructures as well as on distributed applications. These definitions will enable a set of core middleware components to subsequently be specified, both for supporting advanced application environments as well as for providing a basis for other middleware services.
このドキュメントは1998 12月4日〜5日に持たれていた臨時のMiddleware Workshopの製品です。 Workshopはシスコ、AdvancedインターネットResearchのためのノースウェスタン大学の国際センター(iCAIR)、IBM、および国立科学財団(NSF)によって組織化されて、後援されました。 ワークショップの目標は高度なネットワークインフラと分配されたアプリケーションに関するミドルウェアという用語とその要件を定義することでした。 これらの定義は、1セットのコアミドルウェアの部品が次に指定されるのを可能にするでしょう、高度なアプリケーションが環境であるとサポートして、他のミドルウェアサービスの基礎を前提とするための両方。
Although this document is focused on a greater set of issues than just Internet protocols, the concepts and issues put forth here are extremely relevant to the way networks and protocols need to evolve as we move into the implementation stage of "the network is the computer". Therefore, this document is offered to the IETF, DMTF, Internet2, Next Generation Internet (NGI), NSF Partnerships for Advanced Computational Infrastructure (PACI), the interagency Information Technology for the 21st Century (IT2) program, the Grid Forum, the Worldwide Web Consortium, and other communities for their consideration.
このドキュメントはまさしくインターネットプロトコルより大きいセットの問題に焦点を合わせられますが、ここから差し出された概念と問題はネットワークとプロトコルが、私たちが「ネットワークはコンピュータです」の実装ステージに移行するとき発展する必要がある方法に非常に関連しています。 したがって、彼らの考慮のためのIETF、DMTF、Internet2、Next Generationインターネット(NGI)、Advanced Computational InfrastructureのためのNSF Partnerships(パーチ)、21世紀(IT2)プログラムのための省庁情報Technology、Grid Forum、WorldwideウェブConsortium、および他の共同体にこのドキュメントを提供します。
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はアプリケーション要件について論じます。 アプリケーションとミドルウェア開業医によって定義されるようにその後のセクションはミドルウェアのために要件と能力について論じます。 また、これらのセクションは必要な基本的な輸送インフラ、施政方針、および管理について論ずるでしょう、模範的コアミドルウェアの部品、問題、ネットワーク環境、導入問題、および研究領域に食糧を供給して。
1.0 Contextual Framework
1.0 文脈上のフレームワーク
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
大きいサービスを成就するためにミドルウェアを定義できます。 例えば、私たちは、初めは分散ネットワーク環境に基づく一般的なアプリケーションをサポートするのに必要であるサービスに焦点を合わせるのを選びました。 Workshopのコンセンサスが意味にはミドルウェアサービスの巻き癖が全く本当になかったということであった、それ、すべてのアプリケーション
Aiken, et al. Informational [Page 3] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[3ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
required them. This consensus does not diminish the importance of application domain-specific middleware, or the flexibility needed in determining customized approaches. Many communities (e.g., Internet2, NGI, and other advanced Internet constituencies) may decide on their own set of common middleware services and tools; however, they should strive for interoperability whenever possible. The topics in this workshop were chosen to encourage discussion about the nature and scope of middleware per se as distinct from specific types of applications; therefore, many relevant middleware topics were not discussed.
それらを必要としました。 このコンセンサスはアプリケーションのドメイン特有のミドルウェアの重要性、またはカスタマイズされたアプローチを決定するのにおいて必要である柔軟性を減少させません。 多くの共同体(例えば、Internet2、NGI、および他の高度なインターネット選挙民)がそれら自身の一般的なミドルウェアサービスとツールのセットを決めるかもしれません。 しかしながら、可能であるときはいつも、彼らは相互運用性を求めて努力するべきです。 このワークショップにおける話題は議論を奨励するためにそういうものの特定のタイプのアプリケーションと異なるとしてのミドルウェアの自然と範囲に関して選ばれました。 したがって、多くの関連ミドルウェア話題について議論しませんでした。
Another consensus of the Workshop that helped provide focus was that, although middleware could be conceptualized as hierarchical, or layered, such an approach was not helpful, and indeed had been problematic and unproductive in earlier efforts.
焦点を提供するのを助けたWorkshopの別のコンセンサスは本当に、そのようなアプローチが以前の取り組みでミドルウェアを階層的であるとして概念化したか、または層にすることができましたが、役立たないで、問題が多くて、非生産的であったということでした。
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.
Workshopの重要な目標は高度なアプリケーションが環境であるとサポートするために到達技術水準を進めるのに必要であるミドルウェアや、ネットワーク関連の研究やまたは開発を特定することでした、NGIとInternet2によって開発されて、追求されるものなどのように。 その結果、議論はそのような進歩の最大の機会を持っていたそれらの領域に焦点を合わせました。
2.0 What is Middleware?
2.0 Middlewareは何ですか?
The Workshop participants agreed on the existence of middleware, but quickly made it clear that the definition of middleware was dependent on the subjective perspective of those trying to define it. Perhaps it was even dependent on when the question was asked, since the middleware of yesterday (e.g., Domain Name Service, Public Key Infrastructure, and Event Services) may become the fundamental network infrastructure of tomorrow. Application environment users and programmers see everything below the API as middleware. Networking gurus see anything above IP as middleware. Those working on applications, tools, and mechanisms between these two extremes see it as somewhere between TCP and the API, with some even further classifying middleware into application-specific upper middleware, generic middle middleware, and resource-specific lower middleware. The point was made repeatedly that middleware often extends beyond the "network" into the compute, storage, and other resources that the network connects. For example, a video serving application will want
Workshop関係者は、ミドルウェアの存在に同意しましたが、ミドルウェアの定義にそれを定義しようとするものの主観的な見解に依存しているとすばやく断言しました。 恐らく、質問が行われた時それは同等の扶養家族でした、昨日(例えば、Domain Name Service、公開鍵基盤、およびEvent Services)のミドルウェアが明日の基本的なネットワークインフラになるかもしれないので。 アプリケーション環境ユーザとプログラマはAPIの下のすべてをミドルウェアであるとみなします。 ネットワーク導師はIPの上の何でもミドルウェアであるとみなします。 これらの間の数人がさらにミドルウェアをアプリケーション特有の上側のミドルウェア、ジェネリックの中央ミドルウェア、およびリソース特有の低いミドルウェアに分類してさえいる状態で2つの極端がTCPとAPIの間のどこかでそれを見るアプリケーション、道具、およびメカニズムに取り組むもの。 ポイントが繰り返して作られていて、そのミドルウェアがしばしば「ネットワーク」を超えて広がっているということであった、計算してください、ネットワークが接続するストレージであって、他のリソース。 例えば欲しいアプリケーションに役立つのがなるビデオ
Aiken, et al. Informational [Page 4] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[4ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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).
リソース発見と配分にアクセスするために、ネットワークだけではなく、アーカイブとコンピュータのためにサービスがビデオストリームに役立って、処理するのが必要です。 一般集合論と荒いコンセンサスのアプリケーションで、それらのサービスがサービスの輸送(すなわち、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.
ミドルウェアのいくらかの最も前のconceptualizationsが1970年代後半と1980年代前半の分配された操作研究を発して、サウスカロライナ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研究領域に関するNext Generationインターネット(NGI)ワークショップは「次世代インターネットのための挑戦について研究してください」というミドルウェアの以下の記述をもたらす刊行物をもたらしました。 「ネットワークでつながれた環境でよく機能するのに多くのアプリケーションで一般的に必要である再利用できて、拡張可能なセットのサービスと機能としてミドルウェアを見なすことができます。」 永続的なサービスを含むようにさらにこの定義を洗練できました、環境(例えば、Java/ジニー)、ネットワークインフラ(例えば、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
また、少なくとも1980年代後半以来ネットワークでつながれた情報が発見であるとサポートするために強いミドルウェアの部品にかかわるシステムはアクティブな研究領域です。 例えば、アーチーかハーベストプロジェクトを考えて、2つの例を引用してください。 1つは、アーチーかブローカーシステムと収穫エージェントによって使用されたサイトログが重要なミドルウェアツールであったと容易に主張するかもしれません、そして、この領域での追加仕事はそのように主張します。
Aiken, et al. Informational [Page 5] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[5ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
urgently needed in order to improve the efficiency and scope of web- based indexing services.
サービスに索引をつけながら基づくウェブの効率と範囲を改良するのに緊急に必要です。
"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年より」RFC1862で「インターネットへの情報インフラストラクチャ」に関して報告されたワークショップを開きました。様々な意味で、RFCは同様の問題をカバーしました。 推薦は以下の通りまとめられましたが:
- 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.
最終的に、このワークショップは、1セットの規格としてのミドルウェアとプロトコルの間には、近いリンケージがあることに注意しました、そして、インフラストラクチャはミドルウェアを重要にする必要がありました。 例えば、DNSプロトコルはDNSサーバのシステム、および本当に名前登録の管理インフラストラクチャがなければ限られた意味のものでしょう。 NTPは役に立つように時間サーバの存在を必要とします。 命名などの、より新しいミドルウェアサービス(公開鍵登録と認証局)は、役に立つものと同様に使用可能なサービスになるようにさらに大規模なサーバと管理インフラストラクチャを必要とするでしょう。
3.0 Application Perspective
3.0 アプリケーション見解
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
アプリケーション見解から、ネットワークはそれが使用して、管理する必要があるただのタイプに関するリソースです。 高度なアプリケーションをサポートするのに必要なミドルウェアサービスと要件のセットは、それが含むビジョンによって定義されて、以下などの領域でアプリケーションを結合します。 分散コンピューティング(分散形データベース)はビデオサービスを進めました、teleimmersion(すなわち、例えば、CAVE技術に基づく仮想環境の無視できない現実の経験を提供するための能力)、触覚学による拡大、電子商取引、遠隔教育、対話的な協力的な研究; 事実上、管理している多量のオンライン科学的施設(例えば、顕微鏡、望遠鏡など)の使用、データ、計算、情報Grids、融通のきいて変形しているネットワークインフラ、プロキシ、およびエージェントを含む高い率計装(支えられたより60より多くのMByte/s)と電子永続的な存在(EPP)。 これらのアプリケーションの多くが、商品インターネットより現在配布しているアプリケーションに関する「最前線」であり、したがって、ユニークな要件を持っています。 ちょうどウェブが1990年代前半の高度なアプリケーションであったように、上で定義された応用分野の多くがもっとも近い将来において平凡にならないでしょう。 しかしながら、彼らには皆、ネットワークが使用されている方法を変える能力があります。
Aiken, et al. Informational [Page 6] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[6ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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.
私たちのインフラストラクチャの定義、ウェブとモザイクが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。 単一のミドルウェアインタフェースを通してまだアプリケーションにすべて調整されています。 セキュリティと効率のために、オンライン器具を使用する人はリアルタイムの分析の直接の結果が器具からそれを受け取るようにデータに働いたとき、デバイスを導いて、パラメタを変える能力を必要とします。 したがって、ネットワーク要件はミドルウェアを通してすべて調整しなければならない高帯域、低遅延、およびセキュリティを取り囲みます。 大容量データベース、アーカイブ、およびデジタルライブラリは研究者と産業のための大黒柱になっています。 それらがネットワークと、そして、ミドルウェアに置く要件は大規模になるでしょう、ほんのいくつかを命名するために認証、承認、アクセス管理、サービスの質、ネットワークでつながれた情報発見、検索ツール、命名、およびサービス位置のサポートを含んでいて。 また、彼らは、データを築き上げて、自己に説明する収集をサポートするためにミドルウェアを必要とします。 分散コンピューティング環境(例えば、グローバス、Condor、Legionなど)は急速に未来のコンピューティングと情報Gridsに発展しています。 これらのGridsは適応型の、そして、処理しやすいネットワーク・サービスを必要とするだけではなく、使用への簡単な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.
多くのアプリケーション開業医はまた彼らが能力を必要とした金剛不懐がサービスを「通り抜ける」ということでした。 これがミドルウェアを迂回させて、直接オペレーティングシステムかネットワークなどの基本的なインフラストラクチャにアクセスする能力を示す、)、彼らは、ミドルウェアサービスを利用して、見ることを切望していましたが、それの以上は、それら自身のアプリケーションをサポートするために展開しました。 さらに、認証、アクセスコントロール、およびセキュリティが前記のようにアプリケーションのすべてに必要です、異なったレベルで。
4.0 Exemplary Components
4.0 模範的コンポーネント
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
ミドルウェアについて説明して、関連問題について議論するその開発と展開に関連する試みでは、模範的サービスは議論のために選択されました。 これらのサービスは、議論と唯一のミドルウェアサービスを定義するどんな試みとしても刺激とならないように選ばれました。 また、他の標準化団体(例えば、DMTF)の既存のIETF取り組みかものをコピーするのではなく、むしろそれらの取り組みを利用するのが、この取り組みの意図であり、本当に
Aiken, et al. Informational [Page 7] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[7ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
highlight areas where work was already advanced to a stage that might be approaching deployment.
仕事が既に展開にアプローチしているかもしれないステージに進められた領域を強調してください。
5.0 Application Programming Interfaces and Signaling
5.0 アプリケーションプログラミングインターフェースとシグナリング
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.
アプリケーションは明らかに彼らの即座の用法の必要性に基づくリソースを要求する能力を必要とします。 これらの要求はネットワークマネージメントコントロールとネットワーク資源含意を関連づけました。 しかしながら、これらの要求の遂行は複数の途中経過を必要とするかもしれません。 ミドルウェア定義の予備の状態を考えて、一般的なフレームワークがない、アプリケーションが1セットの必要なネットワーク・サービスの必要性を示すまして付き添いのリソース要件と同様にサービスの品質と優先権を含むメソッドが現在、あります。 しかしながら、ミドルウェアに関するユーティリティを考えて、高度なアプリケーションのための特に最適化に関して、品質とサービスと資源管理の優先権の両方のための予備のモデルは、存在していて、発展し続けています。しかしながら、さらにミドルウェア豊富なインフラストラクチャの展開を遅らせるかもしれない複数の競争している規格の危険がこの領域の規格のための同意されたフレームワークなしであります。 このフレームワークは、たぶんメソッド、アクセス/入場コントロール、一連の定義されたサービス、およびリソースに合図するのを含むべきです。 SLA仕様には性能があるか、またはアプリケーションがSLAに違反するとき、さらに、それはサービスレベル、優先権問題、スケジューリング、サービス・レベル・アグリーメント(SLA)機能、およびアプリケーションかシステムに通知するためのフィードバック・メカニズムを含むべきです。 どんなそのようなメカニズムも以下のために能力を含意します。 1) タイプの政策の実施と実施との相互作用、2) 利用可能なネットワーク資源のダイナミックな査定、3) 方針モニター、4) サービス保証、5)紛争解決、および6) 性能の不足のための賠償。
Application programmers are concerned with minimizing the interfaces that they must learn to access middleware services. Thus the unification of common services behind a single API is of great interest to middleware users. Examples of common APIs that may be achievable are:
ミドルウェアサービスにアクセスすることを学ばなければならないことをインタフェースを最小にするのにアプリケーション・プログラマーを心配させます。 したがって、単一のAPIの後ろの共益サービスの統一はすごくミドルウェアユーザにおもしろいです。 達成可能であるかもしれない一般的なAPIに関する例は以下の通りです。
* Environmental discovery interface, whether for discovering hardware
resources, network status and capabilities, data sets,
applications, remote services, or user information.
* Remote execution interface, whether for distributed metacomputing
applications, or for access to a digital library presentation
service, or a Java analysis service.
* Data management interface, whether for manipulating data within
distributed caches, or replication of data between file systems, or
archival storage of data.
* ハードウェアリソースかネットワーク状態と能力か、データセットか、アプリケーションか、リモートサービスか、ユーザー情報を発見するためにか否かに関係なく、環境発見インタフェース。 * 分配されたmetacomputingアプリケーションか、デジタルライブラリプレゼンテーション・サービス、またはJava分析サービスへのアクセスにかかわらずリモート実行インタフェース。 * データ管理は連結します、分配されたキャッシュの中でデータを操作するか、またはファイルシステム、または記録保管所のデータ記憶の間のデータの模写にかかわらず。
Aiken, et al. Informational [Page 8] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[8ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
* Process management interface, whether for composing data movement
with remote execution, or for linking together multiple processing
steps.
* リモート実行によるデータ運動を構成するか、または複数の処理ステップを結びつけることにかかわらず工程管理は連結します。
6.0 IETF AAA
6.0 IETF AAA
The IETF AAA (authentication, authorization, and accounting) effort is but one of many IETF security initiatives. It depends heavily on a Public key infrastructure, which is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model).
IETF AAA(認証、承認、および会計)取り組みは多くのIETFセキュリティイニシアチブの1つにすぎません。 それは大いにPublicの主要なインフラストラクチャによります(RFC1422はそのようなモデルのひとりの例です)。さまざまな信頼/階層構造環境とさまざまな用法が環境であるとサポートするフレームワークはインフラストラクチャを提供されるつもりです。
The IETF AAA working group has recently been formed. IETF AAA working group efforts are focused on many issues pertaining to middleware, including defining processes for access/admission control and identification (process for determining a unique entity), authentication (process for validating that identity), authorization (process for determining an eligibility for resource requests/utilization) and accounting (at least to the degree that resource utilization is recorded). To some degree, AAA provides for addressing certain levels of security, but only at a preliminary level. Currently, AAA protocols exist, although not as an integrated model or standard. One consideration for AAA is to provide for various levels of granularity. Even if we don't yet have an integrated model, it is currently possible to provide for basic AAA mechanisms that can be used as a basis to support SLAs. Any type of AAA implementation requires a policy management framework, to which it must be linked. Currently, a well-formulated linking mechanism has not been defined.
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.
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.
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.
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 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.
Aiken, et al. Informational [Page 9] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 9] RFC 2768 A Report of a Workshop on Middleware February 2000
7.0 Policy
7.0 Policy
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.
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.
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.
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.
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.
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
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
Aiken, et al. Informational [Page 10] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 10] RFC 2768 A Report of a Workshop on Middleware February 2000
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).
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).
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.
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.
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.
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.
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.
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.
Aiken, et al. Informational [Page 11] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 11] RFC 2768 A Report of a Workshop on Middleware February 2000
8.0 Directories
8.0 Directories
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.
Directories are critical resource components that provide support to many other elements in the middleware environment, especially policy. As network-based environment evolves, it will no longer be viable to encode policy information directly into each individual application. The prevailing model in use today is for each application to store its view of a device's data (e.g., configuration) in its own private data store.These data include relevant information concerning network resources and services as well as clients wanting to use those resources (e.g., people, processes, and applications). The same resource (or aspects of that resource, such as its physical vs. logical characteristics) may be represented in several data stores. Even if the device is modeled the same way in each data store, each application only has access to its own data. This leads to duplication of data and data synchronization problems.
The promise of technologies like CIM and DEN is to enable each application to store data describing the resources that they manage in a single directory using a common format and access protocol. This results in the data describing the resource being represented only once. Defining a logically centralized common repository, where resources and services are represented in a common way, enables applications of different types to utilize and share information about resources and services that they use.
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.
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.
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:
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:
Aiken, et al. Informational [Page 12] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 12] RFC 2768 A Report of a Workshop on Middleware February 2000
- 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.
- 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.
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.
Containment can be used for many purposes, including associating roles with objects. This is critical in order to support a real world environment, where people and elements may assume different roles based on time or other context.Containment may also be used to provide different naming scopes for a given set of data.
Directories use attribute inheritance - subclasses inherit the attributes of their superclasses. This enables one to define generalized access control at a container (e.g., a group) and then refine the access control on an individual basis for objects that are inside that container (e.g., different objects have different access privileges).
Directories use attribute inheritance - subclasses inherit the attributes of their superclasses. This enables one to define generalized access control at a container (e.g., a group) and then refine the access control on an individual basis for objects that are inside that container (e.g., different objects have different access privileges).
Currently, directories are used mostly to represent people, servers, printers, and other similar objects. CIM, DEN, and other similar efforts have encouraged directories to be used to contain common objects in a managed environment. For networked applications, this enables clients of the network (e.g., users and applications) to be bound to services available in the network in a transparent manner. The "Grid" community is making extensive use of directory services for this purpose, using them to maintain information about the structure and state of not only networks but also computers, storage systems, software, and people. The DMTF is using directories to contain CIM and DEN information, which enables a common information model to be applied to objects in a managed environment. The IETF is using directories for many different purposes, not the least of which is to contain common policy information for users and applications of an environment, as well as services and configuration information of network devices.
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.
Aiken, et al. Informational [Page 13] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 13] RFC 2768 A Report of a Workshop on Middleware February 2000
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 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.
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.
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.
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.
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.
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.
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
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
Aiken, et al. Informational [Page 14] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 14] RFC 2768 A Report of a Workshop on Middleware February 2000
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.
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.
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.
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.
9.0 Resource Management
9.0 Resource Management
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.
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
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
Aiken, et al. Informational [Page 15] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 15] RFC 2768 A Report of a Workshop on Middleware February 2000
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.
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.
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.
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).
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).
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.
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.
Aiken, et al. Informational [Page 16] RFC 2768 A Report of a Workshop on Middleware February 2000
Aiken, et al. Informational [Page 16] RFC 2768 A Report of a Workshop on Middleware February 2000
10.0 Networked Information Discovery and Retrieval Services
10.0 Networked Information Discovery and Retrieval Services
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.
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はUniform Resource Identifier(URI)のために構文を定義する際にかなりの仕事をしました。(Uniform Resource Identifierはさまざまな政府機関によって管理された永続的な名前空間であることを意図します)。 URIはレゾルバサービスを利用することでURLに決議されています。 そのようなレゾルバサービスのための多くの異なった提案があります、そして、いくつかの実装がCNRI Handler Serviceなどのように存在しています。 多くの組織が、URI名前空間を確立して、管理し始めています、著しくそれらのDigital Object Identifier(DOI)がある出版共同体。しかしながら、多くの未解決の問題があります、どう最も効果的にURIによって指定されたリソースがネットワークの複数の場所に存在する(例えば、ネットワークの接続性とリソースの有用性に関して「最も近い」鏡を見つけてください)ところに時局に処するのなどように。 レゾルバの周りに大規模なセットのインフラストラクチャの必要があります、識別子がどうリソースが登録されていて、割り当てられてデータの特定のURIによって特定されるリソースの現在の位置に関する進行中の管理と、様々な名前空間へのレゾルバのセットの操作であるかを含んでいて。 最終的に人は、URIを考えて、その名前空間に関連づけられるレゾルバサービスの場所を見つける必要があります。 IETFはURI名前空間のために解決サービス位置に対する初期の仕事をしました。
URIs are intended to be processed primarily by machines; they are not intended to necessarily be easy to remember, though they are intended to be robust under transcription (not sensitive to whitespace, for example). More recently, the IETF has begun work on defining requirements for human friendly identifier systems that might be used to register and resolve mnemonic names.
主としてマシンによってURIが処理されることを意図します。 覚えているのがそれらが必ず簡単であることを意図しません、転写で強健であることを(例えば、空白に敏感でない)意図しますが。 より最近、IETFは簡略名を登録して、決議するのに使用されるかもしれない人間の好意的な識別子システムのための要件を定義することに対する仕事を始めました。
Another set of issues revolves around various types of metadata - descriptive, ratings, provenance, rights management, and the like, that may be associated with objects on the network. The Resource Description Framework (RDF) from the Worldwide Web Consortium (W3C) provides a syntax for attaching such descriptions to network objects and for encoding the descriptions; additional middleware work is needed to locate metadata associated with objects that may be stored in repositories, and to retrieve such metadata. Validation of metadata is a key issue, and both IETF and W3C are working on XML
もう1セットの問題は様々なタイプに関するメタデータを中心題目とします--描写的です、格付け、起源はネットワークのオブジェクトに関連するかもしれない管理、および同様のものを正します。 WorldwideウェブConsortium(W3C)からのResource記述Framework(リモート・データ・ファシリティ)はそのような記述をネットワークオブジェクトに付けて、記述をコード化するための構文を提供します。 追加ミドルウェア仕事が、倉庫に保存されるかもしれないオブジェクトに関連しているメタデータの場所を見つけて、そのようなメタデータを検索するのに必要です。 メタデータの合法化は主要な問題です、そして、IETFとW3Cの両方がXMLに動いています。
Aiken, et al. Informational [Page 17] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[17ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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.
メタデータ主張に署名するのに公開鍵認証基盤に関連して使用できるcanonicalizationアルゴリズム。 しかしながら、そのようなアプローチは複雑な信頼関係、管理される必要がある階層構造、および検索におけるこれらの信頼関係の使用に指定される必要がある方針を含意します。
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).
権利管理などの応用のために様々なタイプに関するメタデータを定義しながら先に入る特定の仕事があります。 結局、これはミドルウェアサービスの開発を含意するでしょう。 また、それはこの情報のストレージ、アクセス、および検索におけるディレクトリ、データベース、および同様のサービスの使用に影響を与えるでしょう。 同様に、サービスが描写的であるメタデータと識別子(URNs)を接続する必要があるでしょう。
(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-proceedings/EU-NSF/metadata.ps http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.pdf のメタデータ研究課題に関するNSF/ERCIMレポートを見てください。
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.
最終的に、既にアーチーやハーベストなどのサービスと統合された研究を当てにする1セットのミドルウェアサービスの必要があります。 必ずそれらのサービスを検索して、点検するというわけではなくて、これらのサービスはネットワーク情報オブジェクトの、そして、サービスのコンテンツに関するメタデータの効率的な抽出を可能にします。 これは「エージェントに索引をつけ」ながら急ぐ能力かそのようなインデックスを計算するためにサイトで稼働できる"knowbots"を含んでいます、適切なセキュリティと認証規制で。 また、さらに、複数のサイトからメタデータを集めて、フィルターにかけて、集めて、関心があるアプリケーションにそれらを提供する1セットの「プッシュベース」のブローカーサービスが必要です。 そのようなサービスは今日のwebcrawlerベースの索引作成業務のための大規模な性能、品質、包括性、およびタイムリー改良を提供できます。
11.0 Network QoS
11.0 ネットワークQoS
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
より早く注意されるように、アプリケーションが、あるタイプに関するコミュニケーションのためのそれらの必要条件を満たすために明らかにネットワークで利用可能なリソースを要求する必要があるかもしれませんか、または提供するために帯域幅、ジターなどの1か測定基準の適切な保証で潜在、および損失を修理してください。 最近多くの取り組みの焦点である1つのタイプの要求はベストエフォート型を超えたサービスのためのものです、特にIPをひくサービスに関して。 以前に(例えば、想像とteleimmersion)下側の帯域幅か声とビデオがデータで共同混ぜられている声、ビデオ、特に声、およびビデオ操作の現れている重要性と同様に注意された高度なアプリケーションには、これは特に重要です。 この問題の見解が複数の低下の効果であると考えることになっている1
Aiken, et al. Informational [Page 18] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[18ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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.
独身のRTTでは、どれが、TCPアプリケーションに壊滅的ですが、リアルタイムのトラフィックのためのどんな特別な意味のものでないかもしれないか。 さまざまなサービスの質(QoS)とクラスのサービス(CoS)メカニズムを通して改良されたサービスに備えるのを実行できます。第1代IETFモデルはIntegrated Services(IntServ)モデルでした。(そのモデルはシグナル伝達機構としてRSVPを使用しました)。 このモデルが、あらゆるルータにおける州があらゆるセッション、交通の流れを管理するのを必要とするので、一般に、それはスケーリング限界を持つために認識されます。 しかしながら、ある状況に、それは非常に適切です。
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.
差別化されたServices、またはDiffServがIETF IntServモデルに関する知覚されたスケーラビリティ問題に対して反応から成長しました。 DiffServは、インターネットでスケーラブルなサービスが分化であると実装するためのアーキテクチャです。 スケーラビリティは、IP-層のパケットマークの使用でトラフィックに集めることによって、達成されます。 パケットは、それらの経路に沿ったノードで1ホップあたり1つの特定の推進の振舞いを受けるために分類されて、マークされます。 洗練された分類、マーク、取り締まり、および成形操作はネットワーク限界かホストで実装されるだけでよいです。 トラフィックがどのように差別化されたサービスできるネットワークへのエントリーをマークされて、条件とするか、そして、そのトラフィックがそのネットワークの中でどのように送られるかを治める方針に食糧を供給するサービスでトラフィックストリームにネットワーク資源を割り当てます。 これらの簡単なPHBsは方針をはるかに多く取り締まると広くてフレキシブルな範囲のサービスを提供するためにネットワーク縁で実施される結合されます、状態かコアで実行されるという複雑な推進決定と分配層を必要としないで。
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.
最近、RSVPのDiffServできるネットワークの上で「トンネル」であるという考えは重要な関心を呼びました。 これは、それぞれの損失を緩和している間、IntServとDiffServの両方の最も良い特徴を結合するのを試みます。 これは、IETFがDiffervとInteservも共存できるだけではありませんが、また、共同利用できるのを保証する方法を研究するように順番に導きました。
The practical realization of either or both architectures depends on many middleware components, some of which are described in this document. The workshop discussion mainly focused on DiffServ mechanisms and on what effect such mechanisms would have on middleware and its ability to monitor and manage the network infrastructure for the benefit of the applications. Both IntServ and DiffServ only fully make sense if linked to a policy mechanism. This mechanism must be able to make policy decisions, detect and resolve conflicts in policies, and enforce and monitor policies.
どちらかかアーキテクチャの両方の実用的な実現は多くのミドルウェアの部品に依存します。その或るものは本書では説明されます。 ワークショップ議論はアプリケーションの恩恵のためにDiffServメカニズムとどんな効果でメカニズムがミドルウェアの上に持っているそのようなものとネットワークインフラをモニターして、管理するその性能に主に焦点を合わせたか。 方針メカニズムにリンクされる場合にだけ、IntServとDiffServの両方が完全に理解できます。 このメカニズムは、方針を政策決定をして、方針で闘争を検出して、解決して、実施して、モニターできなければなりません。
Workshop participants almost unanimously agreed that they also required a scalable inter-domain resource manager (e.g., a bandwidth broker). Currently, if an RSVP session is run, each router along a
講習会参加者は、また、彼らがスケーラブルな相互ドメイン資源管理プログラム(例えば、帯域幅ブローカー)を必要としたのにほぼ満場一致して同意しました。 現在のaに沿った各ルータRSVPセッションが実行されるなら
Aiken, et al. Informational [Page 19] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[19ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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.
経路は各ホップの流れの取り締まりにかかわるようになります。 帯域幅Brokerモデルはその後のルータが集合流れに対処するだけでよいように最初のホップにおける集合流れを述べさせること取り締まりに備える帯域幅ブローカー、政策決定ポイント(コントロールと方針入場を決定させる)、および方針実施ポイント(すなわち、縁のルータ)を入れます。
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.
また、Bandwidth Brokerモデルが(例えば、COPS、Diameter、および他のもの)であると実装するのに使用できたIETFプロトコルについて議論しました。 Diameterプロトコルはこのような関係においてはおもしろいです、QoSが向けられたものを様々なタイプの帯域幅ブローカー実装に任意のallocations.これらのすべてを使用できるのと同じくらいよく含む基本的なネットワーク資源配分と再配分のためにセットをメカニズムに供給するので、RSVPタイプ情報を使用して。 直径は、現在経路情報を提供しませんが、代わりにイングレスで確立されたネットワーク小道情報と出口ノードを当てにします。 しかしながら、Diameterの状態は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.
どんなタイプのBandwidth Brokerモデルも実装するために、方針交換のためにメカニズムを確立するのが必要です。 Internet2のQboneワーキンググループは、現在、プロトタイプ相互ドメイン帯域幅ブローカーシグナリングプロトコルを定義するために働いています。 この仕事はIETF取り組みで調整されています。
Another mechanism is required for traffic shaping and SLA policing and enforcement. One mechanism is fair queuing in its various forms, which has been described as TDM emulation without the time and space components. Techniques have been used for several years for fair queuing for low speed lines. For DS-3 with 40 byte packets and OC-3c speeds with 200-byte packets, weighted fair queuing uses a deficit round-robin algorithm that allows it to scale. It is capable of flow discrimination based on stochastically hashing the flows. An additional expansion of this technique is to preface this technique with class indicators. Currently, classification techniques are based on IP precedence. However, classification will soon be achieved in many routers using Diffserv code points (DSCPs) to specify the type of conditioning to be applied. The complete requirements of policing for DiffServ implementations, e.g., via bandwidth brokers, have not yet been fully explored or defined.
別のメカニズムがトラフィック形成、SLAの取り締まり、および実施に必要です。 1つのメカニズムは様々なフォームで公正な列を作りです。(その列を作りは時間と空間成分なしでTDMエミュレーションとして記述されています)。 テクニックは低速系列のための公正な列を作りに数年間使用されています。 200バイトのパケットがある40バイトのパケットとOC-3c速度があるDS-3のために、均等化キューイングはそれが比例する赤字連続アルゴリズムを使用します。 確率的に流れを論じ尽くすことに基づいてそれは流れ区別ができます。 このテクニックの追加拡張はクラスインディケータでこのテクニックについて前書きすることになっています。 現在、分類のテクニックはIP先行に基づいています。 しかしながら、分類は、すぐ、多くのルータで適用されるために調節のタイプを指定するのに、Diffservコード・ポイント(DSCPs)を使用することで達成されるでしょう。 DiffServのために例えば、帯域幅ブローカーを通して実装を取り締まる完全な要件は、まだ完全に調査もされませんし、定義されてもいません。
Aiken, et al. Informational [Page 20] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[20ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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.
ミドルウェアとアプリケーションがサービスであるとサポートするネットワーク監視能力(すなわち、ミクロとマクロレベルの州の情報のためにネットワークについて質問する)がコア要件として特定されました。 事実上、ネットワーク計装と測定インフラストラクチャ(1セットのインテリジェントネットワーク管理ミドルウェアサービスを組み込むことができる)は絶対に重要です。
Current mechanisms (e.g. ICMP, SNMP) were not deemed robust enough for middleware and applications developers to determine the state of the network, or to verify that they were receiving the specific type of treatment they had requested. This was judged especially true of a network providing QoS or CoS. Indeed, it is not at all clear that SNMP, for example, is even the right architectural model for middleware to use to enable applications to determine the state of the network. Other capabilities, such as OcxMon, RTFM, new MIBs, and active measurement techniques (e.g., IPPM one-way delay metrics) need to be made available to middleware services and applications.
現在のメカニズム(例えば、ICMP、SNMP)はミドルウェアとアプリケーション開発者がネットワークの事情を決定するか、または彼らが彼らが要求した処理の特定のタイプを受けていたことを確かめるほど強健であると考えられませんでした。 これはネットワークがQoSかCoSを提供することに関して特に本当であると判断されました。 本当に、警報解除では、例えば、SNMPはミドルウェアがアプリケーションがネットワークの事情を決定するのを可能にするのに使用する正しい建築モデルになりさえしません。 OcxMonや、RTFMや、新しいMIBsや、アクティブな測定技術などの他の能力(例えば、IPPMの一方向遅れ測定基準)は、ミドルウェアサービスとアプリケーションに利用可能に作られている必要があります。
The provisioning of differentiated services takes the Internet one step away from its "dumb" best effort status. As the complexity of the network increases (e.g. VPNs, QoS, CoS, VoIP, etc.), more attention must be paid to providing the end-user/customer or network administrator with the tools they require to securely and dynamically manage an adaptable network infrastructure. Differentiated services means that theoretically some traffic gets better service than other traffic; subsequently, one can expect to pay for better service, which means that accounting and billing services will be one of the important middleware core components that others will rely upon. The model and protocols necessary to accomplish this are not developed yet.
差別化されたサービスの食糧を供給するのは1ステップでベストエフォート型「馬鹿な」状態からインターネットを取り除きます。 ネットワークの複雑さが(例えば、VPNs、QoS、CoS、VoIPなど)を増強するのに従って、彼らがしっかりと、ダイナミックに融通のきくネットワークインフラを管理するのを必要とするツールにエンドユーザ/顧客かネットワーク管理者を提供するのにより多くの注意を向けなければなりません。 理論的に何らかのトラフィックが他のトラフィックより良いサービスを得る差別化されたサービス手段。 次に、人は、より良いサービスの代価を払うと予想できます。(サービスは会計と支払いサービスが他のものが当てにする重要なミドルウェアコア構成要素の1つになることを意味します)。 これを達成するのに必要なモデルとプロトコルはまだ開発されていません。
12.0 Authentication, Authorization, and Accounting
12.0 認証、承認、および会計
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,
IETFのAAAワーキンググループはアクセスの認証、承認、会計、および監査をサポートするための要件に集中していて、ネットワーク資源マネージャ(例えば、帯域幅ブローカー)でサービスは提供しました。 これらのプロセスはミドルウェアとアプリケーションで当てにされる重要なセキュリティインフラストラクチャを構成します。 しかしながら、これらのコンポーネントは基本的なセキュリティコンポーネントにすぎません。 公開鍵認証基盤(PKI)は重要なセキュリティー・サービスインフラストラクチャコンポーネントとして特定されました。 例えば、PKIは適切であるところの認証、承認、アクセスコントロール、会計、および支払いの推移性をサポートしなければならないでしょう。 グループセキュリティに対処する問題とことによるとより効率的で簡単な経営者側以外に、このときPKIサポート構造の広いスケール展開を防ぐどんな本当の技術的難関もないことに注意されました。 代わりに、克服する主な障害は、現実にほとんど政治上であって、経済です。 しかしながら
Aiken, et al. Informational [Page 21] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[21ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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.
追加ミドルウェアが、PKIをよりよく容易にするのに必要であるかもしれません。 それが言われていて、何人かの人々が、2つの例であるグループ会員資格を変えることに関して私たちにはいくつかの大きい技術的なセキュリティ挑戦、取消しリスト、およびセキュリティがあると信じています。
Middleware and security support is also required for newer applications (e.g., proxy agents that would act on a process or application's behalf and gather the necessary certificates for access and using resources). A particularly difficult example is remote collaboration. Accessing a particular resource may require a user and/or application to gather certificates from more than one policy- controlling agent. It is also true that an entity may have various identities that are dependent on the task they are performing (usage or role based) or the context of the application. In order for the PKI to become truly functional on a ubiquitous level, there needs to exist a set of independent signing authorities that can vouch for the top-level certificate authorities.
また、ミドルウェアとセキュリティサポートが、より新しいアプリケーション(例えば、プロセスかアプリケーションの利益に影響して、アクセスとリソースを使用するための必要な証明書を集めるプロキシエージェント)に必要です。 特に難しい例はリモート共同です。 特定のリソースにアクセスするのは、エージェントを監督しながら1つ以上の方針から証明書を集めるためにユーザ、そして/または、アプリケーションを必要とするかもしれません。 また、実体にはそれらが実行しているタスク(用法か基づく役割)かアプリケーションの文脈に依存する様々なアイデンティティがあるのも、本当です。 PKIが本当に、遍在しているレベルで機能的になるように、トップレベル認証局を保証できる1セットの独立している署名当局は、存在する必要があります。
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、IntServ、帯域幅ブローカー、ディレクトリで可能にされたネットワークなど)で比較的馬鹿なネットワーク(例えば、ベストエフォート型IP)からインターネットまで移行するとき、情報の安全な交換はさらに重要になるでしょう。 さらに、私たちが差別化されたサービスを提供し始めるのに従って、会計と統計集会ははるかに重要になるでしょう。 また、私たちは、保全、ネットワークマネージメントを集めて、分析して、輸送するセキュリティ、およびモニターしている情報に備える必要があります。 そして、データプライバシーの問題とサービスと非拒否の否定を扱うのに伴う保全を無視できません。
13.0 Network Management, Performance, and Operations
13.0 ネットワークマネージメント、パフォーマンス、および操作
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
両方をアクティブで受け身のネットワーク統計とエンドユーザにとって、利用可能な情報にするのは焦点を合わせる多くの顕微鏡の、そして、巨視的なネットワークマネージメントプロジェクトがあります。 現在の視力
Aiken, et al. Informational [Page 22] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[22ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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に新しい要件を置くでしょう。
14.0 Middleware to support multicast applications
14.0 マルチキャストアプリケーションをサポートするミドルウェア
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パケットのルーティングと推進)は、あります。 また、基本的なネットワーク・サービスであるとインターネットGroup Multicastプロトコル(マルチキャストグループの接合と退出を管理する)を考えることができました。 しかしながら、マルチキャストが様々なアプリケーションのためにミドルウェアサービスによってuseableされる物凄い必要があります、IPアプリケーションをuseableさせる際にTCPが重要な役割を果たしたように。 明確に、人は、合理的にミドルウェアサービスに認証されたマルチキャストサービスのコントロールを提供して欲しいかもしれません。 これらのサービスに関する例はマルチキャストグループの作成と接合を含んでいます、マルチキャストアドレス管理、マルチキャストチャンネルディレクトリ(既に、かなりの仕事がこの領域にあった)、様々な形式の信頼できるマルチキャストサービス(これはIRTF研究領域である)、そして、マルチキャストを保証するのは様々な暗号の戦略で分類されます。 さらに、特にQoSに関連して、マルチキャストがネットワークに持つことができる大きい影響力のために、マルチキャスト管理ミドルウェアサービスが、直接マルチキャストルーティング情報を交換しない様々なネットワークの中でマルチキャスティングを結びつけるのにサービスのように必要でしょう。 しかしながら、マルチキャストのいくつかの安全保障問題(特にダイナミックな会員資格方針があるグループ)が、まだ決議される必要に注意されるべきです。
Aiken, et al. Informational [Page 23] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[23ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
15.0 Java and Jini
15.0 Javaとジニー
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を使用することで書かれたミドルウェア)のサポートに、ジャバ言語とコンパイラが重要であるということでした。 また、どんなオペレーティングシステムやネットワークOSもミドルウェアであると考えられるほどミドルウェアであるとシステムに見つけられた仮想のJavaマシンを考えることができます。 ジニーミドルウェア技術が発見のために1セットのプロトコルを定義するだけではなくて、接合してください、ダイナミックなネットワークでつながれた環境に弾力を提供するルックアップ、賃貸借契約、およびトランザクションメカニズムだけも Javaとジニーは特に署名しているアプレットにおいて機能しているPKIに依存するようになるでしょう。 それが言われていて、扱われる必要があるJavaとジニーの両方がある安全上の配慮があります、アプレットとサーブレットのダウンロードを許すのなどように。
16.0 Security Considerations
16.0 セキュリティ問題
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.
このドキュメントはセキュリティが一般的なテーマであったワークショップのレポートです、ドキュメントから終えたセキュリティの参照で見ることができるように。 しかし、ワークショップは新しいセキュリティ関連の用語のための少しの特定の推薦にも達しませんでした。
17.0 Summary
17.0 概要
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
ミドルウェアには、永続的なインフラストラクチャで存在するだけであるコンポーネントとサービスがあるかもしれませんが、また、それは複数の自治の管理ドメインの向こう側に終わりから終わり(すなわち、主催するアプリケーションかホストへの適用)への相互作用を可能にして、サポートするコンポーネントを持つでしょう。 1セットのコアの永続的なミドルウェアサービスが、集めることができるか、またはアプリケーションが基づくより豊かなミドルウェアサービス(例えば、たまねぎか層にされたモデル)の開発をサポートするのに必要です。 このセットのコアミドルウェアサービスは、アプリケーションがアプリケーションを可能にするのに伴う基本的なネットワークインフラがネットワークへの変化で適応するサービスと能力を利用するのを助けるでしょう。 アプリケーションかプロセスによって利用されたそのような特定のサービスはアプリケーション分野かアフィニティー・グループ(例えば、ネットワークマネージメントか高エネルギー物理学アプリケーション)願望がネットワークか分散データ/計算インフラストラクチャを利用するという要件の機能になるでしょう。 このドキュメントは基本的、そして、コアミドルウェアサービスのいくつかについて議論します。(以下に含んでいますが、サービスは限られていません)。 ディレクトリ、名前/アドレス解決サービス、セキュリティー・サービス(すなわち、認証、承認、会計、およびアクセスコントロール)(ネットワークマネージメント)はモニター、時間サーバ、および会計をネットワークでつなぎます。 マルチキャストやDiffServなどのネットワークレベル能力がありません。
Aiken, et al. Informational [Page 24] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[24ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
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.
ミドルウェアとして、分類されます。 むしろ、彼らはミドルウェアがミドルウェアが組立てられるか、利用して、または管理するかもしれないインフラストラクチャサービスを可能にしています。 第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.
認識された目標は、基本的なネットワークインフラのアクセスと管理を可能にする1セットのミドルウェアサービスを提供して、そのネットワークベースのインフラストラクチャを利用したがっているアプリケーションを支持することです。 サポート、食糧を供給することおよび操作のためのサービス、およびネットワークの経営の枠組みに同意するのは必要に見えます。 今日、私たちには、様々な規格組織で既に追求されるばらばらの活動があります。 これらはIETFとDMTF(例えば、AAA、Policy Framework、DiffServ、DEN、CIMなど)、および高度なアプリケーション環境(例えば、Grid Forum、PACIs、NGI、Internet2など)に努力を含んでいます。 これらの努力の両方がネットワークだけではなく、多くのインフラストラクチャコンポーネントを統合と管理に要求します。 しかしながら、私たちには、これらの活動のすべてを調整するために一緒にこれらのすべて、またはメカニズムを引くどんな総合的な枠組みもありません。 私たちはただ豊かなミドルウェアサービスのプランの開発を始めています。 その結果、私たちには、まだ行われていない多くの仕事があります。 例えば、電子しつこい存在(EPP)環境にアイデンティティか人(または、彼らのプロキシエージェントさえ)の複数の例が支持されるところに移るとき、私たちは、高められたロケータとサービスを仲介するのを必要とするつもりです。 このタスクには、今日のディレクトリ(例えば、DNSかX.500)とロケータサービスは適切でないかもしれません。
One goal of the workshop was to identify research and development areas in middleware that federal agencies and industry may choose to support. The workshop highlighted a few areas that may benefit from additional R&D support. These areas include, but are not limited to:
ワークショップの1つの目標は連邦機関と産業が支えるのを選ぶかもしれないミドルウェアの研究開発領域を特定することでした。 ワークショップは追加研究開発サポートの利益を得るかもしれないいくつかの領域を強調しました。 含んでいますが、これらの領域は制限されません:
- inter-domain resource management architecture and protocols (e.g.,
inter-domain bandwidth brokers)
- resource languages that describe and enable the management of a
wide variety of resources (e.g., networks, data bases, storage,
online facilities, etc.
- avoiding deadlock and ensuring efficiency with resource managers
- network management tools and APIs that provide macroscopic and
microscopic real-time infrastructure
- information to middleware services and applications (not just MIBs
and SNMP access)
- domain and inter-domain accounting and billing
- monitoring and verification services of contracted infrastructure
services
- enhanced locators that can locate resources and resource managers
- 相互ドメインリソース管理体系とプロトコル(例えば帯域幅が仲介する相互ドメイン)--、さまざまなリソースの管理を説明して、可能にするリソース言語、(例えば、ネットワーク、データベース、格納、オンライン施設など; - 行き詰まりを避けて、資源管理プログラムで効率を確実にします--巨視的で顕微鏡のリアルタイムのインフラストラクチャを提供するネットワークマネージメントツールとAPI--ミドルウェアサービスとアプリケーション(MIBsとSNMPアクセスであるだけではない)への情報--ドメインと相互ドメイン会計と支払い(収縮したインフラストラクチャサービスのモニターと検証サービス)はリソースと資源管理プログラムの場所を見つけることができるロケータを機能アップしました。
Aiken, et al. Informational [Page 25] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[25ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
- 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
- 施政方針交渉と認証に交差してください--、ミドルウェア迂回、(すなわち、生のシステムかネットワーク資源メタデータ(すなわち、ディレクトリで見つけられるか、または資源管理プログラムやPDPsやPEPsやディレクトリや会計や支払いサービスなどのサービスの間で交換されたデータについて説明するのに使用されるデータ)(可動の、または、遊牧民的な使用のミドルウェアサポート)にリソースの有用性のサポートにアクセスしてください、(すなわち、模写とロードバランシング
This workshop was just one small step in identifying relevant middleware topics, technologies and players. Even though this workshop did not arrive at a consensual definition of middleware, it did identify the need for additional work. Specifically, further work is needed to identify and qualify middleware services for specific affinity groups (e.g. Internet2, Education, the PACIs, Grids, etc.) as well as to define a macroscopic framework that incorporates the middleware work of the IETF, DMTF and other relevant organizations such as the Grid Forum.
このワークショップは関連ミドルウェア話題、技術、およびプレーヤーを特定することにおいて小さいちょうど1ステップでした。 このワークショップはミドルウェアの合意している定義に到達しませんでしたが、それは追加仕事の必要性を特定しました。 明確に、さらなる仕事が、特定のアフィニティー・グループ(例えば、Internet2、Education、PACIs、Gridsなど)としてミドルウェアサービスを特定して、資格を与えて、Grid ForumなどのIETF、DMTF、および他の関連組織のミドルウェア仕事を取り入れる巨視的な枠組みを定義するのに必要です。
18.0 Participants
18.0 関係者
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
edu>、ジョージ Brett <ghbrett@mindspring.com 、gt;、リッシュ Carlson <racarlson@anl.gov 、gt;、ブライアンCarpenter<bcarpent@uk.ibm.com>、チャーリー Catlett <catlett@ncsa.uiuc.edu 、gt;、ビルチェン<wtcheng@us.ibm.com>、キム Claffy <kc@caida.org 、gt;、ビル Decker <Wdecker@nsf gov>、クリスティン Falsetti <cfalsetti@arc.nasa.gov 、gt;、イアンフォスター<里子@mcs.anl.gov>、アンドリュー Grimshaw <grimshaw@cs.virginia.edu 、gt;、エドグロースマン<egrossma@ncsa.uiuc.edu>、テッド Hanss <ted@internet2.edu 、gt;、ロン Hutchins <ron@oit.gatech.edu 、gt;、ラリー Jackson <jackson@ncsa.uiuc rn@us.ibm.com 、gt;、ビル Nitzberg <nitzberg@nas.nasa.gov 、gt;、Hilarie Orman <ho@darpa.mil 、gt;、ジョン Schnizlein <jschnizl@cisco.com 、gt;、リックスティーブンス<stevens@mcs.anl.gov>、ジョン Strassner <johns@cisco com>、ベン Teitelbaum <ben@advanced.org 、gt;、ジョージ Vanecek <g.vanecek@att.com 、gt;、ケンKlingenstein<ケンタッキー州Klingenstein@Colorado.EDU>、アービンド Krishna <akrishna@us.ibm.com 、gt;、ディリップKandlur<kandlur@us.ibm.com
Aiken, et al. Informational [Page 26] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[26ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
19.0 URLs/references
19.0のURL/参照箇所
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 を見てください。
20.0 Authors' Addresses
20.0 作者のアドレス
Editor: Bob Aiken
EMail: raiken@cisco.com
エディタ: ボブエーケンEMail: raiken@cisco.com
Authors:
作者:
Bob Aiken Cisco Systems, Inc. 6519 Debold Rd. Sabillasville, Md. 21780 USA
ボブエーケンシスコシステムズInc.6519Debold通り Sabillasville、メリーランド州 21780 米国
Phone: +1 301 271 2919 EMail: raiken@cisco.com
以下に電話をしてください。 +1 2919年の301 271メール: raiken@cisco.com
John Strassner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ジョンStrassnerシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: +1 408 527 1069 EMail: johns@cisco.com
以下に電話をしてください。 +1 1069年の408 527メール: johns@cisco.com
Brian E. Carpenter IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire SO21 2JN, UK
mp185、ブライアンE.大工IBMイギリスの研究所Hursley Parkウィンチェスター、ハンプシャーSO21 2JNイギリス
EMail: brian@hursley.ibm.com
メール: brian@hursley.ibm.com
Ian Foster Argonne National Laboratory The University of Chicago Argonne, IL 60439 USA
イアンフォスターアルゴンヌ国立研究所シカゴ大学アルゴンヌ、IL60439米国
Phone: +1 630 252 4619 EMail: foster@mcs.anl.gov
以下に電話をしてください。 +1 4619年の630 252メール: foster@mcs.anl.gov
Aiken, et al. Informational [Page 27] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[27ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
Clifford Lynch Coalition for Networked Information 21 Dupont Circle Washington, DC 20036
デュポンサークルワシントン、ネットワークでつながれたInformation21DC 20036へのクリフォードリンチ連合
Phone: +1 202 296 5098 EMail: cliff@cni.org
以下に電話をしてください。 +1 5098年の202 296メール: cliff@cni.org
Joe Mambretti International Center for Advanced Internet Research 1890 Maple, Suite 150 Northwestern University, Evanston, Illinois 60201
国際ジョーMambrettiは1890年の研究カエデ、スイート150ノースウェスタン大学、エバンストン、イリノイ 60201を高度なインターネットの中心に置きます。
Phone: +1 847 467 3911 EMail: j-mambretti@nwu.edu
以下に電話をしてください。 +1 3911年の847 467メール: 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、ドライブラ・ホーヤ、ギルマンカリフォルニア92093-0505の米国のM.C.0505 9500
EMail: moore@sdsc.edu
メール: moore@sdsc.edu
Benjamin Teitelbaum Advanced Networks & Services, Inc.
ベンジャミン・タイテルバウム高度なネットワークとサービスInc.
EMail: ben@internet2.edu
メール: ben@internet2.edu
Aiken, et al. Informational [Page 28] RFC 2768 A Report of a Workshop on Middleware February 2000
エーケン、他 情報[28ページ]のRFC2768 ミドルウェア2000年2月に関するワークショップのレポート
21.0 Full Copyright Statement
21.0 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Aiken, et al. Informational [Page 29]
エーケン、他 情報[29ページ]
一覧
スポンサーリンク
