摘要：
這篇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

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

分布式osgi--rfc119文檔翻譯