osgi框架的应用_OSGi enRoute – OSGi应用程序的新框架

最新推荐文章于 2021-06-02 18:28:34 发布

diluan6799

最新推荐文章于 2021-06-02 18:28:34 发布

阅读量611

点赞数

文章标签： spring java 大数据编程语言人工智能

OSGi enRoute是OSGi应用程序的新框架，它提供了μservice编程模型，强调动态性和模块化。框架允许开发人员创建高度模块化的组件，通过μservice动态交互。虽然OSGi具有强大的动态服务注册和发现能力，但其μservice模型对传统开发人员来说是一个挑战。OSGi enRoute简化了OSGi的使用，提供了完整的工具链、最佳实践和文档，以促进高效开发。项目旨在展示OSGi服务的优势，并推动模块化开发的广泛应用。

摘要由CSDN通过智能技术生成

osgi框架的应用

当我们开始使用OSGi时，就有机会为小型网络网关开发世界一流的框架。相比之下，今天的Raspberry Pi巨大。 16年后的今天，OSGi是市场上针对Java应用程序的主要模块化解决方案。我们认为，模块化解决方案对于每个复杂的Java应用程序都是不可避免的。就是说，一些博客表明，人们对OSGi有一些错误的信念。

OSGi是市场上唯一包含行业内地震波的解决方案，例如面向对象和控制/依赖注入的反转，同时还提供了下一个范式转换：面向服务的编程。不，这不是引起炒作的一种方式，不，面向服务的编程并不是OSGi中的事后思考。自1998年以来，真正的面向服务的系统（SOS）一直是OSGi的基石。（在SOA窃取了服务一词之后，我们开始将服务称为微服务。我们现在使用μservice，因为微服务已被广泛使用。较重的REST服务模型。）

尽管μservice模型是OSGi的最重要功能，但它也是采用过程中的最大挑战，因为它要求开发人员进行不同的思考。 Java，尤其是Java EE，使许多不良习惯流行起来。例如，从来没有打算将类加载用作扩展机制，并且API中的静态变量与全局变量具有相同的缺点：它们都创建了令人讨厌的上下文和单例问题。不幸的是，Java没有提供更强大的扩展模型，该扩展模型不允许使用（可重用）模块构建应用程序。 OSGi确实为模块化提供了一种可靠的解决方案。但是，由于避免了Java中反模块化的不良习惯，因此很难与主流Java开发人员建立联系。也就是说，只有当这些开发人员陷入软件沼泽的深处，以至于OSGi不可避免时，解决方案才最终被理解。

OSGiμservice模型是一种范式转变

范式转换的最大问题是，观众通常对新范式的优势视而不见。 Flatland是一本关于不同维度生活的书，精美地描绘了这一点。它解释了生活在直线陆上的点如何无法构想平面，以及飞机如何无法构想球体。在思考第4（或第5）维度时，我们如何迷失自我。我们可以理性地理解这一点，可以计算成千上万的维度，但是我们永远不会“感觉”到我们缺乏深入经验的东西。例如，在Sun Java问题跟踪器中，有人要求提供Multi Map，这是Java collections API中令人惊讶的空白。 Sun终止了此问题，因为作者从未感觉到这种需要（与许多被忽视的支持者不同）。同样，作为一个古老的Smalltalker，有趣的是，过去几年中有关在Java中添加lambda的讨论很有趣。许多开发人员对此表示怀疑，但几年后，这些相同的开发人员将无法再想象没有lambda的世界。如果我们仅谈论在愤怒中实际实践的技术，那么世界将是一个安静的地方。

因此，在OSGi联盟中，我们在软件方面有了新的奇妙之处，但发现它确实很难卖。也就是说，只有当有人体验到这种好处时，他们才会生气，问我们为什么没有人这么早告诉他们！然后，他们通常会写出第1023次被误解的OSGi“ Hello World”博客。作为上个世纪面向对象技术的推销员，这是一种奇怪的似曾相识的感觉。是的，曾经有一段时间，业界对物体非常怀疑。

那么OSGi有何特别之处？

让我们简短浏览一下我们最近的历史，以提供一些背景信息。

