分布式osgi--rfc119文档翻译

摘要：
这篇RFC包括了RFPS 79和88中的需求的设计.这个设计为分布式OSGI处理流程定义了一个最小级别的特征(feature)和功能(function),包括外界环境(external environments)服务的发现和获取.这个设计的目的不是对其他分布式OSGI的设计持否定态度，也并不对基于其他外部的API(external api)，如：Jave EE，SCA,JBI等等这些api上所实现的分布式OSGI持否定态度（This solution is not intended to preclude any other solution and is not intended as an
alternative to Java EE, SCA, JBI, or any other external API set that may be mapped onto OSGi. ）。
0 文档信息
0.1 目录：（略）
0.2 专业术语和文档约定（不做翻译）
The key words "MUST", "MUST NOT", "REQUIRED",  "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as
described in [1].
0.3 文档更改历史信息（不做翻译）
1 简介
这篇RFC的目的是创建一个设计报告以满足RFPS 79和88中的需求，重点是在OSGI环境中定义一个可行的解决方案，这个解决方案为分布式OSGI流程提供给了一个最小级别的特征(feature)和功能(function)，它包括外界环境服务的发现和获取。尽管这个解决方案是为了促成外部系统（如SCA、java ee等等）和其相关技术之间的交互工作，这个设计的目的不是对其他分布式OSGI的设计持否定态度，同时也并不对其他特定外部系统(external api)，如：Jave EE，SCA,JBI等等这些外部系统做出选择。
这个解决方案的目的是为了给OSGI的开发者们提供一个分布式计算功能的最小集合(minimal set),而不需要学习而外的api和概念。换而言之，如果一个开发者熟悉OSGI编程模型，那么他们使用本解决方案去配置实现OSGI环境中的分布式计算
（RFPS 79和88中的需求），会非常自然和流利。如果开发者需要去使用更高级的分布式计算能力，他可以使用任何其他支持OSGI环境的api来替代本rfc中定义的分布式基本功能。
这篇rfc的内容是基于讨论在现有的OSGI环境下最小和最需要的扩展点，以实现下列目标：
  .一个部署在JVM中的bundle，这个bundle可以调用(invoke)另一个jvm中的service（包括远程计算机）（译者：这里指调用另一个jvm中的osgi服务）。
  .一个部署在JVM中的bundle，这个bundle可以调用另一个地址空间（包括远程计算机）中的服务（或者对象、或者存储过程等等  or object, procedure, etc.），并且这些服务部署在一个非OSGI环境下。（译者：这里指调用另一个jvm中的非osgi服务）
  .一个部署在其他JVM环境下的osgi服务（包括远程计算机），它可以找到并且获取一个在“本地”OSGI JVM中的服务（译者:这里指对于服务来说，本地和远程的服务使用上没有区别）
  .一个部署在非OSGI环境中的程序可以找到并且使用“本地”OSGI JVM中的服务(译者：这里对于本地的理解如上)
  基本假定包括以下两点：1.分布式获取的基本模型和目前OSGI编程模型一致；2.在大多数情况下分布式软件的使用可以通过配置和部署中的元数据.配置和部署元数据是基于抽象分布式计算能力中的SCA概念模型。本设计的目标是为了能和目前广为采用的分布式计算软件系统协同工作，比如Web services, CORBA, 或者 messaging等等。
  为了完成业务需求，现有的分布式计算技术在各种情况下广为使用。更进一步讲，我们首先要区分开两种对分布式的解决思想，一是用同一种分布式系统来做所有的交互，二是使用不同的分布式系统。当多种分布式系统被引进时，额外的元数据也会同时要求被携带进来，以保证配置的一致性和兼容性。
  本RFC没有定义任何新的分布式交互协议、数据和策略:它只是简单的定义了一个OSGI编程模型的扩展，和定义如何获取和加载模块的元数据，这些元数据为现有的分布式交互协议服务。
1.1 Open Items （不做翻译）
•  See bug list
1.2 专用术语 （暂时不做翻译，以免产生误解，以后补上）
  OSGi service platform: See OSGi core specification chapter 1.
  OSGi bundle: See OSGi core specification chapter 3 and 4.
  OSGi service: See OSGi core specification chapter 5.
  OSGi service registry: See OSGi core specification chapter 5.
  Component: A piece of code (e.g. similar to a Spring bean or a POJO) that is packaged and deployed in a bundle. （和SCA中的Component很像）
  Application: A set of bundles that are logically coupled to perform a common task. The bundles of this application don’t have to be deployed in the same service platform, but can be spread over multiple service platforms.
  Distribution software (DSW): A software entity providing functionality to an OSGi service platform that supports the binding and injection of services in other address spaces or across machine boundaries, using various existing software systems.
  Discovery service: A software entity providing functionality to an  OSGi service platform that supports the publishing and lookup of services in other address spaces or across machine boundaries, using various existing
discovery systems.
  Service consumer: A bundle which requires a service from other service platforms.
  Service provider: A bundle which provides a service to other service platforms.
1.3 符号列表
  下列图标用于以图型化的表示阐述分布式OSGI的设计原理 （目前不做翻译）

 

 

 

同时，还有一些uml符号在本文中使用，请查阅相关uml符号说明： www.uml.org

 

以下翻译以后将贴出来。

小记：

5.5.3 intents 定义

5.4 service registry hooks