rfc2768.txt

中、英文RFC文档大全打包下载完全版 .

   computing and networking resources, including libraries and utilities
   for resource discovery, scheduling and monitoring, process creation,
   communication and data transport.

   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.

   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



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


   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:

   -  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.

3.0 Application Perspective

   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



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


   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.

   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.

   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

   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



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


   highlight areas where work was already advanced to a stage that might
   be approaching deployment.

5.0  Application Programming Interfaces and Signaling

   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.

   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:

   * 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.




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


   * Process management interface, whether for composing data movement
     with remote execution, or for linking together multiple processing
     steps.

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).

   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.