在OSGi中，当您创建组件时，您将创建一个充当μservice的类，并将其依赖关系表示为μservices。例如，以下代码显示了提供Speakμservice的组件

public interface Speak { void say(String text); }

    @Component
    public class SpeakLogImpl implements Speak {

        Logger logger;

        public void say(String text) {

          logger.info(text);
        }

@Reference
        void setLog( Logger log) { this.logger = log; }
   }

这通常是第一次攻击发生的地方，因为第一React很可能是：“为什么不使用CDI的@Inject？” 好吧，新尺寸的问题在于，视觉效果远不止于此。首先，尽管此组件在此处不可见，但实际上它是完全动态的，并且在处理并发性之前和之后都有很多保证。例如，仅在记录器服务注册后才注册语音服务。

还请参见： OSGi的简要介绍

谁使用Speakμservice，记录仪从哪里来？这与我们创建的组件无关。该组件已表达了其功能（记录器服务）得到满足时提供的功能（Speakμservice）。部署者/组装者的任务是创建一个需求和功能相匹配的环境。由于该组件忽略了所有这些细节，因此它可以并且应该仅专注于其域功能（在我们的示例中可以说是微不足道的）。

在此示例中，我们可以忽略动态因素，因为系统将在满足依赖项时激活SpeakLogImpl实例，并在依赖项消失后将其停用。该实例并不真正了解其生命周期，但在动态环境中的行为确实正确。这有点像吃蛋糕也要吃！

动态的事实使人们感到恐惧，但这就像您生活在3D世界中时害怕时间。现实世界中的事情确实会发生变化，因此我们倾向于使用领域特定的代码来处理这些动态变化。有了μservice原语，我们就拥有了出色的通用基础，可以处理大量生命周期，初始化，排序，故障和更改方案，而无需或几乎没有域专用代码。结果是基于μservice的系统往往非常健壮和可靠。

在分布式系统中，使用μservice动态的最杰出的例子之一。由于组件在不声明谁可以使用该服务的情况下注册了服务，因此任何其他组件都可以观察到该注册。因此，根据服务的特征（和授权），可以将这样的服务注册为通信端点，并可以通过网络服务发现层使用。然后，另一个OSGi系统可以提取此服务并注册本地代理μservice。由于服务是动态的，因此当通信中断或原始服务的提供者决定注销该服务时，我们可能会正确处理此情况，这可能是因为该服务已停止或不再满足其依赖关系。使用此模型进行编程的任何人都喜欢它，因为它在处理各种故障案例时都非常简单，而且其外观优雅。

在示例中不可见的第二部分是配置。通过OSGi Configuration Adminμservice，可以动态实时地定义一个或多个Speakμservice实例，所有实例都具有不同的配置属性。

也许对您来说听起来并不多（我在八十年代解释对象时收到了很多React），但是我可以确保您在总体上降低了系统的复杂性。降低复杂性的关键原因是μ服务模型对这些μ服务的API的影响。由于这些API不必关心生命周期，动态性，初始化，配置以及与它们的域无关的许多其他细节，因此它们往往变得越来越大，越来越小，越来越简单。

在OSGi中，μservice的API唯一需要关注的是协作，因为可以解决配置和生命周期问题。如果组件是参与者，则服务就是它们所扮演的角色。 μserviceAPI描述了这些角色之间的协作，就像剧本一样。因此，μserviceAPI不仅是一个接口，因为一般而言，我们需要定义多个角色，即接口。例如，在Event Adminμservice规范中，我们具有Event Handler和Event Admin的角色。因此，在Java包中指定了μserviceAPI。然后，此程序包还可以包含帮助程序类，例如Event Adminμservice中的Event对象。包中定义的良好的μserviceAPI具有很强的凝聚力，并且不会与其他API耦合。

组件需要部署在运行时环境中，这是通过捆绑包完成的。捆绑包在JAR文件中包含类，资源和元数据。捆绑包在运行时得到修复。也就是说，组件可以监视包，并根据该包中的信息扩展这些包。例如，在OSGi enRoute中，有一个Web服务器扩展程序，可将分发包的“ / static”目录的内容映射到当前Web服务器，同时提供缓存管理和高级HTTP功能（如（缓存的）压缩和范围）。这种模式称为扩展器模型，是OSGi中最受欢迎的模式之一。

模块化

捆绑包是模块。模块之所以起作用，是因为它们提供了围栏：创建了私人空间和公共空间。由于减少了运动部件，因此降低了总体复杂性。模块化是相当普遍认可和实践的。 OSGi模块化与传统Java的不同之处在于其依赖关系模型。我们从使用面向对象的技术中学到，直接依赖于其他类并不是一个好主意。它创建的系统类似于头发中的泡泡糖：非常粘。 Java的创新之处在于，它添加了接口来打破可传递类型的依赖关系，这些依赖关系导致了90年代许多面向对象的项目被杀死或瘫痪。接口打破了可传递类型的依赖性，因为实现者和用户都依赖于同一接口，但是它们不再彼此依赖。现在，仅通过实现那些接口而无需拖拽其他用户/实现者，就可以在另一个上下文中重用该库。

如果您对这个问题有点陌生，那么您可能会想到Maven。 Maven使用完全相同的身份依赖模型，该模型因类而失败。尽管Maven确实没有下载Internet，人们下载了Internet，但这是直接模块身份依赖项与可传递性结合使用的结果，使模型如此渴望下载Internet。显然需要的是为模块提供什么Java接口提供给对象的东西。

在OSGi中，我们已经将该软件包用作模块的接口，因为它已经是μserviceAPI的单元。因此，捆绑包可以导出（提供）包，捆绑包可以导入（需要）包。如果捆绑包导入了软件包，则另一个捆绑包应导出该软件包。在此模型中，可能有许多捆绑包提供相同的软件包，这显然引发了一个问题：如何找到导出所需软件包的捆绑包？

使用Maven，如果您有存储库URL，组ID，工件ID和版本，则可以下载该工件。但是，您也被锁定在单个包中，就像需要实现类将您锁定一样。在OSGi中，您没有被锁定，并且包可以在广泛不同的上下文中重用，但是这样做的代价是需要额外的组装步骤才能运行。

随着时间的推移，我们了解到软件包实际上是通用功能模型的一个实例。现在，我们在功能方面定义了所有依赖关系，还允许用户定义功能。通过对这些功能进行语义版本控制，我们可以确保我们也可以检测到不兼容性。所有这些都可能使人们担心维护这些功能需要大量工作：我们可以向您保证，有一些工具可以从类文件中提取大部分功能，甚至还有可以生成必要元数据的注释。好处是捆绑包现在可以自我描述，我们可以利用工具从捆绑包中组装应用程序。

快进

随着时间的流逝，OSGi联盟为基于组件的系统奠定了坚实的基础，而μservice作为组件之间的链接。捆绑包是部署的单元，是自描述的，因此可以使用工具组装到应用程序中。坚实的基础是因为OSGi规范包含的令人惊讶的快捷方式很少，并且为确保互操作性而进行了充分的文档记录。很难为真正的软件工程组件模型构想更好的基础。

就是说，我们了解到我们没有适当关注应用程序开发人员。我们专注于规范实现者。我们基本上告诉应用程序开发人员，他们现在有一个梦幻般的Lego盒子，其余的必须自己弄清楚。如果他们做不到，那是他们自己的错。

我认为失败的另一个方面是我们在OSGi Enterprise规范中指定的某些服务的API设计。这些规范中的大多数是派生的，或者与相应的Java EE API相同。尽管我确实理解其原因，但是Java EE API具有大量的关注者和许多实现，但我认为这是一个错误。由于不得不重用为另一个世界开发的API，因此很难利用OSGi提供的独特功能。结果是过多的me-too规范，将落后于原始规范，并产生令人讨厌的偏差，并且根据定义，几乎没有可用的实现。话虽如此，无数的公司正在使用它，听到人们正在使用该技术的令人惊讶的地方总是令人心动。

还请参见：在OSGi环境中使用JPA

但是，我们确实相信拥有适当的OSGi API是值得的。我们实际上认为，使用适当的API可以提高生产率，以至于我们可以说服许多主流开发人员在他们淹死之前就朝我们的方向前进。

显然，这不是一件容易的事，与主流竞争通常是一场失败的斗争（除非这并非绝对）。一个大问题是如何获得实现，因为大多数开源项目都集中在Java EE或SE上。幸运的是，经验表明，由于OSGi API往往要小得多，因此通常不难使用现有的（开放源代码）实现，因为从视图中隐藏了令人惊讶的大量实现细节。只需将所有类（通常是依赖项）放在一个包中，而不导出其中的任何一个，而只是小型协作API。这是看起来很陡的曲线，但实际上并不能真正提供OSGi的好处和模块化的优点。

为什么选择OSGi enRoute？

渴望拥有真正的OSGi服务并向世界展示OSGi的功能是OSGi联盟启动OSGi enRoute项目的原因。愿景是创造一个开放的

100％以OSGi方式完成的OSGi应用程序的源环境。利用OSGi的优点，并为OSGi所缺少的内容进行开发，并在可能的情况下与现有的开源基金会合作。 OSGi enRoute项目试图提供一站式服务，其中包括最佳实践，完整的工具链，配置文件，文档，教程和运行时分发。使用OSGi enRoute，您可以在几分钟内启动并运行带有REST后端的Web应用程序项目（好的，不包括下载时间）。

什么是OSGi enRoute？

工具链已完成。它提供了一个IDE（基于Eclipse的Bndtools），在Travis上的持续集成（带有bnd的Gradle），与GitHub的集成以及一个索引Maven Central工件以及一个名为JPM4J的存储库。可以将在IDE中创建的项目推送到GitHub，并自动在Travis上构建，而无需付出额外的努力。

Bndtools是首要的OSGi开发环境。 OSGi enRoute在GitHub上提供了一个基本的工作区模板，并为API，API的提供者，测试包和Web应用程序创建了不同的项目类型。该Web应用程序创建一个显示Bootstrap / Angular用户界面和REST后端的小型应用程序。 Bndtools提供了一个非常短的开发周期，介于保存操作和一个新的网页之间，该网页演示了对某些Javascript的修改或对后端REST服务器的调用。所有这些都不影响保真度。由于工具链基于bnd，因此在发布之前会标记错误和不良做法。它甚至集成了基准，持续将当前API与以前的版本进行比较，并在您违反语义版本时对其进行标记。而且，当您准备发布时，可以发布到多个存储库，或者仅在持续集成后才发布。（作为bnd的提交者，我显然有偏见，但是我还没有看到这样一种环境，不仅可以轻松开发OSGi和Java代码，还可以使用Javascript或其他网络语言进行开发。）

OSGi enRoute配置文件是一组服务API，扩展程序和Web资源。它们收集在仅是规范的JAR文件中。该JAR文件可以放在您的构建路径上，并允许您开发应用程序而无需供应商锁定。可以通过JPM存储库添加外部依赖项。

当前，OSGi enRoute基本配置文件包括以下服务：

org.osgi.service.cm –提供推拉模型来配置组件。
org.osgi.service.component –声明性服务组件的扩展程序。
org.osgi.service.coordinator –基于线程的请求的协调器，可以在请求结束时进行回调。
org.osgi.service.event –通用事件的简单发布和订阅机制。
org.osgi.service.http – HTTP服务器框架。
org.osgi.service.log –用于记录错误，警告和信息的服务。
org.osgi.service.metatype –一种描述数据结构的标准，旨在从中创建用户界面。
org.osgi.service.url –通过服务注册表注册URL处理程序的工具。
org.osgi.service.useradmin –一种服务，用于管理用户信息，例如组，凭据和常规属性。
org.osgi.util.promise –使用Promises进行异步处理的实用程序。
org.osgi.util.tracker –可靠地跟踪服务和捆绑的实用程序。
osgi.enroute.authentication.api –基于可变的用户凭证提供经过身份验证的ID。
osgi.enroute.authorization.api –通过提供基于当前用户的权限来授权应用程序执行其操作。
osgi.enroute.capabilities –在enRoute基本配置文件中找到的所有特定的非代码功能。
osgi.enroute.configurer.api –从捆绑软件获取配置信息的扩展器。
osgi.enroute.debug.api –用于调试的常量和帮助程序。

osgi.enroute.dto.api –支持将对象转换为其他对象或JSON。
osgi.enroute.jsonrpc.api –一种用于JSON RPC的白板方法。
osgi.enroute.launch.api –与启动器进行交互的API，包括访问启动参数。
osgi.enroute.logger.api –一种工具，不仅可以使用OSGi日志记录，还可以管理平台上的日志记录。
osgi.enroute.rest.api –提供基于方法命名模式的REST端点，类型安全使用有效载荷，参数和结果主体。
osgi.enroute.scheduler.api –提供基于时间的功能，例如延迟，（基于cron和周期的）计划以及Promises上的超时。

以下网络资源：

Angular Javascript
Angular UI Javascript
D3 Javascript
引导CSS
Pagedown Javascript Markdown编辑器

以下支持包：

一个Web服务器，用于服务于捆绑包中的静态资源。
从捆绑软件读取配置的配置器
OSGi Event Adminμservice到服务器的已发送事件（Javascript）桥

基本配置文件及其服务基于OSGi Core Release 6和Java 8。新的API充分利用了lambda。

工作流程

该配置文件足以制作复杂的Web应用程序。正在大力开发的是enRoute网站上的服务目录。该目录将成为当前缺少有关如何使用服务的手册。意图是每个服务都将具有一个附带的应用程序，该应用程序允许开发人员复制和粘贴使用模式并在调试器中使用该服务。

面向服务的系统由试图重用的包组成。即使是一次性的，也通常明智地进行开发，就好像它可能被重用一样，因为这样做确实会使开发阶段的生活变得更简单。定义适当的API，并确保仅导出API包。从存储库开发或选择组件之后，需要将它们打包到应用程序中。在经典环境中，创建该应用程序可能会很麻烦，因为它必须包含所有传递依赖项，并且在没有帮助的情况下，这可能会很麻烦。因此，Bndtools具有解决功能，可以帮助快速创建提供所有必要功能的捆绑包。

定义应用程序后，Bndtools将提供响应Swift的调试和测试环境。您创建一个bndrun文件，该文件指定诸如框架，属性等详细信息。可以启动和调试该bndrun文件。实际上，IDE中的所有更改都会立即生效。您几乎不必重新启动框架。

输出包装取决于目标环境。当前，默认情况下，我们将包含框架，属性和所有捆绑包的可执行JAR打包。 JAR可以在您有Java 8运行时的任何地方运行。但是，我们正在与IBM合作，使其也可以在IBM WebSphere Application Server Liberty Core上进行部署（和调试），并与Paremus一起在Paremus Service Fabric上进行部署。我们也正在研究Karaf Kars和其他人。任何其他目标也非常受欢迎。这些目标必须提供分布；发行版必须提供配置文件中定义的所有功能。

可在enroute.osgi.org上获得文档和教程（当前所有工作都集中在此处）。我们所做的一切都在GitHub上。如果要找出所有零件的位置，可以在《路线手册》中找到一个好的起点。

我们在哪？

那么，OSGi enRoute今天在哪里？我们基本上已经完成了功能，可以进行集成测试了。这意味着我们需要渴望并且愿意的早期采用者，他们愿意帮助OSGi enRoute进一步发展，并且可以承受一些障碍，跳跃和挑战。 1.0版的发布日期定于今年夏天，与计划的OSGi Enterprise Release 6发布日期保持一致，以便它可以包含一些必要的更新。

大多数出色的工作是编写文档，创建示例，制作教程以及对OSGi enRoute进行宣传。

尽管我们忘记了组装说明，但在OSGi enRoute上进行的工作已经清楚地表明，我们确实向世界提供了一个出色的Lego实心盒子。显然，OSGi模块化确实有效。它提供了一个复杂的依赖模型，可以从可重用组件中真正构建应用程序。但是，很显然，我们非常需要那些适当的OSGi服务来满足每个开发人员面临的常见任务。我们的方法太少了。 OSGi enRoute工作已经产生了十个OSGi提案请求（163-172），这是规范过程的第一步。

因此，如果您有兴趣成为那些早期采用者之一，或者您有时间帮助您，请随时与我联系。对于其余的部分，请注意，因为一旦我们完全投入使用，OSGi将会令人震惊！